 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can someone please explain this to me in simpler terms than those used in
the MegaPOV docs? I've been struggling to get this thing to work on
heightfields higher than 1 unit (in my case a heightfield 3.28 units high,
which will be changed later). Specifically the one with syntax: slope,
<x,y,z>,<x,y,z>,<u,v>,<u,v>. An example is greatly appreciated. TIA
--
Anthony Bennett
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" <ben### [at] catholic org> wrote in message
news:3aeb089c@news.povray.org...
> Can someone please explain this to me in simpler terms than those used in
> the MegaPOV docs? I've been struggling to get this thing to work on
> heightfields higher than 1 unit (in my case a heightfield 3.28 units high,
> which will be changed later). Specifically the one with syntax: slope,
> <x,y,z>,<x,y,z>,<u,v>,<u,v>. An example is greatly appreciated. TIA
>
I may well be wrong here, but I've always assumed that slope (apart from the
simple "slope <slope>"usage) requires the hf to be only 1 unit high max.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was afraid of that...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tony[B] <ben### [at] catholicorg> wrote:
: I was afraid of that...
Texture first, scale then. What's the problem?
--
#local D=array[6]{11117333955,7382340,3358,3900569407,970,4254934330}
#local I=0;#macro M()<mod(D[I],13)-6,mod(div(D[I],13),8)-3,10>#end
#while(I<6)cylinder{M()#local D[I]=div(D[I],104);M().1
pigment{rgb M()}}#local I=(D[I]>99?I:I+1);#end /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3aee9b74@news.povray.org...
> Tony[B] <ben### [at] catholicorg> wrote:
> : I was afraid of that...
>
> Texture first, scale then. What's the problem?
Perhaps his texture is distorted when scaled. Of course, he could scale his
texture inversely to account for this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
: Perhaps his texture is distorted when scaled.
Well, he can do this:
heighfield
{ whatever
scale <10, 1, 20>
texture { whatever }
scale <1, 2, 1>
}
--
#local D=array[6]{11117333955,7382340,3358,3900569407,970,4254934330}
#local I=0;#macro M()<mod(D[I],13)-6,mod(div(D[I],13),8)-3,10>#end
#while(I<6)cylinder{M()#local D[I]=div(D[I],104);M().1
pigment{rgb M()}}#local I=(D[I]>99?I:I+1);#end /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3aeea3be@news.povray.org...
>
> heighfield
> { whatever
> scale <10, 1, 20>
> texture { whatever }
> scale <1, 2, 1>
> }
>
Shouldn't that be:
heighfield
{ whatever
texture { whatever scale <1, 1/2, 1>}
scale <1, 2, 1>
}
?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3aeeab4b$1@news.povray.org>, "Tom Melly"
<tom### [at] tomandlucouk> wrote:
> Shouldn't that be:
>
> heighfield
> { whatever
> texture { whatever scale <1, 1/2, 1>}
> scale <1, 2, 1>
> }
#declare HFTrans = transform {...}
heighfield { whatever
texture {whatever transform {HFTrans inverse}}
transform {HFTrans inverse}
}
;-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
> Can someone please explain this to me in simpler
> terms than those used in the MegaPOV docs? I've
> been struggling to get this thing to work on
> heightfields higher than 1 unit (in my case a
> heightfield 3.28 units high, which will be
> changed later). Specifically the one with syntax:
> slope, <x,y,z>,<x,y,z>,<u,v>,<u,v>. An example is
> greatly appreciated. TIA
slope, <x,y,z>,<x,y,z>,<u,v>,<u,v>
A B C D
You have four vectors. Let's call them vector A, B, C and D. A and B are 3D
vectors. C and D look like 2D vectors in their syntax, but in fact they have
nothing to do with vectors.
A is a 3D vector controlling the which direction the slope pattern is based
on. As I'm sure you understand that one, I won't go into details.
C is used to give you better control over A. If you're using a heightfield
and A is set to be y you are not having any surfaces that are anti-parallel
to A (-y). Actually, even the most steep surfaces of the HF would be
perpendicular to the slope vector at most. That means the pattern only will
return values from 0.5 (perpendicular) to 1.0 (parallel). The part of your
color_map that uses values from 0.0 to 0.5 is sort of wasted, since it's
never used.
You can use C to specify that only a certain range of slopes are used. The u
part in C sets the lo-slope and the v part sets the hi-slope. For example,
if you set C to be <0.5,1.0> it means that the pattern value goes from 0
when the slope is perpendicular to A, to 1 when the slope is parallel to A.
That means that your entire color_map is used, even though only a certain
range of slopes are used.
Let me know if it's clear so far!
To be continued...
In the next message I'll try to explain how to use the slope pattern with
heightfields higher than 1 unit! But maybe someone will beat me to it...
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: I don't understand the slope pattern
Date: 1 May 2001 11:51:38
Message: <3AEEDBAE.C1F5024D@gmx.de>
|
|
|
| |
| |
|
|
Rune wrote:
>
> slope, <x,y,z>,<x,y,z>,<u,v>,<u,v>
> A B C D
>
> [...]
That looks really good and understandable, just add some illustrating
pictures (and of course something on B and D) and you have an excellent
slope pattern tutorial.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks a lot Rune! If you can finish this maybe you can send it to the right
people to include it in the mythical 3.5... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
> Thanks a lot Rune!
> If you can finish this maybe you can send it to the
> right people to include it in the mythical 3.5... :)
It took me only about 10 minutes to write, so I'm rather surprised you find
it that good... :)
Anyway, here's the next chapter.
slope <x,y,z>, <x,y,z>, <u,v>, <u,v>
A B C D
B is a 3D vector controlling the direction of a special gradient. You know
the pattern gradient y will increase the pattern values along the y axis.
Well, the B vector in the slope pattern will increase the pattern values
along the B vector. The B vector can be any vector.
C was used to specify which range of values should be used for A. Similar, D
is used to specify the range of values for B. The u part of the D is the
lo-altitude and the v part is the hi-altitude. Let's say you set B to y, so
the pattern value increases along the y axis. Say you have a heightfield
that is one unit high so the bottom is at y=0 and the top is at y=1. In that
case you should set D to be <0,1>. But if your heightfield is bigger so it
for example goes from y=-1.1 to y=3.5, then you should set D to <-1.1, 3.5>.
So far we have looked at how A+C work (the slope) and at how B+D work (the
altitude). But how does it all work together? Well, the pattern value for a
given point is a weighted average of the slope and the altitude. The weights
are the lengths of the vectors A and B. If vector A is much longer than
vector B it means that the slope has greater effect on the results than the
altitude. If on the other hand vector B is longer, it means that the
altitude has more effect on the result.
That's all for now. Hope that was clear too. I intent to write more and to
improve what I've already written, but that'll require quite a bit more of
time and planning.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
: Shouldn't that be:
: heighfield
: { whatever
: texture { whatever scale <1, 1/2, 1>}
: scale <1, 2, 1>
: }
No. The idea was that the heighfield should be scaled in widht and length
to the appropriate size before texturing (so that the texture would not be
distorted or anything), but the height should be 1 because of the used slope
pattern.
My suggestion was to first set the width and length of the heightfield to
whatever they should be but leave the height to 1, then texture it and then
set the height to what it should be.
--
#local D=array[6]{11117333955,7382340,3358,3900569407,970,4254934330}
#local I=0;#macro M()<mod(D[I],13)-6,mod(div(D[I],13),8)-3,10>#end
blob{#while(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2
pigment{rgb M()}}#local I=(D[I]>99?I:I+1);#end} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3af00193@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> No. The idea was that the heighfield should be scaled in widht and
> length to the appropriate size before texturing (so that the texture
> would not be distorted or anything), but the height should be 1
> because of the used slope pattern.
But when you scaled the height field to it's proper height, the textures
would still be stretched along the y axis.
BTW, you need to do the "scale <1, 1/2, 1>" or "transform {Trans
inverse}" in the textures in the texture_map being controlled with the
slope pattern, not in the slope-mapped texture itself...just thought
that needed to be clarified.
--
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 message
news:chrishuff-9A11E6.08000702052001@news.povray.org...
>
> But when you scaled the height field to it's proper height, the textures
> would still be stretched along the y axis.
That's what I thought. Warp, can you confirm, or have I/we missed something?
> BTW, you need to do the "scale <1, 1/2, 1>" or "transform {Trans
> inverse}" in the textures in the texture_map being controlled with the
> slope pattern, not in the slope-mapped texture itself...just thought
> that needed to be clarified.
Sounds right - definately one to suck and see - at least for the
mathematically and spatially challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But the slope pattern does indeed work with heightfields that are more than
1 unit high, so all this scaling trouble is rather pointless isn't it?
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] inamecom> wrote in message
news:3af01d83$1@news.povray.org...
> But the slope pattern does indeed work with heightfields that are more
than
> 1 unit high, so all this scaling trouble is rather pointless isn't it?
>
<very small voice>yes, mr rune</very small voice>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
:> But when you scaled the height field to it's proper height, the textures
:> would still be stretched along the y axis.
: That's what I thought. Warp, can you confirm, or have I/we missed something?
It depends on how you use the slope pattern, but yes, in many cases this
can happen.
--
#local D=array[6]{11117333955,7382340,3358,3900569407,970,4254934330}
#local I=0;#macro M()<mod(D[I],13)-6,mod(div(D[I],13),8)-3,10>#end
blob{#while(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2
pigment{rgb M()}}#local I=(D[I]>99?I:I+1);#end} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" wrote:
> "Rune" wrote:
> > But the slope pattern does indeed work with
> > heightfields that are more than 1 unit high,
> > so all this scaling trouble is rather
> > pointless isn't it?
>
> <very small voice>yes, mr rune</very small voice>
Hehe, I can understand that you want to have things cleared out, I just
wanted to make sure you knew it wasn't a real problem. :)
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for your help Rune! I think I mostly understand it now. This
definitely has to get into 3.5 to help those POVers who are stuck like me...
Anybody have the address for the POV-Team?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tony[B]" wrote:
> Anybody have the address for the POV-Team?
I do :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mind you, if the 'pigment_pattern' statement makes it into v3.5 it would
probably be worth removing the convoluted extended syntax from 'slope'.
You can do exactly the same effects with pigment_pattern and it is as
easy to understand as the extended slope syntax.
I only tacked the extended syntax on to Hans Detlev-Fink's original
slope concept because no-one had implemented anything like the
pigment_pattern at that time. If we have pigment_pattern to do this (and
many other clever effects) in v3.5 then the extended slope syntax is
pointless and should be depreciated.
It pains me to say this about my only real contribution to The Cause but
...
Bye for now,
Mike Andrews.
"Tony[B]" wrote:
>
> Thanks for your help Rune! I think I mostly understand it now. This
> definitely has to get into 3.5 to help those POVers who are stuck like me...
> Anybody have the address for the POV-Team?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Andrews wrote:
>
> Mind you, if the 'pigment_pattern' statement makes it into v3.5 it would
> probably be worth removing the convoluted extended syntax from 'slope'.
> You can do exactly the same effects with pigment_pattern and it is as
> easy to understand as the extended slope syntax.
>
> I only tacked the extended syntax on to Hans Detlev-Fink's original
> slope concept because no-one had implemented anything like the
> pigment_pattern at that time. If we have pigment_pattern to do this (and
> many other clever effects) in v3.5 then the extended slope syntax is
> pointless and should be depreciated.
>
> It pains me to say this about my only real contribution to The Cause but
> ...
Yes, it's a pitty. Now that I understand everything at last. ;-)
-Hans-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Michael Andrews" wrote:
> Mind you, if the 'pigment_pattern' statement makes it
> into v3.5 it would probably be worth removing the
> convoluted extended syntax from 'slope'. You can do
> exactly the same effects with pigment_pattern and it
> as as easy to understand as the extended slope syntax.
Do you mean by using an average between a slope pigment and a gradient
pigment, or is there an easier way?
If that's what you mean, then yes, it might be as easy to understand, but
it'd take up many more lines of code to achieve the same effect and you'd
have to do some calculations to be able to control it as well.
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated March 29)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: I don't understand the slope pattern
Date: 3 May 2001 11:20:39
Message: <3AF1775C.D99BDD5B@gmx.de>
|
|
|
| |
| |
|
|
Michael Andrews wrote:
>
> Mind you, if the 'pigment_pattern' statement makes it into v3.5 it would
> probably be worth removing the convoluted extended syntax from 'slope'.
> You can do exactly the same effects with pigment_pattern and it is as
> easy to understand as the extended slope syntax.
>
> I only tacked the extended syntax on to Hans Detlev-Fink's original
> slope concept because no-one had implemented anything like the
> pigment_pattern at that time. If we have pigment_pattern to do this (and
> many other clever effects) in v3.5 then the extended slope syntax is
> pointless and should be depreciated.
>
There already was a discussion on that matter some time ago:
Subject: slope-dependent pattern
Date: Thu, 4 Jan 2001 20:40:41
From: "Nathan Kopp" <Nat### [at] Koppcom>
Newsgroups: povray.unofficial.patches
I still think the extended syntax is worth keeping, but it would not be an
enormous problem if it is removed IMO. I never made a speed comparison
between extended slope pattern and the average-pigment_pattern construct,
but it probably will be slower at least to some extend. Since the pattern
is often used for texturing (isosurface) landscapes, speed might be quite
an important argument.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other
things on: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
