[Bf-committers] bump mapping - white is down & black is up???
mikkelsen7 at gmail.com
Fri Feb 25 15:29:04 CET 2011
It would be extremely easy to fix this for just the most recently added bump
method should we choose to do it that way.
In render_texture.c in the function ntap_bump_compute() At the top
change the line:
float Hscale = Tnor*mtex->norfac;
such that it's negated:
float Hscale = -Tnor*mtex->norfac;
And then similarly in gpu_material.c in the function do_material_tex()
change this line:
norfac = hScale * mtex->norfac;
such that it is also negated:
norfac = -hScale * mtex->norfac;
I apologize for not making this a real patch but I am sitting at my gf's
Perhaps mario can cook one up? or I can do it later.
But anyway, if someone wants to try it out, That's all it takes.
On Fri, Feb 25, 2011 at 12:50 AM, michael williamson <
michaelw at cowtoolsmedia.co.uk> wrote:
> In pretty much everything out there the convention is "white is True,
> black is False"...
> in most DCC this equates to white being high (a bump) and black being
> low(a crevice)...see lightwave, 3ds max, maya and also note that this
> is consistent with the displacement map modifier in blender...
> On 25/02/11 08:18, Tom M wrote:
> > Is there a 'standard' - ie does every other 3d animation package use
> > the inverse of what we currently use?
> > LetterRip
> > On Thu, Feb 24, 2011 at 10:03 PM, Morten Mikkelsen<mikkelsen7 at gmail.com>
> >> So as you guys most likely know white means down and black means up when
> >> bump mapping in Blender
> >> which is kinda counter intuitive.
> >> However, we recently did a completely new implementation of bump mapping
> >> Blender
> >> and I was wondering, since we kept in the original bump mapping methods
> >> as available options, is there any good reason why we shouldn't let the
> >> bump mapping
> >> method use the more intuitive interpretation which is white is up and
> >> is down?
> >> We could just leave the legacy methods the way they are and only change
> >> for the most recent method
> >> of bump mapping (was added early this year).
> >> Anyway, was just a thought :)
> >> Cheers,
> >> Morten.
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers