|
Introduction to Scene Manager in Vanda
|
|
Overview
The view frustum is the volume that contains everything that is potentially (there may be occlusions) visible on the screen. This volume is defined according to the camera’s settings, and when using a perspective projection takes the shape of a truncated pyramid.
The apex of the pyramid is the camera position and the base of the pyramid is the far plane. The pyramid is truncated at the near plane, hence the name frustum.
All the stuff that will potentially be visible on screen is inside, at least partially, the truncated pyramid, so there is no need to try and render what is outside the frustum, since it won’t be visible anyway.
In the figure above all the green stuff (totally inside the view frustum) and all the yellow stuff (partially inside) would be rendered, whereas the red stuff will not be rendered.
Scene Manager in Vanda Engine
In Vanda Engine, a scene manager improves the frame rate by rendering only the visible instanced geometries and skins of the current VScene.
Vanda Engine uses a combination of Octree and Bounding Box to manage static instanced geometries. Moreover, Vanda Engine simply uses Bounding Box to detect visible dynamic instanced geometries (Animated or controlled by Physics engine) and skins.
Bounding Box
Vanda Engine puts bounding box around each instanced geometry or skin and just calculates if the vertices of bounding box are viewable. If one or more vertices of the bounding box are visible, Vanda Engine renders the instanced geometry or skin.
Octree
When there are lots of static instanced geometries, It's expensive to put bounding boxed around all of the static instanced geometries and calculate if those boxes are viewable. To use less bounding boxes, Vanda Engine uses a technique called Octree.
An Octree is a tree data structure in which each internal node has exactly eight children. An Octree system in Vanda Engine recursively splits the VScene into eight regions and only renders the content of regions that are in the view area of the camera.
But when should we start and stop dividing octree cubes into smaller ones?
It's specified by a property that specifies the number of objects per final octree cubes. For example assume that each final Octree cube should contain 2 static instanced geometries and your VScene contains 30 static instanced geometries. At the beginning, our Octree contains one cube with 30 instanced geometries inside it. Since it contain more than 2 instanced geometries, it's not a final cube. Due to that, Vanda Engine attaches all of the instanced geometries to the first Octree cube and divides the first cube to eight smaller cubes. It repeats this process for smaller cubes until each final cube contains 2 or less static instanced geometries. For example if a child cube named "CubeLevel2" contains 10 instance geometries, Vanda Engine attaches these 10 instanced geometries to CubeLevel2 and divides CubeLevel2 to 8 smaller cubes and repeats the process for smaller cubes.
The most important things to understand about Octrees is that if a cubic parent of Octree is not inside the view frustum, then its children aren't either; and if a cubic parent of Octree is completely inside the view frustum, then its children are either. So Vanda Engine doesn't need to put bounding boxes around the static instanced geometries of invisible or completely visible Octree cubes to calculate if those spheres are viewable.
Each parent Octree cube contains all static instanced geometries of its child cubes.
