Feedback Particle System C# Job System support

Is this feature automatically activated for Unity 2019.3.0a9+?
Also, do you have any plans on developing particle systems for ECS?

 

What is even the point of running the particles on another thread if the main thread sits idle waiting for it to finish?

 

Hello!
Where and when Particle System Jobs would be available in public build?

 

Found your similar answer in some PS-Jobs thread (^ thank you for clarifications! Unfortunatly, I'd can not use PS-Jobs in production, 'cause 2019.3 would realy non-production ready and migration would be painful, but we're shipping in march 2020 Would experiment with it. Planning to replicate Legacy Lens Flare System with it

 

Hello Everyone

sorry if my Question looks stupid , but what's the benefits of using the IJobParticleSystem knowing that sadly there is no way to complement it with ECS ?
1) is it only for Complexe Particale systems and used to free the main thread by running everything in worker threads ?
2) is it worth using it even for simple particle systems ?

Thanks in advance!

 

I've few more questions:
- IJobParticleSystemParallelFor is not IJobParallelFor ? This mean, that I can't combinate it with other IJobParallelFor?
- Somewhere you've write that PS-Jobs should be Scheduled int MonoBehaviour callback
OnParticleUpdateJobScheduled. But where it can be created,in MonoBehaviour.Update? FixedUpdate, [UpdateBefore(typeof(Update)]ComponentSystem.OnUpdate?

 

Although we've not got particles working in Jobs yet, in one of our assets, Sci-Fi Ship Controller, we have ECS working with MonoBehaviours. Our main ship physics etc code runs as a monobehaviour and there is an option to run projectiles through our weapons system as Entities (updated in parallel with Jobs). If ECS / DOTS is enabled, we also do ray casting in a job.

Recently we've got some interaction working with the new DOTS-based Unity Physics too. So, it is definitely possible - although not that obvious how it should work together.

As tools developers, we took this approach because we figured for the foreseeable future people would want to combine monobehaviours (which everyone knows) and DOTS / ECS.

Certainly having the option of running some of our particle systems with DOTS is appealing - although we understand they are very different from what we currently think of in terms of particles.

 

Thanks for clarifications! Would continue to experiment

 

I am really glad that we have this feature in Unity. It allows us to do far more particles

I was wondering, is there a way to turn off the simulation altogether and manipulate the aliveTimePercent, position, velocity, etc. ourselves?
We would want the aliveTimePercent to be used for curves like ColorOverLifetime and ShapeOverLifeTime, but the lifetime of our particles cannot be determined a priori.
I.e. we may want to start at 0, loop back to 25 when we hit 75, and jump to 75.001 when an event happens and kill the particle at 100.
Or in some cases, when the event occurs lerp from the current percent to 100 in a fixed period of time. (i.e. for a fade-out)
It is also important that we can set the position and velocity and not have the position automatically updated by the velocity.

Thanks!

Tangent:
Now if only we could get mesh instancing to work with our SRP so that we could get away from sprites and still have the render thread keep up with the particles that the CPU can simulate)

Tangent 2:
Somewhere it was mentioned that using percent had better precision than 0..1.
How is that possible? Isn't it the other way around? 100 is not a power of two, you cannot divide without losing precision.

 

I love physics and it is awesome to be able to write "Physically inspired" simulations of particles that run entirely in a background thread on code compiled with Burst.
Setting playback speed works, thanks a lot!

One issue: It appears that if I access rotationalSpeeds I get three nulls.
I have been able to work around it by updating the rotation myself, but I thought that I would mention it.
Ideally, we could use quaternions (three elements, leaving out w and inverting if negative) and/or a more traditional angular velocity vector or possibly angular momentum (which is constant even with varying principal axes of inertia), but that is low priority.

 

That makes sense, thanks!
It is fine as it is, no sense in adding extra overhead or complexity if it can get it so easily.
I would just add comments to let people know.
Best,

 

To clarify, if simulation speed goes below a certain threshold (0.001) OnParticleUpdateJobScheduled() is still called but the job never runs.
Using 0.001 is "good enough" but it would be a nice extra to have less execution overhead when it is effectively zero.

 

We are doing CFD simulation for water in a SandBox type game. The goal is to enable two-way interactivity between the water and general physical objects (i.e. players, the environment, ais, etc), through a robust simulation.
We don't use open-loop, techniques such as recomputed playback, noise, or procedurals, as these techniques are difficult to make interactive.

The Basic system is eulerian (i.e. a sparse 2d grid modeling the height, velocity, temperature, and pressure of the water at staggered sample points). This is great for high performance, low-frequency simulation.

TLDR: In order to visualize the high-frequency properties of the water (such, splashes, foam, high-frequency ripples, etc) we use particles. We define the model through the particles in question, emit them as appropriate and simulate them based on the environment and the surface and velocity of the water.
For example, we also simulate things like debris using particles with a simple buoyancy model.

We considered using sparse 3d grid structures and hierarchical grid schemes, but in the worst case (which will always turn up when the player gets their hands on the controls) these methods get very ugly very fast.

 

Unity3d 2019.3.9f1

When I inherit from IJobParticleSystemParallelFor
I'm missing job.Schedule(ParticleSystem)

Should I include some special extension ?

 

OK I have found the problem.
The only thing that makes me a little less ashamed of myself are misleading error and the fact that you have not found error in my post .
Basically for IJobParticleSystemParallelFor we have to use job.Schedule(ParticleSystem,int) or else it will give use error that it cannot convert from ParticleSystem to JobHandle.

 

@richardkettlewell I've been playing around with the ParticleSystem jobs and they are really great! One thing I'd like to be able to do is kind of a post-process pass on the particles but am having a tough time with it. Basically the idea is akin to a vertex shader that operates on the particle itself (so it affects rendering/bounds/billboarding etc) but doesn't affect the underlying sim.

My thought is that the best way to do it would be to cache some things in custom data, but even that doesn't seem like it gets me exactly where I want because the job always runs after the native particle update. What I'd like to do seems like it might need to run one job before the native update, and then another job after. Something like -

Remove render offsets from last frame stored in custom data
Run native simulation
Add render offsets for this frame, store in custom data

Do you have any thoughts on other ways this could be accomplished?

 

Hello, I've same problem as koirat, Schedule(ParticleSystem,int) is not found, but my Unity 2019.2.2f1 version. Can I use ParticlesJobs at this version?
richardkettlewell

EDIT: found, at this version I should use ParticleSystem.SetJob(job)

 

Thanks for fast answer. Shuriken is amazing with all this new stuff thanks for your work

 

The reason not to use a vertex shader would be to leverage the internal particle functionality, like the way the particle system updates its local bounds, billboards to the camera, can have trails following, etc. But I understand it's not how the job system was designed.

 

Cool, thanks for your answer!

 

Hey!

Is there a way to draw a line to connect two particles? I got how to manipulate all the particles with IJobParticleSystemParallelFor, but I need to connect them with a LineRenderer (maybe a prefab). Without a JobSystem it's easy, but not very performant if we have more thousand particles.
Is there a way to achieve this? Pass a LineRenderer data to a native array or something?
The benefit would be here if we can iterate all particle, make calculations then put the position[0] and [1] back to LR to connect two particles. But can I access a LineRenderer object in a job thread?

 

Thanks sir, I appreciate it. I'll definitely make some experiment and report back here.

 

Are the particle jobs supported on mobile yet? I just tested running my particle jobs (IJobParticleSystemParallelFor) in an Android build and it crashes immediately upon emitting. Is there any way to debug this on my end? I am using Unity 2020.1f1.

 

Thanks, sadly I've already tried removing Burst entirely, I think the issue is somewhere else as it crashes exactly upon emission still. There's actually no information thrown back onto Unity that helps me debug this so I wonder if there are any tools I might be missing here. I've tried the LogCat browser but it too does not give me any stacktrace at all. I might try going with a simpler particle test or use a different job type and see if I can find what's causing this. It works just fine in the editor and in Windows builds.

 

@richardkettlewell Hi. Can I change mesh index of particle in particle jobs?

Normal Particle struct has SetMeshIndex() method, but it seems that there is no such a method for ParticleSystemJobData. My purpose is imitating mesh version of sheet-animation, so I need to change mesh index by particle's elapsed time.

 

Sure. I reported as Case 1312288. I hope that APIs will be available in 2020.x cycles.

 

One big issue I'm having with trying to write completely custom behavior inside of a particle system job has to do with the fact that there is no built-in conversion from quaternions to euler in radians in the Mathematics library.

Code (CSharp):

1. public void Execute(ParticleSystemJobData particles) {
2.     var rotations = particles.rotations;
3.    
4.     for (int i = 0; i < particles.count; i++) {
5.         // rotations[i] = ...
6.     }
7. }

This makes it difficult to perform basic operations with the output of the Mathematics library such as quaternion.LookRotation or really any time you've built a new rotation as a quaternion. We have helper functions to create quaternions such as quaternion.EulerXYZ(), but when it comes time to set a new value for a particle's rotation it's expecting to see an Euler vector in radians again.
I haven't seen anyone post any examples of code anywhere which is setting a new value for a particle's rotation, so I'm not sure if there is even a precedent at the intersection of these two APIs (particle system job and Mathematics).

 

Hi,
I just ran into a performance issue using classical ParticleSystem as it is shipped with 2020.3. Just looking into what is the best way to apply Jobs and Burst Compiler to help me.

My goal is to simulate a printer, spitting droplets (particles) from the print head to the paper.
For that I need to emit a defined amount of particles at once and providing each of them an individual specific position and velocity. When the particle reaches the substrate, a collision is triggered and so I update the texture of the substrate. Livetime at collision is set to Zero.

The demo is working fine using the conventional ParticleSystem. But I am running into some performance issues.

1st: I suspect losing a lot of time by calling ps.Emit for each droplet individually.

Code (CSharp):

1.  
2. for (int i = phase; i < nozzelCount-phases+phase; i+=phases)
3. {
4.     if (nozzleData[i] == true) {
5.       psParams.position = transform.TransformPoint(nozzlePos[i]);
6.       psParams.velocity = dropletVelocity + rb.GetPointVelocity(psParams.position);
7.       ps.Emit(psParams, 1);
8.    }
9. }
10.  

2nd: I have 4 printheads, each having it's own particle system. So I would like to run the Emit and Collision task (private void OnParticleCollision(GameObject other)) in parallel using the jobs system, too.


Questions:
1. What is the most performant way to emit multiple particles, with individually defined velocity and position?
2. The ParticleSystemJobData just provides access to particles that are alive. Is it possible to access the allocated data structure of the particle system from the job bejond "count". I would like to reuse old, exisiting, but inactive (aliveTimePercent <= 0.00) particles. Instead of adding new new particles, I want to take dead ones, reset with a aliveTimePercent = 1.00 defining new position and velocity. Anything I need to consider regarding the order of theparticles in the system?

Many thanks for your support!

 

Sounds good. Will do as suggested. Any assumption I can make about where to find the new, recently emitted, particles? Are they at the top or the end of the list? Knowing that could avoid parsing through the entire list just to update 10% of the particles I am interested in.

Also on the scheduling of UpdateParticlesJob. I need to emit the particles from fixedUpdate(). In your examples the jobs is scheduled from OnParticleUpdateJobScheduled(). Is it save to call job.Schedule(ps) from FixedUpdate()?