1
\$\begingroup\$

I'm in the process of sketching out the design of a 3D rendering engine as I'm learning my way around the subject. (Preemptively: yes, I have my reasons for rolling one from scratch, not least the educational value, so no, I'm not interested in just using prefab solution X.) As in the Elder Scrolls games, the engine fundamentally differentiates between "indoor" and "outdoor" areas, since in "indoor" (primarily enclosed) areas it uses a portal-and-cell approach to simplify visibility determination. I've been trying to work out a good solution for simplifying visibility determination for "outdoor" (primarily open, freely roamable) areas, but I haven't run across anything I like nearly as much.

Primarily the issue is that, with portal rendering, you can not only skip on rendering anything behind an occluded portal, but you can actually discount it outright. If, for example, you store the cells as separate data structures and track which objects are within which cells, if a portal isn't visible, anything within the cell behind it can be completely removed from consideration without ever having to even check the objects themselves. (Aside from a few edge cases of objects that extend over the boundary of the portal into another cell, but that's not too hard to work around.) And that happens entirely without any pre-calculated visibility information, just by the nature of the rendering process. I like that quite a bit.

But I haven't found a technique that provides that kind of benefit for "outdoor" spaces, at least not without a lot of pre-baked analysis. The inverse of portal-and-cell rendering, "antiportal," seems like a not-bad approach in the broad strokes, since in the intended application "outdoor" areas will likely have fairly large areas of the screen occluded (by mountains, buildings, etc.) But as far as I can determine there's no way to use it for the kind of wholesale removal of objects/architecture at the data-structure level as you can pull with portal-and-cell rendering, since antiportal rendering requires you to actively check objects against an "occlusion volume" created from the antiportal and dependent on the camera position. Which, I guess, would work, but it seems like there should be a better way.

Maybe there isn't, and it's just the nature of the beast, but I thought I'd ask: is there a good method for removing objects from visibility determination in a primarily open environment before considering the individual shapes, without having to use more traditional pre-calculated BSP-type techniques?

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.