I haven't tried with megapov, but what you're saying is that in
standard pov, the bug is with normal_maps... Well it isn't: I've just
tried rendering a file with two identical normals, one inside a
normal_map and the other outside and sure enough when I scale the whole
scene up, the one inside the normal_map doesn't change while the one
outside looks completely different...

	Now, here's how I understand things: when you scale a height_field by a
constant value (say 5), what pov does is promote the 5 to <5, 5, 5>
therefore the height_field is 5 times deeper as well as 5 times wider
(which keeps the slope unchanged, I agree). But when you scale a normal
by 5, the way pov does it is equivalent to scaling by <5, 1, 5> (I
haven't looked at the code, so I'm not sure why it's that way, but
that's what the result look like) which does change the slope...

	Bottom line: I believe that your reasoning is sound, but that your
conclusion is false: if Nathan has changed it so that it always behaves
as if it was in a normal_map, then he has indeed the right of it.

		Jerome

PS: If anybody is interested in wild speculations, here's how I would
explain the bug in the official version. Keep in mind that I haven't
looked at the code so this might be completely stupid...

I'll assume we're speaking about a plane { y, 0 } with a normal. When
you scale it by 5, it gets promoted to <5, 5, 5> but the y component
doesn't matter since the plane is flat. Then pov computes the normals:
it evaluates the pattern to determine the relative amount of
perturbation, then uses the depth given as a float parameter to
determine the total amount of perturbation. The problem is that the
values returned when evaluating the pattern don't take scale into
account (the scale only affects the point at wich the pattern is
evaluated, *not* the returned value) and this value is akin to the depth
of the height field so it should have been scaled too... That's what I
mean when I say that the result is similar to a scale <5, 1, 5> as far
as the normal is concerned.

-- 
*******************************

* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message