|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
First rendering of a complete ride!! Links:
http://www.sohcahtoa.net/videos/antigone.m1v
http://www.sohcahtoa.net/videos/antigone.avi
Both are 1.8 megs, the AVI is encoded in DivX 6. M1V is obviously MPEG1.
Banking is working, track ties are transforming correctly now (Except
that last couple segments), no disappearing objects.
I now precalculate the positions of all the points that make the track
rails, as well as the locations of the track ties. For that track, it
takes about 2 1/2 minutes to calculate that data. It saves it in an
include file. After that, it only takes about 3 seconds to parse.
I'm also no longer using sphere_sweeps, but rather, spheres connected by
cylinders as suggested by scott on p.b.i. This dramatically reduced
rendering times. When I first started rendering this specific track, it
took over 2 minutes to render each frame without AA. When I switched to
spheres/cylinders, it now takes only 6 seconds even WITH AA.
The only other point to mention is that I haven't implemented any sort
of friction or wind resistance, hence the reason why the ride is going
so fast at the end.
(Oh...and about the filename...AntiGone is the name of the track. I did
not design the track, but rather I got it off of CoasterSims.com)
One more note...the way I'm calculating banking is completely wrong.
The transitions are MUCH smoother in No Limits. I'm just using some
basic linear interpolation, which will cause problems when I make roller
coasters with loops because at the bottom of the loop, banking is 0. At
the top, its 180. With the way I'm doing banking, it'll turn into 90
half way up, which is wrong. This creates some distortion that can been
seen at http://www.sohcahtoa.net/images/thriller.png . Does anyone know
how I could work around that?
-DJ
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wow. That's very cool!
Maybe you could try to link the look_at (or direction) vector of the camera
to a point further ahead on the track. I guess this would result in a more
realistic appearence and thus strenghten the observers feeling of being
part of the action (at the moment it looks more like a camera that is
attached to the wagon (if this is the right word?)). Maybe it would also
smooth out those kinks a bit since camera and movement wouldn't jump at the
same time.
Regards Roman
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> First rendering of a complete ride!! Links:
>
> http://www.sohcahtoa.net/videos/antigone.m1v
> http://www.sohcahtoa.net/videos/antigone.avi
Wow that is great! Even though it is basic graphics it really feels like
you're on there.
Roman's suggestion was a good one about setting the camera look_at further
up the track.
And maybe add in some random vibration to the camera too, although I guess
it would be quite tricky to get that right, it would need to be linked to
the speed of the wagon.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Roman Reiner wrote:
> Wow. That's very cool!
> Maybe you could try to link the look_at (or direction) vector of the camera
> to a point further ahead on the track. I guess this would result in a more
> realistic appearence and thus strenghten the observers feeling of being
> part of the action (at the moment it looks more like a camera that is
> attached to the wagon (if this is the right word?)). Maybe it would also
> smooth out those kinks a bit since camera and movement wouldn't jump at the
> same time.
>
> Regards Roman
>
You're probably right. Right now, the look_at point is barely in front
of the camera, so it is as if the camera is attached to the car (That's
the word we use, at least in the US). No Limits does it the same way,
though I think it might be a LITTLE bit farther ahead.
What makes it seems really jerky is the banking. I'm not doing it right
at all. In No Limits, the banking transitions are far smoother. The
thing is, Ole Lange, the author of No Limits, is very secretive about
how he calculates the banking.
-DJ
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>
> And maybe add in some random vibration to the camera too, although I guess
> it would be quite tricky to get that right, it would need to be linked to
> the speed of the wagon.
>
>
Wouldn't be too tricky at all, really. The question is realism.
How much the track vibrates depends on the manufacturer and designer of
the ride. Arrow Dynamics rides are known to vibrate signficantly,
especially during points of lateral Gs. B&M are known to be smooth as
glass, with almost no vibrations at all. Intamin is also very smooth,
but with a few years age, they tend to just shake a little.
Of course, all of those are just for steel tracks. For wood, EVERY
manufacturer vibrates, its just a matter of how much.
So adding a vibration to the camera doesn't necessarily add realism.
Besides, I would think that video compression, especially low-bitrate
MPEG1, would HATE it.
-DJ
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
DJ Wiza wrote:
> First rendering of a complete ride!! Links:
>
> http://www.sohcahtoa.net/videos/antigone.m1v
> http://www.sohcahtoa.net/videos/antigone.avi
>
> Both are 1.8 megs, the AVI is encoded in DivX 6. M1V is obviously MPEG1.
>
> Banking is working, track ties are transforming correctly now (Except
> that last couple segments), no disappearing objects.
>
> I now precalculate the positions of all the points that make the track
> rails, as well as the locations of the track ties. For that track, it
> takes about 2 1/2 minutes to calculate that data. It saves it in an
> include file. After that, it only takes about 3 seconds to parse.
>
> I'm also no longer using sphere_sweeps, but rather, spheres connected by
> cylinders as suggested by scott on p.b.i. This dramatically reduced
> rendering times. When I first started rendering this specific track, it
> took over 2 minutes to render each frame without AA. When I switched to
> spheres/cylinders, it now takes only 6 seconds even WITH AA.
>
> The only other point to mention is that I haven't implemented any sort
> of friction or wind resistance, hence the reason why the ride is going
> so fast at the end.
>
> (Oh...and about the filename...AntiGone is the name of the track. I did
> not design the track, but rather I got it off of CoasterSims.com)
>
> One more note...the way I'm calculating banking is completely wrong. The
> transitions are MUCH smoother in No Limits. I'm just using some basic
> linear interpolation, which will cause problems when I make roller
> coasters with loops because at the bottom of the loop, banking is 0. At
> the top, its 180. With the way I'm doing banking, it'll turn into 90
> half way up, which is wrong. This creates some distortion that can been
> seen at http://www.sohcahtoa.net/images/thriller.png . Does anyone know
> how I could work around that?
>
> -DJ
I have been following your threads very closely (I am a browser not much
of a poster) and have been waiting for every new arrival.
This is something I have wanted to do myself for a long while and
although knowing the math behind it would not know how to implement it.
I noticed in your animation that some of the track is still missing
(very small criticism) on some of the track that is visible from the
current position. Dont know if you are aware of this or not. If you
want the times let me know. It seems to be on the high points of the track.
Keep up the excellent work on this, I for one am waiting for the next
installment.
Dave.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Brickell wrote:
> I have been following your threads very closely (I am a browser not much
> of a poster) and have been waiting for every new arrival.
Cool. Makes me feel good to have brought a lurker out from the darkness.
> This is something I have wanted to do myself for a long while and
> although knowing the math behind it would not know how to implement it.
Its not really that hard. Was it the animation, or the track itself
that you weren't sure how to implement?
> I noticed in your animation that some of the track is still missing
> (very small criticism) on some of the track that is visible from the
> current position. Dont know if you are aware of this or not. If you
> want the times let me know. It seems to be on the high points of the
> track.
The beginning of the first drop as a gap in the very top. That's a
known problem. That's simply because the very last segment isn't drawn.
That will be fixed later. The first drop can be seen on the right
before entering the helix at about 25 seconds. As it goes over a bunny
hill at about the 30 second mark, you can see it on the left. Then for
a split second at 39 seconds you can see it going up the hill. Then one
final glimpse of it at 47 seconds as you enter the last turn.
Its all the same hill, unless there's some other parts where track
disappears. There's no reason anything SHOULD be disappearing. The
track is generated once and saved into an include file, which is then
included on every frame.
> Keep up the excellent work on this, I for one am waiting for the next
> installment.
I'm currently rendering one with the framerate set to 300 fps. The idea
is to turn it into a 30 fps video with 10-sample motion blur. I made
another .pov file for making motion blur easy. I haven't made it
configureable yet, but you'll just give it the prefix (ie, "image") the
number of digits, the suffix, and the number of samples per frame, and
it'll turn every N frames into a single frame by rendering them all to a
box with an average of image_maps. For example, if the prefix is
"bezier", digits is 5, suffix is ".png", and 10 samples per frame, it'll
turn bezier00000.png through bezier00009.png to image00000.png,
bezier00010.png though bezier00019.png into image00001.png, and so on.
So basically, to get motion blur, you just render your scene with a high
number of frames, then open up the motion blur .pov file, set the
#declares at the beginning, and render it, and you'll be done.
I'll probably post it to p.b.s-f when I'm done.
-DJ
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So basically, to get motion blur, you just render your scene with a high
> number of frames, then open up the motion blur .pov file, set the
> #declares at the beginning, and render it, and you'll be done.
Heh, that's something I've scripted some time ago as well. It's funny how we
Povers always end up writing our own motion blur script, particle system and
what not... I even tried something fancy like giving the first frame more
"exposure" than latter ones, it does create interesting results if used
excessively...
In regard to your animation, a real nice one. Rune (http://runevision.com)
did something similiar some time ago, and IIRC he had some shaking on his
camera. You might want to email him and ask him, or just look at his
source-code, though he used MegaPOV.
Regards,
Tim
--
aka "Tim Nikias"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And maybe add in some random vibration to the camera too, although
>> I guess it would be quite tricky to get that right, it would need
>> to be linked to the speed of the wagon.
>>
>>
>
> Wouldn't be too tricky at all, really. The question is realism.
>
> How much the track vibrates depends on the manufacturer and
> designer of the ride. Arrow Dynamics rides are known to vibrate
> signficantly, especially during points of lateral Gs. B&M are
> known to be smooth as glass, with almost no vibrations at all. Intamin is
> also very smooth, but with a few years age, they tend to
> just shake a little.
Yeh, what I meant was it would be tricky to get the vibration looking
anything like realistic. Without simulating it properly (which would be a
horrendous task in non-linear vibrations and FEM) I guess you need to think
of a simple algorithm to determine the camera displacement at each frame.
My first thought is to define some macro that determines the camera
displacement as a function of distance along the track. Some sort of noise
function, like Perlin noise might do the trick. That way, the faster you go
the faster the camera will vibrate.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|