Particle System C# Job System support

[richardkettlewell]

I’ve just released a new version with the following improvements:

• Support passing a JobHandle to the Particle System Schedule function, in case the particle job has prior dependencies
• Fix job scheduling to ensure jobs are kicked off immediately, rather than not being processed until their results are needed (gives much better performance)

Still waiting for the Burst fix… it sounds like it’s going to be a fix in the Burst package.

[richardkettlewell]

There is another new version out, with a fix for errors when trying to pass custom containers (eg NativeArray) to a particle job. Plus we added support for the safety system, which provides you with errors when you (for example) try to write to invalid indices from a ParallelFor job.

[richardkettlewell]

Hey all, this feature has been released in the forthcoming 2019.3.0a9 build! You are welcome to continue posting feedback in this forum, and also in the 2019.3 alpha/beta forum if you prefer.

[snacktime]

Forgive my ignorance here. So is the basic idea to get the best performance use the api to set custom particle data, manipulate it via jobs, and disable all of the associated particle system component options?

[richardkettlewell]

@snacktime

Forgive my ignorance here. So is the basic idea to get the best performance use the api to set custom particle data, manipulate it via jobs, and disable all of the associated particle system component options?

Hey

The idea is to be able to modify all particle data in a much faster way than with the old ParticleSystem.GetParticles and ParticleSystem.SetParticles APIs.

You can modify any of the data (position, velocity etc), or, as you say, you can also setup and manipulate custom particle data.

You might be able to get faster performance than the built-in components by re-writing them in jobs (eg Velocity over Lifetime, etc) but we haven’t tested this, and it’s probably not a good use of your time - I would expect the differences to be quite small. The real power of this feature is to write custom code for your particle systems that is not possible via the built-in components.

[TeotiGraphix_1]

This is interesting, I just happened on this and probably will try it with a visualizer I am making using particles.

[recursive]

@richardkettlewell - Is there an ECS launch point for particle system Jobs or is it just the MonoBehaviour callback for the time being?

[richardkettlewell]

@recursive

@richardkettlewell - Is there an ECS launch point for particle system Jobs or is it just the MonoBehaviour callback for the time being?

Hey, there are no plans at the moment for an ECS hookup with the particle jobs.

[recursive]

Hybrid it is then, just wanted confirmation. Thanks for the quick response!

[TeotiGraphix_1]

This is great, I am just finishing up my engine code and I can actually give performance numbers from before and after as well, can’t wait to try this in my framework.

[richardkettlewell]

@TeotiGraphix_1

and I can actually give performance numbers from before and after as well,

I’d love to hear your numbers for the particle jobs if you are happy to share them! Remember to use [BurstCompile] on your jobs!

[system]

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

[richardkettlewell]

Is this feature automatically activated for Unity 2019.3.0a9+?

Yes

Also, do you have any plans on developing particle systems for ECS?

No plans; it probably won’t happen for the current Particle System.

[Neto_Kokku]

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

[richardkettlewell]

@Neto_Kokku

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

If you have more than one particle system to update, they should run in parallel (unless it’s a sub-emitter) Indeed for the singular case it’s sub-optimal.

[mitaywalle]

@richardkettlewell

If you have more than one particle system to update, they should run in parallel (unless it’s a sub-emitter) Indeed for the singular case it’s sub-optimal.

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

[richardkettlewell]

@mitaywalle

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

It’s shipping in 2019.3 can use the final version in any recent beta version.

An experimental version exists in 2019.1 and 2019.2 but we made breaking changes for 2019.3, so best to start there if possible. Who knows, maybe it’ll make it out of beta soon…

[mitaywalle]

@richardkettlewell

It’s shipping in 2019.3 can use the final version in any recent beta version.

An experimental version exists in 2019.1 and 2019.2 but we made breaking changes for 2019.3, so best to start there if possible. Who knows, maybe it’ll make it out of beta soon…

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

[Opeth001]

Hello Everyone

sorry if my Question looks stupid :p, 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!

[mitaywalle]

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?