Hey folks,
I’ve recently finished a new addition to jME that allows us to collect all or part of a scene in render buckets which are then rendered in logical and correct ordering. The result being that opaque objects are rendered first from closest to furthest from the camera, then transparent objects are rendered from farthest to closest (allowing for correct light/colors) and finally orthagonal items are drawn last in “zOrder” (another new field) which ensures they are on top of the other scene objects.
A correctly drawn scene where solid objects are drawn from closest to furthest can actually speed up some cards which have optimizations related to the zbuffer. Transparency sorting, and rendering them after opaques, will give more correct transparency effects. Furthermore, having the objects sorted by depth allows us to do other tricks in the future like occlusion culling.
The new render queue is mostly optional (there is a tiny impact whether used or not) but the added sorting required when using it seems to have very little impact on rendering speed (using OptimizeIt for profiling.) You add a Spatial to the render queue by simply setting a field on the spatial to the bucket you want it to be in… Transparent, Opaque or Ortho. Other options for this field include Skip (render immediately, don’t queue) and Inherit (default). Inherit means bucket placement is inherited from its parent. If it doesn’t have a parent, it renders immediately. You can mix and match rendering immediately with rendering from queue if you want. (queues get rendered on the call to show back buffer)
I will check these additions in later today once I clean up the code and comments a bit. There’s also a new test that shows off the impact of the queue in terms of visual scene correctness.
Ok, checked in… There’s places for improvement, widgets for example, but we can hit them as time goes by. Please let me know of any issues, concerns or comments. 
Btw, use the Q key in the new test (TestRenderQueue) to switch between using the queue (on) and not using it (off). It’s off by default in the test.
i think there is only one word to describe the increase in FPS i get, and the correct blending… WOW!
When I try TestRenderQueue, then on my PC the queued and non-queued modes look differerent, since without queueing the orthos are not rendered in ortho mode at all. Maybe there should be an addition to handle ortho nodes in some way in normal mode, too?
Apart from that, if I analyzed this correctly you render the queue in displayBackBuffer(). But before that, in SimpleGame the normal render() is called, so everything gets rendered twice?
No, when render is called, a decision is made as to whether to immediately render the various items in the scene or to place them in the queue. So, items are only rendered once.
And yeah, I recently added in a few ortho items just to see how well that would work. imho there is no good reason not to use the queue for ortho style objects unless you write your own render method and call setOrtho before rendering. So your choices are calling the ortho mode before rendering ortho objects or marking those objects to be placed in the ortho queue and let jme do the work for you. There’s not a good way to do the first when extending SimpleGame aside from not using rootNode, so the test only shows the affect of the queue on a normal object when marked as ortho.
PS: The other real visible difference in the test aside from the ortho objects is the correct handling of transparent objects.
Thinking more about it, I’ve tweaked the test’s use of SimpleGame so that I AM using my own render calls so that the queue-off mode also sets the orthos as being ortho. The test looks even nicer now because the items meant to be ortho will ghost in and out behind the other items in the scene in queue-off mode and be properly on top when in queue-on.
As an aside: Yes, by carefully manipulating the scene tree you can usually get items to draw in a specific order on your own but that is a lot of manual work for a large scene and hard to guarentee in any case. Furthermore, in the future we’ll have other optional improvements and features relying on queues.
So in fact I am really happy with this new improvement since it solves quite a bit of internal working and makes some things much easier. On the other hand now I have to change my engine...
XD
Hehe, sorry about that, hopefully all for the better though!
Hey, that’s the reason why I’ve decided to use jME: there is something happening here! Things develop, you can feel the development with every update - I just like it.
I really love the render queue. I’ve been going over it, trying to figure out its implementation and all. I have one suggestion or question rather. Why did you use TreeSet? TreeSet uses unneeded processing power keeping the list sorted after every insertion. On my home computer I put the values into an array and quicksort each bucket during renderBuckets(). It seems to be faster (from what I can tell) and doesn’t use the heap at all. I can upload it to the CVS if you like, but didn’t want to if you had a reason for using TreeSet trees.
No, just used to using TreeSet from my work (financial apps) which need things to be sorted as they come in. I’m not sure it will necessarily speed things up hugely though since adding an item to an already sorted list should be fairly fast, but if you are seeing performance gains and there isn’t a change to the api then sure.
It’s in. The speed up is only visable when using lots of the render queue, otherwise it’s minimal (but still existant). The biggest advantage is memory. jME can now run most Test applications with zero heap usage per frame.
-Edit- it was all in my head. BoundingVolumes are considered.
update: seems sortCam has the same issue. They are both periodic, happening after a few seconds of heavy use.
It’s my implimentation of quicksort. I’m updating it now.
Try again. It wasn’t in the CVS.
If anyone is using the RenderQueue a lot in their program (200+ elements inside it) let me know if it’s any better new vs old.
Works again, thanks. Doesn’t seem to be faster though, but I guess ymmv.
Ugh, Cep, not sure if you thought of running TestRenderQueue, but the new sorting alg you have in there really screws that up. transparents don’t sort correctly and you get weird jag issues and disappearing geometry. reverting back to RenderQueue 1.4 solves it. 
Mother of a turkish cow! } } }
I’ll check it out at home. If I don’t fix it in 5 minutes of looking, I submit
XD I hadn’t really had much of a chance to streamline what was there (at v1.4) when you started, so I’ll look at that approach as well,