[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