Multiple Materials and Kinda Deferred Rendering
1,423
3
Advertisement
[subheading]Tracking Multiple Materials during BSP Tree Generation[/subheading]
My mesh loader sorts the model's triangles (ie vertex indices) into attribute groups by material, that's why you'll see references to "Sorted Indices" in my sourcecode.
I'm happy to completely forget about tracking materials at this stage because I know that I can easily determine what material any triangle uses via my 'attribute lists'.
These are simply the starting index and number of indices for each group of triangles.... very similar to what we'd find in a mesh that was sourced from a ".X-File" ...
So given any triangle index, I can determine what attribute range it falls into, and that tells me what indexed material from the mesh is being applied.
And it gets even better.
The triangle indices began life as a sorted list, and are processed in order during tree generation.
They remain sorted by material at all times, hah.
[subheading]Gathering the Renderables[/subheading]
Now about Rendering.
The 'render' function won't actually draw anything - not immediately anyway... it will recurse the visible portals with an ever-shrinking frustum, gathering up the visible triangle indices into an output indexbuffer, and then drawing them, hopefully with as few as one batch involved.
[subheading]What now?[/subheading]
Of course, that's a way off yet - we need to find the Portals now, and to do that, we need to start by creating 'big fat quads' that are aligned with each splitting plane (we recorded those at each non-leaf node). The vertices of these quads lay at the intersections of the plane and the node's boundingbox. For each non leaf node, we must find four vertices which are simultaneously coplanar with (ie 'on') the splitting plane, and on the surface of the bounding box.. sounds tricky, but it's not too bad.
My mesh loader sorts the model's triangles (ie vertex indices) into attribute groups by material, that's why you'll see references to "Sorted Indices" in my sourcecode.
I'm happy to completely forget about tracking materials at this stage because I know that I can easily determine what material any triangle uses via my 'attribute lists'.
These are simply the starting index and number of indices for each group of triangles.... very similar to what we'd find in a mesh that was sourced from a ".X-File" ...
So given any triangle index, I can determine what attribute range it falls into, and that tells me what indexed material from the mesh is being applied.
And it gets even better.
The triangle indices began life as a sorted list, and are processed in order during tree generation.
They remain sorted by material at all times, hah.
[subheading]Gathering the Renderables[/subheading]
Now about Rendering.
The 'render' function won't actually draw anything - not immediately anyway... it will recurse the visible portals with an ever-shrinking frustum, gathering up the visible triangle indices into an output indexbuffer, and then drawing them, hopefully with as few as one batch involved.
[subheading]What now?[/subheading]
Of course, that's a way off yet - we need to find the Portals now, and to do that, we need to start by creating 'big fat quads' that are aligned with each splitting plane (we recorded those at each non-leaf node). The vertices of these quads lay at the intersections of the plane and the node's boundingbox. For each non leaf node, we must find four vertices which are simultaneously coplanar with (ie 'on') the splitting plane, and on the surface of the bounding box.. sounds tricky, but it's not too bad.
Advertisement
Advertisement
Advertisement
Discussion