How It Works
BACK > Home
This page explains how the functionality behind kPortals works.
Data diagram for kPortals.
The stage has three methods; Manual, Automatic and Hybrid
Manual: The user creates Portal Volumes in the scene. The Portal System then generates a flat data structure to fill with visibility information.
Automatic: The Portal System calculates a bounds that encapsulates all static renderers, then subidivdes it by the amount of the user defined property Subdivisions. This process generates a hierarchical data structure to fill with visibility information.
Hybrid: A mix of the previous two. The Portal System will calculate a subdivided bounds as per Automatic mode. However, the user can then suppliment this with extra Portal Volumes in the scene.
Automatic Volume generation.
Next the Portal System filters all the renderers in the scene by the Occludee Static flag. It also collects any user defined Port Occluders in the scene. From this information the Portal System generates a collection of serialized occluder data. Later, during the bake process, The Portal System then generates temporary mesh renderers based on these occluder objects to test for occlusion. These are then discarded.
Visualization of different types of Occluder data.
Now the Portal System, per Volume, generates a number of rays based on the user property Ray Density. This value defines the amount of rays to calculate per cubic unit.
Generated rays for a single Volume.
Per-ray, the Portal System filters the occludees by testing their bounds against a cone around the ray, with its angle defined by the user property Filter Angle. Occludees that fail these test are discarded from visibility for this ray.
Cone angle filtering.
For all filtered occludees, the ray is tested for intersections with their AABBs. Occludees that fail this test are discarded from visibility for this ray.
Occludee AABB ray intersection.
Next the ray is tested against the Occluders defined during step 2 by physics raycast. Occluders that are hit by the ray are sorted in a list by their distance to the ray origin, then all occludees that passed the visibility test have their distance tested against the nearest Occluder. All visible occludees further from the occluder are considered occluded and discarded from visibility for this ray.
Physics raycast based Occlusion test.
Finally all occludees that passed occlusion tests per-ray are accumulated and stored in the temporary data for this volume. Steps 3 through 7 are repeated for every volume in the lowest subdivision level, then this visibility data is serialized along with the occluder and volume data.
Component editor GUI.
At runtime the system simply searches the serialized visibility data to find the lowest subdivision volume that each of the registered Portal Agents are within bounds of then calculates the differences in visible occludees.
For now, for lack of a better scriptable culling solution, these occludees simply have their renderers enabled/disabled to provide “culling”.