#light pre-pass

[fdastero-blog]

normal mapping without precomputed normal

Update 4:

For cubes my method will definitely work. The partial derivative of P with respect to x will always be aligned to T, because we're working with a cube here. So we that can be use for T. THen we can just cross product N and T to produce B. 

For the general case we can't assume that the dFx is aligned to T, so my method cannot work. A solution to that can be found in that link I posted earlier to gamedev.net, which comes from ShaderX5, is a the general solution for normal mapping without precomputed normal (Note: it's an optimized solution of computing the inverse matrix to derive T and B).

....

Update3:

actually the per triangle encoding thing won't work. it's really stupid. I was going to store this in the color channel per vertex. That won't work because this vertex could belong to the triangle that faces either direction....

....

Update2:

I'm not so sure about dx being the tangent. dx is change of the interpolate value with respect by to screen x. This may not be aligned with one of the edges? Need to to think about this

Update: On second thought, I will just modify the c++ code to write a code to denote the normal direction and pass that as a per vertex color. I already pass material code in the x component of color per vertex anyway. This way I only do this for cubes. For normal character mesh the T and B vectors are pre-computed per vertex as usual.

....

In my engine for cubes I do away with storing per vertex normal in order to save up on bandwidth and instead compute the normal in a pixel shader using dx,dy. Problem is normally for tangent space based normal mapping one pre-compute the tangent and bitangent vectors per vertex. That's a luxury I don't have. 

So how to solve? One way I could do is store a code per triangle because I'm working with cubes and there are only 5 possible normal directions for those. This involves modifying the current SurfaceMesh to take an code per triangle. I figure I could do this by using an vertex index to store the code, thus each triangle consists of 4 indices. When constructing the triangle skip every 4th index. But I'm lazy, I don't want to modify c++ code right now.

So the only option left is to compute the tangent basis per pixel. How to do this? What is a tangent basis matrix anyway? It's a matrix such that Af = { f(e1), f(e2), f(e3)} where f is a linear map which maps the standard basis into some other vector. So f(e3) maps e3 into the normal. So at each pixel we can find dx, dy, of the pixel. Then compute the normal N. Using Gram-Schmidt process we can find the bitangent, assuming that dx is the tangent. I believe we can assume dx is the tangent because it's the partial derivative with respect to screen space x along a interpolated surface (this gives a tangent in view space).

I found a post here also doing this I don't understand how he is computing the tangent basis skimming it. (http://www.gamedev.net/topic/539061-solved-normal-mapping-without-precomputed-tangents/)

Does it work? I think it ought to work because I said a matrix is Af. So if f(e1), f(e2), f(e3) forms an orthonormal basis, then f(e3) maps e3 into the normal, and f(e1), f(e2) maps the respective standard basis into S and T in tangent space. 

[fdastero-blog]

deferred lighting in viewspace

Last week I was working on doing deferred lighting. I'm at the point now where I can write the light buffer generating shader. The input into the light buffer shader is the G buffer (mini), the G buffer is generated by outputing the normal R,G,B and linear depth A into a float16 buffer. The format for this buffer is not final since I'll test different formats later on.

Anways, in order to write the light buffer shader, we need to reconstruct a position from the G buffer--meaning we need to figure out which space we're going to do our lighting computation in, viewspace or worldpsace. I've decided to do it in view space for now and still leaving open the possibility of worlspace light computation later on.

There are several ways to reconstruct the position of a pixel (texel?) in viewspace. One can work with the screenspace position and transform it back into view space, by doing some similar triangle thing with the view frustum.

http://jcoluna.wordpress.com/2011/01/27/reconstructing-view-space-position-from-depth/

Or you can do things in viewspace, you can read up on this here:

http://mynameismjp.wordpress.com/2010/09/05/position-from-depth-3/

...

Actually, I didn't spend too much time reading those links. I'm just going to try my own thing here and if it doesn't work then I will read those links. But it should be pretty simple if you work in viewspace (actually, just from looking at the diagram in the 2nd link, this is what I'm doing). For some arbitrary 3d light volume, the idea is to transform vertices into viewspace and pass it to the vertex interpolator. The interpolated positions in the pixel shader are the positions of the light volume in viewspace. Now if we have the far clip plane plus linearized depth of the scene, then to reconstruct the view space position of the G-buffer given the view space position of the light volume, the G buffer position is:

(X', Y', Z * farClip). Where X', Y' are from light volume viewspace position and Z is the linear depth, farClip the farClip distance. Why does it work? Z the linear depth is proportional to far clip. Also because we're trying to compute light parameters of the position corresponding to the depth in G buffer, i.e. we need to "light" the G buffer. Thus there is a correspondence between the light volume and the G buffer, there is a relationship between G buffer and light volume. It could be distance, inclusion, etc, etc.

[fdastero-blog]

more implementation details: light pre-pass

After slacking off (running errands) for a good part of the day, I'm at the point where I can write the light buffer shader (ref: http://diaryofagraphicsprogrammer.blogspot.com/2008/03/light-pre-pass-renderer.html), finally!

A little bit on how I'm generating the light geometry. In my case, I'm rendering 3D geometry to represent the light volume into a light buffer. For starters I will not worry about efficiency issues* so I will be using the excellent Ogre Procedural addon to generate the light volume mesh. I create a bunch of sphere geometries, associate it with a physics object, then just inject the light out into the world in the view direction at the mouse cursor. Well, they're scene nodes, nodes that are not attached to the root. In the deferred shading phase, I just attach them manually to the root and detach when done. Like I said, this is just for starters--I can worry about generating massive number of these later on.

That's generating the actual light geometries. I still need to write the shader to output the light buffer.

The shader:

attach the G buffer from step one. For each vertex, transform eye direction into view space. In the pixel shader, multiply eye direction in view space by linear depth (from G Buffer) to recover pixel position in view space. Compute the light parameters and output to light buffer (for HDR use Float16 RGBA. For reference, see above link.

*Actually, this is the dynamic light part. After I get this to work I will be using this in my "radiosty" setup.

[fdastero-blog]

light pre-pass practical implementation notes

Looked at how to do this in Ogre some more. 

There were some issues I wasn't sure about like whether the Z buffer were shared between RenderToTextures. 

This thread on Z buffer sharing seems to answer that:

http://www.ogre3d.org/forums/viewtopic.php?f=4&t=53534

So here is the current implementation plan for light pre-pass:

-Setup RTT.

The RTT I will need are the mini "G" buffer. They will be a single RGBA FP16 texture storing both the normal and depth as FP16s. If depth precision is not enough then perhaps try MRT to two textures: RGBFP16 and R_FP32. 

-Deferred lighting stages

In my custom update method which I talked about a few post back. I will need to do a custom call sequence. I think I want to do all the rendering first, followed by update render queue calls. If I do it this way it will speed up the render because of the fire and forget nature of making calls to the GPU. (I forgot which is the order though, I'm sure drawing then calling update render queue is what I want.)

1) Render To Texture the mini "G" buffer.

Set the scheme to MiniG on the viewport of the RTT. (I'm not going to worry about materials that doesn't support this since everything I'm doing is custom).

2) Render the light buffer.

I'm not sure exactly how I want to do this yet. I guess for start I will just use the issue RenderSystem operations to render the light geometry. I can check the deferred shading example for some hints. 

What I really want is use the instancing pipeline for this. My lighting system is custom anyway so this is the most efficient for my case. What I plan is to keep light buffers the same way I have voxel buffers. Then using instancing, I translate each light volume in the vertex shading by using translation and scaling to correspond to the position and shape of the light volume. 

3) Another geometry pass.

Do another pass on the main render window, setting scheme to mainpass, and also sample from light buffer.