Hi,

I'm at the point of implementing alpha blending (shader) to be able to use transparant/translucent textures, grass etc.

For now I didn't use any object/ mesh sorting because I didn't see the advantage yet.

But.. when using alpha blending, I've learned that I have to render objects (or better triangles?) from back to front for the expected result.

A few questions I'd like to hear your opinion on;

- is it worthwhile to render meshes/ objects based on world positition Z (initial worldpos vector * actual world matrix)?

(by the CPU, finding an efficient way of looping through objects, materials, effects, entities)

- what would you suggest to sort objects on when it comes to alpha blending?

The direction I'm following now is:

- update worldmatrix of each mesh each frame

- multiply by initial worldpos, resulting in a vector with 'Z' value

- use Z value to render 'regular' objects, front to back (increase performance on rasterization/ pixel shader)

- use Z value to render 'blended' objects, back to front

Any hints or pointers are really appreciated.

Will also be quite a challenge too find the best way to combine the 'loops' (materials, effects, effects, subobjecs/entities).

I think the way your currently going about it is fine and fairly common. So your just adding all visible transparent objects to a list then sorting that list based on world distance from the camera. One thing to consider however, using the world position to camera may not be the best metric because consider two objects being close together, and the one at the back being much larger than the one in front. In this case you should probably render the object at the back first. So instead maybe calculate the distance from the camera to the objects bounding box.

Thanks Nyssa, I can easily do that by using my radius value for each mesh, in combination with the world position (based on current camera position).

Good to hear that I'm on the right way.

Sorting 'regular' meshes (cpu usage) for rendering isn't that usefull (yet/ for now).

In the end I might need to merge vertex and indexbuffers to save renderstates etc..

I know loop through all effects, then materials, then meshes, the entities. This is potentially not perfect, because I switch meshes (index/ vertexbuffer) more then once for each entity. I find this a difficult choice, it's more setting of vars for the materials (in the effect/shader) versus setting more matrices and index/vertexbuffers. Don't know what's worse.

I might go for index table to prevent loops (for static objects that is, now 90% of the scene), but also then I would need to do switches on the meshes or materials. When I think of it now, probably switching materials is quicker then meshes:

- material select:

=> 2 SetFloatArray calls (amb and diff)

=> 1 TexTure call (or more when multitexturing or so)

- mesh select:

=> SetMatrix (World)

=> SetMatrix (WorldInvTransp, for normals/ lighting)

=> SetStreamSource

=> SetIndices

But then again going through all meshes and then materials, means selecting the materials again for other meshes.

Dilemma's dilemma's ....

Any advice on this?

as an addition, I do have a table (unsorted), with for each entity/ sub object:

- entity nr of mesh

- mesh ID

- material ID

- effect/ shader ID

@Nyssa (and others :))

I've been studying my renderframe and found some flaws (I believe). To illustrate.

Sample scene:

15 meshes

5 entities for each mesh

7 unique materials

Assume that I do the following one time for Opaque meshes with Opaque technique and another time for blended meshes with Blending technique (already have 2 mesh index int lists in use):

loop through effects/shaders

{

begin effect

set technique (blended or opaque)

set viewprojection matrix of camera

loop through passes of technique

{

loop through materials

{

select material (setfloatarray 2x, settexture)

loop through meshes; if mesh.mEffect = current effect

{

if mesh in frustum

{

setstream vertices, setindices

set worldmatrix

commitchanges

loop through entities; if entity.material = current material

{

if in frustum

{

draw

}

}

}

}

}

}

}

This means I do:

- 7 material switches (2 float arrays, texture)

- 105 mesh switches (setstreamsource, indices and world matrix)

- 105 commitchanges

- 105x check effectindex for mesh

- 525x check material index for entity

I figure if I turn it around and go through meshes and then materials:

- 15 mesh switches

- 105 material switches

- 105 commitchanges

- 15x check effectindex for mesh

- 525x chec material index for entity

Room for improvement?

- what would take more performance, switching a mesh versus switching a material?

- bringing back the if loops for effect and material ID checking, I can do with index lists (int array's)

- what other improvements should I look for?

(I'm not yet ready to go for merged meshes into one vertex or index buffer, which might bring other possibilities)

Any advice is really appreciated.

Hi Phantom,

Thanks, this clears things up. The article covers recognizable stuff, that's the good thing :)

I thought about making indices of entities (with corresponding mesh ID) who share the same material.

This way I could batch up and reduce the material changes to the number of materials in the scene.

Thinking about it, with what your saying, this saves a lot of state changes.

Assuming that I don't need to 'CommitChanges' when setting another streamsource and indexbuffer, is this correct?

If so, this will be my first step.

Maybe later on bundle the streams/indexbuffer to improve further.

@Phantom; just remembered that this probably wont help/ work, because when changes the streamsource/vertexbuffer (mesh) I also need to set the mesh's world and worldinvtranspose matrix. Which probably means I need to commitchanges anyway...

Yeah Phantom is spot on, your doing alot of redundant searching there.

The way I currently do it is via render "buckets". So as you loop over your scene objects, after you have determined an objects visible, you determine if its solid or transparent (you might have a boolean in your material for this) then add that object to the solid or transparent list. Each Object also has a key based on its render state (this can include its rasteriser state, blend state, texture ids, etc...) and each list is sorted using that key. So objects with similar states will be next to each other thus state changes should be kept to a minimum. Then you just render each object in those lists, setting world matrix values as you go.

Keep in mind that all this sorting needs to be done in an efficient way else it ends up being faster to simply do all the state changes anyway! You could also add to the above method a way of altering these lists only when an object moves in/out of the viewing frustum. That way they don't need to be rebuilt each frame!

I should add...I'm currently working in c++, but the same theory should translate in to c#