wiki topic: nvidia gffx info

Nice demo, Zed. I get around 15-25 fps on a 6800 (84.12). The rocks are very cool, like the grass and all the shadows on everything, too ;-).

I thought I had a crash, but it was just an inordinately long start-up time :smiley: .

“I thought I had a crash, but it was just an inordinately long start-up time”
yeah sorry i should of mentioned that, it precalculates quite a bit but saves it on disk , so next time its a faster startup keys 1-6 turn things off/on.
though like i mensionted ive improved that app a bit now (better cascading shadowmap implementation, + also faster )
anyways to whet your appetite about CC ive just stuck up some new screenshots (last 4)
hmmm just looking now, noticed an error in the appleseeds no being lit correct, it never ends :frowning: . also im starting a new job soon working from 10pm->6am so i doing know how this is gonna affect my ability to code (so it might be a while before the next demo comes out)
http://uk.geocities.com/sloppyturds/CaptainCourgette/GameMedia.html

zed, could you let us know how you’ve done your cascading shadowmaps?

theyre pretty common sense theres no tricks involved im using 3x2048 textures in that demo i think (that is using the same texture 3x)
what specifically do u want to know?
FWIW someones writing a paper on the subject ( i dont know when it will be out though )

specifically, how do you decide which map to sample from for a given object/fragment?
Or do you use multipass?

well u only have sample from one shadowmap since u dont wanna create eg 3-5x 2048x2048x24bit uncompressed shadowmap textures just for the suns shadows (which is a lot of memory)

for each lights frustum (from the CSMs) render all the geometry within to a depthmap + then switch to the cameras viewpoint + render all the light recieving geometry (usually the same geometry as the shadowcasters) ie just like normal shadowmapping.
repeat this with each of the CSM frustum’s

start with the closest frustum to the camera (best quality shadows since they cover the smallest area) and work outwards

Originally posted by zed:
[b]
// Hardware limitations

  • The EXT_depth_bounds_test extension is only available with gffx5900 + 5950 the rest of the gffx line aint capable
    [/b]
    I’m not sure about this one any more. I know it was the case that the driver only exposed this on 5900 when it came out, but it appears to be showing up on 5600/5700 now.

Originally posted by zed:
well u only have sample from one shadowmap since u dont wanna create eg 3-5x 2048x2048x24bit uncompressed shadowmap textures just for the suns shadows (which is a lot of memory)
Well that’s 36mb, which isn’t all that much memory to devote to shadows. The cheap card sitting in my current machine has 256mb of memory, and that’s today…next year it will be even less of a problem.

Originally posted by zed:
for each lights frustum (from the CSMs) render all the geometry within to a depthmap + then switch to the cameras viewpoint + render all the light recieving geometry (usually the same geometry as the shadowcasters) ie just like normal shadowmapping.
repeat this with each of the CSM frustum’s…

Wow, that’s a lot of rendering each frame.
The method I’ve been thinking about is nesting the shadowmaps (as implied by carmack), and updating them over many frames rather than every frame if only the viewpoint is moving.
I must admit, I hadn’t even considered that brute force approach. I suppose it depends on the scene being rendered…small objects that don’t cross the boundries between two frutums.
Anyway, I’m dragging this thread off topic, so I shall stop.

I’m not sure about this one any more. I know it was the case that the driver only exposed this on 5900 when it came out, but it appears to be showing up on 5600/5700 now.
ta, im pretty sure it wasnt supported in my gf5200 ( i could check if necesaary)
also ive noticed FBO + mipmapped cubemaps dont seem to work. dont know if this is cause im doing it wrong or what.

The cheap card sitting in my current machine has 256mb of memory, and that’s today…next year it will be even less of a problem.
next year u will want 4096x4096 sized shadowmaps. also 3 frustums aint enuf, eg u will notice in the demo if youre on top of the hill looking out sometimes far away parts aint shadowed (thus can be solved with 4 frustums, but i figured the extra performance hit wasnt worth it)

anyways its not that much more rendering, its only meshes that straddle the boundry between 2 frustums that need to be rendered twice. so maybe an extra 20-40% rendering comapred to a single frustum.
but its not so back cause depth passes only are fast.
also spreadoing out the rendering over serveral frames is one of those ideas that sounds good until u try it, but u must update every frame or else its crap (unless maybe youre running at 100fps + updating every 2 frames ie 50hz maybes not to bad, but normally its very glaring to see an object + its shadow is outta sync). ive tried it before and it doesnt work visually (i now have the option in my game to spread the updating of the envmap over several frames and it looks not that great, and envmaps are much harder to notice than shadows)

btw what does nesting help, it only helps in instances where offscreen objects are casting there shadows into the scene. but even then theres places where it wont work eg sunlight 5 degrees above the horizon. eg so u have a tree a km away casting a shadow into the scene. u
could do a bias with the SM frustums if the sun is behind the viewer ( u have to sorta do this anyway, ie take the suns position relative to the camera dir into consideration when u decide what dir to focus the Sms on if u want optimal results)

small objects that don’t cross the boundries between two frutums.
aye!!?, a lot of objects will cross a frustum, esp for the nearer frustums where the overlap is great (~50%) u just have to render it in both frustums…
hmmm shall i go to the pub and watch the kiwis vs oz $10bet on nz for a win 12points less, return $47.50 (i think oz will win though)

Well the idea, with the cascading approach, is that you don’t have to update all the shadow maps every frame. Compare it to geometry clipmaps. If the viewpoint is moving slowly then you get plenty of time to update the highest detail shadowmap, but if the viewpoint is moving fast, you have plenty of low resolution shadowmap to tide you over until the high resolution one is rendered as the viewpoint slows down.
Read the geometry clipmaps paper to get an idea of how they could be adapted to shadowmaps.