clipka wrote:

> Question is, do those normal maps carry /absolute/ or /relative/ values? 
> That is, are these coordinates in true X;Y;Z space (subject only to 
> transformations applied to the whole object), or are they rather to be 
> interpreted in U;V;N space?

 From what I've read, and the normal map I have it seems to hold true 
that it is in the U;V;N space,

> If they carry absolute values, then the whole thing should be as easy as 
> eating pancakes (and should actually give better results than POV-Ray's 
> current bump mapping implementation).
> 
> If they carry relative values, then they should still be about as easy 
> to implement as it would be to fix the major flaw of POV-Ray's bump 
> mapping implementation.

On both fronts, this is good to hear :)

> I wouldn't be all too surprised if both variants were in use out there.

That really wouldn't surprise me one bit.

> That's probably because while it is darn easy to convert a bump map into 
> a normal map, the reverse needs some more math (and may actually be 
> impossible in some cases; there are things you can do with a normal map 
> that you can't do with a bump map, e.g. an endless slope around a 
> cylinder).

Right, it requires integration, but the math on that isn't terribly bad, 
just takes a bit of processing power.

>> I need to sit down and write a small app that will do it. Maybe 
>> support for normal maps can go into POV 4's suggestion box? Unless 
>> it's trivial to add to 3.7, I'm guessing not, due to the way normals 
>> work (though, some normal patterns do have special normal perturbing 
>> functions...)
> 
> Theoretically it shouldn't be much of a problem: Normal maps are just 
> another description of how to mangle the geometric surface normal. To 
> the contrary, it should actually be even easier: With bump maps, you 
> have to first evluate at least three pixels to get the local slope in U- 
> and V-direction; with normal maps, you get the same information in a 
> single pixel.

Right. It's rather simple to take the RGB values, and alter the normal 
at the point of ray->surface intersection to get the new normal.

> The problem here is that POV-Ray doesn't even treat bump maps properly. 
> But it shouldn't make a worse job on normal maps either.

I had no idea POV-Ray was handling bump-maps incorrectly. Interesting, 
I've only skimmed the code for POV-Ray, so I wouldn't know... At the 
time, I was more interested in poking around with the root solver code.

> (The biggest obstacle might actually turn out to be that the term 
> "normal map" is already occupied in POV-Ray for a totally different 
> thing ;-))

Yep. Finding an acceptable grammar for the feature would be a problem... 
But it isn't like that hasn't happened before, material_map, for 
instance, doesn't exactly mean what it says.

normal_pattern, much like pigment_pattern, perhaps? Though I can't see 
using basic patterns as a normal map...

Post a reply to this message