Got a question concerning this one.
I saw in the code, that AbstractCamera would maintain additional world planes to further limit the view frustum, which is something very handy for portal rendering as I could define new planes once I pass a portal to limit visibility calculations of the neighboring portals. Alas (nice word btw.), there are no push or pop methods.
Is there any reason for that? Did you drop the idea of using this feature? It looks like a partly converted idea from the WildMagic code.
Another thing: to reduce overdraw, I found the idea somewhere to have an int (32bit) framecounter incremented in the render loop and passed to each spatial when it is drawn. This way a spatial can check whether it has already been drawn during that frame (it will set its own framecounter after beeing drawn). Is this something considerable for the engine?
how would a counter reduce overdraw? I’m not following there. One way we currently reduce overdraw via our use of rendering queues… solid objects are drawn closest to farthest so that pixels that do not pass z buffer are quickly thrown away. We have also considered occlusion culling, which would remove objects whose bounds are hidden from the current view.
As for your question regarding abstract camera… Could you not simply extend that class and use additional planes?
Never mind, though, I've implemented the frame counter inside the RegionManager so it does not need to be externally known.
As for your question regarding abstract camera... Could you not simply extend that class and use additional planes?
Hmm, LWJGLCamera extends AbstractCamera. So it won't benefit from the additional functionality. Why, btw. is the array defined to contain 32 planes when there are only 6 currently available? In the Wild Magic code I've seen that the additional room is used to push and pop additional planes - exactly for the reason of portal culling. So I thought it was predefined in AbstractCamera for the same reason but not yet used.
very interesting. I’m guessing you’re right about the max planes number being brought across from eberly without a current use. Implementing push and pop and making sure this doesn’t break .contains(BoundingVolume) (and maybe .onFrameChange?) would just be needed as you point out.