Drawing order

Adversus · Post by **Adversus** » Wed Mar 11, 2009 12:50 pm

Is there a way to force a mesh scene node to draw after it's parent?

hybrid · Post by **hybrid** » Wed Mar 11, 2009 1:43 pm

No, because geometry is sorted front-to-back, without any relation to the scene node hierarchy. The only way is to exclude the mesh from rendering and draw it from a separate scene graph later on.

Adversus · Post by **Adversus** » Wed Mar 11, 2009 4:59 pm

Yea that's cool. I thought as much but sometimes it's better to be sure.

asparagusx · Post by **asparagusx** » Sat Mar 14, 2009 11:38 am

I have a related problem with drawing order. Looking at the code in drawAll(), solid materials appear to be ordered by material and NOT in back to front order. Transparent materials are. My question - how do I combine 'all' nodes in back to front order. Secondary thought is that rendering might slow down, as there will be a lot of render state changes, as nodes (solid) are not sorted by material in that case. I am using 1.5.

Thanks

Anton

Adversus · Post by **Adversus** » Sat Mar 14, 2009 3:08 pm

Yea that would slow the rendering down but you can do that by registering each node as transparent.

My problem is that I need to manually order "transparent" objects as sometimes taking their origin position isn't accurate enough when doing effects as sometimes multiple transparent models (that make up the effect) have the same matrix to position them.

asparagusx · Post by **asparagusx** » Sun Mar 15, 2009 8:42 am

I have exactly the same problem! I did some tests re rendering speed in my app and in actual fact it does not really make a difference. Wether you sort on texture or distance does not really matter - the system still needs to go through the sort process - it is just the value that you test on that changes. By sorting on distance rather than texture, it might slow the actual rendering process down, as there might be many more state changes. It will depend on the model that you are viewing at the time - the material sorting only 'groups' materials with the same texture - diffuse colour etc. seems to be ignored.

Anton

Adversus · Post by **Adversus** » Sun Mar 15, 2009 10:32 am

I think it depends on the OGL or directx driver too.

The materials also don't get changed if they are the same type with the same values (for lighting etc), check out the OGLMaterialRenderer, and it could be that your geometry just happens to all be 1 vb has 1 texture or close etc. It's hard to really determine these things for definite.

That said, as for not making a difference, I did something similar. I turned off the color arrary hoping to get a speed boost as I heard the device I worked for worked best with a small vertex format and got very little speed up at all. It would seem that it's the big stuff (texture sizes, number of passes, number of triangles etc).

Munger · Post by **Munger** » Wed Mar 18, 2009 3:49 am

I had a similar problem. If you want to take on all the rendering responsibilities (i.e. don't use drawAll), it's not that much of a hassle. The thread was over at http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=32045.

Adversus · Post by **Adversus** » Mon Mar 30, 2009 6:29 am

Yea I ended up doing pretty much that.

I also handle the update separately as it runs more often than the rendering too.

I was pleased to do this without having to make changes to Irrlicht.