#### Archived

This topic is now archived and is closed to further replies.

# Particle depth sorting

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

## Recommended Posts

Hi all... I made a particle system, the principe is to render only one object with all particle in, and each particle can have its own lifeTime and fade. the problem is the depth sorting.... its very slow. I compute Particle distance with each other with a DotProduct. Are there a way to depth sort with hardware z-buffer or someting like this ?? maybe anyone can help ?? tank you.. Fantasio

##### Share on other sites
quote:
Original post by Fantasio
I compute Particle distance with each other with a DotProduct.

Why don''t you use the distance formula?

sqrt{(x1 - x2)^2 + (y1 - y2)^2 + (z1 - z2)^2}

And you are doing spherical collision detecting, your don''t even have to do the square root.

##### Share on other sites

  struct particle {...float _m_distance_squared;};struct distance { vec3d m_eye; distance(vec3d _eye):m_eye(_eye) {} void operator()(particle& _this) {  _this._m_distance_squared = vec3d::square(m_eye - _this.m_pos)); }};inline bool b_more_far_than_a(const particle& a,const particle& b) { return a._m_distance_squared < b._m_distance_squared;}//the particle update:void sort_particles() { for_each(particles.begin(),particles.end(),distance(g_eye)); sort(particles.begin(),particles.end(),b_more_far_than_a);}

for all the nitpicker: i know for_each should not be used if data is changed, but actually the particledata doesn''t get changed but only some bufferdata. at least, its a very fast solution..

if your particles are in a simple array, it will look like this:

  //size = size of the array, in particlesfor_each(particles,particles+size,distance(g_eye));sort(particles,particles+size,b_more_far_than_a);

it should work that way quite fast.. dont forget to include "algorithm" (without .h)

"take a look around" - limp bizkit

##### Share on other sites
I found PointSprite solution...

Isn''t an hardware depth sorting ??

##### Share on other sites
Do you really need to sort them ? If you use additive blending, you don''t have to.

##### Share on other sites
Prosper/LOADED, yes you do. If you are using additive blending and NO ZBUFFER, then you don''t.

Even translucent polygons make a write to the Zbuffer. If you draw a particle near the camera, and it obscures half the scene, no other particle will appear "behind" it because they are "obscured" by the foremost particle.

For particles... well, if your particles are never going to be very big on-screen, don''t bother sorting them. If there is a chance that they''ll be huge, I''d suggest a filthy axis sort...

For a given GROUP of particles, not each particle, determine which of the six cardinal axes (Z+, Z-, X+, X-, Y+, Y-) is closest to the direction the camera is facing. Then, use your preferred fast sort algorithm on the particles, measuring only the relevant axis.

For example, if the camera is looking 5 degrees to the left of straight up the -X axis (relative position irrevelant), sort your particles with the lowest X values at the "front", and highest as "back".

##### Share on other sites
quote:
Original post by Wyrframe
Prosper/LOADED, yes you do. If you are using additive blending and NO ZBUFFER, then you don''t.

Even with a Z buffer, you don''t have to sort your particles (If you are using additive blending). Try this :

- enable Z test.
- draw all solid objects.
- disable Z write (but KEEP Z test enabled).
- draw all (unsorted) particles with additive blending.

Works flawlessly.

1. 1
2. 2
Rutin
21
3. 3
A4L
15
4. 4
5. 5

• 13
• 26
• 10
• 11
• 44
• ### Forum Statistics

• Total Topics
633741
• Total Posts
3013624
×