Irrlicht Engine

If you have a wrapper, surely you can multiply the Z value there? The internal Z value can be the layer times 20.

hendu : That's exactly what I'm doing. Well, what I think I'm doing anyway.

CuteAlien : That's good to know it's high on the priority list! Thanks a lot! Like I said in a previous post, I'm not trying to put undue pressure on that issue, as I fully realize, having worked on an open source project in the past, that it sometimes require a lot of spare time. And with Christmas approaching, like you said, it's time we wish we could spare with our families! So, no pressure, I'll go with my patchy-patch for the time being!

I meant more like multiply the Z value in your constructor, so that it's correct in all places, not just with the absolute matrix.

Oh yeah, sorry, it makes sense now!

Yes, that would also be possible! I'd just need to make a list of all the methods of a ISceneNode that affects the Z-Value and reimplement them in my base object. That would also work, and it would be less patchy.

For posterity, I did what hendu suggested, and it worked great!

I'm reviving this post because I had a new "problem" today which I think is related to this one. I'll try to describe it accurately ; if it's not enough, I'll find some time to write a minimal example.

Still using an orthographic camera, I setuped the following scene (seen from the side, and again, forgive the Paint skills) :



IMG1 and IMG2 are custom nodes based on the billboard (to be able to rotate). They're displaying a transparent texture (represented by the blue lines inside the black ones). Both image nodes have exactly the same Z-value. Behind the images, I created two billboards, that each have their own Z-value. Like this, the scene renders perfectly.

But if I rotate the node IMG2 like this :



Then the IMG2 transparency hides IMG1 completely, but not the billboards, that I can still see through IMG2's transparency! This surprised me a lot!

But this only happens when IMG1 and IMG2 have the same Z-Value as their position. If I reduce a little bit the Z-Value of IMG2, then everything's working correctly (meaning that when IMG2 passes in front of IMG1 while rotating, I can still see IMG1 through IMG2's transparency).

Is it related to the problem I reported?

Sorting should be done by distance from the camera, not Z-value, eliminates popping when rotating the camera around.

Also billboards should face towards camera, not along Z+ (openGL convention Z+, d3d Z-)

If you want your own sorting method, then make your own scene manager inheriting from CSceneManager and set it as the input receiving scene manager.

There was some bugreport about that before (https://sourceforge.net/p/irrlicht/bugs/262/).
In the discussion there had been then some voices against that because of costs: http://irrlicht.sourceforge.net/forum// ... hp?t=33410
I haven't created test-case yet to profile costs. But basically I don't want a quick hack, but the change needs to be flexible. Either allowing user-function(s) for sorting (somewhat relucant to do that before the switch to STL) or a bunch of fixed options.

This project was put in the backlog where I'm working, but essentially, I did what hendu suggested and artificially multiplied the Z-value inside my custom classes, which kinda fixed the problem (in the sense that it went away). Of course, this is only true if the ortho camera is created to look perpendicularly along the Z-axis (which is what I'm doing).

Creating a custom SceneManager was, of course, a possible solution, but being a 2D game programmer, I felt that my math and comprehension of 3D, along with my knowledge of Irrlicht's architecture, weren't strong enough to tackle that problem in an effective way. So I went for the quick fix.

The way I see it, the sorting on an orthogonal camera should happen as if the camera is a plane aligned with the screen, and the sorting should be done on the node's distance from that plane, and not to that of the camera eye itself.

Yes, it should in this case. But it's not a free calculation. So maybe too expensive to use as default (or at least other sort should still be an option).

Uh yeah... that one slipped away for a while. So fix in November 2023 in svn trunk r6573.
The used algorithm can now be switched via ISceneManager::setTransparentNodeSorting and setting it to ETNS_PLANE_ORIGIN or ETNS_PLANE_CENTER will both work for your case.

Not the default thought, I tried it, but with perspective cameras and real scenes ETNS_CENTER (which is also new) worked best for me.