|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
> In article <3aad1701@news.povray.org>, Geoff Wedig
> <wed### [at] darwin epbi cwru edu> wrote:
>> I didn't think it would. I only added it because it kept saying "Normal
>> type not defined"
> Because you were specifying a float value when it expected a normal
> pattern or normal identifier.
>> I know. I was trying to take a pigment I made with a proximity and
>> use it in the normal instead. I knew I'd have to jiggle the
>> variables, but since it didn't work at all...
> Well, of course it didn't...you have to do more than "jiggle the
> variables", you have to use a completely different type. Don't expect to
> be able to use an object as a color, either.
It was a mistake on my part, because I (stupidly) assumed that a normal
takes a normal_map. I don't know why I thought that, since a pigment
doesn't take a pigment_map, nor a texture a texture_map, but I did. Mea
Culpa.
>> In fact, this is the problem. When I changed to a slope map, it worked.
>> didn't do what I wanted,
> I would be surprised if it did...you are still using the wrong type. The
> slope_map takes a 2D vector...when you specify a float, the same value
> is used for both components when it is automatically promoted to a 2D
> vector, for example, 0.5 is promoted to < 0.5, 0.5>...which is pretty
> much useless in slope_maps.
No, when I changed to slope map, I changed the components too. I know that
the type would be upgraded, and at least I'd be able to see the areas where
things were happening, and could tweak later, but I didn't do that.
The first component is "height", and the
> second is "slope". POV uses a spline based on this information to figure
> out the slope of the pattern at in-between values, and get an equivalent
> to a "color_map" for normals. A normal_map behaves more like a
> pigment_map than a color_map, it interpolates between complete normals,
> each with it's own pattern and other normal stuff.
> If you stated what your goal is, you might better help...however, I
> suggest you look through the manual, which clearly explains the syntax
> of normals, normal_maps, and slope_maps...especially look at section
> 2.7.2, which is a tutorial about normals, and section 4.7.2, which is a
> complete syntax reference for normals.
I'm pretty familiar with this stuff, really. I just had a brain loss for a
bit there. Sometimes the simplest things seem to disappear.
As I see it, the error should have come up in the normal_map, though, not at
the end of the normal. That's where there were missing types, it seems,
since a normal can consist of a normal_map of normals. It was specified
correctly, but the normal_map wasn't. Again, it was a stupid error, but the
error message was a little esoteric.
>> but it didn't crash. ;)
> Wait, it crashed before? That's not good, it means there is a bug
> somewhere...it should just stop parsing and produce an error message.
Sorry again. Crashed in the euphamistic sense of "didn't draw a picture of
stunning complexity and beauty." Of course, by that definition, POVray
always crashes for me. :/
Geoff
Post a reply to this message
|
![](/i/fill.gif) |