POV-Ray : Newsgroups : povray.binaries.animations : Cube deformed by NURBS functions (972KB) - 1 attachment (1/2) Server Time
19 Jul 2024 13:26:07 EDT (-0400)
  Cube deformed by NURBS functions (972KB) - 1 attachment (1/2) (Message 11 to 11 of 11)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: Tor Olav Kristensen
Subject: Re: Cube deformed by NURBS functions (972KB) - 1 attachment (1/2)
Date: 22 Apr 2003 20:32:29
Message: <Xns93661A5AE176Dtorolavkhotmailcom@204.213.191.226>
Sorry for replying so late
                           - and thank you for your comments !


I have put a new 2.4MB MPEG-file with better quality here:

http://home.no/t-o-k/povray/Quadrivariate_NURBS_Deformation.m1v


Dennis, you can find the old one properly assembled if you
follow this link to the web interface:

http://news.povray.org/povray.binaries.animations/31252/222120


Maybe I should warn you about looping it. (It seems that Bill
got into trouble doing that. =)

I guess that Tek meant that I could change the T parameter from:

T = clock

to something like this:

T = (1 + sin(-pi/2 + clock*pi))/2

And yes; I think that this would smoothen up some of the
transitions more than they already are. So maybe I'll try this
later.


- But there is another way to achieve more smooth transitions.

Below is an attempt at an explanation this for those of you
that are curios and that know some about NURBS:

To make this animation I concatenated 4 shorter animations.
(Because I was lazy.)

I mentioned that I had 8 different "key frames". In the table
below, they are denoted A, B, C, D, E, F, G and H.

1.   A --> (B) --> C
2.                 C --> (D) --> E
3.                               E --> (F) --> G
4.                                             G --> (H) --> A

To make the whole sequence loopable I made the end "frame" the
same as the start "frame".

For each of these four animations I let the clock go from 0 to 1.

To make sure that the end of one animation was exactly equal to
the beginning of the next animation, I had to use "open uniform
knot vectors" assosiated with the T parameter (time).

Each animation sequence then started with exactly the start
"frame", moved towards the middle "frame" but did not reach it
completely and then moved away from it towards the end "frame"
until it was reached exactly.

E.g.   A --> (B) --> C

I have put the B frame in parenthesis to indicate that it is
not reached completely.

If I had used "uniform knot vectors" instead, then the
animation sequences would be like this:

(A)-> (B) ->(C)
               (C)-> (D) ->(E)
                              (E)-> (F) ->(G)
                                             (G)-> (H) ->(A)

This would cause a glitch between the sub sequences. I have
tried to indicate this by shifting the beginning of each sub-
sequence a little to the right.

If I hadn't been lazy, I could have made it into one single
long sequence. E.g. like this:

A -> (B) -> (C) -> (D) -> (E) -> (F) -> (G) -> (H) -> A

(With a single "open uniform knot vector" for the T parameter)

This would have generated _huge_ NURBS functions, which would
have taken a long time to parse. (IIRC each image in the
animation already took about 5 minutes to parse and 1 minute
to render on my 2GHz Athlon PC.)


I hope that this made a little sense to some of you.


Tor Olav


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.