Top of the line vs Old crap

Started by
31 comments, last by riuthamus 11 years, 3 months ago

So we are running into a bit of an issue. Our point lights are still not working. Here is a skinny on what we have:

1) we have deffered rendering.

2) we are attempting to do point lights with log depth included ( this could be the wrong method )

3) we are using sharpDx and C#

4) dx10 and 11 are the only things we are attempting to use. We are not using any dx9 methods

So, the issue:

We are getting some odd errors and none of the tools we are using are showing a reason as to why. We can not find out if the issue is the code or the methods we are using or the math. We lack the understanding of the things in place to really grasp what is going on. Perhaps one of you more skilled people here can assist?

We are attempting to avoid a complete breakdown of ever system... as that seems to be the last result.

What our goal is:

We are attempting to keep the deffered rendering while using the point lights ( we would like to have many of them in a single location ). We are under the impression that to do this we must use dx11 methods. If we are unable to use these methods it could hamper some of our other systems since we are sending some of our ui elements through dx11.1 stuff.

Other issues:

PIX has been abandoned by MS ( apparently ) and dx11.1 support from nvidia will not exist for until nsight 3.0 ( which could take some serious time to get ) This means we would need to revert back to dx11 and if we do that we lose the methods for controlling our UI that let us have special effects as well as we take a big FPS hit when ui elements are open ( probably another issue with how we are doing it )

Final Thoughts:

So all in all, we have some compounded issues that need to be resolved. Right now the thing seems to be a mess. If we can get the point lights to work with the current setup we will be good.... Any and all help would be very appreciated.

Advertisement

So, the real issue is that your logarithmic depth buffer isn't working (or your code to reconstruct position from depth isn't working), but somehow switching to DX 11.1 will solve this, which brings more issues? What's the theory behind the 11.1 fix?

To check if the issue is the logarithmic-depth code, or the reconstruct-position code, have you tried switching temporarily back to a 'standard' depth buffer and checking whether you can correctly reconstruct positions from it?

With your logarithmic depth values, are you computing them per-vertex or per-pixel?

Have you considered using a floating-point depth-buffer instead of a regular one with the logarithmic mapping? A 32-bit floating point buffer with near/far reversed gives better precision than a 24-bit logarithmic one anyway, with the down-side being that you lose your 8 bits of stencil buffer.

So, the real issue is that your logarithmic depth buffer isn't working (or your code to reconstruct position from depth isn't working), but somehow switching to DX 11.1 will solve this, which brings more issues? What's the theory behind the 11.1 fix?

Eh, our move to 11.1 was for the UI issues we were having. We pushed the UI elements to a new rendering technique with 11.1 and it only creates 8fps lag now instead of 100+, again probably because of our methods... but thats for another topic tongue.png I think I was trying to express that we may need to revisit how we are doing the UI in case we need to revert back to 11 or 10, but yeah that should be in another topic.

The issue is that the only way we know how to fix it would be to revert to something not dx related or get rid of the deferred rendering. So, your suggestions are very helpful. We will try them out today and I will let you know what results we get. Thank you for your continued help.

It mostly works without the logarithmic depth. I say mostly because I can get it working by disabling the specular calculation (which is resulting in an output value of 1#QNAN0 or something like that). With the logarithmic depth on, it doesn't work at all. The logarithmic value is calculated in the vertex shader and then written to a standard depth buffer. I think the usual DX9 way is to actually write that out to a separate render target since you can't read from a depth buffer in DX9. Since we're using DX11, we're using an actual depth buffer, so we don't actually write to it ourselves, so I'm not sure if that's considered as calculating it per-vertex or per-pixel (I would assume per-pixel).

I might give the reversed floating point buffer a try, I was under the impression that log depth was the best but I guess not.

Hey there,

unfortunately I can not say much about reconstruction of logarithmic depth because I never used it before. When it comes to pointlights and reconstruction I'm using linear depth in a seperate Rendertarget since I'm still on DX9 but if I have some time in the next days I may change some shadercode in my engine to see if it works for me.

For your issues with PIX and DX11: Maybe you can have look at the Intel Graphics Performance Analyzer. It says it has full Windows 8 support so I suppose it has also DX11.1 support. I'm using it by myself from time to time but on my rather old machine there are some problems with it so I normally stick with PIX.

Sadly Intel GPA doesn't seem to work. It starts up fine, unlike all the other tools, but it doesn't display its HUD and ctrl+f1 doesn't bring it up.

So I got some time in the morning to do some tests. I implemented the log depth and reconstruction in my engine and it showed up completely without lighting as I expected so I found some information in this post:

http://outerra.blogspot.de/2012/11/maximizing-depth-buffer-range-and.html

In the comments Kemen said that the reconstructed depthvalue is already in viewspace so I switched the construction of the worldposition in two parts. First multiplying the screenspaceposition with the depthvalue and then with the inverseprojection. But when I tried to get the worldposition with multiplying it with the inverseviewmatrix according to PIX the worldpos is still a bit off. Maybe I have an error somewhere else and I will look into it if I have more time but for now I wanted to share my results maybe you can get it working with that.

Obviously Intel GPA has different problems on different systems. For me I cannot view DepthBuffers and Stencil in the FrameAnalyzer. If you dont need the HUD you can try pressing Ctrl+Shift+C to make a snapshot for analyzing.

Wow, nice find. That is more or less what we were aiming for so this might just be what we needed.

I couldn't find any actual tutorials on how to do reversed z-depth so I just tried switching the near and far values on the viewport and changed the depth comparison to GreaterEqual. DirectX promptly yelled at me for having a viewport with a MinDepth > MaxDepth. It renders but fog stopped working and if I look at the depth buffer in the debugger, it's just pure black (though who knows if it's actually even showing me the right thing, the debugger is so buggy I wouldn't be surprised if it isn't). Reversing the fog distance values (from .999-1 to 0.1-0) results in a 100% fog covered scene.

I also tried the suggestion from that blog for the log depth, I couldn't get that to work either. I'm not really sure when/if I'm still supposed to do the position/w part. I tried it with and without, in different places, among other things. Pretty much all I get is a light that is invisible until your actually inside its radius, and then you see some not-very-correct shading.

Pressing ctrl+shift+c in Intel GPA doesn't do anything either. It's pretty much as if the program isn't running at all.

If I'm not wrong the reversed z Method just means that you write (1- z/w) into the buffer instead of the standart z/w because floating point values have slightly more precision close to 0 than close to 1 so you get a better distribution when the depth is reversed.

You could also go with linear-z and a 32bit Buffer which should have the best precision but I cannot recall a comparison between logdepth and linear so I could be wrong.

Thats exactly what I experienced. I was thinking about the pos/w part too. My conclusion was that after the multiply with the inverseview w should be 1 so if it's necessary than after the first multiply with the inverseprojection.

There is also AMDs Gpu Per Studio but I cannot say what it supports or measures or what else it can do because it only support DX10 and up and I'm still using DX9 as I said so I never took a look at it.

This topic is closed to new replies.

Advertisement