Well with “not guaranteed” I meant “nothing is done to order them but nothing is done to keep them in the order you set them”. Maybe it works right now in the sky bucket (maybe the gui bucket too) but the order of objects in the scene graph is not meant to determine the rendering order. if you want to control the order, you have to do what I was suggesting.
attachChildAt can be useful if you want to control the execution order of controls attached to spatials. I guess there are other applications.
Yep yep, I’m currently trying @nehon 's suggestion and @zzuegg 's suggestion, both sound like it would flatten my SpotLight in a textured quad and thus solve the whole Bucket.Sky node depth problem. I’ll be back later today with results. I’m very excited at both suggestions. Thanks everybody!
RESULT for @nehon 's setGeometryComparator() hypothesis: This will obviously not work on a SpotLight since it only sorts Geometry, but I actually walked the mile (just to learn a little more on how JME3 works internally) and printed everything this comparator was passed and indeed, only true Geometry objects were passed, so this route is a dead end. I’m now going the offline rendering in a second viewport route
@nehon said:
Well with "not guaranteed" I meant "nothing is done to order them but nothing is done to keep them in the order you set them". Maybe it works right now in the sky bucket (maybe the gui bucket too) but the order of objects in the scene graph is not meant to determine the rendering order. if you want to control the order, you have to do what I was suggesting.
attachChildAt can be useful if you want to control the execution order of controls attached to spatials. I guess there are other applications.
Hi Paul, I’m glad you’re still reading on here! I was about to mention you in this post.
I used a mix of an older post you did concerning viewports in 2012, @zzuegg 's link here at the top (but I had to dig a little for a working/updated version) and also @nehon 's setGeometryComparator() function to accomplish this today. As a matter of fact, everybody put their grain of salt and you guys did very good work in supporting my effort to make this work. Today, I learned a lot about viewports, buckets and I’m almost done altogether with this thing. Be proud, JME3 community of all your supporting efforts. I was really (positively) shocked when I saw a viewport rendered in a textured quad in my main viewport, I was seriously astonished, I thought it was so cool and also no frame drop at all.
Now, as you can see on this screenshot it is now exactly doing what I wanted through a viewport textured quad Geometry: it’s in the Bucket.Sky but it’s always underneath the grass but not underneath the clouds WHICH IS WHAT I WANTED!! Yayyyyyyy!
I’ll now proceed with the transparency and the bloom/volumetric filters for the halos and such.
@pspeed when you said just above this post that Bucket.Gui is always sorted by Z, I mean, can we mix the render order from Bucket.Sky nodes with Bucket.Gui nodes? The grass band you see is in Bucket.Sky but must always be rendered in front of the sun, while the sun must always be rendered in front of the clouds (which are also in Bucket.Sky). How would Bucket.Gui solve this problem? Are you implying I could have put everything in Bucket.Gui and then specify Z translate values to manually predict the render order of those nodes? I always talk about nodes because some of them are NOT geometries, which seems to be a very important detail because all the buckets do when sorting before rendering is just sorting geometries, not filters for instance, which are always drawn afterwards it seems.
