DJ Wiza <Kil### [at] sohcahtoanet> wrote:
> http://www.sohcahtoa.net/videos/amazinggrace.m1v
>
> This roller coaster is called Amazing Grace.  It was designed by RiscIt,
> one of the admins of CoasterSims.com.  The actual track looks FAR better
> in No Limits, because he uses terrain and 3DS objects, both of which I
> have not implemented yet.  Also, the lack of supports kind of takes a
> bit away from the feel of the ride.
>
> That said, this represents the fact that I've fixed my banking problem
> in that corkscrews and loops work (See my post on p.general), though
> loops with little lateral movement will show a glitch, which shows
> itself in one of the loops in this ride.
>
> I need to change the method of interpolation though...through the
> corkscrews, the ride kind of wobbles because the interpolation is
> linear.  I know that No Limits uses some sort of bezier interpolation,
> but I'm not sure how exactly to implement it for banking.  I might
> settle for 3rd order b-spline interpolation.  While it may end up being
> very smooth, it won't be as accurate to the original track.
>
> -DJ

Got any barf bags?  That was kind of fun.

As a note, you have a kink in your track, ascending the loop at about the
38sec mark.

-tgq

Post a reply to this message

Trevor G Quayle wrote:
> DJ Wiza <Kil### [at] sohcahtoanet> wrote:
> 
>>http://www.sohcahtoa.net/videos/amazinggrace.m1v
>>
>>This roller coaster is called Amazing Grace.  It was designed by RiscIt,
>>one of the admins of CoasterSims.com.  The actual track looks FAR better
>>in No Limits, because he uses terrain and 3DS objects, both of which I
>>have not implemented yet.  Also, the lack of supports kind of takes a
>>bit away from the feel of the ride.
>>
>>That said, this represents the fact that I've fixed my banking problem
>>in that corkscrews and loops work (See my post on p.general), though
>>loops with little lateral movement will show a glitch, which shows
>>itself in one of the loops in this ride.
>>
>>I need to change the method of interpolation though...through the
>>corkscrews, the ride kind of wobbles because the interpolation is
>>linear.  I know that No Limits uses some sort of bezier interpolation,
>>but I'm not sure how exactly to implement it for banking.  I might
>>settle for 3rd order b-spline interpolation.  While it may end up being
>>very smooth, it won't be as accurate to the original track.
>>
>>-DJ
> 
> 
> Got any barf bags?  That was kind of fun.
> 
> As a note, you have a kink in your track, ascending the loop at about the
> 38sec mark.
> 
> -tgq
> 
> 

I know about the kink, that's why I noted above that vertical loops with 
very little lateral movement will show a glitch.

The problem is with vertical track.  If a track is exactly 90 degrees 
down, how do you know which way is up?  To make an up vector, I use 
VPerp_To_Plane to find a vector that is perpendicular to a plane defined 
by a vector that points "foward" along the track and the vector y.  This 
creates a vector pointing right.  I then use vaxis_rotate to rotate that 
by the amount of banking defined by the track.

Of course, this creates the problem that as track gets closer and closer 
to going 90 degrees either straight up or down, you get rounding errors 
that result in those kinks.

The author of No Limits found a way around it by allowing the user to 
specify that a banking angle is "relative" to the previous control 
points banking.  Not sure how I could implement that though.  I might 
have to do a lot of reworking.

-DJ

Post a reply to this message

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

> The problem is with vertical track.  If a track is exactly 90 degrees
> down, how do you know which way is up?  To make an up vector, I use
> VPerp_To_Plane to find a vector that is perpendicular to a plane defined
> by a vector that points "foward" along the track and the vector y.  This
> creates a vector pointing right.  I then use vaxis_rotate to rotate that
> by the amount of banking defined by the track.
>
> Of course, this creates the problem that as track gets closer and closer
> to going 90 degrees either straight up or down, you get rounding errors
> that result in those kinks.

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

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

Post a reply to this message

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