GPU powered particles

General Discussion
1

Godot seems to do this on GPU:

JME does it in CPU with the ParticleControl and stuff? Right? Just thought that an interesting topic, perhaps. Something to mimic or not?

2 Likes
2

Funny, I was thinking about having a crack at GPU powered particles this week.

1 Like
3

Godots new stuff looks really cool. Shouldn’t be hard to do? Might play with it

1 Like
4

I’ve done what I’d call pseudo-particles on the GPU before. When the paths of the particles are predictable then it’s easier to simulate… even if some are not always on. (For example, I’ve used it for flame particles in the old mythruna and in the waterfalls I was working on for a different game.)

It would be interesting if someone poked around to see what their approach is.

Waterfall made of large billboard pseudo particles… 100% GPU:

2 Likes
5

When I introduced OpenCL support to jme last year, I also started on some utilities that should show the power of the new system.
It includes a simple fluid solver and a very flexible and powerful particle system.
Try it out:

2 Likes
6

The link provided earlier seemed to indicate that this would allow particles to run efficiently on older cards and stuff. That made me wonder if it was using OpenCL or something else… as I wasn’t sure how well older cards would run OpenCL.

7

That waterfall looks really cool! 100% GPU you say? What’s the process behind it?

So I’d imagine first making a bunch of quads in a line separated by one unit or something…then in vert move them with a 3D function that resembles a waterfall along with time (scale+outward and down movement?). I guess the randomness could be from the starting mesh.

I’m not exactly sure how one would differentiate individual quads when you only have a single vertex to work with though (or do you even need to?), and how would you move them back to the top, maybe using modulus and scaling them just based on height?

And in the end vector product bilboarding? Sounds like all the advanced stuff mashed together :smile:

I kinda feel like the fill rate problems would outweigh the entire no-cpu optimization part though, so it’s not like it’s cpu bottlenecked in any case.

8

Basically a line of billboard quads… so each vertex is at one position (the center) and is projected out from there based on camera angle. Lighting is mixed in, too.

Along with the vertex information is a vector and length along which the quad will travel based on time… it just wraps over and over. So each part is a segment. Shorter segments = more dense waterfall. When a quad reaches the end of its segment then the next segment is back at its own beginning and so looks like the quad keeps going.

If your paths are predictable then you can easily encode a particle effect like this in a relatively small mesh. (Even if it’s not predictable but relatively stable, you could do it, too.)

The fill rate issues would be the same with our without CPU involvement. A bunch of semi-transparent quad particles are going to be a fill problem no matter what is positioning the buffers. This is nice because it is “fire and forget”.

1 Like
9

I read it as it is possible to run the particle system on the legacy cpu on old systems and mobiles, and/or on modern gpus.
IMHO the first point where using the gpu is an option for a more complex particle system is OpenCL 1.1 or Transform Feedback (GL30) (Middle of 2008). Not sure about GLES support.

But as you showed, highly specialized gpu particles can be implemented to work on any system

10

PS. This is how the simple OpenCL particle test looks like:

OpenCL-Particles.png1600Ă—926 134 KB

2 Likes
11

Hmm this gets me thinkin, can idea be extended to supporting GPU Powered Physics?

12

That’s something I’ve been considering for some time. With OpenCL, yes, you could do fully GPU powered physics… the trouble as I see it is the shear amount of work that goes into a full-featured physics engine like Bullet. I think in practice it would be pretty difficult to develop a full-featured physics engine in OpenCL.

EDIT: Note that Bullet already has a fully GPU accelerated rigid body pipeline written in OpenCL.

13

You wouldn’t need this though, may features like rigid bodies and joints would not be needed, only point vs hull collision really. And in the interest of speed, that could be partially faked on the GPU using a scene reconstructed from the depth buffer… interesting…

14

Oh, you mean for particle physics… as soon as I saw GPU physics I started thinking Bullet-type functionality. For years I’ve been interested in seeing full GPU acceleration for a physics engine like that. :stuck_out_tongue:

Yeah, for particle physics it’s much simpler.

15

Ok its done! :stuck_out_tongue:

blob.jpg1035Ă—799 162 KB

16

Do you mean something like this?
http://www.sebastian-weiss.eu/programming/bachelors-thesis-voxel-erosion/
In my bachelor thesis I implemented a full SPH simulation in OpenCL.

You can do a lot in OpenCL. The problems start when you want the information back on the CPU in the current frame. Then it becomes pretty slow.
This would be needed in a physics engine for jme: you can resolve all the collisions and transformations in OpenCL, but then you need to transfer the computed transformations back to the CPU memory and update the scene graph. Otherwise, frustum culling, light culling and so on will be difficult.

4 Likes