Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPU Instanced Particles #62

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

mhQuake
Copy link

@mhQuake mhQuake commented Mar 28, 2022

Proposed modifications to the particle system; modernizes particle rendering by using hardware instancing and performing particle billboarding on the GPU, in addition to some other quality-of-life improvements. Feel free to accept or reject as much or as little of this as you see fit. :)

Full features list:

  • Framerate-independent particle physics (accurately replicates classic Quake particle physics but in a framerate-independent manner).
  • Unlimited (except by memory) number of particles dynamically allocated at runtime (useful for pointfiles, but even the ID1 timedemos overflow the default max of 2048).
  • Correctly handles cases of particles that last forever.
  • Correctly handles cases of particles that only last one frame.
  • Restores r_particles 3 option (as new default).
  • Performs particle scaling and billboarding entirely on the GPU for added performance.
  • Reduced upload bandwidth requirement.
  • Reduced particle fillrate overheads by drawing as quads (tristrips, actually) instead of triangles.

@andrei-drexler
Copy link
Owner

Hey, sorry, I keep meaning to go over this, but reviewing/testing so many changes in a monolithic commit just for particles always seems so daunting, I keep bouncing back to other things that might make more of an impact. For now, I've pushed 8f72553 based on your code (with the billboarding performed directly in clip space, though), increased the default particle limit to 16k (same as in vkQuake) and factored out particle allocation, which will make it easier to test at some point to what extent my main gripe with the particle code - the fact that it uses a linked list, which interferes with out-of-order execution - actually affects performance.

@mhQuake
Copy link
Author

mhQuake commented May 11, 2022

The linked list is a pain.

I've been meaning to write up something that treats each particle emitter (explosion, teleport splash, etc) as it's own batch, sorted by die time, and just draw the number of particles in each emitter that would still be alive in one draw call. That would enable much of the data to become static as well (the emitter origin could be pushed as a uniform). Something like the old system would be retained for more dynamic particle types, such as trails.

Just never got around to it, but some day...

@mhQuake
Copy link
Author

mhQuake commented May 11, 2022

Overall though I feel that fillrate is probably the biggest bottleneck for particles, and fixing up things such as the physics, trail spawning rate, increasing the max number, etc is of more visible benefit to players.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants