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