Sunday, March 10, 2013

Links to my papers and some Summaries

The 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.

One paper some have been asking for recently is my skin rendering paper from 2010:

Skin Rendering by Pseudo-Separable Cross Bilateral Filtering

In this paper I show how to convert the work 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 here.

Next there is the bump mapping paper and the accompanying source and binary.

Bump Mapping Unparametrized Surfaces on the GPU

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.

A different paper I wrote though somewhat more academic is the paper:

Microfacet Based Bidirectional Reflectance Distribution Function

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 paper. 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 paper written by Walter B. et al..
In practice I have found for a normalized phong specular power of 8.0 and above there is no visible difference between the two.

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.

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.

I also wrote a long paper in which I set out to understand the work of Henrik Wann Jensen and the work of Craig Donner:

Skin Rendering: Reflectance and Integration

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).
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.

I wrote my masters thesis at DIKU (University of Copenhagen).

Simulation of Wrinkled Surfaces Revisited

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 xNormal.

Finally some oldies:

DOT3 Normal Mapping on the PS2

Separating Plane Perspective Shadow Mapping.


  1. Hi, will Separate Perspective Shadow Mapping work for directional lights?

    I saw, that in the paper there lz which is supposed to be finite?


  2. So the short answer is yes it will work but in equation 7
    you need to use det(A_33) and det(B_33) instead of
    det(A_34) and det(B_34).

    This way will also work for point lights but for directionals it's a requirement since det(A_34) is in this case zero. Since det(A_34) is zero equation 4 is already simplified without using substitution.

    Let me know if you have more questions I'd be happy to answer them. That paper is a blast from the past :)

  3. Looks like the dropbox link to "Bump Mapping Unparametrized Surfaces on the GPU" is dead. I'd love to take a look at that paper.

    I managed to find a summary online which was enough to implement it, and it works great. Humourously enough, I'm coming at it from the opposite angle, of wanting lower accuracy. Often in Renderman, you would just compute a displaced position and then recompute the normal from the new surface derivatives, which is theoretically maximally accurate. In practice though, the main place where you see a difference between that and your bump mapping is when the displacement is so extreme that things start self intersecting or otherwise screwing up. It looks like it will be very handy to have a simple convenient approach that seems quite robust.

    So thanks a lot for coming up with a nice way of looking at this and doing the derivation, and hopefully I can actually see it sometime!

    1. Hmmm...could you try the link again? It should work.

  4. Oh sorry, I just realized I'm an idiot - my office blocks Dropbox.

    I'll check it out at home - thanks!

  5. This comment has been removed by a blog administrator.

  6. Hi, I read your thread on gamedevnet, and found this blog.

    I am interested in looking at the illum.h file written on that thread, since the link is broken. Is it still possible to get access to it ?

    1. There's a bump demo available in this post:

      You can get either binary or source. Both contain the file you're looking for.

  7. This comment has been removed by the author.

  8. This comment has been removed by a blog administrator.