[Bf-committers] Re: parallaxmap error

[Alfredo de Greef]

Ton wrote:
> However, I think you've misunderstood the purpose of

> "Warp" as currently coded.
> I didn't aim at parallax mapping at all (nor as  
> special support for normal maps), but wanted to
> provide a method to 
> deform texture coordinates, like how normals can be
> influenced or how  
> displacement mapping works.
> For that reason the normal vector output of  
> textures is directly applied to the texture
> coordinates of the next  
> channel. This is useful in many cases, but mostly
> just for artistic  
> control. It was a feature I liked to have a long
time
> before, not  
> related to normal maps.

This isn't related to normal maps either, you can
still use regular height maps as I said in the
previous mail.
btw, Sofar the usage of normalmaps in Blender (at
least that I have seen) is not really different from
bumpmapping, it is more a shortcut to not have to
calculate the normals in code. It would probaly really
be more of use with normalmaps created directly from
meshes, not images, then you might as well use regular
bumpmapping.
In any case, the impression I got (and others as well
it seems) from the changelog pictures about 'warp',
was that this was somehow supposed to be similar to
parallax mapping, and also the subject has come up now
several times now on this and the funboard mailing
list as well as blender.org, so I thought I might as
well create a patch for those wanting to experiment
with it.

> A parallax mapping option should reside next to
that,
> it's something very different, as your code below 
> already illustrates;

Actually, I made another mistake when comparing it
with your code. It is in fact possible to get a
reasonably similar effect to parallax maping with your
code as well. The setup in the example blendfile
cannot be used for comparison for this purpose, then
the result will be really radically different. To get
a similar effect with your code, you should copy the
normalmap to the first channel set to warp, not the
heightmap of course, and then the effect can be quite
similar, but still not quite the same. But it might be
good enough, so you might as well forget about this
patch...

> float tvi[3], bh = mtex->warpfac*(0.5f -
(Tr+Tg+Tb)*0.333333333f);
> VECCOPY(tvi, shi->view);
if (shi->vlr && shi->vlr->ob)
Mat4Mul3Vecfl(shi->vlr->ob->imat, tvi);

As I said in my previous mail, there should be another
line here:

Normalise(tvi);

And for the example blend the warpfactor then needs to
be set lower, about 0.1 or less.

> warpvec[0] = tvi[0] * bh;
> warpvec[1] = tvi[1] * bh;
> warpvec[2] = tvi[2] * bh;

> What I don't understand is;
>
> - What is the reason for averaging the RGB output of

> textures? How can  
> texture RGB output be of interest for modulating a 
> displacement?

The reason is to get a bump height value that is all.
For procedural textures that don't return color by
default Tin should be used I guess, so the code has to
be adapted for that case too, but since Tin is not set
when used with images (unless set to NoRGB of course)
I had to average the colors.

It does not do actual displacement, only modify the
texture coords to look at the position where it
'could' be (it is only an approximation) if it were
really displacement mapped.
The heightmap should do the warping, then those warped
coords should be used to look up the normal for the
bumpmap as well as the color. So you can't just set
the normalmap to warp if you are going to use the
normalmap for bumpmapping as well, unless you copy it
to the next channel.
Look at the original pdf that explains the process:
http://www.infiscape.com/rd.html

> - I assume this is a special case for normal maps?
If
> that's true, the  
> 'warp' as used here should be applied to the same 
> channel... and then  
> still, what's averaging RGB doing with it?
> - Or, is this is a generic trick for any texture
type
> in Blender?

Already answered all that above.

> I can experiment a bit with this to check on the
best
> way to integrate  
> it. And, BTW, I'm also already working on killing
all
> these ugly globals from texture code :)

Never mind, as I said above, while not exactly the
same, your code can be used to emulate the effect more
or less too, so forget about it, you probably have
more urgent code to look into.

Alfredo


		
__________________________________ 
Do you Yahoo!? 
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com