• entries
  • comments
  • views

Multiple Materials and Kinda Deferred Rendering

Sign in to follow this  


[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.
Sign in to follow this  


Recommended Comments

Thanks for chiming in :)

When we apply the 'portal rendering algorithm' which involves finding the piece of frustum sticking through visible portals, and then using that for visibility testing in the adjacent subspace, we are indeed performing occlusion culling :)

Remember that our triangles don't have a back face - a backfacing triangle is in another subspace. All the triangles in the same subspace are pointing toward each other and are part of its convex hull. Its how we we grouped them - if they are all pointing toward each other, then they are all on the front side of each other, and there is no plane we could choose that would divide them, proof that they are a convex set :)

For a given node, and with a given input frustum, we can see a given set of triangles, since its convex... by definition, occlusion cannot exist in a convex space, with the exception of planar self intersecting geometry which is something no decent artist would produce and we can with some more work detect.

If you were to create a deliberate occlusion in the same subspace as the camera, the subspace would no longer be convex, and you would have to re-process that part of the bsp tree since the affected leaves are in fact no longer leaves at all. The cost of doing so is trivial if we kept the rest of the tree intact.

So for example, if we are in a square room, which is a convex subspace, and we put a square pillar in the middle of that room, we have now made that room to be no longer convex: we can expect that room will be divided into four convex subspaces, whose shapes will depend on both input shapes.
That's an important and powerful concept which I intend to revisit. We can actually perform geometric logical operations like intersection, union/addition and difference/subtraction with pairs of meshes that have been turned into a BSP tree !!! This technique is known as Constructive Solid Geometry :) In the first person shooter big name corporate world, such a BSP-prepared mesh object is called a "Brush"... and you can perform operations with pairs of brushes. One of the brushes can be the entire world :)

Our camera's origin is a point, and a point has no volume.
The camera can exist in exactly one leaf node at a time :)

The BSP Tree does not tolerate occlusions - its one thing that it solves particularly well, with the exception of obviously deviant geometry such as self intersecting geometry and triangles which are extremely narrow and very similar to a line segment or edge.

The Portal Rendering algorithm is just an extension of the frustum culling algorithm, it's not magical, but it has more depth or resolution because we are recursively querying the visibility of the stuff that is definitely inside the view frustum if we can see a hole in it, STARTING from the point of view of our camera.

Share this comment

Link to comment
So if we want to dynamically change our Portalized finished world, we will need to hang on to the entire bsp tree to avoid very high processing costs.
But if we are happy to leave it the way it is, we can throw away the entire bsp tree except the leaves - the final system is a portal and cell graph, and the cells are the convex subspaces, our leaves.Each leaf can contain any number of portals, and any portal is built on a plane and separates/connects exactly two leaves.We can think of the portals as 'exits', although that's a dangerous assumption since windows, cracks, any kind of peep hole counts as a portal. Portals support complex geometry, expressed as a planar projection. We don't draw them, we discover them ;)

Share this comment

Link to comment
OK I see where you're going with this now.
Realtime occlusion of the visible triangles in the LOCAL subspace is unjustifiable because the number of triangles involved is trivial and the cost/benefit ratio is not in our favor. However the occlusion of portals (and therefore visible triangles in ADJACENT subspaces) is a much more interesting question, as we stand to make substantial savings if we can determine that a portal that would otherwise be visible is completely occluded by a dynamic entity.
If it's not completely occluded, then we should ignore the occluder because once more we only stand to lose.
But if we can determine cheaply that a 'visible' portal is in fact NOT visible, hmmz.

I'm going to add this one to my TODO list and revisit it once the portal graph is all working :)

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now