AbstractCamera frustum planes

Troubleshooting General Help
1

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?

2

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?

3
"renanse" wrote:
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.
Portals create circular graphs, rather than a tree. Which means, walking the portals you have to prevent already visited regions from being drawn again. This can be done by introducing a "visible" flag which is valid during one drawing of the whole portal system. So you need to reset these for every frame. Or you simply increment a frame counter and each region has an own counter which can be compared against the "system" frame counter in order to find out, whether that region has already been drawn during this frame.
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.
4

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.