Hardware occlusion culling, Art path

Pics out of the way first this time.

http://www.blackrayne.net/27/fs_shot0015.jpg

Shot of my current test map. Just wanted to get the tri counts up to test the room system out. This is part of a map containing two towers like this.

http://www.blackrayne.net/27/maxscene_watertest.png

The red geometry is the visible scene mesh, the purple and green cylenders are "room hulls" for visiblity culling. 6 rooms total.

Work continues on updating quake3 into a more modern engine...


Theres no water

After getting the fragment shader code and new T&L style surface management code in, I wanted to see about going and doing HalfLife 2 style water. The basic premise for reflective/refractive water is you sample two specially crafted renders of your scene into a pixel shader, with the lions share of hard work being the actual setup and render of the two extra scene renders per frame you're required to do.

First you need to mask off and draw just whatever is going on underneath the water for the (faked) underwater refraction drawing.

Then you have to draw a mirror view of the scene for the waters reflection plane with the underwater stuff masked out.

I got as far as producing a test map for this with an encapsulating brush defining the boundary between the two areas (under water and not) when I realised that the work I was putting into this one special water case was largely following work I could have been doing to create a new visibility determination scheme...

New vis was already on the Big Wish List of things we needed to see about; Q3's PVS system looks great on paper, but in practice and with q3map2, you're really praying for things to work right once you're bringing out the hint brushes to get a larger map performing well.

So thats what I've spent my spare time for the last two weeks reinventing, and only just now can get back to seeing about doing something about that water.

New Vis

Anyway, regarding the new vis; The system I came up with has made the mappers happy - Mappers build their map out of an arbitary soup of meshes with no consideration for sealing or portals, and then mark in how the vis is supposed to work.

The mapper breaks the level down into cullable "rooms" using a closed mesh to zone off what triangles belong to the room. The engine then uses a combination of AABB checks, logic, and hardware occlusion tests to build the scene up at render time.

http://www.blackrayne.net/27/vis_system.GIF

This mspaint job was done up when I was first thinking about how to do this. It's still mostly accurate except I quickly scrapped the idea of bounding rooms with brshes and went with meshes instead.

The room system has a couple of rules:
1) Rooms can nest within other rooms (encouraged!)
2) Rooms can't intersect other rooms ( so A can sit within B, but A can't sit half in, half out of B)
3) Room Meshes have to be closed and 2 manifold.

I'm very proud of this scheme. I know I'm late to the party with hardware occlusion tests for vis, but it took a bit of thinking for a way to come up with a method that wasn't just another portal placement nightmare.

Building zones is a little bit of work for the mapper but the payoff is huge - it's ALL they have to do, no portals or other hinting.. so it completely thumps portal schemes in terms of set up; mappers don't have to worry about sealing every orifce of their room with portals and antiportals, it's just "voodoo magic" once the rooms are marked in.

Unlike portals-only, it also adapts extremely well to doing large outdoors areas like terrain with buildings on it, because
A) everything in the scene blocks vis for near-free (plants, hills, trees, buildings, etc)
B) rooms can be used around open geomety, like a statue on a hillside can be placed into a room, even though it's mostly air.
C) the mapper doesn't have to provide portals to fill in all the windows and doors on buildings.. the per pixel occlusion takes care of it provided theres a room inside to be culled out.

So in terms of rendering things are still pretty similar to a portal engine. The scene graph is traversed from front to back, starting in the current room and working further away. Where it differs is each room is hardware occlusion tested against whats already been rendered, and it ( and its children ) can be culled. In a metaphorical sense, every drawn/closed pixel is an antiportal, and every open pixel is a portal.

In practice it means that you can break a map like casa up into about a dozen rooms and get far more accurate and robust culling then q3 ever managed. Things like L shaped hallways and other "Pray it works" setups just work implicity now.

Erk late, will probably edit this again later.