Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 22 Feb 2000
Offline Last Active Oct 21 2016 04:41 PM

Posts I've Made

In Topic: Billboard Particle Sorting

13 October 2016 - 06:18 PM


I've set up a 2d array aligned to my terrain, the array is at most 1024 x 1024.   I've then filled this array with the relevant leaf of my quadtree.  So when I traverse the tree and either enable or disable parts of the tree for rendering the array effectively is updated at the same time, the tree pruning also culls static assets for those leaves.   But, for dynamic assets that move, I use the 2d array to find out where they are if they need to be rendered.  I am going to use this for my particle system too, to remove the particles that aren't on screen at that point in time.  Sorting should be quicker.


As far as culling goes ... what I've got working is a simple sleeping mechanism

Each emitter has a uint sleep counter, while processing the particle system I do a min max on all points to generate a AABB.
The AABB is checked against the view frustum. If it's visible I reset the counter to zero... otherwise I increment.
If the counter is above lets say 30 I just stop updating it and wait for the last bounding box to become visible again before resuming.

This works well for environmental emitters (working on a waterfall at the moment) but other uses might need to time out destroy themselves.

In Topic: Billboard Particle Sorting

12 October 2016 - 01:20 AM

I assume also that the depth sort you have already occluded in screen space/frustrum and then used a quick sort once you have the depth of every particle?


Just interested in your execution.


I have to do the same thing soon for my particle engine, in fact I spent the weekend changing my code in preparation for this.

Not sure what you mean about "occluded in screen space"....
A rough outline of what I have right now.

Solve particle system (does a lot but it's basically an ubershader-esque design of different functions to transform the particle data. sizeOverLife() colorOverLife() etc etc etc
One of the most important things to get right here I feel is the "swap deletion" method of maintaining a contiguous list of particles in an array. Helps with allocation from a pool.

Sort the particles. I do this with a key rather than sorting the actual particle data. I have a simpler struct that contains an {index,depth} pair and I qsort them.


I now have a list of active particles and their attributes. One thing to note is I solve this system at a fixed time step of 30 FPS. I also double buffer all attributes related to rendering (position, rotation, color, etc) this allows me to tween the particle for rendering at an fps higher than 30 and still get smooth consistent results.


Using the sorted key list I iterate over all the particles and build a vertex buffer (dynamic) to send to the GPU. I submit one vertex per particle that contains both frames of the double buffered data. This allows me to only update that GPU buffer at 30 FPS as well.


vertex shader - to expand the packed particle data and tween it for the current delta time
geometry shader - turn the one vertex into 4 verticies of a quad
pixel shader - sample textures and output

I also have a lighting system now built for the particles that decouples lighting from screen size much the same way as mentioned in the latest DOOM tech papers.

In Topic: Billboard Particle Sorting

07 October 2016 - 06:46 PM

Thanks for the replies.

I looked through billboard code (I wrote it a few years ago) and I am aligning them to be (0,0,-1) in viewspace so I guess that answers my question.
I will use the plane equation for sorting.

"Do you even need to sort them? Have you already tried just disabling depth-writing (but still depth-test), and see how it looks? Sure, it won't be accurate, but it might look good enough to satisfy you."

In this case I do need to sort them because I am lighting and shadowing the particles.


In Topic: SDL : Circle transition effect - masking

26 September 2016 - 01:53 PM

Hi there...

If you have shaders up and running this should be relatively simple. I've written a quick example on shadertoy for you.



You can do something like that ... you'll probably want to run something like this as a fullscreen quad after you're done rendering your scene.

And run the reverse logic of setting the pixel black if inside the radius and using the glsl discard instruction on anything outside the circle.

Hope this helps!

In Topic: Particles in idTech 666

12 September 2016 - 08:14 PM

I've been thinking about lighting our particles in this manner as well. 
Anyone have idea on a fast way to:

- Allocate a location for the quad in the atlas. I can easily see how this would be done on the CPU. But lets say you want to do it while rendering out the atlas itself. Ideas?

- If you want to have a normal map for the particle you'd probably still have to render out something like the HL2 basis. They don't seem to do this ... it seem like the lighting resolution would be too low. Thoughts?