tag:blogger.com,1999:blog-353209199042587902018-12-20T01:37:42.872-08:00Mikkelsen and 3D GraphicsMorten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-35320919904258790.post-71424959273587906032016-05-17T10:21:00.000-07:002016-05-17T10:30:34.797-07:00Fine Pruned Tiled LightingTiled lighting techniques have gained significant interest in recent years. However, a problem with tiled lighting techniques vs. traditional directx 9 styled deferred lighting (additive alpha blending) is the significant amount of false positives largely due to intersection testing using coarse bounding volumes. This is particularly relevant when supporting lights/volumes of different shapes such as long narrow spot lights, wedges, capsules etc. The downside to directx 9 style lighting is this approach does not work with forward lighting and having thousands of lights is extremely expensive due to setup cost per light and overlapping reads from gbuffer and overlapping writes to the frame buffer.<br /><br />During the development of Rise of the Tomb Raider (ROTR) we came up with a new tiled lighting variant which we named Fine Pruned Tiled Lighting (FPTL) which we describe in GPU Pro 7. There are many details to the full implementation discussed in the article and I will not go over them here but the main point is the cost of fine pruning can easily be absorbed by using asyncronous compute. This implies we obtain a light list with a very minimal amount of false positives almost for free.<br /><br />As explained in the article the technique will work with essentially any methodology such as deferred shading, pre-pass deferred, tiled forward and even hybrids between these. A <a href="https://github.com/wolfgangfengel/GPU-Pro-7/tree/master/02_Lighting/02_Fine%20Pruned%20Tiled%20Light%20Lists">demo sample</a> is available though it was written in vanilla directx 11 which implies the asyncronous compute part is left as an exercise for the reader! The demo shows a single terrain mesh lit by 1024 lights (heat map and fine pruning enabled by default). For simplicity the demo is setup as tiled forward though on ROTR we used a hybrid where we supported pre-pass deferred, tiled forward and conventional forward.<br /><br />When running the demo you will notice fine pruning enabled runs faster than disabled despite the fact that there is no asyncronous compute in the demo (since it is standard DX11). However, the improvement on speed is of course much more significant when asyncronous compute is used correctly.<br /><br />Other interesting aspects to the implementation is we determine screen-space AABBs around each light (regardless of type of shape) on the GPU. This allows us to reduce coverage significantly for partially visible lights (accellerates fine pruning) and reduces pressure on registers during light list generation (explained in the article). Additionally, we keep light lists sorted by type of shape to miminize chances of thread divergence during tiled forward lighting.<br /><br />For more information on the details....Buy GPU Pro 7! :)<br /><br /><br /><br /><br /><br /><br />Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com2tag:blogger.com,1999:blog-35320919904258790.post-52674702457096515152013-10-06T17:00:00.001-07:002018-08-27T12:21:31.673-07:00<b>Volume Height Maps and Triplanar Bump Mapping</b><br /><br /><br />I know it has been a while but I thought I would like to emphasize an easily missed contribution in my paper <a href="https://www.dropbox.com/s/l1yl164jb3rhomq/mm_sfgrad_bump.pdf?dl=0">Bump Mapping Unparametrized Surfaces on the GPU</a>. The new surface gradient based formulation (eq. 4) of Jim Blinn's perturbed normal unifies conventional bump mapping and bump mapping from height maps defined on a volume. In other words you do not have to bake such heights to a 2D texture first to generate<br />Jim Blinn's perturbed normal. The formula also suggests that a well known <a href="http://web.cse.ohio-state.edu/~shen.94/681/Site/Slides_files/p287-perlin.pdf">method</a> proposed by Ken Perlin is wrong. For a more direct visual confirmation a difference is shown in figure 2. The black spots on the left are caused by subtracting the volume gradient which causes the normal to implode. The result on the right is when using the new surface gradient based formulation and as you see the errors are gone.<br /><br />To give an example of how the theoretical math might apply to a real world practical case<br />let us take a look at triplanar projection. In this case we have a parallel projection<br />along each axis and we use a derivative/normal map for each projection.<br /><br />Let's imagine we have three 2D height maps.<br /><br />H_x:<span class="Apple-tab-span" style="white-space: pre;"> </span>(s,t) --> R<br />H_y:<span class="Apple-tab-span" style="white-space: pre;"> </span>(s,t) --> R<br />H_z:<span class="Apple-tab-span" style="white-space: pre;"> </span>(s,t) --> R<br /><br />The corresponding two channel derivative maps are represented as (dH_x/ds, dH_x/dt) and similar for the other two height maps. Using the blend weights described on page 64 in the <a href="http://www.slideshare.net/icastano/cascades-demo-secrets">presentation</a> by Nvidia on triplanar projections, let us call them w0-w2, the mixed height function defined on a volume can now be given as<br /><br />H(x,y,z) = H_z(x,y)*w0 + H_x(z,y)*w1 + H_y(z,x)*w2<br /><br />The goal is to use equations 2 and 4 on it to get the perturbed normal.<br />However, notice the blend weights w0, w1 and w2. These are not really constant.<br />They depend on the initial surface normal. In my paper I mention that the height map<br />defined on a volume does not have to be global. It can be a local extension on an open<br />subset of R^3. What that means (roughly) is at every given point we just need to know some local height map function defined on an arbitrarily small volume which contains the point.<br /><br />At every given point we can assume the initial normal is nearly constant within some small neighborhood. This is the already applied approximation by Jim Blinn himself.<br />Constant "enough" at least that its contributions, as a varying function, to the gradient<br />of H will be negligible. In other words in the local height map we treat w0, w1 and w2 as constants.<br /><br />Now to evaluate equation 2 using H as input function we need to find the regular gradient of H<br /><br />Grad(H) = w0 * Grad(H_z) + w1 * Grad(H_x) + w2 * Grad(H_y)<br /><br /><span class="Apple-tab-span" style="white-space: pre;"> =</span> w0*[ dH_z/ds<span class="Apple-tab-span" style="white-space: pre;"> </span> dH_z/dt<span class="Apple-tab-span" style="white-space: pre;"> </span> 0 ]^T +<br /> w1*[ 0 dH_x/dt dH_x/ds ]^T +<br /> w2*[ dH_y/dt 0 dH_y/ds ]^T<br /><span class="Apple-tab-span" style="white-space: pre;"> </span><br /> [w0*dH_z/ds + w2*dH_y/dt]<br /> = [w0*dH_z/dt + w1*dH_x/dt]<br /><span class="Apple-tab-span" style="white-space: pre;"> </span> [w1*dH_x/ds + w2*dH_y/ds]<br /><div><br /></div><br />Now that we have the gradient this can be used in equation 2 and subsequently equation 4. Another way to describe it is to use this gradient with Listing 3 in the paper.<br /><br />The derivation in this post is according to OpenGL conventions. In other words assuming a right hand coordinate system and Y is up. Furthermore, using lower left corner as texture space origin. Let me know if you need help reordering things to D3D.<br /><br /><br />Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com2tag:blogger.com,1999:blog-35320919904258790.post-31820112366066253972013-03-10T12:02:00.000-07:002018-08-27T10:55:18.503-07:00Links to my papers and some SummariesThe jbit.net server appears to be down still. So I have decided to write a post listing some of my papers and with links to their alternative urls.<br /><br />One paper some have been asking for recently is my skin rendering paper from 2010:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-Bol161eDs90/UTzCgsc8fwI/AAAAAAAAAB8/c7lssdiJ03Q/s1600/skin_joined.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://1.bp.blogspot.com/-Bol161eDs90/UTzCgsc8fwI/AAAAAAAAAB8/c7lssdiJ03Q/s400/skin_joined.png" width="400" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"></div><br /><br /><b><a href="https://www.dropbox.com/s/tn9b9tenykk650w/cbf_skin.pdf?dl=0">Skin Rendering by Pseudo-Separable Cross Bilateral Filtering</a></b><br /><br /><br />In this paper I show how to convert the <a href="http://http.developer.nvidia.com/GPUGems3/gpugems3_ch14.html">work</a> of Eugene d'Eon accurately into screen-space using the cross bilateral filter. The 2D filter region is chosen on a per pixel basis such that it represent a rectangular bounding box of a projected disc. The disc has a constant radius in mm and is tangent to the surface at the pixel. Also as mentioned in the paper I never bothered to use more than one separable Gaussian pass though Eugene suggests using six Gaussians. There is also a video available <a href="http://www.youtube.com/watch?v=D73H2le5HzY">here</a>.<br /><br /><br />Next there is the bump mapping paper and the accompanying <a href="https://www.dropbox.com/s/pfgin7kvcsjkhin/bumpdemo_src.zip?dl=0">source</a> and <a href="https://www.dropbox.com/s/dfthauvthg2deca/bumpdemo_bin.zip?dl=0">binary</a>.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-M3lgw_2Hlak/UTzDnDn-EfI/AAAAAAAAACE/FCfKWI084gs/s1600/marblebump.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-M3lgw_2Hlak/UTzDnDn-EfI/AAAAAAAAACE/FCfKWI084gs/s1600/marblebump.png" /></a></div><b><a href="https://www.dropbox.com/s/l1yl164jb3rhomq/mm_sfgrad_bump.pdf?dl=0">Bump Mapping Unparametrized Surfaces on the GPU</a></b><br /><br />In this paper I describe bump mapping on the gpu in a broader context which allows combining perturbations from all kinds of multiple unwraps and procedural fields. Since the subject has already been covered extensively in all my previous posts I will not go over further details here.<br /><br /><br /><br /><br /><br /><br />A different paper I wrote though somewhat more academic is the paper:<br /><br /><br /><b><a href="https://www.dropbox.com/s/u502mzmd1hmk8an/mm_brdf.pdf?dl=0">Microfacet Based Bidirectional Reflectance Distribution Function</a></b><br /><br />The point to me when I did this paper was developing a good solid understanding of what physically based specular reflection really is. The way I did this was by deriving the Torrance-Sparrow model from scratch. There is a frequent trend in the graphics community to consider physically based specular as essentially Fresnel and using the Beckmann surface distribution function. This leads me to believe a lot of people never read the Torrance-Sparrow <a href="http://inst.eecs.berkeley.edu/~cs283/sp13/lectures/TorranceSparrow.pdf">paper</a>. The paper does not attribute any major significance to the underlying choice of isotropic surface distribution function. An interesting fact which is less known is that you can remap from a beckmann to a normalized phong and you won't be able to tell them apart. The observation is made in my section 2.4 but is also an observation made on page 7 in a <a href="http://www.cs.cornell.edu/~srm/publications/EGSR07-btdf.pdf">paper</a> written by Walter B. et al..<br />In practice I have found for a normalized phong specular power of 8.0 and above there is no visible difference between the two.<br /><br />In regards to Fresnel, though relevant, the point to the Torrance-Sparrow paper was to dispute a previous model which attributes off-specular peaks to Fresnel exclusively. As is pointed out this model would not work for metals since in this case the Fresnel reflectance is closer to constant.<br /><br />To add to the irony a term which is often marginalized in the graphics community is the shadow/masking term also sometimes referred to as the geometry factor. It's ironic because this term is essentially the fruit of the Torrance-Sparrow paper. This term combined with the division by the dot product between the view vector and the normal is how the model predicts off-specular peaks.<br /><br /><br />I also wrote a long paper in which I set out to understand the <a href="http://graphics.ucsd.edu/~henrik/papers/bssrdf/bssrdf.pdf">work</a> of Henrik Wann Jensen and the <a href="http://graphics.ucsd.edu/papers/layered/layered.pdf">work</a> of Craig Donner:<br /><br /><br /><b><a href="https://www.dropbox.com/s/2wfpwl5dx0yia5g/mm_skin.pdf?dl=0">Skin Rendering: Reflectance and Integration</a></b><br /><br /><br /><br />It was a very long and hard road and I am having trouble coming up with something brief to say about the contents of the paper. It was very interesting to me academically yet at the same time I think though I achieved my goal I still arrived at the conclusion it wasn't necessary to understand the model to its core to do good skin rendering. Important things to know is that the reflectance profile should exhibit exponential decay so a spike followed by a broad base is important. Further we need most of the bleed in red, less in green and even less in blue (and of course no bleed in the specular).<br />That being said if you are interested in all the details that lead to the multi-pole based bssrdf this paper is a very good walk-through of the underlying details.<br /><br />I wrote my masters thesis at DIKU (University of Copenhagen).<br /><br /><b><a href="http://image.diku.dk/projects/media/morten.mikkelsen.08.pdf">Simulation of Wrinkled Surfaces Revisited</a></b><br /><br />It's a rather extensive analysis of bump mapping in its original form. Many things are studied but a core element component is normal mapping on low resolution geometry today and why we get unwanted lighting seams/discontinuities in our results. This is due to tangent space not being calculated the same way in game engines and bake tools which causes bad errors in practice. Ideally, baking tools must allow developers to customize them such that the game developer can ensure the tool does the exact inverse of what the game engine and shader does. Such functionality has since then been added to the very popular baking tool <a href="http://www.xnormal.net/1.aspx">xNormal</a>.<br /><br /><br />Finally some oldies:<br /><br /><a href="https://www.dropbox.com/s/8s1vl79a2l7atln/ps2_normalmapping.pdf?dl=0"><b>DOT3 Normal Mapping on the PS2</b></a><br /><br /><b><a href="http://image.diku.dk/projects/media/morten.mikkelsen.07.pdf">Separating Plane Perspective Shadow Mapping.</a></b>Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com11tag:blogger.com,1999:blog-35320919904258790.post-55735637918088572722012-02-24T14:55:00.026-08:002018-08-27T10:43:34.342-07:00Parallax/POM mapping and no tangent space.<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-tab-span" style="white-space: pre;">I thought I would do yet another follow up post regarding thoughts on <a href="https://www8.cs.umu.se/kurser/5DV051/VT09/lab/parallax_mapping.pdf">Parallax</a>/POM mapping <a href="http://mmikkelsen3d.blogspot.com/2011/07/derivative-maps.html">without the use of conventional tangent space</a>. </span><span class="Apple-style-span" style="white-space: pre;">A lot of the terms involved are terms we already have when doing bump mapping using either derivative or height maps.</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"><br /></span></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;">// terms shared between bump and pom</span></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float2 TexDx = ddx(In.texST);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float2 TexDy = ddy(In.texST);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float3 vSigmaX = ddx(surf_pos);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float3 vSigmaY = ddy(surf_pos);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float3 vN = surf_norm; // normalized</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float3 vR1 = cross(</span><span class="Apple-style-span" style="color: #38761d;">vSigmaY, </span><span class="Apple-style-span" style="color: #38761d;">vN</span><span class="Apple-style-span" style="color: #38761d;">);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-style-span" style="color: black;"><span class="Apple-style-span" style="color: #38761d;">float3 vR2 = cross(</span></span></span><span class="Apple-style-span" style="color: #38761d;">vN, </span><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-style-span" style="color: black;"><span class="Apple-style-span" style="color: #38761d;">vSigmaX</span></span><span class="Apple-style-span" style="color: black;"><span class="Apple-style-span" style="color: #38761d;">);</span></span></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-style-span" style="color: black;"><span class="Apple-style-span" style="color: #38761d;">float fDet = dot(</span></span></span><span class="Apple-style-span" style="color: #38761d;">vSigmaX, </span><span class="Apple-style-span" style="color: #38761d;">vR1</span><span class="Apple-style-span" style="color: #38761d;">);</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><br /></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">// specific to Parallax/POM</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float3 vV = vView; // normalized view vector in same space as surf_pos and vN</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float2 vProjVscr = (1/</span><span class="Apple-style-span" style="color: #38761d;">fDet</span><span class="Apple-style-span" style="color: #38761d;">) * float2( dot(</span><span class="Apple-style-span" style="color: #38761d;">vR1, </span><span class="Apple-style-span" style="color: #38761d;">vV), </span><span class="Apple-style-span" style="color: #38761d;">dot(</span><span class="Apple-style-span" style="color: #38761d;">vR2, </span><span class="Apple-style-span" style="color: #38761d;">vV) );</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;">float2 vProjVtex = </span><span class="Apple-style-span" style="color: #38761d;">TexDx*</span><span class="Apple-style-span" style="color: #38761d;">vProjVscr.x + </span><span class="Apple-style-span" style="color: #38761d;">TexDy*</span><span class="Apple-style-span" style="color: #38761d;">vProjVscr.y;</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: #38761d;"><br /></span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">The resulting 2D vector vProjVtex is the offset vector in normalized texture space which corresponds to moving along the surface of the object by the plane projected view vector which is exactly what we want for POM. The remaining work is done the usual way.<br /><br />The magnitude of vProjVtex (in normalized texture space) will correspond to the magnitude of the projected view vector at the surface. To obtain the third component of the transformed view vector the applied bump_scale must be taken into account. This is done using the following line of code:<br /><br /><span style="color: #38761d;">float vProjVtexZ = dot(vN, vV) / </span><span style="color: #38761d;">bump_scale</span><span style="color: #38761d;">;</span><br /><br />If we consider T the texture coordinate and the surface gradient of T a 2x3 matrix then an alternative way to think of how we obtain vProjVtex is through the use of surface gradients. One per component of the texture coordinate since each of these represent a scalar field.<br /><br /><span style="color: #38761d;">float2 vProjVtex = mul(SurfGrad(T), vView)</span><br /><span style="color: #38761d;"><br /></span><br />The first row of SurfGrad(T) is equal to (1/fDet)*(TexDx.x*vR1 + TexDy.x*vR2) and similar for the second row but using the .y components of TexDx and TexDy. In practice it doesn't really simplify the code much unless we need to transform multiple vectors but it's a fun fact :)<br /><br />Note that one of the observations made in the <a href="https://www.dropbox.com/s/l1yl164jb3rhomq/mm_sfgrad_bump.pdf?dl=0">paper</a> is that the surface gradient of a given scalar field can be obtained using any parametrization of the surface and the field (<b>eq. 3</b>). For a scalar field defined on a volume we can (though not required) use <b>eq. 2</b> instead to obtain the surface gradient.<br /><span style="color: #38761d;"><br /></span></div>Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com1tag:blogger.com,1999:blog-35320919904258790.post-81000241847178555322012-01-03T10:31:00.005-08:002018-08-27T10:45:47.168-07:00How to do more generic mixing of derivative maps?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.<br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-uS0z5QWh7pQ/TwPV4ErjyyI/AAAAAAAAABE/MWvlfazbLXw/s1600/mix_shot.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="229" src="https://2.bp.blogspot.com/-uS0z5QWh7pQ/TwPV4ErjyyI/AAAAAAAAABE/MWvlfazbLXw/s320/mix_shot.jpg" width="320" /></a></div><br />The location of the demo is still the same: <a href="https://www.dropbox.com/s/pfgin7kvcsjkhin/bumpdemo_src.zip?dl=0">source</a> and <a href="https://www.dropbox.com/s/dfthauvthg2deca/bumpdemo_bin.zip?dl=0">binary</a>. Also notice that dHdst_derivmap() can be made shorter by passing<br /><i>VirtDim / sqrt(abs(VirtDim.x * VirtDim.y))</i> as a constant<i>.</i> Furthermore, this vector constant is ±1.0 when <i>VirtDim.x == </i><i>VirtDim.y</i>. 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.<br /><br />One relevant thing to notice here is that the numerator <i>VirtDim </i>is a float2 and not part of the bump scale. It serves to convert the height derivatives to the normalized texture domain from which we apply the chain rule. The factor <i>1 / sqrt(abs(VirtDim.x * VirtDim.y)) </i>on the other hand <b>is part of the bump scale</b>. The distinction is subtle when doing bump mapping but becomes relevant when we do <a href="http://mmikkelsen3d.blogspot.com/2012/02/parallaxpoc-mapping-and-no-tangent.html">parallax mapping</a>.<br /><br />If for instance you are using derivative maps made with xNormal or you are just using this way of <a href="http://mmikkelsen3d.blogspot.com/2011/11/derivative-maps-in-xnormal.html">auto calculating a bump scale</a> then the expression for the bump scale is:<br /><br /><i>bump_scale = g_fMeshSpecificAutoBumpScale / sqrt(abs(VirtDim.x * VirtDim.y))</i> <br /><br />where g_fMeshSpecificAutoBumpScale is the square root of the average ratio of the surface to normalized texture area. There is code which shows how to calculate this in the demo. The final value bump_scale is the same as the value which is returned by <span style="background-color: white; color: #222222; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13px; line-height: 18px;"><a href="http://mmikkelsen3d.blogspot.com/2011/11/derivative-maps-in-xnormal.html">SuggestInitialScaleBumpDerivative() in xNormal</a>.</span>Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com0tag:blogger.com,1999:blog-35320919904258790.post-53991974085372564422011-12-16T17:43:00.000-08:002018-08-27T10:41:08.571-07:00So finally a no tangents bump demo is up!So I wrote a small demo of the no tangents bump mapping technique from my paper and <a href="http://www.metalliandy.com/">Andy Davies</a> has worked with me by supplying the Gothic window model and textures.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-6dstBd4uv4k/Tuvvcwxb0wI/AAAAAAAAAA4/_S4y9uD2TQg/s1600/scr_shot.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://4.bp.blogspot.com/-6dstBd4uv4k/Tuvvcwxb0wI/AAAAAAAAAA4/_S4y9uD2TQg/s400/scr_shot.jpg" width="400" /></a></div><br />There is both a <a href="https://www.dropbox.com/s/dfthauvthg2deca/bumpdemo_bin.zip?dl=0">binary</a> and <a href="https://www.dropbox.com/s/pfgin7kvcsjkhin/bumpdemo_src.zip?dl=0">source code</a> available. However, it is a Direct3D11 sample so for those with older cards......get an upgrade!<br /><br />When running the Gothic window you can toggle between height map and derivative map on the M key.<br />For the model on the right there are no options since it's doing <a href="http://www.slideshare.net/icastano/cascades-demo-secrets">triplanar</a> bump mapping.<br />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.<br /><br />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!<br /><br />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! :)<br /><br />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.<br /><br />That's it for this time.Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com16tag:blogger.com,1999:blog-35320919904258790.post-42159745205918488952011-12-13T14:25:00.000-08:002011-12-13T16:11:55.805-08:00Oh no! Quads only!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".<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-SGOgc9pB5j4/TufU95wwozI/AAAAAAAAAAw/wIpo2CGPZBU/s1600/scr_shot.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="http://4.bp.blogspot.com/-SGOgc9pB5j4/TufU95wwozI/AAAAAAAAAAw/wIpo2CGPZBU/s400/scr_shot.png" width="400" /></a></div><br /><br />For this reason I thought I'd make one available which was obtained by taking the third example from the bottom given here <a href="http://iat.ubalt.edu/summers/math/platsol.htm">http://iat.ubalt.edu/summers/math/platsol.htm</a> and then typing the given function:<br /><br /><div style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;"><span class="Apple-style-span" style="font-size: x-small;"><i><b>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)), </b><b>T=</b><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">golden ratio</span></i></span></div><br /><div style="-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">into <span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px;">Maple and then having Maple apply marching cubes to triangulate it. A retopo of this mesh is available here:</span></div><br /><a href="http://jbit.net/~sparky/academic/icosym_ctrl_744quads.obj">http://jbit.net/~sparky/academic/icosym_ctrl_744quads.obj</a><br /><br />Hope others will find this useful.Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com2tag:blogger.com,1999:blog-35320919904258790.post-31618512038418125402011-11-29T09:43:00.000-08:002018-08-27T10:46:52.571-07:00Derivative Maps in xNormalVersion 3.17.8 of <a href="http://www.xnormal.net/">xNormal</a> has just been released with a new map type called a Derivative map.<br /><br />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 <b>does not use tangent spaces</b>. There are many advantages to using this method.<br /><br />1. Reduces foot-print<br />2. Is much better suited for synthesized surfaces/tessellation<br />3. Does not distinguish between regular geometry and tessellation.<br />4. Works with per pixel generated texture coordinates such as <a href="http://www.slideshare.net/icastano/cascades-demo-secrets">Tri-Planar Texturing</a>.<br />5. No issues regarding multiple standards for implementation of tangent space generation.<br />6. Mirroring trivially works.<br />7. No need to recalculate tangent spaces on meshes with complex geometric deformations.<br /><br />So how do you do this? It's actually fairly simple to throw into your own shader.<br />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.<br /><br />So the shader code you use for derivative maps is still, essentially, listing 1 in my paper <a href="https://www.dropbox.com/s/l1yl164jb3rhomq/mm_sfgrad_bump.pdf?dl=0">"Bump Mapping Unparametrized Surfaces on the GPU"</a>. 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 <a href="http://mmikkelsen3d.blogspot.com/2011/07/derivative-maps.html">blog post</a>. You don't have to understand<br />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).<br /><br />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 <b>examples\mikktspace\CMIKK_TangentBasisCalculator.cpp</b> and grab the small function SuggestInitialScaleBumpDerivative() which returns fUseAsRenderBumpScale. Then you adapt this function to your own tools pipeline.<br /><br />As for the dependency on texture resolution you can postpone the divide by <i>sqrt(width*height)</i> 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.<br />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 <a href="http://mmikkelsen3d.blogspot.com/2011/07/derivative-maps.html">post</a>.<br /><br />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.<br /><br />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 <i>(dBdu, dBdv)</i> while the normal map represents the normal of the height map <i>normalize( (-dBdu, -dBdv, 1) )</i>. 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.Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com4tag:blogger.com,1999:blog-35320919904258790.post-30317815169825245772011-07-27T15:21:00.000-07:002018-08-27T10:42:27.802-07:00Derivative MapsFor those interested in the paper <a href="https://www.dropbox.com/s/l1yl164jb3rhomq/mm_sfgrad_bump.pdf?dl=0">Bump Mapping Unparametrized Surfaces on the GPU</a><br />which discusses an alternative method to normal mapping. I thought I'd comment on a few additional variants/use-cases.<br />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.<br /><br /><span class="Apple-style-span" style="color: #444444;"> </span><span class="Apple-style-span" style="color: #38761d;">// set bFlipVertDeriv to true when texST has flipped t coordinate</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>int2 dim; dbmap.GetDimensions(dim.x, dim.y);</span><br /><span class="Apple-style-span" style="color: #38761d;">const float2 dBdUV = dim*(2*dbmap.Sample(sampler, In.texST).xy-1);</span><br /><span class="Apple-style-span" style="color: #38761d;"><br /></span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>// chain rule</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>const float2 TexDx = ddx(In.texST);</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>const float2 TexDy = ddy(In.texST);</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>const float fS = bFlipVertDeriv ? -1 : 1;<span class="Apple-tab-span" style="white-space: pre;"> </span>// resolved compile time</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>float dBs = dBdUV.x * TexDx.x + fS*dBdUV.y * TexDx.y;</span><br /><span class="Apple-style-span" style="color: #38761d;"><span class="Apple-tab-span" style="white-space: pre;"> </span>float dBt = dBdUV.x * TexDy.x + fS*dBdUV.y * TexDy.y;</span><br /><br />A demo incl. source is available for <a href="http://mmikkelsen3d.blogspot.com/2011/12/so-finally-no-tangents-bump-demo-is-up.html">download</a> and a method for achieving parallax occ./POM mapping, without tangent space, is described in this <a href="http://mmikkelsen3d.blogspot.com/2012/02/parallaxpoc-mapping-and-no-tangent.html">post</a>.<br /><br />The advantage to using derivative maps is a better looking visual during texture magnification especially.<br />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.<br /><br />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.<br />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.<br /><br /><br />Morten Mikkelsen.Morten S. Mikkelsenhttp://www.blogger.com/profile/11647723969880785609noreply@blogger.com14