Mikkelsen and 3D Graphics

How to do more generic mixing of derivative maps?

2012-01-03T10:31:00.000-08:00

I have added a shader to the demo which shows how to do mixing of derivative maps in a more typical scenario in which auto bump scale is used and all derivative maps are using same base unwrap but using different scales and offsets on the texture coordinate. The auto bump scale is what allows us to achieve scale invariance like we are used to with normal mapping.

The location of the demo is still the same: source and binary. Also notice that dHdst_derivmap() can be made shorter by passing
VirtDim / sqrt(abs(VirtDim.x * VirtDim.y)) as a constant. Furthermore, this vector constant is ±1.0 when VirtDim.x == VirtDim.y. Finally, the scale and offset which is applied to the texture coordinate can be moved to the vertex shader. However, this requires the use of multiple interpolators so this might not be the preferred way.

So finally a no tangents bump demo is up!

2011-12-16T17:43:00.000-08:00

So I wrote a small demo of the no tangents bump mapping technique from my paper and Andy Davies has worked with me by supplying the Gothic window model and textures.

There is both a binary and source code available. However, it is a Direct3D11 sample so for those with older cards......get an upgrade!

When running the Gothic window you can toggle between height map and derivative map on the M key.
For the model on the right there are no options since it's doing triplanar bump mapping.
In other words it's generating texture coordinates from three planar projections and then mixing based on the normal which would be significantly more cumbersome to achieve using conventional tangent space based normal mapping since no one likes to store three sets of tangent spaces.

I would also like to say thank you to Rune Stubbe of Square Enix for pointing out that triplanar is a good application for my method!

Finally, the triplanar example on the right is using three different textures (one for each plane). There is a derivative map, a height map and a procedural function. For anyone who's still not getting this. There is no texture unwrap in the triplanar case! :)

I'd also like to point out that the shader on the Gothic window is using an auto-generated bump scale to match xNormal so this sample is a good reference for that as well. The triplanar is a good reference for seeing how you can mix different kinds of derivatives. And this includes scenarios where these are obtained from different texture spaces.

That's it for this time.

Oh no! Quads only!

2011-12-13T14:25:00.000-08:00

I have found in general it can be difficult to get hold of a control mesh that is quads only, well proportioned, and represents something "interesting".

For this reason I thought I'd make one available which was obtained by taking the third example from the bottom given here http://iat.ubalt.edu/summers/math/platsol.htm and then typing the given function:

2 - (cos(x + T*y) + cos(x - T*y) + cos(y + T*z) + cos(y - T*z) + cos(z - T*x) + cos(z + T*x)), T=golden ratio

into Maple and then having Maple apply marching cubes to triangulate it. A retopo of this mesh is available here:

http://jbit.net/~sparky/academic/icosym_ctrl_744quads.obj

Hope others will find this useful.

Derivative Maps in xNormal

2011-11-29T09:43:00.000-08:00

Version 3.17.8 of xNormal has just been released with a new map type called a Derivative map.

The primary goal with this new map type is to provide a map that can be used with a new method for bump mapping that does not use tangent spaces. There are many advantages to using this method.

1. Reduces foot-print
2. Is much better suited for synthesized surfaces/tessellation
3. Does not distinguish between regular geometry and tessellation.
4. Works with per pixel generated texture coordinates such as Tri-Planar Texturing.
5. No issues regarding multiple standards for implementation of tangent space generation.
6. Mirroring trivially works.
7. No need to recalculate tangent spaces on meshes with complex geometric deformations.

So how do you do this? It's actually fairly simple to throw into your own shader.
First I'd like to point out that the method is much more closely related to Blinn's bump mapping than it is to normal mapping. This implies that there is a bump scale, however, I'll explain in a moment how this can be auto-generated to work with derivative maps generated using xNormal.

So the shader code you use for derivative maps is still, essentially, listing 1 in my paper "Bump Mapping Unparametrized Surfaces on the GPU". The variables dBs and dBt are the derivatives of the height value with respect to screen-space. Now the screen-space derivative of the height map can be evaluated from a derivative map using the chain rule which I explained in my previous blog post. You don't have to understand
the math behind it. Using it is trivial since all you do is copy the shader code from the blog post and use it to replace the dBs and dBt in listing 1 (in the paper).

The one thing I forgot to mention in my previous blog post is that you need a bump scale that you apply to dBs and dBt. This can either be a user-defined one or an auto-generated one. Auto-generating the bump scale will make the work-flow more like what artists are used to with normal maps. To do this get the xNormal sdk and open the file examples\mikktspace\CMIKK_TangentBasisCalculator.cpp and grab the small function SuggestInitialScaleBumpDerivative() which returns fUseAsRenderBumpScale. Then you adapt this function to your own tools pipeline.

As for the dependency on texture resolution you can postpone the divide by sqrt(width*height) until the shader which will allow you to use the same mesh specific bump_scale as a constant for many different textures should you want to mix derivatives in the pixel shader. In fact height maps and derivative maps are much better suited for mixing than normal maps. Another option you have is keeping some maps as derivative maps and others as height maps. The screen space derivative of a height map is determined using a different approach such as listing 2 in the paper. But all of the final screen-space derivatives can be mixed together whether they came from one map type or the other.
Also note that if width and height are the same then the dependency on width and height is canceled since we also scale by these to obtain dBs and dBt as was shown in the shader code from my previous post.

Another thing I'd like to point out is that if you make your own implementation that auto-generates the bump scale and it's not the exact same method that is entirely ok. It will not result in any disasters unlike tangent space generation mismatch in normal mapping which results in unwanted hard edges in the lighting.

Finally, for those curious about the distinction between a derivative map and a normal map the derivative map represents the derivatives of the height map (dBdu, dBdv) while the normal map represents the normal of the height map normalize( (-dBdu, -dBdv, 1) ). However, in the context of baking from a hi-res model the distinction is more interesting. Unlike the conventional approach where the derivatives of the surface position (tangent and bitangent) are perceived to be normalized and perpendicular to each other we don't make this approximation for baking a derivative map. The reason is that using the more accurate non orthonormal basis is significantly more compliant with the synthesized basis used to perturb the normal in the pixel shader.

Derivative Maps

2011-07-27T15:21:00.000-07:00

For those interested in the paper Bump Mapping Unparametrized Surfaces on the GPU
which discusses an alternative method to normal mapping. I thought I'd comment on a few additional variants/use-cases.
For instance listing 2 computes the screen-space derivative of the height value. This can also be achieved using precomputed derivative maps. These texture space derivatives can be transformed to screen-space using the chain rule.

// set bFlipVertDeriv to true when texST has flipped t coordinate
int2 dim; dbmap.GetDimensions(dim.x, dim.y);
const float2 dBdUV = dim*(2*dbmap.Sample(sampler, In.texST).xy-1);

// chain rule
const float2 TexDx = ddx(In.texST);
const float2 TexDy = ddy(In.texST);
const float fS = bFlipVertDeriv ? -1 : 1; // resolved compile time
float dBs = dBdUV.x * TexDx.x + fS*dBdUV.y * TexDx.y;
float dBt = dBdUV.x * TexDy.x + fS*dBdUV.y * TexDy.y;

The advantage to using derivative maps is a better looking visual during texture magnification especially.
The downside is of course using two channels instead of one. Advantages to either method over conventional normal mapping is of course no precomputed tangent space is needed. There are no tangent space splits in the visible region and the method works whether the surface is tessellated or just a standard triangular model.

I also want to point out that one of the significant observations made in the paper is that the underlying parametrization is irrelevant. What determines Blinn's perturbed normal is the distribution of heights and the shape of the surface. Not how the distribution of heights or the surface are parametrized. This can also be exploited in a domain shader to calculate the new normal when displacement mapping.
To do this the derivative is, again, sampled from a precomputed derivative map. It is then transformed to the corresponding domain space derivative using the chain rule. Finally, the domain space derivatives are used as dBs and dBt in listing 1 where vSigmaS and vSigmaT are replaced with the domain space surface derivatives.

Morten Mikkelsen.