[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Portal/sector visibility is based on 2D clipping. The 2D projected outline (in screen coordinates) of the last portal is used as a clipper for all geometry that can be seen through that portal.
This approach obviously has some disadvantages. It means we have to transform all geometry to camera space and then to screen space. Given the current advances in hardware (i.e. hardware accelerated transforms) this is no longer a good thing to do. In the future it might be possible to change this system to 3D clipping. For now this is a fundamental change and we'll try to get around this limitation in other ways.
The most important way to fix this limitation is not to cull detail objects like this. i.e. sprites, curved surfaces, and detail things should not be clipped to the 2D portal this way. Only for the software renderer could this make some sense as overdraw is expensive there. The new DrawTriangleMesh and the even newer DrawPolygonMesh (in iGraphics3D interface) will be able to handle this. All detail objects will be rendered with those. The engine will take care to only enable clipping if really needed (i.e. there are some cases where clipping is mandatory: for example, if you have a floating portal you cannot rely on correct Z-buffer information. So you need to clip geometry to the 2D clipper).
For detail objects we have a number of options. We can simply consider them visible is they are in the view frustum and ignore portals all-together. Note that all detail objects are linked to a sector. If a sector is not traversed too (because the current viewable portals don't connect to that sector) then the detail objects in that sector will not be considered as well. So for fast hardware this approach can be good as overdraw is not very expensive.
Another option is to clip the convex outline of the detail object to the portal. This is a rough clip which will simply indicate if part of the object is visible and then render it in total if that's the case (unless we have a special case like a floating portal which requires clipping). This option is useful for intermediate speed hardware or even for software if the detail object is very small. Clipping is still an expensive operation (especially doing it for every triangle or polygon) so we need to balance that against the cost of overdraw.
The last option is to clip every individual triangle or polygon. For software rendering this might be the base case as overdraw is expensive. This will have to be tested to see if that is really the case.
So this will limit 2D clipping to world geometry which is still useful because that enables good culling of other portals. Culling portals is valuable because culling a portal means that the entire sector behind that portal is also culled.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |