![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3aacf34b@news.povray.org>, Geoff Wedig
<wed### [at] darwin epbi cwru edu> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
> In article <3aacf34b@news.povray.org>, Geoff Wedig
> <wed### [at] darwin epbi cwru edu> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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.
> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/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) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3aae1467@news.povray.org>, Geoff Wedig
<wed### [at] darwin epbi cwru edu> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
> In article <3aae1467@news.povray.org>, Geoff Wedig
> <wed### [at] darwin epbi cwru edu> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3aae69fb@news.povray.org>, Geoff Wedig
<wed### [at] darwin epbi cwru edu> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |