 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen wrote in message
news:Xns### [at] 204 213191226...
> Will W wrote in
> news:3e86277b@news.povray.org:
<snip>
> The first one is about the same two lines that I
> commented on earlier:
>
> #local dX = (toPt.x-fromPt.x)/Cols;
> #local dZ = (toPt.z-fromPt.z)/Rows;
>
> Remember that when you have N on a line, then there
> are only N - 1 intervals between them.
>
> So the resulting patch will be more "correct" if you
> change these lines to:
>
> #local dX = (toPt.x - fromPt.x)/(Cols - 1);
> #local dZ = (toPt.z - fromPt.z)/(Rows - 1);
I'll take another look at this. This is exactly the kind of feedback I
need-- another pair of eyes can immediately see goofs that my preconceptions
blind me to.
> You will see the effect from this better if you
> temporarily remove your clipped_by statemnt and add
> a colored sphere at each of the four corners of the
> patch. The pacth will now have an equally wide flat
> "border" at all the edges.
I've found marker spheres useful in developing this macro. But I don't
understand what you trying to tell me. I'll do the exercise, maybe your
point will become clear then.
>
>
> The next one is about this uv vectors statement:
>
> uv_vectors <(C-dX)/Cols,(R-dZ)/Rows>
>
> Here you have <Columns, Rows> while you have
> [Rows][Columns] when indexing your array:
>
> A[R][C][Y]
It is a bit odd, but I'm pretty sure that is right. I want the initial data
array to be intuitively obvious to the user, which means defining it as
Array[Row][Col]. This is imposed upon me by the way the array initializer in
POV works-- I really wanted to define the arrays as Array[Col][Row], which
is consistent with my spreadsheet experience, and with the cartesian
coordinate system used in POV's vectors. But I couldn't do that if I want
users to be able to cut and paste array content into an array initializer.
What's important is that the Cols and the x-coordinates and the Rows and
z-coordinates match up. (or in this case, Cols match with u and Rows match
with v). But it does end up looking strange.
> This looks a little bit odd to me, and I'm not sure
> if the result is what the user expects. (But I might
> be wrong here.)
>
>
> And another comment is about your intensive use of
> array lookups. This can be a very time consuming
> task for POV-Ray to do, so often it is better to
> look up a value once and put it in a 'plain' variable
> for later use.
True. There's a huge amount of room for performance optimization since this
was written to optimize human readability (and thus debugging).
> My last comment (for now) is about repeating calcu-
> lations that POV-Ray has already done earlier.
>
> Have a look at the code below code. (It does the same
> as yours but calculates iX + dX*C and iZ + dZ*R only
> once in each loop instead of 16 times.)
Again true. This is also to some degree an artifact of production, since it
let me easily play around with changing the points' offsets.
Thanks very much for your help with this, Tor.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in
news:Xns### [at] 204213191226:
...
> Have a look at the code below code. (It does the same
> as yours but calculates iX + dX*C and iZ + dZ*R only
> once in each loop instead of 16 times.)
>
>
> // This first line should be placed outside the loops
> #local vXYZ = <dX, dY, dZ>;
> .
> <snip>
> .
> bicubic_patch {
> type 1 flatness 0 u_steps 3 v_steps 3
> .
> <snip>
> .
> <0.0, A[R ][C ][Y] , 0.0>*vXYZ
> <0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>*vXYZ
> .
> <snip>
> .
> <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>*vXYZ
> <1.0, A[R+1][C+1][Y] , 1.0>*vXYZ
> translate <iX + dX*C, 0, iZ + dZ*R>
> }
I forgot to mention that you can probably move the
vXYZ vector into a scale statement at the end to save
further calculations. Like this:
bicubic_patch {
type 1 flatness 0 u_steps 3 v_steps 3
.
<snip>
.
<0.0, A[R ][C ][Y] , 0.0>
<0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>
.
<snip>
.
<0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>
<1.0, A[R+1][C+1][Y] , 1.0>
scale vXYZ
translate <iX + dX*C, 0, iZ + dZ*R>
}
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
These are interesting ideas. I'll look into them once I'm satisfied the
control hull is good enough. I'm pretty sure it is, but I'm going to wait a
few days on that and see if there are any other opinions. I'm sort of
abusing the bicubic_patch by treating the points of the control hull as if
they were controlling bezier vectors attached to the nearest data point.
There may well be better forms of abuse than the one I've chosen (doing it
right would entail a lot of cubic expressions and I think slow things down
to a huge amount-- and not be anywhere near as much fun).
I am confused about the translation you are proposing-- I don't think that,
for instance, (iX+dX*C) can be subtracted out from all the points in the
bicubic. Wouldn't that imply that dX*C + 0.5 = dX*(C + 0.5) which I think
breaks the law of distribution of multiplication over addition?
I think your corrections to the expressions defining dX and dZ are right,
and I had them wrong.
I've gaining a better understanding of the uv_mapping problem. What is
happening is the image is being mapped correctly to the entire patchwork,
which includes the pseudodata rows and columns. So the margins of the image
are lost when the patchwork is clipped to its final size, and the image has
also undergone the equivalent of a scale <1+2*dX, 1, 1+2*dZ>. I'm at a loss
about how to correct for these problems. That is, unless I turn the
uv_mapping statement into something really ugly.
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
"Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
news:Xns### [at] 204213191226...
> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in
> news:Xns### [at] 204213191226:
>
> ...
>
> > Have a look at the code below code. (It does the same
> > as yours but calculates iX + dX*C and iZ + dZ*R only
> > once in each loop instead of 16 times.)
> >
> >
> > // This first line should be placed outside the loops
> > #local vXYZ = <dX, dY, dZ>;
> > .
> > <snip>
> > .
> > bicubic_patch {
> > type 1 flatness 0 u_steps 3 v_steps 3
> > .
> > <snip>
> > .
> > <0.0, A[R ][C ][Y] , 0.0>*vXYZ
> > <0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>*vXYZ
> > .
> > <snip>
> > .
> > <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>*vXYZ
> > <1.0, A[R+1][C+1][Y] , 1.0>*vXYZ
> > translate <iX + dX*C, 0, iZ + dZ*R>
> > }
>
>
> I forgot to mention that you can probably move the
> vXYZ vector into a scale statement at the end to save
> further calculations. Like this:
>
>
> bicubic_patch {
> type 1 flatness 0 u_steps 3 v_steps 3
> .
> <snip>
> .
> <0.0, A[R ][C ][Y] , 0.0>
> <0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>
> .
> <snip>
> .
> <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>
> <1.0, A[R+1][C+1][Y] , 1.0>
> scale vXYZ
> translate <iX + dX*C, 0, iZ + dZ*R>
> }
>
>
> Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in
news:3e8783bc@news.povray.org:
> These are interesting ideas. I'll look into them once I'm satisfied
> the control hull is good enough. I'm pretty sure it is, but I'm going
> to wait a few days on that and see if there are any other opinions.
> I'm sort of abusing the bicubic_patch by treating the points of the
> control hull as if they were controlling bezier vectors attached to
> the nearest data point. There may well be better forms of abuse than
> the one I've chosen (doing it right would entail a lot of cubic
> expressions and I think slow things down to a huge amount-- and not be
> anywhere near as much fun).
I have some ideas on how to define all the
control points. It's quite simple, but I'm
too tired to explain it right now.
> I am confused about the translation you are proposing-- I don't think
> that, for instance, (iX+dX*C) can be subtracted out from all the
> points in the bicubic. Wouldn't that imply that dX*C + 0.5 = dX*(C +
> 0.5) which I think breaks the law of distribution of multiplication
> over addition?
No. Here is an example of how you can rewrite
one of the expressions:
<
iX + dX*(C + 1/2),
dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
iZ + dZ*(R + 1)
>
=
<
iX + dX*C + dX/2,
dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
iZ + dZ*R + dZ
>
=
<
dX/2,
dY*(A[R+1][C+1][Y] - A[R+1][C+1][X]),
dZ
>
+<iX + dX*C, 0, iZ + dZ*R>
=
<
0.5,
A[R+1][C+1][Y] - A[R+1][C+1][X],
1.0
>
*<dX, dY, dZ> + <iX + dX*C, 0, iZ + dZ*R>
> I think your corrections to the expressions defining dX and dZ are
> right, and I had them wrong.
>
> I've gaining a better understanding of the uv_mapping problem. What is
> happening is the image is being mapped correctly to the entire
> patchwork, which includes the pseudodata rows and columns. So the
> margins of the image are lost when the patchwork is clipped to its
> final size, and the image has also undergone the equivalent of a scale
> <1+2*dX, 1, 1+2*dZ>. I'm at a loss about how to correct for these
> problems. That is, unless I turn the uv_mapping statement into
> something really ugly.
Why don't you just scale down the pigment that
is going to be used in the mapping (prior to
the mapping).
E.g.:
If it is an image map, then you first translate
the image map pigment so that it is centered at
the origin, scale it and then translate it back.
Tor Olav
>
> "Tor Olav Kristensen" <tor_olav_kCURLYAhotmail.com> wrote in message
> news:Xns### [at] 204213191226...
>> Tor Olav Kristensen <tor_olav_kCURLYAhotmail.com> wrote in
>> news:Xns### [at] 204213191226:
>>
>> ...
>>
>> > Have a look at the code below code. (It does the same
>> > as yours but calculates iX + dX*C and iZ + dZ*R only
>> > once in each loop instead of 16 times.)
>> >
>> >
>> > // This first line should be placed outside the loops
>> > #local vXYZ = <dX, dY, dZ>;
>> > .
>> > <snip>
>> > .
>> > bicubic_patch {
>> > type 1 flatness 0 u_steps 3 v_steps 3
>> > .
>> > <snip>
>> > .
>> > <0.0, A[R ][C ][Y] , 0.0>*vXYZ
>> > <0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>*vXYZ
>> > .
>> > <snip>
>> > .
>> > <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>*vXYZ
>> > <1.0, A[R+1][C+1][Y] , 1.0>*vXYZ
>> > translate <iX + dX*C, 0, iZ + dZ*R>
>> > }
>>
>>
>> I forgot to mention that you can probably move the
>> vXYZ vector into a scale statement at the end to save
>> further calculations. Like this:
>>
>>
>> bicubic_patch {
>> type 1 flatness 0 u_steps 3 v_steps 3
>> .
>> <snip>
>> .
>> <0.0, A[R ][C ][Y] , 0.0>
>> <0.5, A[R ][C ][Y] + A[R ][C ][X], 0.0>
>> .
>> <snip>
>> .
>> <0.5, A[R+1][C+1][Y] - A[R+1][C+1][X], 1.0>
>> <1.0, A[R+1][C+1][Y] , 1.0>
>> scale vXYZ
>> translate <iX + dX*C, 0, iZ + dZ*R>
>> }
>>
>>
>> Tor Olav
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor wrote in message
news:Xns### [at] 204213191226...
> Will wrote in news:3e8783bc@news.povray.org:
>
<snip>
> I have some ideas on how to define all the
> control points. It's quite simple, but I'm
> too tired to explain it right now.
Looking forward to hearing from you about this!
> > I am confused about the translation you are proposing-- I don't think
<snip>
> No. Here is an example of how you can rewrite
<snip>
Nice explanation. Thanks. I've tried this and I'm adopting the translation
idea as it does make the code cleaner (easier to maintain). To my mind the
scaling makes it harder for me to see what's happening-- I mean that when I
come back to this 6 months from now, I would have a more difficult time
relearning the code if I adopt your scaling concept. That just might be me
and my foibles, YMMV.
As far as optimization for speed, I was disappointed with both of these
techniques, and also with moving the array references into earlier
declarations as you had also suggested. Even when used all together, these
only speed up processing incrementally. Except on possibly a very large
patchwork, I'd need a fine stopwatch to see the improvement. Bummer.
OTOH, I've found that excluding the clipped_by segment speeds up processing
a very great amount. I'm wondering if the clipped_by is disabling POV's
implicit bounding box construction.
I'm going to spend a few hours playing with an alternate approach that might
get around the need for the clipped_by and also correct the uv_mapping
problems. If I can't do that, I'll see what happens if I construct an
explicit bounding box.
> Why don't you just scale down the pigment that
> is going to be used in the mapping (prior to
> the mapping).
>
> E.g.:
> If it is an image map, then you first translate
> the image map pigment so that it is centered at
> the origin, scale it and then translate it back.
For a one-shot, that would be acceptable to me. For a tool that I want to
use over and over again, and share with others, it is not. Either the macro
handles uv_mapping in the normally expected way, or it gets an attached
disclaimer that says uv_mapping is only supported to a limited degree.
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in
news:3e888420@news.povray.org:
...
>> Why don't you just scale down the pigment that
>> is going to be used in the mapping (prior to
>> the mapping).
>>
>> E.g.:
>> If it is an image map, then you first translate
>> the image map pigment so that it is centered at
>> the origin, scale it and then translate it back.
>
> For a one-shot, that would be acceptable to me. For a tool that I want
> to use over and over again, and share with others, it is not. Either
> the macro handles uv_mapping in the normally expected way, or it gets
> an attached disclaimer that says uv_mapping is only supported to a
> limited degree.
OK, but you could have let a macro do the necessary adjustments
to the pigment.
An alternative is to change your uv_vectors to this:
<C-1, R-1>/<Cols-1, Rows-1>,
<C , R-1>/<Cols-1, Rows-1>,
<C , R >/<Cols-1, Rows-1>,
<C-1, R >/<Cols-1, Rows-1>
To see the effect, uncomment your clipped_by statement, and use
these statements:
union {
sphere { <-5, -0, -5>, 0.1 }
sphere { < 5, -0, -5>, 0.1 }
sphere { < 5, -0, 5>, 0.1 }
sphere { <-5, -0, 5>, 0.1 }
pigment { color rgb <2, 2, 2> }
}
light_source { <-1, 2, -2>*100 rgb <1, 1, 1> }
background { color blue 1 }
camera {
orthographic
location 12*y
look_at 0*y
}
object {
bigPatch(<-5, 0, -5>,<5, 0.02, 5>, PiThing)
texture {
uv_mapping
pigment {
object {
box { <0, 0, 0>, <1, 1, 1> }
color red 1
color green 1
}
}
/*
pigment {
image_map {
png "test"
// png "mtmandj"
once
interpolate 2
}
}
*/
}
}
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav Kristensen wrote:
> I have attached two images
> [Image]
>
> [Image]
Um... Tor...
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote in news:3E890E1F.946701EB@pacbell.net:
>
>
> Tor Olav Kristensen wrote:
>
>> I have attached two images
>> [Image]
>>
>> [Image]
>
> Um... Tor...
Sorry Ken
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Will W" <wil### [at] NOSPAMwizzardsnet> wrote in
news:3e888420@news.povray.org:
>
> Tor wrote in message
> news:Xns### [at] 204213191226...
>> Will wrote in news:3e8783bc@news.povray.org:
>>
> <snip>
>> I have some ideas on how to define all the
>> control points. It's quite simple, but I'm
>> too tired to explain it right now.
>
>
> Looking forward to hearing from you about this!
...
I thought that
if on are to connect two cubic Bezier curves
smoothly, the "last" control point for the first
curve, the point connecting the curves and the
"first" control point in the last curve must lie
on a line (as written in the docs),
then in order to connect 4 bicubic Bezier
patches smoothly, all the 8 control points around
the point connecting the 4 patches should all lie
in same plane.
I'll post two images to povray.binaries.images
showing how to choose this plane and where to
place the control points.
Tor Olav
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor Olav wrote in message
news:Xns### [at] 204213191226...
> I thought that
>
> if on are to connect two cubic Bezier curves
> smoothly, the "last" control point for the first
> curve, the point connecting the curves and the
> "first" control point in the last curve must lie
> on a line (as written in the docs),
That's my understanding as well. The two control vectors must lie on the
tangent to the curve at the data point.
> then in order to connect 4 bicubic Bezier
> patches smoothly, all the 8 control points around
> the point connecting the 4 patches should all lie
> in same plane.
Which is what I found to be true empirically-- and then realized I should
have been able to reason out from the above statement. Sometimes I do things
the hard way.
> I'll post two images to povray.binaries.images
> showing how to choose this plane and where to
> place the control points.
>
>
> Tor Olav
Nice images, Tor Olav-- thanks very much. bigPatch01_03.jpg does the best
job I've seen of showing how each "control vector" has to parallel the slope
of the line between the neighbors of the data point.
Now the tough question is once you've found the control vector's direction,
how far out should you position the control point along it? Your diagram and
all others I've seen (at this point I think that's every one that google can
find) have all shown the control points to be spaced at one third and two
thirds of the flat distance between two neighbors. But this appears to be
arbitrary; there is nothing I've run across which says it needs to be this
way. Note that in this scheme the control points on the diagonals are about
41% longer than the others-- and this all seems to be due more to ease of
presentation than to any underlying mathematic principles. And of course the
data points themselves don't have to lay on rectangular grid.
bigPatch superimposes both control points on the midpoint between the data
points (though of course the y values will often be quite different). This
seems neither a better nor worse approximation than doing the usual 1/3 and
2/3-- but it is a different approximation. The "ess" curves will be
different. As near as I can tell, getting accurate "ess" curves would
require solving a series of cubic polynomials-- which I expect would be very
slow, and is certainly beyond the effort I'm willing to put into this.
I've used the feedback I've gotten to make a complete revision of the
bigPatch code which I'll send in a separate post as soon as I reveiw the
forum's rules. I think it's short enough I can put it in the message body--
things have compacted down very nicely!
--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
