<p>Sort the particles by Z each rendering cycle using an algorithm such as bubble sort which is good when element changes position in small steps. If the perspective does not change much the errors would be few enough over time to be unnoticable. The technique is easy to configure between quality and performance dependning on the target platform by adjusting how much sorting is performed each cycle.</p>

CC BY-SA 3.0
2017-09-15T16:15:02.437Z
2017-09-15T16:15:02.437Z
Andreas
<p>First option should be to make all particles able to go through the same pipeline. Perhaps with an uber shader. That way you can batch them all.</p>

<p>Positive ieee floating point numbers can be sorted like unsigned integer. And there are O(n) algorithms to sort those for example radix sort. </p>

CC BY-SA 3.0
2017-09-15T13:03:41.230Z
Also you can get near n, or atleast less than n log n, with bucket sort and it is trivial to do. Even better if you begin with a BSP/occ-tree you can even get it to be less than N as you get cameara occlusion culling for free.
joojaa
CC BY-SA 3.0
2017-09-15T13:13:26.673Z
BSP and octrees are kinda overrated for real-time graphics work. All the pointer chasing required is detrimental for cache performance.
ratchet freak
CC BY-SA 3.0
2017-09-15T13:25:01.780Z
Not necceserily if your buckets are bigish then you divide the work, but still have the benfits of lists with very few jumps
joojaa
CC BY-SA 3.0
2017-09-15T13:42:43.687Z
For me, the "ubershader" is the magic sauce here and is a good point. Thanks!
Alan Wolfe
CC BY-SA 3.0
2017-09-16T11:54:40.797Z
If you have a huge amount of particles you can also sort them on the GPU with a compute shader using bitonic sort. It's n log n (i think) but parallelized so super fast. There's a working implementation in the old DirectX 2010 SDK.
russ
CC BY-SA 3.0
2017-09-15T08:44:17.403Z
2017-09-15T08:44:17.403Z
ratchet freak
<p>If you have a bunch of particles to render, using different shaders and/or render states, that have some level of transparency, the naive solution of sorting all particles by depth can be extremely inefficient since it is likely to turn a few large batch draw calls into a multitude of smaller batch calls which have expensive render state switches between those draw calls.</p>

<p>I know of a few ways to help fake things such as sorting particle batches by their emitter location, or using something like additive blending, which gives the same result regardless of draw order.</p>

<p>I also know there are some techniques out there to attempt order independent transparency, often being an approximation, requiring a (sometimes unbounded) amount of memory, or some combination thereof.</p>

<p>Does anyone know any pragmatic solutions (fast/low extra memory requirements/absolute correctness not required) for dealing with this situation?</p>

<transparency><particles>
Are there tricks for getting proper sort ordering on particle systems?
Alan Wolfe
# Are there tricks for getting proper sort ordering on particle systems?

(Asked by: username_0 on 2017-09-15)

If you have a bunch of particles to render, using different shaders and/or render states, that have some level of transparency, the naive solution of sorting all particles by depth can be extremely inefficient since it is likely to turn a few large batch draw calls into a multitude of smaller batch calls which have expensive render state switches between those draw calls.

I know of a few ways to help fake things such as sorting particle batches by their emitter location, or using something like additive blending, which gives the same result regardless of draw order.

I also know there are some techniques out there to attempt order independent transparency, often being an approximation, requiring a (sometimes unbounded) amount of memory, or some combination thereof.

Does anyone know any pragmatic solutions (fast/low extra memory requirements/absolute correctness not required) for dealing with this situation?

**Tags:** transparency, particles


---

## 2 answers

### Answer by username_2 on 2017-09-15. Score: 4 | Accepted answer

First option should be to make all particles able to go through the same pipeline. Perhaps with an uber shader. That way you can batch them all.

Positive ieee floating point numbers can be sorted like unsigned integer. And there are O(n) algorithms to sort those for example radix sort.

> **Comments:**
> **username_3**: Also you can get near n, or atleast less than n log n, with bucket sort and it is trivial to do. Even better if you begin with a BSP/occ-tree you can even get it to be less than N as you get cameara occlusion culling for free.  
> **username_2**: BSP and octrees are kinda overrated for real-time graphics work. All the pointer chasing required is detrimental for cache performance.  
> **username_3**: Not necceserily if your buckets are bigish then you divide the work, but still have the benfits of lists with very few jumps  
> **username_0**: For me, the "ubershader" is the magic sauce here and is a good point. Thanks!  
> **username_4**: If you have a huge amount of particles you can also sort them on the GPU with a compute shader using bitonic sort. It's n log n (i think) but parallelized so super fast. There's a working implementation in the old DirectX 2010 SDK.  

---

### Answer by username_1 on 2017-09-15. Score: 1

Sort the particles by Z each rendering cycle using an algorithm such as bubble sort which is good when element changes position in small steps. If the perspective does not change much the errors would be few enough over time to be unnoticable. The technique is easy to configure between quality and performance dependning on the target platform by adjusting how much sorting is performed each cycle.


---

