[Bf-committers] bump mapping - white is down & black is up???

Morten Mikkelsen mikkelsen7 at gmail.com
Fri Feb 25 20:56:47 CET 2011


I have attached a proposal for a patch.
I put in a comment as well.



On Fri, Feb 25, 2011 at 6:29 AM, Morten Mikkelsen <mikkelsen7 at gmail.com>wrote:

> It would be extremely easy to fix this for just the most recently added
> bump mapping
> 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
> laptop.
> 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>
>>  wrote:
>> >> 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 for
>> >> 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
>> new
>> >> bump mapping
>> >> method use the more intuitive interpretation which is white is up and
>> black
>> >> is down?
>> >> We could just leave the legacy methods the way they are and only change
>> it
>> >> 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
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
-------------- next part --------------
Index: source/blender/render/intern/source/render_texture.c
===================================================================
--- source/blender/render/intern/source/render_texture.c	(revision 35189)
+++ source/blender/render/intern/source/render_texture.c	(working copy)
@@ -1899,8 +1899,14 @@
 	TexResult ttexr = {0, 0, 0, 0, 0, texres->talpha, NULL};	// temp TexResult
 
 	const int fromrgb = ((tex->type == TEX_IMAGE) || ((tex->flag & TEX_COLORBAND)!=0));
-	float Hscale = Tnor*mtex->norfac;
 
+	// The negate on Hscale is done because the
+	// normal in the renderer points inward which corresponds
+	// to inverting the bump map. The normals are generated
+	// this way in calc_vertexnormals(). Should this ever change
+	// this negate must be removed.
+	float Hscale = -Tnor*mtex->norfac;
+
 	// 2 channels for 2D texture and 3 for 3D textures.
 	const int nr_channels = (mtex->texco == TEXCO_UV)? 2 : 3;
 	int c, rgbnor, iBumpSpace;
Index: source/blender/gpu/intern/gpu_material.c
===================================================================
--- source/blender/gpu/intern/gpu_material.c	(revision 35189)
+++ source/blender/gpu/intern/gpu_material.c	(working copy)
@@ -1081,7 +1081,12 @@
 						
 						if( mtex->texflag & MTEX_BUMP_TEXTURESPACE )
 							hScale = hScaleTex;
-						norfac = hScale * mtex->norfac;
+
+						// The negate on norfac is done because the
+						// normal in the renderer points inward which corresponds
+						// to inverting the bump map. Should this ever change
+						// this negate must be removed.
+						norfac = -hScale * mtex->norfac;
 						tnorfac = GPU_uniform(&norfac);
 						
 						if(GPU_link_changed(stencil))


More information about the Bf-committers mailing list