• Advertisement
Sign in to follow this  

Cpu/Gpu particle idea

This topic is 2316 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm having an idea for particles on both the cpu and the gpu. This includes two steps:

- Calculating the particles position on cpu side, using complex physics like particle hygrodynamics.

- Then lock a floating point texure, store positions in there, and use that texture in combination with eigther rotation component as shader constant for billboards or pointsprites as well as the ViewProjection-matrix to construct the final WorldViewProjection-matrix in the vertexshader.

Is this a suitable solution? Should I re-locate any of these calculations to eigther cpu/gpu? I need a complex physics simulation so I can't simply update positions in the shader. Will this method perform well in combination with instancing? I'm considering this because my current implementation constructing a WVP-matrix per frame for every particle and writing it to the instance-buffer is performing bad with like 10.000 or more. I want to go for ~ 500.000 on high quality settings on a modern cpu without bottlenecking my game. Is this possible with my suggestion? Will it even work the way I think? I can't write it till saturday, so I want to collect and plan out some ideas..

Share this post


Link to post
Share on other sites
Advertisement
I suggest you do it all on the GPU using something like a Compute Shader or a Vertex Shader to do the physics and stream to a buffer which can then be passed to a shader to be rendered. Passing such large buffers between CPU and GPU is always going to be a major bottleneck.

Share this post


Link to post
Share on other sites
Thanks for the suggestions, however currently I'm stuck with directx 9 so a compute shader isn't going to work well.

Using a vertex shader is an option, but would it really work well? I need to store speed, velocity, multiple force fields with different shapes.. Wouldn't this mean having to perform many tex2d reads per frame for each particle? I'm already having a huge fillrate-consumation due to many effects (shaodws, ssao, atmo-scattering, hdr..). I think that locking, filling and u locking an, say 1024x1024 (1 mio particles) texture per frame while calculating physics on the cpu should be faster. Am I wrong?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement