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 <[email protected]>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 <
> [email protected]> 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<[email protected]>
>> 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
>> >> [email protected]
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> > _______________________________________________
>> > Bf-committers mailing list
>> > [email protected]
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> _______________________________________________
>> Bf-committers mailing list
>> [email protected]
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
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))
_______________________________________________
Bf-committers mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-committers
