So, I've picked up on working on my Worm-Short again. So, where did that
lead me?

Problem #1: A Worm lives in the earth, so I need tunnels. How should I
create those? Especially since I have one complicated scene involving a
tunnel which might need to be outsourced to Java for preprocessing of
particle interaction...

Solution #1: Use a whole bunch of CSG cylinders and spheres, and cut a tube
from that.
Analysis: Too costly on parsing (tons of objects) and rendering (heavy CSG)

Solution #2: Extrude a circle along a path, thus build deformable mesh-tube.
Analysis: What happens when the circles don't line up properly?

...

And that's where these two animations finally came from. The tunnel_jagged
shows how a circle might be extruded along a Bezier-Spline (hence the "Some
math aid required..." thread in advanced-users). Orienting the circle along
the path isn't trivial if you want to have one smooth go which may be easily
connected via triangles. My approach was to simply take the direction it
should point to, and rotate the face of the disc to align with the normal.
This may introduce some internal spinning to the discs, especially if the
directions change from front to back, up and down etc.
For further effect and test of the following script, I've introduced some
random rotation to the discs, and thus I get tunnel_jagged.

So, what I do now is build the nodes, but then I check the second circle to
properly line up with the first: seek the two closest points (one on each
circle), then "twist" the nodes on the second circle to align the indices
with the two closest points. Repeat for third in relation to second, fourth
to third, etc.

And that's how I get tunnel_corrected.

If anyone's interested in even more detail, let me know. My main aim with
this post was to see if anyone has any other solution which is still trivial
and doesn't involve heavy-duty algebra to solve, hence the already pretty
detailed description.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Attachments:
Download 'tunnel_jagged.mpg' (127 KB) Download 'tunnel_corrected.mpg' (127 KB)

Tim Nikias v2.0 wrote:
> My approach was to simply take the direction it
> should point to, and rotate the face of the disc
> to align with the normal.

How is the disc oriented before this rotation? I suppose you just start
with a standard orientation, like facing in the z direction, and then
rotate it to be aligned with the normal? This would give the jagged look
you talk about.

The trick here is to not start out with a standard orientation, but
instead start out with the orientation of the previous circle and rotate
that one so that it is aligned with the normal.

In order for this to make sense you need of course to keep completely
track of the orientation of the circles, not just their normals. For
example, if the normal of each circle is "forward" then you additionally
need to have an "up" direction for each circle, which could be the place
where the first node is build. The point now is that for each circle you
take the forward and up vectors from the previous circle and rotate them
both by the same amount around the same axis in such a way that the new
forward vector is aligned with the spline.

This method is rather simple, since instead of correcting the twisting,
you prevent the twisting from happening in the first place. Let me know
if you need more details.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> The trick here is to not start out with a standard orientation, but
> instead start out with the orientation of the previous circle and rotate
> that one so that it is aligned with the normal.
>
> In order for this to make sense you need of course to keep completely
> track of the orientation of the circles, not just their normals. For
> example, if the normal of each circle is "forward" then you additionally
> need to have an "up" direction for each circle, which could be the place
> where the first node is build. The point now is that for each circle you
> take the forward and up vectors from the previous circle and rotate them
> both by the same amount around the same axis in such a way that the new
> forward vector is aligned with the spline.
>
> This method is rather simple, since instead of correcting the twisting,
> you prevent the twisting from happening in the first place. Let me know
> if you need more details.

I think I've understood your idea and know how to solve it, now that you've
given some basic instructions. My problem is that though I do understand
matrix-transformation and different vector-arithmetics like vdot and such to
get angles, I tend to think more in direct steps. With the technique you
mentioned, and have to do some inbetween calculations to get the desired
angles, like projecting the forward vector onto a plane with the sky-vector,
thus getting vectors with which I can calculate the "internal" spin to get
the up-vectors lined up...

It's my perspective on things that stands in my way of finding efficient
solutions for problems like these. Don't play around with vectors,
matrix-transformations and angles enough, I guess...

Well, thanks for the help!

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Oh, and another note: sometimes it's a bad idea posting here. You're
satisfied to have found a nice solution to something which, in your eyes,
looks neat, and then some newsgroup jerk (not meant personal :-) comes along
and tells you how to do it in one of the best conceivable ways. There goes
satisfaction...

:-)

Just kidding, though it is kinda weird how someone presents a nice thing
he's just finished, and then one or another points out how someone else
already did that, and how he made it better than what you've just created. I
still like my algorithm, but it's kinda pointless now, I guess. :-(

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Don't be sad. Look at it this way: if you haven't done
it yourself, you are often not able to understand the
solution of someone else. So keep posting your own
solutions.

	Andrel

Post a reply to this message

Tim Nikias v2.0 wrote:
> Just kidding, though it is kinda weird how someone
> presents a nice thing he's just finished, and then
> one or another points out how someone else already
> did that, and how he made it better than what
> you've just created. I still like my algorithm,
> but it's kinda pointless now, I guess. :-(

The leaning experience was not pointless. Every time you make up some
algorithm on your own your programming skills improve a bit. That is not
the case if you just use someone else's algorithm from the beginning. :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Tim Nikias v2.0 wrote:
> With the technique you mentioned, and have to do
> some inbetween calculations to get the desired
> angles, like projecting the forward vector onto
> a plane with the sky-vector, thus getting vectors
> with which I can calculate the "internal" spin to
> get the up-vectors lined up...

I'm not sure I understand. Why do you need any sky-vector in the first
place? Why do you need to know anything about the spin of the tunnel?

> It's my perspective on things that stands in my
> way of finding efficient solutions for problems
> like these. Don't play around with vectors,
> matrix-transformations and angles enough, I guess...

Playing around with those have often proven to be very handy for me...
;)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> Don't be sad. Look at it this way: if you haven't done
> it yourself, you are often not able to understand the
> solution of someone else. So keep posting your own
> solutions.

I'm not sad. I still think I can be pretty proud of myself, cause I do find
some sort of solution on my own most of the time, may they be pretty
unspectacular and round-about. And posting here keeps the newsgroups alive
and provides insight into techniques for others (even if the algorithm is
overly complicated, it might be useful for something else).

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

> The leaning experience was not pointless. Every time you make up some
> algorithm on your own your programming skills improve a bit. That is not
> the case if you just use someone else's algorithm from the beginning. :)

Right. In this case, I guess my problem is more with the vector-arithmetic
than the programming, but I'll tackle that sooner or later as well.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Rune wrote:
> Tim Nikias v2.0 wrote:
>> With the technique you mentioned, and have to do
>> some inbetween calculations to get the desired
>> angles, like projecting the forward vector onto
>> a plane with the sky-vector, thus getting vectors
>> with which I can calculate the "internal" spin to
>> get the up-vectors lined up...
>
> I'm not sure I understand. Why do you need any sky-vector in the first
> place? Why do you need to know anything about the spin of the tunnel?

Here's some crude and simple code to explain the basic idea. The
algorithm is simpler than I remembered. Just use the VPerp_Adjust()
macro to make the last up-vector perpendicular to the current
forward-vector and then use that as the current up-vector... The code
here just aligns boxes and does not create a tunnel out of a mesh, but
the basic idea is the same.

#include "transforms.inc"
#include "math.inc"
camera {location <-2,1,-3> look_at 0}
light_source {<-1,2,-3>*1000, color 1}
background {rgb 1}
#declare Spline = spline {
   cubic_spline
   -2, -x,
   -1, -x,

    0, -y,
    1, -z,
    2, y,
    3, z,
    4, x,
    5, x+y,

    6, y+z,
    7, y+z
}
#declare C = 0;
#declare Samples = 50;
#declare Range = 5;
#declare LastY = y;
#while (C<=Samples)
   #declare Val = C/Samples*Range;
   #declare P = Spline(Val);
   #declare Z = vnormalize(Spline(Val+0.001)-Spline(Val-0.001));
   #declare Y = VPerp_Adjust(LastY,Z);
   #declare X = vcross(Y,Z);
   #declare T = Matrix_Trans(X,Y,Z,P)
   #declare LastY = Y;
   superellipsoid {<0.2,0.2> scale 0.1 transform {T} pigment {rgb 1}}
   #declare C = C+1;
#end


Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> I'm not sure I understand. Why do you need any sky-vector in the first
> place? Why do you need to know anything about the spin of the tunnel?

You somehow have to put the two forward- and up-vectors into relation. I
thought that maybe projecting both forward vectors onto a plane, get the
angle, rotate the vectors and then calculate new angles for the up-vector
might be a way to go. You've probably got something faster up your sleeve,
the way you phrase it...

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

> Here's some crude and simple code to explain the basic idea. The
> algorithm is simpler than I remembered. Just use the VPerp_Adjust()
> macro to make the last up-vector perpendicular to the current
> forward-vector and then use that as the current up-vector... The code
> here just aligns boxes and does not create a tunnel out of a mesh, but
> the basic idea is the same.

Hm. I can see that it works, but I don't understand why and how. I can't
visualize what that VPerp_Adjust actually does, and why it works for
generating a proper new matrix for the new box. Care to elaborate and
enlighten me? :-)

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
>> Here's some crude and simple code to explain the basic idea. The
>> algorithm is simpler than I remembered. Just use the VPerp_Adjust()
>> macro to make the last up-vector perpendicular to the current
>> forward-vector and then use that as the current up-vector... The code
>> here just aligns boxes and does not create a tunnel out of a mesh,
>> but the basic idea is the same.
>
> Hm. I can see that it works, but I don't understand why and how. I
> can't visualize what that VPerp_Adjust actually does

From the doc:
VPerp_Adjust(V1, Axis). Find a vector perpendicular to Axis and in the
plane of V1 and Axis. In other words, the new vector is a version of V1
adjusted to be perpendicular to Axis.

So the new Y vector is the same as the previous Y vector, except that it
is adjusted to be perpendicular with the new Z vector. Since the
previous and the new Y vectors are as close to each other as possible,
there is no twisting.

The Y and Z vectors are now perpendicular, and from those we can get the
X vector using the vcross-function. Now we have the local X, Y and Z
vector for the box as well as its origin P, and then we can create its
transformation matrix out of those four vectors.

That's all really.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> That's all really.

Hm, now that you've described it, I can actually build a visual
representation in my mind. You see, as long as I can't actually tell via
diagramm (even if its a complicated one that only fits into the mind, not on
paper) I don't really grasp the formula. I've read the doc, but I got
confused somewhere with that Last_Y and the actual Y etc. Now I can picture
it and understand it.

Now that I've understood it, I'll try to implement it, shouldn't be too much
of a problem. Once the tunnel is properly constructed, I'll get to the
actual tricky part: water simulation. I'm still wondering if I should make
something half-artistic and half-simulation, so that I can actually control
the effects, but still have some degree of realism... Ah well, I'll come to
that later. Maybe I'll ponder about it for a few days and tackle some other
stuff first.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
> Hm, now that you've described it, I can actually
> build a visual representation in my mind. You see, as
> long as I can't actually tell via diagramm (even if
> its a complicated one that only fits into the mind,
> not on paper) I don't really grasp the formula.

My mind works the same way... :)

> Once the tunnel is properly constructed, I'll get to
> the actual tricky part: water simulation.

I'm looking forward to see what you'll come up with!

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message