3D Graphics Papers


This page contains a listing of some of my papers, with links to their URLs.

It is common in real-time graphics to use tiling textures to represent large surface area however repetition is noticeable as can be seen here on the left. Using hex-tiling allows us to hide the repetition but requires a solution to hide the seams between adjacent hex tiles. This sample is a demonstration of my 2022 paper


which has been published in in JCGT. The method is an adaptation of the original work by Eric Heitz and Fabrice Neyret as well as Thomas Deliot and Eric Heitz.


In this paper from 2020 a new framework is proposed for layering/compositing of bump/normal maps including support for both multiple sets of texture coordinates as well as procedurally generated texture coordinates and geometry. Furthermore, we provide proper support and integration for bump maps defined on a volume such as decal projectors, triplanar projection and noise–based functions.

Surface Gradient Based Bump Mapping Framework


The paper below is my real-time 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.

2 comments:

  1. I wonder if using "normal map" instead of "bumb map" is still relevant ?

    - heightmaps gives more info and allows more
    - normal map is at least 2 times bigger and gpu bandwith and latency are the limiting factor nowadays
    - on current gpu fetching one or 4 pixel is the same if you fetch one perf wise

    Could we say normal map is a thing of the past ? like using LUT for normalizing ?

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete