Doesn't understand how A1 VisTree works

Have a question, suggestion, or comment about Aleph One's features and functionality (Lua, MML, the engine itself, etc)? Post such topics here.
Post Reply
Qweasy908
Cyborg
Posts: 86
Joined: Jul 18th '18, 22:45

I have found nothing in the Alephone code about portals, there are only clipping windows and lines.
The RenderVisTree and RenderSortPoly work together to put polygons in a data tree, but I don't understand how.
I think the visible polygons are put in the data tree with polygon indexes.

How are polygons put in the data tree?

What polygon nodes are parent, reference, sibling and children in the data tree?

How are greater, shared and less nodes used?

How is cast_render_ray used?

I'm trying to make this in Unity game engine so I have the real way to render game maps.
In Unity the clipping windows have to be game objects to add a clipping planes shader.
I've read about portal culling, but not about how a data tree can show what is visible.
User avatar
LidMop
Spazeroid
Posts: 6
Joined: Jan 2nd '19, 20:18

There's no explicit concept of portals in the engine, but you can maybe think of every boundary between polygons as a portal.

The vis tree is a DAG of all polygons that are within the FOV arc represented by view->left_edge and view->right_edge. It's generated by build_render_tree(), which basically works as follows. The first node is always the view origin polygon, and others are added by casting rays from the view origin in certain directions. Every polygon intersected by a ray before it hits a wall is added. The first 2 rays are along the FOV boundaries. Subsequent rays are aimed at vertices of polygons that have been found (excluding vertices already aimed at and vertices outside the FOV), and this is repeated until no more new polygons are found.

Clipping data (line_clip_data, endpoint_clip_data) is generated as part of ray traversal. This data is later consumed by build_clipping_windows() to construct 1 or more clipping windows for each visible polygon. These windows describe screen-space rectangle(s) outside of which any drawing is culled. The engine relies on clipping windows to properly render "5D space" situations; back-to-front drawing alone is insufficient when polygons overlap.

The pointer members of node_data are for linking and navigating nodes in the DAG. The parent-to-child relationship in particular is the graph direction, i.e. the order in which a ray hits polygons.
Qweasy908
Cyborg
Posts: 86
Joined: Jul 18th '18, 22:45

LidMop wrote: Apr 12th '21, 05:06 There's no explicit concept of portals in the engine, but you can maybe think of every boundary between polygons as a portal.

The vis tree is a DAG of all polygons that are within the FOV arc represented by view->left_edge and view->right_edge. It's generated by build_render_tree(), which basically works as follows. The first node is always the view origin polygon, and others are added by casting rays from the view origin in certain directions. Every polygon intersected by a ray before it hits a wall is added. The first 2 rays are along the FOV boundaries. Subsequent rays are aimed at vertices of polygons that have been found (excluding vertices already aimed at and vertices outside the FOV), and this is repeated until no more new polygons are found.

Clipping data (line_clip_data, endpoint_clip_data) is generated as part of ray traversal. This data is later consumed by build_clipping_windows() to construct 1 or more clipping windows for each visible polygon. These windows describe screen-space rectangle(s) outside of which any drawing is culled. The engine relies on clipping windows to properly render "5D space" situations; back-to-front drawing alone is insufficient when polygons overlap.

The pointer members of node_data are for linking and navigating nodes in the DAG. The parent-to-child relationship in particular is the graph direction, i.e. the order in which a ray hits polygons.
Thanks, I will research DAG trees and experiment with ray casting.
Post Reply