[Bf-committers] blender bumpmapping

M.G. Kishalmi lmg at kishalmi.net
Sun Jan 2 11:22:43 CET 2011


hi list,

first, a short disclaimer:
 while only being 'Pinky' in this grand scheme of bump domination,
  really 'The Brain' is M. S. Mikkelsen (sparky), doing all the math!
   I just happen to know blender, tiny parts of its code and how to
compile it =)

so we started to work on an improvement of the bumpmapping code aka 'newbump'
 and it turned out it has quite a bunch of flaws.
'oldbump' did a better job in some places, but wasn't all too
physically correct.


best you check this comparison of blender bumpmap variants:
 -> http://kishalmi.servus.at/3D/bumpcode/

to avoid confusion, we named our code 'sparkybump',
 but it's probably going to replace 'newbump' in the long run.

note1: oldbump looks much softer with a factor of -5.0
 - too soft, if you ask me. I mean -5.0 !?...
   should result in one hell of a bump, given the image used -
but sparkybump produces similar results with factors around -0.2
 except its fade out is linear, rather than quadratic.

note2: the row at the very bottom is using 5 taps for calculations,
 giving slightly better results at the cost of speed.
  it's disabled in the patch, but left for reference + testing.
   for further insight into this -> read sparkys paper.


you'll be glad to hear, that this also fixes some normal-related bugs:

 [#24591] Artefacts/strange normal mapping when anti-aliasing is on
 [#24735] Error at the Normal function.
 [#24962] Normals are not calculated correctly if anti-aliasing is off
 [#25103] Weird artefacts in Normal


it still needs more testing, finetuning and cleaning up,
 but it basically works and for those of you that want to give it a spin,
  here's a WiP patch:
 -> http://www.pasteall.org/17942/diff


that's it. now let the feedback roll in! =)

cheers,
 mario


More information about the Bf-committers mailing list