Deltakosh

GPU particles

Recommended Posts

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

image.png

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 "

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?  :)

Share this post


Link to post
Share on other sites

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)

 

Share this post


Link to post
Share on other sites

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.  :D

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.