Some phong lighting with shadowmapping. Looks like this:
Available here:
http://esprit.campus.luth.se/~humus/
Available here:
http://esprit.campus.luth.se/~humus/
New demo
- Thread starter Humus
- Start date
Humus said:Some phong lighting with shadowmapping. Looks like this:
Available here:
http://esprit.campus.luth.se/~humus/
WOW.......Nice one......
Mintmaster
Veteran
Humus, I read your blurb about the texture formats and your solution. I assume that's for the shadow maps, right?
I was thinking about splitting the precision into multiple channels like the way you did so that I could get more precision on the 8500. However, no matter how I looked at it, it didn't theoretically work. Doesn't that screw up the filtering of the shadow map?
For example, suppose you have a depth of 255 in one texel, and a depth of 513 in adjacent texel (I'm using only integers). The first is stored as (R,G) = (0,255), and the second is stored as (R,G) = (2,1), and the full precision depth is reconstructed in the PS as 256*R+G. If x is the fractional lerp factor between the texels, the texel read will be (R,G) = (2x, 256*(1-x)-1), with R and G rounded to integer values. You can see the the reconstructed depth will hardly be a linear interpolation between 255 and 513, but rather a discontinous pattern even worse than a step function:
600
|--------------------**---
|-----------------------**
|------**-----------------
|---------**--------------
|-------------**----------
|-----------------**------
|**-----------------------
|---**--------------------
|===============
200
My best try for a text graph
It should be three parallel lines. The y-axis is the reconstructed depth, and the x-axis has x going from 0 to 1. Of course, what we want is a line from (0,255) to (1,513). Otherwise, you can get worse artifacts what you were initially trying to avoid with low precision shadow maps.
Or was this all a waste of breath? Are you disabling texture filtering? That would create very blocky shadow outlines, though. If you found some other workaround, I'd like to know.
I was thinking about splitting the precision into multiple channels like the way you did so that I could get more precision on the 8500. However, no matter how I looked at it, it didn't theoretically work. Doesn't that screw up the filtering of the shadow map?
For example, suppose you have a depth of 255 in one texel, and a depth of 513 in adjacent texel (I'm using only integers). The first is stored as (R,G) = (0,255), and the second is stored as (R,G) = (2,1), and the full precision depth is reconstructed in the PS as 256*R+G. If x is the fractional lerp factor between the texels, the texel read will be (R,G) = (2x, 256*(1-x)-1), with R and G rounded to integer values. You can see the the reconstructed depth will hardly be a linear interpolation between 255 and 513, but rather a discontinous pattern even worse than a step function:
600
|--------------------**---
|-----------------------**
|------**-----------------
|---------**--------------
|-------------**----------
|-----------------**------
|**-----------------------
|---**--------------------
|===============
200
My best try for a text graph
It should be three parallel lines. The y-axis is the reconstructed depth, and the x-axis has x going from 0 to 1. Of course, what we want is a line from (0,255) to (1,513). Otherwise, you can get worse artifacts what you were initially trying to avoid with low precision shadow maps.Or was this all a waste of breath? Are you disabling texture filtering? That would create very blocky shadow outlines, though. If you found some other workaround, I'd like to know.
Yeah, I know, the filtering isn't ideal for packing data like this. I do use a linear filter anyway though. In practice however I found that it did improve precision, artefacts went away. For most pixels you'll have very similar depths in adjacent pixels, so I suppose it's only in extreme cases it doesn't work.
Mintmaster
Veteran
I'm a bit surprised that it helped so much. Maybe the consequences are more apparent when the shadow caster and reciever are closer together.
Anyway, how high is the resolution in your shadow maps? They look pretty good in your demo. Is it possible to render onto a multisample texture? That should help stop aliasing and jerky borders on the shadows of moving objects, should you use lower resolution shadow maps.
Also, have you tried ATI's native shadow map support, or do they not have an extension yet? I thought they now support the same shadow maps as the GF3/4.
Anyway, how high is the resolution in your shadow maps? They look pretty good in your demo. Is it possible to render onto a multisample texture? That should help stop aliasing and jerky borders on the shadows of moving objects, should you use lower resolution shadow maps.
Also, have you tried ATI's native shadow map support, or do they not have an extension yet? I thought they now support the same shadow maps as the GF3/4.
OpenGL guy
Veteran
This is not possible in D3D due to API limitations, I don't know about OpenGL. There are solutions for D3D, but they come at a price.Mintmaster said:
Mintmaster said:
I use 512x512x6.
It should be possible to use WGL_ARB_multisample on a render target. Last time I checked though it was only supported on the framebuffer though, but as far as I know it's going to be supported in the future at least. I think nVidia supports this already.
I haven't tried the normal shadow maps even though they are supported. Mostly because it only works with spotlights.
Mintmaster
Veteran
OpenGL guy said:
Damn! I was hoping D3DRS_MULTISAMPLEANTIALIAS would allow it, but you're right. That's a real shame, because it's often the render to texture operations that need the most antialiasing, since performance issues often require lower resolution images. I had some plans that needed antialiased rendering to textures to work best.
Do you think this will change with DX9? I suppose I could just do manual supersampling, but that sort of sucks, and it's rather slow.
Similar threads
- Deleted member 2197
- Tools and Software