Horde3D

Could someone please confirm that when you specify order="BACK_TO_FRONT" in a DrawGeometry this means that the items will be rendered in the order of the furthest away from the camera to the closest to it.

If this is correct can someone please explain why I am getting square borders when rendering particles using this and with depth testing turned on.

I have included a screen shot to try and make it more obvious what I am talking about
http://lmcdowall.co.uk/dare/screen%20shot.JPG

The particle being used is the one included in the demo's and so does have an alpha channel I think

I haven't tested depth sorting myself yet because I have another approach but:

Are you using a shader for the particles (actually, how could you not...)? What have you specified in the render configuration, in the shader file? You can specify different blending modes. These would affect how your rendered objects look like regardless of order, I guess... some of those is probably capable of producing square borders.

"blend function (Values: REPLACE, BLEND, ADD, ADD_BLENDED, MULT) (Default: REPLACE) {optional}"

I'm using ADD_BLEND which produces the correct results when depth writing is off but obviously draws over everything so is less than ideal.

Depth sorting is working on a per-node basis. Particles are not sorted, this would usually be rather slow.

Can depth-writes be disabled just for the particles (and not for everything else)?

Yes but doing this obviously cause's particles behind objects to be rendered over everything as no depth testing is carrier out

can you suggest a method to allow the rendering of particles within a scene then, espeshally with the defered shaders

We can discuss this in your dedicated thread in the rendering technique section...

No, it shouldn't - not if testing is still enabled but writes are disabled.

First the scene is rendered with depth writes and depth testing enabled.
Now we have a valid depth buffer for the scene.
Then particles are rendered with depth testing on (so they don't appear in front of objects), but depth writes are disabled, so that they don't modify the existing depth-buffer data (and occlude each other).