Tim Nikias wrote:
> I've once written a small script to create a mesh-tube running along a
> spline, and ran into similiar problems. What was suggested to me then by
> Rune and someone else who's name I've forgotten (sorry) to update the
> up-vector successively, instead of independantly for each frame (in my case,
> for every ring of the tube, in your case, it's the frames).
> 
> I start with the initial direction I'm heading to, and an initial up vector.
> On the next frame, use the old up-vector, and double vcross it with the new
> direction to get the new up-vector.
> 
>   #local Up = vnormalize(vcross(vcross(New_Direction,Last_Up),
> New_Direction));
> 
> Since the new direction and the old up-vector aren't perpendicular, you'll
> create a new up-vector that is aligned along the plane defined by the old
> up-vector and new-direction... Quite simple, once you think it through.
> 
> Additionally, since this only affects corkscrew or other loopings, you could
> create a parsing step that'll just do that when it's needed. Needs a little
> more though, but would be worthwhile in case you plan on distributing the
> render and making the animation independant of former frames.
> 
> Regards,
> Tim
> 

Hmm...If I understand you correctly, then what I'd be doing is starting 
with an up vector of simply y, double cross it with the new direction 
with each frame, and pass it to the next frame (Just like I pass the 
current location and speed with each frame).  On every frame, I'll do 
all my banking calculations based on that vector, rather than using y 
every time.

Correct?

-DJ

Post a reply to this message

Ok no problem.  If things get a little more drawn out with your intended 
landscape and 3DS objects my offer still stands.  That is if you can 
split the animation down into sections?

Keep the animations coming

Dave

DJ Wiza wrote:
> David Brickell wrote:
> 
>> If you require any rendering done I have a lot of CPU time I could 
>> spare.  Also I get to see how you are working things ;)
>>
>> Let me know.
>>
>> Dave.
>>
> 
> Test renders are quick.  Because I'm using spheres/cylinders rather than 
> sphere_sweeps, it only takes about 6 seconds per frame, and most of my 
> test renders are just single frames to make sure something is being 
> calculated correctly.
> 
> -DJ

Post a reply to this message

> Hmm...If I understand you correctly, then what I'd be doing is starting
> with an up vector of simply y, double cross it with the new direction
> with each frame, and pass it to the next frame (Just like I pass the
> current location and speed with each frame).  On every frame, I'll do
> all my banking calculations based on that vector, rather than using y
> every time.
>
> Correct?

Yup.

Regards,
Tim

-- 
aka "Tim Nikias"
Homepage: <http://www.nolights.de>

Post a reply to this message

David Brickell wrote:
> Ok no problem.  If things get a little more drawn out with your intended 
> landscape and 3DS objects my offer still stands.  That is if you can 
> split the animation down into sections?
> 
> Keep the animations coming
> 
> Dave
> 

You can and you can't split the animation.

At every frame, it tries to read two variables from a text file.  These 
two variables tell my script the current location and speed.  If it 
can't find this file, it starts from the beginning.

So by creating this file yourself, you can make it start somewhere in 
the middle.

-DJ

Post a reply to this message

> At every frame, it tries to read two variables from a text file.  These 
> two variables tell my script the current location and speed.  If it 
> can't find this file, it starts from the beginning.
> 
> So by creating this file yourself, you can make it start somewhere in 
> the middle.
> 
> -DJ

So you have to run the simulation up to the point in the track you wish 
to render from so it has the correct location and speed.  That makes sense.

Patiently waiting for next render ;)

Dave.

Post a reply to this message

David Brickell wrote:

>> At every frame, it tries to read two variables from a text file.  
>> These two variables tell my script the current location and speed.  If 
>> it can't find this file, it starts from the beginning.
>>
>> So by creating this file yourself, you can make it start somewhere in 
>> the middle.
>>
>> -DJ
> 
> 
> So you have to run the simulation up to the point in the track you wish 
> to render from so it has the correct location and speed.  That makes sense.
> 
> Patiently waiting for next render ;)
> 
> Dave.

Its going to be awhile.  I've gotten the banking to be smoother by using 
a spline for up vectors, which fixed the kink in the track, but I 
haven't implemented the double-crossing of the up vectors to make 
vertical track work right, so really its just luck that the track 
appears and banks correctly.  A track tie still appears wrong, showing 
that it still isn't right, it just looks right in most cases.

I've also fixed the spine rail.  It no longer goes up and down, causing 
track ties to appear in the bottom of the spine.  This was being caused 
by rotating the vector y over the vector of the direction of travel, so 
track that had a slope caused the spine to be closer to the bezier 
defining the track.

In any case, I don't really think its enough change to warrant a new 
upload.  I thought of making a 60 fps 10-sample motion blur render, but 
that would take almost 4 days, and I'd rather have the CPU time devoted 
to test renders of the support track, which I haven't even begun working on.

-DJ

Post a reply to this message