Occlusion Culling

#1 There are two things going for Undercity which keeps the performance reasonable.

1. The Advanced Lighting system requires a zprepass. This means that during forward rendering it only needs to read zdepth and not write zdepth. This removes almost all overdraw from the scene so no pixels are shaded more than once.

2. We use hardware occlusion culling after the zprepass to cull lights and disabled updating their shadow maps.

Thats all the occlusion culling we're doing at the moment. I hope that for beta 2 i'll get some time to try hardware occlusion culling at the SceneObject/DTS level.

#2 If I have three rooms and one light in each room, is there a light leak from one room to another? I mean, is it possible to have a dark corridor while the lights in the adjacent rooms are on?

#3 @Sorin - At the moment the lights leak fully if they have no shadows. With shadows they only leak if the shadow misses some occluding geometry (something that can happen alot with the lower quality shadow projection methods).

While it is something you can work around as a designer it is still a pain to deal with. I would like to figure out a solution during the beta.

There are a few ways i can see us fix this.

1. Lean on the shadows to occlude lights from going thru walls into adjacent rooms. The problem here is that we need to keep fairly accurate shadows for most of the scene... not impossible, but more work than we would like. Also it doesn't work at all with Basic Lighting... those lights would always leak.

2. Add some simple zoning to DTS. This would at least keep lights from unconnected rooms from leaking, but it wouldn't keep lights from connected areas from going thru walls.

3. Precalculate some sort of light visibility at level design time.

None of the solutions sound ideal or simple to implement. I'm open to suggestions.

#4 You probably could study how C4 works, for what I remember they assign some sort of cubic areas around rooms for light zoning and also for geometry zoning. It's really not difficult and can be made inside the editor. For torque would be enough I think to make this zones in some 3d editor assigning some special name to them like we make for collision mesh. What do you think about it?

#5 Thanks for the update tom.

Sounds very much like it is in many common engines (the HL2 engine as a very good example of massive leaking through non-bsp geometry) and thus should be workable with.

Thought I fully agree on 3, there should be a "light debug mode" (similar to the bsp cull mode in TGE) which allows one to see the directly influenced areas of the light.

Optimum for performance in general naturally would be a designer controled room & connecting portal system. Not only for the light but for world updating (to me more impacting than culling due to the impact of animation, physics and particle system updates) in general.

#6 @Tom

The precalculation from the mission editor/level design is something I suggested to the 3DI guys to look at integrating. I felt that with their tech and how users work with Torque in general that it might be the most optimal flow that a majority of users would really enjoy working with. I am unsure if they have gone down that route or not, but it might be worth pinging them to see what their current plans are (just so that the same thing isn't done twice).

With regards to Occlusion Zones (I think that's what UE3 calls them), that would be a very useful thing to have in general, though I understand its a lot of work.

Also in case anyone complains about the whole "why does light cast through shapes if there is no shadow casting" almost all 3D lights that you see in highend 3D applications work this same way. So its not some wacky Torque thing.

@Marc

Tom's team (sorry I forget who exactly it was at Sickhead... James maybe?) integrated a cool little tool called Shadow Viz which allows you to see the density/compexity of a shadow map generated by a selected light. Its been very useful for sorting odd shadowing so that a person can correct it. Its not quite what you were suggestiong, but I thought I would mention that there are some tools going already to help with light and shadow casting.

#7 Thank you Logan for that.
Thats sounds like an interesting "start" or base to work with.

#8 @Andrea - I took a quick peek thru the C4 wiki. They do have a simple cube based zoning system with rectangular portals. We could leverage the existing zoning system within Torque to exposed zones and portals defined as special meshes within a DTS.

It seems like it would be a huge pain for artists to manage to me. Any other opinions on this?

@Marc - I can add an optional toggle to render the light volumes clipped against the world geometry. This should help show you if a point light is leaking into an adjacent room.

#9 www.umbrasoftware.com/index.php?videoreel

Thats what i want, looks so awesome, and fast :) *dreams*

#10 @Tom: It takes some time to setup a worlds in a manual system like that. But as it is pretty flexible it also offers a lot.

The gain from it is definitely large enough to justify the extra work especially if it is fullscale implemented. But already without that, the possibility to optimize what requires to be "pre-z-passed" should likely help lower end machines, shouldn't it?

Cases where it would help more than a little: large terrains with visually blocking terrain formations / forests / caves and large buildings for example.
if it is fully integrated, that means object update, rendering and networking, the gains would be seriously impacting the performance of the whole game in a positive way.

#11 I dont know how pertinent this is, but this view Occlusion blocker, with some simple modification (to allow it placed inside an mesh object yet still render the object that is hiding it) is working excellent for my TGEA experiments. I hide it inside a mesh shape, like a wall, and it certainly do block all rendered object on the other side. It should not take much to hook it onto dynamic object.

I may be missing the point, but Occlusion Culling do not seem that complex to me...

#12 @Tom

As cool as it would be to have a this in a DTS or Collada(DAE) shape, I think it might be a bit to ask for with regards to getting it fully suppored with the exporters. Plus what happens if you are trying to add this to a shape that say someone has purchased and cannot edit?

What might be useful for T3D users is having a shape that they can place in the mission editor. The user would have control over size/scale of the shape, its position and rotation and can then place as needed. A first implementation might simply be a set of primatives like a box shape, while a later step might be to allow users to add their own DTS/DAE shapes that they create and export as the proxy shape instead.

One thought as well might be to have options of what exactly the occlusion shape will exclude. The default setting could be everything, but I could see when its useful to allow certain types of data (ie. lights, ground terain, foliage/trees, water, DTS shapes, particles, etc.) to render outside of a particular occlusion zone a user has placed (say for example theres an important object in the distance you want the user to see).

#13 Well i don't think it would be terribly difficult to setup if we just use special names for zone/portal meshes in the Collada file.

Still i agree we would need editor support anyway and its the easier way to get into it.

What i want to avoid is having alot of crazy logic for connecting zones and portals. So maybe something as simple as whatever zones a portal overlaps are connected.

I've been peeking at the Crysis Area Docs for ideas.

http://doc.crymod.com/SandboxManual/GameAreas.html

#14 A tutorial video i found on Crysis VisAreas and Portals.

#15

Quote:So maybe something as simple as whatever zones a portal overlaps are connected.

+1 fanboy for the idea

Actually exactly what was on my mind on the previous posts. It is, at least to me, the intuitive and totally natural approach to the problem and what I've used ideawise for a long time even already back with Blitz3D and dx7.

#16 @Caylo - That's interesting... but isn't it just doing a ray cast between the camera and the object bounding box center? So you could easily have something that was quite visible yet because its center point is behind one of these occluders it would be culled.

Or am i missing something?

@Marc - Cool!

Any more opinions before i start to seriously consider the implications of the work i just got myself into?

#17 Just do it :D and do it well <3

#18 By the way I'm an artist and not a programmer, I wouldn't mind constructing occlusion zones around my rooms as long as it's easy as drawing boxes. Would be fast and easy. I mean if I'm used to make a huge level with lot of details making an additional box around a room wouldn't be such a loss of time and also that will give the advantage of more control in the optimization dept.
Since I'm not a programmer I would like to know if you think that using the BSP technology already present in torque would be useful in some way!!

#19 @Tom; I know it seems sloppy and simple but I have never noticed visual oddity's and have used it in some very complex scenes. Besides, think about how the conditions have to be 'just right' before it is actually noticeable anyhow. The view Occlusion blocker is for setting up large view blocker like walls, cliff, building plus size blockers (all the real small details should already cull from properly designed LOD).

If I have time later today/this week, for kicks, I hope to turn it into a VisArea, as in the above video, should not be to difficult (in theory).

#20 @Andrea - Well the old DIF format was built around zones and portals... you just have to have a good sealed DIF and put down portal brushes. Still it was error prone, hard to debug, and had crappy performance.

We would reuse some of the existing zone and portal support already present in Torque, but just add these new WorldEditor objects which you can manipulate in the editor.

If time permits we could allow you to also build these in your modeling app along with your DTS level as specially named meshes.

@Caylo - I'll be interested to see your results.