limited range camera... optimisation idea

[wizzo]

Hi there

alright i had an idea and i'd like you folks to tell me what it's worth. As i don't have half of the skills needed to exploit my idea, i'd be great if someone could try it =)

The idea between Limited Range Camera is the same as a limited range light : i'll talk about if-statement as if we all have sm3.0, but, hey, in a few years we will. Plus, Humus showed us that dynamic branching could be achieved fairly on previous sm.

So basicaly, when you render a light with Phong Shading model, you first check if the fragment is in the light range. With Limited Range Camera, the test is not a radius test, but is achieve with a depth map; steps are :

1 - Render the level with texture, the fastest as possible, with depth test on
2 - Make a depth map from the camera's point of view, put it in a cubemap
3 - Render in the stencil buffer :
you get the vector that goes from the camera to the fragment, get its length
get the depth of the closest fragment from the depth cubemap
if the fragment is further than what the depth cubemaps says, do not render it
4 - Render the whole scene where stencil buffer says

The problem no 1 is to get a precise distance from the depth map.
Another is that you need a high res depth map : for a 1024x768 rendering mode, a 1024x1024 map is ok, but if you want higher res, i think you need 2048x2048.

condition of use : you must have a heavy load of work at fragment level for this algorithm to be efficient.

so here's the idea, tell me what you think of it. thanks in advance

wizzo

[dorbie]

This is already done/suggested by some people and it is much simpler in practice thanks to coarse z and early z test. Just draw the scene to the depth buffer then draw again shaded. Z buffer optimizations cull fragment work and save fill (potentially).

If you can sort front to back you may get most of the savings without the extra zfill pass. Exactly where the tradeoff is depends on sorting, scene layout and shader complexity.

You could optionally use occlusion querries in here to help with geometry load too.

If what you're suggesting isn't an improvement on this then it's a bit pointless.

[T101]

Apart from what Dorbie said - and he definitely knows better than I do - what's the point?

I presume you want to render fewer triangles to increase performance here. Isn't that what the far clipping plane is for?

The improvement I can see in your idea is this:

 Ordinary clipping:
*-----------|
--         /
  --      /
    --   /
      --/
 
Fixed:
*-------|
--      /
  --   /
    --/

OK, I admit, it's crappy artwork. What I mean, though, is that you're rounding the corners of the clipping volume, which means you'll just be clipping some extra geometry.
But I'd say the price you're paying for it is pretty big - rendering all that geometry at least once to make your 3D texture (albeit at a higher speed than the final render).

[wizzo]

To Dorbie:
yes the basic depth test does the work, but i thought for it to be very efficient, you need to sort polygons from front to back, which isn't possible dynamically. Was i thought was interesting with my technique was that there was no need to know the geometry.

To T101:
yeah the far clipping plane is there for that, but generally your far clipping plane is ... well, far. so the idea was to make sort of a dynamic far clipping plane.
what i dont understand is the 3d texture thingy : there is no 3d texture, what im saying is basically : do the same as for a shadow map (which is fast) and then draw the gemoetry with a shader that compare 2 distance, which is also fast.
finally i'm was only suggesting it in addition to other geometry culling system (portals, ...), so you wouldn't have to render ALL geometry each time.

wizzo

[V-man]

There is no need to know the geometry if you render to depth buffer only for pass 1.
No need for RTT, knowing precise distances or stencil buffer.

This is a well known technique and some cards optimize this, and I guess Doom 3 does this as well.
I think the cards in question would be the Geforce FXs series that have a special way of handling the fragments when color is masked.

[T101]

Yeah, you're right, you didn't say 3D texture, you said cubemap - which is if I remember correctly, basically 6 2d textures. My bad.
But with the camera looking in basically one direction, why would you need more than 1 - assuming the cubemap is really mapped to a cube?
I'd say the only point at which that becomes important is when your camera FOV becomes significantly more than 90 degrees wide (i.e. significantly more than 45 degrees in any direction) because then the distortion becomes significantly worse than with a cubemap.

So... what's wrong with moving the far clipping plane?

Also: if you cull or cut triangles, you'll still need to hide that fact visually using distance fog or lighting fall-off, right?
So, suppose you have a complex scene: when you look in one direction, you're going to have better visibility than in the other (without leaving that decision up to the scene designer). Assuming you don't get overall popping in your lighting or fog, because of the complexity, won't it look weird?

[wizzo]

To V-Man:
you're right, i guess i got wrong because i'm still much of a beginner, didn't get all the implications

To T101:
about the cubemap : in fact i just wanted to put it in a cube map because it sounded easier than in a 2d texture, i meant (but did not say, sorry) that the 5 other faces where blank, because out of the fov (depending on the fov, thats right)

about the far clipping plane : nothing is wrong with it =) i mean, yes, moving it is a good idea, but it has to be moved dynamically.

okok it was a bad idea (too complicated, just like many others), thanks for your answers,
wizzo

[davepermen]

it was not a bad idea, but it's possible to simplify it.. and the result is just the one that got mentoyed. but thte idea is the same

[wizzo]

yeah i guess i'm always thinking of too complicated things =) that does not match too well with 3d computing...

wizzo

[dorbie]

Wizzo your suggestion requires a depth pass first as a prerequisite and doing that means you don't need a sort for subsequent passes to save fill through hardware zbuffer optimizations, as V-man explained. As V-man says Doom3 does this but the initial motivation there is the zbuffer values for stencil volume depth testing, this also helps optimize fragment fill on all subsequent passes but I suspect Carmack's beam tree processing (illuminated_set n visible_set) is pretty good. This same thing has certainly been proposed and implemented *purely* as an optimization for shader fill.

It's not that the suggestion was bad, it's just that modern hardware already has zbuffer optimizations that make it redundant.