GPU particles

[GameMonetize]

Heya team!!

I'm proud to announce that the GPU particles feature is now available!

Documentation: http://doc.babylonjs.com/babylon101/particles#gpu-particles

Interactive demo: https://www.babylonjs-playground.com/#PU4WYI#2

Please note that this feature requires webGL2 or it will fallback to CPU particles

[Dad72]

super cool.

[jerome]

YYYYEEEESSSSSSS  !!!! 

[Wingnut]

Thx DK!  Nice work. 

Looks like customStartPosition and customUpdateFunction will be a bit more challenging. 

[jerome]

just can't stop playing

[NasimiAsl]

very Nice @Deltakosh

[Dad72]

Can we add an effect for with GPU particles? I see that the constructor GPUParticleSystem() does not allow it (after scene).

[Wingnut]

Hi Dad72.  Sorry if I'm interrupting.  https://www.babylonjs-playground.com/#4VZ6V9#1

See lines 23-37?  There is a renderEffect and an updateEffect.  (ignore that return in line 38.  That was a Wingnut experiment... before I learned I have no webGL2 browsers in my world.) 

Perhaps... this whole system is effect-driven. 

Ok, I'll shut up and let the experts comment, now.  heh.

[Dad72]

Look in the constructor settings, it is not the same

ParticleSystem();

GPUParticleSystem(); CustomEffect is not available

[Wingnut]

Yeah.  I don't think the two systems are precisely interchangeable.

In your BUGS post, you stated... "It says that we can go from one to the other"

Can I ask... where did you read that?

The closest I can find in the docs... " GPU particles can almost be used like regular particles "

[Dad72]

Here :

Fallback

As the GPUParticleSystem and the ParticleSystem share almost all their API, it is easy to switch from one to another if WebGL2 is not supported. But keep in mind that the CPU cannot animate as much particles as the GPU can. So you will probably have to reduce the capacity of your system in not using the GPU.

[Wingnut]

Ahh, *nod*... thx!

He might have been talking about this sequence of code:

        if (useGPUVersion && BABYLON.GPUParticleSystem.IsSupported) {
            ps = new BABYLON.GPUParticleSystem("particles", { capacity:100000 }, scene);
            ps.activeParticleCount = 20000;
            ps.emitRate = 1000;
        } else {
            ps = new BABYLON.ParticleSystem("particles", 50000 , scene);
            ps.emitRate = 1000;
        }

(from my gpu pg, not his, but almost same code) Perhaps he was not talking-about "live" switching.  Maybe only pre-construction switching, based-upon isSupported.  Let's go knock on his door in Seattle and ask him... and steal some of his morning coffee.    Maybe he will cook pancakes for us.

[Dad72]

For me the particles should react in the same way that they are calculated by the CPU or the GPU. The settings should not have to be changed for either.

If WebGL2 does not support it uses ParticleSystem with the same parameters, but will not react the same anymore and the difference is quite huge. If the difference was slight, it would be fine, but right now it seems to me a very big difference.

I hope DK can fix that.

[Guest]

This is not in my todo list as this is a complex work

Custom shader or functions are not supporting for now:

- Custom functions: because there is no JS code at all and all code is in the shaders

- Custom shader: that's something I can tackle in the future but it won't be the same shader as for CPu particles as they are not working the same way

I will precise it in the documentation

[Wingnut]

Ahh, Dad72 wants "visually indistinguishable" (when both systems have same settings).  I can understand why that is desired.

This is an interesting dilemma.   Dad72 (and maybe others) are looking for a near-perfect copy of standardParticles API... but with GPU-driven under-belly.

A hybrid!  Half one thing, half the other.

Would that be called "glue code"?    Or... a backward-compatibility wrapper?  I dunno.  Didn't I say I was going to shut up?

Actually, I'm  glad that we have ANY GPU particles AT ALL.  That's SO NEW and cool.  vrroooom!

Hey Dad72... I will help investigate where/how they are compatible, and where/how they are lots different., if wanted. 

We could find the #1 biggest difference, and see if we can "glue-code" that, then #2 biggest difference, glue-code that, if possible, etc.  We might be able to build a "middleware layer" between old and new.  I'll help, but... those render and update shaders... I bet they are tumor-causing. 

Ok, I'm REALLY going to shut up, now.  What browsers are you guys running?  Chrome?  I use adblockers, so I have to stay back pre Firefox Quantum, to keep those working.  Currently using FF 52.6 (called ESR).  And my IE won't do them, either.  I guess I need fresh browser.   

Did I shut up yet? 

[Guest]

This should be the case actually if you don't use custom functions or shaders

I had a bug in the previous version but it is fixed now

Look here:   https://www.babylonjs-playground.com/#9C9ACJ#2 (CPU)

and there: https://www.babylonjs-playground.com/#9C9ACJ#3 (GPU)

 

[Dad72]

Yes, that's exactly what I thought. Works good now. Thank you DK

[HoloLite]

Is this in alpha 8? When will it be pushed to npm? Thanks 

[Guest]

We should push this Friday (cc @RaananW

[waverider]

@Wingnut  

console.log('hello hijack');

 

haha, i usually find it so funny when developers put funny logs in their script

[Wingnut]

Yeah, that's a little notification to make sure the in-playground code (hijacked code - hijacked from BJS src) is running, instead-of the framework code.  (checking to make sure my "over-ride" is being called)  *nod*  (You probably knew that already, sorry).

We're pretty far off-topic in this important thread, though.  (Wingnut-caused)    I can't wait to see these new GPUparticles... but I still need a browser that shows them.

But I can't do sparkly GPUparticles, yet, even if I COULD see these demos.  I would need to learn to hack the update shader for GPUParticles.  I'll figure out how.  Sparkly particles cannot be held-back.   Faerie dust is much too important to ignore.