Normal mapping implementation

[Lord Crc]

Thanks SATtva!

Here's a small sample of how to use it:

Code: Select all

Texture "Tex.002_float" "float" "normalmap"
   "string filename" ["normal_mapping\\Scene\\00001\\xnormals_normals.PNG"]
   "float gamma" [1.00000000000000]  # <-- VERY IMPORTANT
   "string mapping" ["uv"]
   "float udelta" [0.000000000000000]
   "float uscale" [1.000000000000000]
   "float vscale" [-1.000000000000000]
   "float vdelta" [0.000000000000000]


MakeNamedMaterial "Material.001"
   "texture bumpmap" ["Tex.002_float"]   # Use as regular bump map
   "color Kr" [0.69999999 0.69999999 0.69999999]
   "string type" ["mirror"]

edit: Pushed my initial implementation. Let's see if I managed to miss something

[moure]

Thanks a lot Lordcrc

Here is my first test , absolutely successful, Carved with alpha map some details in a 6 million polys plane and extracted the map. Applied it in a ....one (or maybe 4) poly plane and here is the result after 5 minutes of rendering. Notice the shadows and the reflections

Also i include the normal map in case anyone wants to make a test. Had to 7zip it cause it was 12 mb.

EDIT: I guess the bump amount when you use a normal map works as a percentage, i had to put it to 1 to get the correct amount of it in contrast to when using regular height maps that white is 1 meter and you have to scale it to 0,005 for example to get correct results.

[moure]

Another test, this time i uvmapped a cube (with some subdivisions) and made an normal map with the help of nvidias normal map plugin for photoshop http://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop
Again the results are great even on edges there seems to be no issue at all.

[jensverwiebe]

Jup, seems fine. Here a little test with normalmap created with NMG ( normal map generator freeware ):

Jens

[Lord Crc]

Thanks for testing guys! And thanks for the scene Moure, it'll come in handy when nailing down those last issues.

EDIT: I guess the bump amount when you use a normal map works as a percentage, i had to put it to 1 to get the correct amount of it in contrast to when using regular height maps that white is 1 meter and you have to scale it to 0,005 for example to get correct results.

Yes, this is because the scale is "baked" into the normal map to begin with. You can think of normal maps as "relative bumps" while height maps as "absolute bumps". As such the scale for normal maps is relative, while absolute for height maps.

[J the Ninja]

And yes, combining normal and bump maps definitely works. Multimix is quite handy for stacking them, and you can scale down your bump map from right within the texture:

Screen shot 2011-07-18 at 11.23.49 AM.png (17.56 KiB) Viewed 1466 times

The torus with its normal map and a blender_clouds (voronoi crackle) bump map:

[Lord Crc]

Good news everyone!

mfoxdogg managed to put me in contact with Morten Mikkelsen, which has written a thesis on bump mapping, with weight on sampled normal maps. He assured me that my current method will be fine for "plain" normal maps (like the ones Moure has used here), but will fail for sampled normal maps (as in the torus I posted).

To render the sampled normal maps correctly it's absolutely essential that the tangent space used during reconstruction matches the tangent space used during sampling ("baking"). In order to make this easier, Morten has created some open source code to consistently create "proper" tangents for meshes, even if vertex order is changed etc. Blender and xNormal now uses his code, and thus I think we should do as well.

In order to support his code, we'll also need a vertex welder (he has one available for that too), as his tangent space code returns an unindexed mesh back.

In addition we'll need to add two new vectors to the RayDifferential class: "tangent" and "bitangent". I propose we add another constructor which accepts these, the old ones just normalize dpdu and dpdv. These new fields will then be used when transforming the normalmap normal back into object space, instead of the current dpdu, dpdv.
edit: Hmm can we just reuse dpdu,dpdv directly for this in GetShadingGeometry? I forgot that the shading geometry's dpdu,dpdv doesn't actually follow u or v.

Since this will require the storage of an additional vector per vertex (the bitangent can be recovered on the fly), I think we should make a parameter to control this behavior. It should then be enabled for "baked" meshes only.

[jeanphi]

Hi,

In GetShadingGeometry dpdu and dpdv are only used to have a coordinate system to compute the shading normal, we could use any coordinate system there (in case there are no UV coordinates we already fall back to a random system), so there's no problem using the tangent bitangent space for that, quite the contrary.
Actually this might be the occasion to rearchitect the UV stuff so that the raydifferential doesn't depend that much on the UV map and we compute UV stuff when needed with support for more than 1 UV set per mesh.

Jeanphi

[syndaryl]

Actually this might be the occasion to rearchitect the UV stuff so that the raydifferential doesn't depend that much on the UV map and we compute UV stuff when needed with support for more than 1 UV set per mesh.

Hurray!

[Lord Crc]

Mind if I commit the added fields to RayDifferential I needed? It now works, and I'd rather have the working code in the repo, we can then refactor it afterwards. It adds two vectors and a float.

I'm adding my current results. First Blender's results, just for comparison. Next up is the Lux results. Compared to BI I think it's quite good indeed.

I still have to clean up the code a wee bit (debug code ftw!).

A BIG thanks to Morten Mikkelsen for his assistance!