I'm trying to use the proximity pattern in a normal.  However, MP0.7 is
telling me that it isn't finding a normal type.  I thought perhaps I needed
to add something like bozo, but if I do it before, it balks at the proximity
("no } found, found proximity instead").  If I do it after, it breaks the
other way.  It looks to me like the proximity pattern is recognized as a
pattern but isn't *set* as the pattern, so when it gets to the end of the
normal, it bombs.

Here is the normal I've been working with:

normal
{
  proximity
  {
    crater, 10
    samples 10
    sample_bailout 100
    max_density 1
    type 1
    sides 1
  }
  normal_map
  {
    [0 .5 ]
    [0.19 .5 ]
    [.2 1 ]
    [.3 .5 ]
    [1  .5 ]
  }
}    
}

Anyone got any ideas?

Geoff

Post a reply to this message

In article <3aacf34b@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> I'm trying to use the proximity pattern in a normal.  However, MP0.7 
> is telling me that it isn't finding a normal type.  I thought perhaps 
> I needed to add something like bozo, but if I do it before, it balks 
> at the proximity ("no } found, found proximity instead").  If I do it 
> after, it breaks the other way.  It looks to me like the proximity 
> pattern is recognized as a pattern but isn't *set* as the pattern, so 
> when it gets to the end of the normal, it bombs.

You were putting "bozo" alongside the proximity{} block? That won't 
work, you can only specify a single pattern for a normal. When it 
finishes parsing the first pattern and finds another one, of course it 
gives an error.
Did you try commenting out the proximity{} block and using only bozo or 
another pattern? I don't think the proximity pattern is the problem 
here...


>   normal_map
>   {
>     [0 .5 ]
>     [0.19 .5 ]
>     [.2 1 ]
>     [.3 .5 ]
>     [1  .5 ]
>   }

This isn't the syntax for normal_maps...you need to put a normal 
modifier in the entries, not a float value. I suspect you want a 
slope_map...but even then, this is the wrong syntax, slope_maps take 2D 
vectors.
Also, there is an extra "}" in the code you posted...but I assume that 
is just a cut-n-paste error.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3aacf34b@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> I'm trying to use the proximity pattern in a normal.  However, MP0.7 
>> is telling me that it isn't finding a normal type.  I thought perhaps 
>> I needed to add something like bozo, but if I do it before, it balks 
>> at the proximity ("no } found, found proximity instead").  If I do it 
>> after, it breaks the other way.  It looks to me like the proximity 
>> pattern is recognized as a pattern but isn't *set* as the pattern, so 
>> when it gets to the end of the normal, it bombs.

> You were putting "bozo" alongside the proximity{} block? That won't 
> work, you can only specify a single pattern for a normal. When it 
> finishes parsing the first pattern and finds another one, of course it 
> gives an error.

I didn't think it would. I only added it because it kept saying "Normal type
not defined"

> Did you try commenting out the proximity{} block and using only bozo or 
> another pattern? I don't think the proximity pattern is the problem 
> here...
>>   normal_map
>>   {
>>     [0 .5 ]
>>     [0.19 .5 ]
>>     [.2 1 ]
>>     [.3 .5 ]
>>     [1  .5 ]
>>   }

> This isn't the syntax for normal_maps...you need to put a normal 
> modifier in the entries, not a float value. I suspect you want a 
> slope_map...but even then, this is the wrong syntax, slope_maps take 2D 
> vectors.

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...

In fact, this is the problem.  When I changed to a slope map, it worked. 
didn't do what I wanted, but it didn't crash. ;)

Thanks.

Geoff

Post a reply to this message

In article <3aad1701@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> 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.


> 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. 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.


> 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.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3aad1701@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> 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

In article <3aae1467@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> 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.

Um, a normal *can* take a normal_map. A pigment can take a pigment_map, 
and a texture can take a texture_map. No finish_map, though...
And their syntaxes are all consistent...a normal_map takes normal stuff, 
a pigment_map takes pigment stuff, and a texture_map takes texture stuff.
The slope_map is just more like a color_map than a pigment_map, it 
interpolates between slopes, not normals, like the color_map 
interpolates between colors instead of pigments.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3aae1467@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> 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.

> Um, a normal *can* take a normal_map. A pigment can take a pigment_map, 
> and a texture can take a texture_map. No finish_map, though...
> And their syntaxes are all consistent...a normal_map takes normal stuff, 
> a pigment_map takes pigment stuff, and a texture_map takes texture stuff.
> The slope_map is just more like a color_map than a pigment_map, it 
> interpolates between slopes, not normals, like the color_map 
> interpolates between colors instead of pigments.

Right.  So the only thing I'm wondering is, why was the error being reported
in the external normal rather than the internal one?

Geoff

Post a reply to this message

In article <3aae69fb@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Right.  So the only thing I'm wondering is, why was the error being 
> reported in the external normal rather than the internal one?

I have no idea...but I've heard about this kind of thing happening 
before.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message