Jump to content
  • Advertisement
Sign in to follow this  
Tera_Dragon

lesson 30 variable clarification

This topic is 5034 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am just reading through lesson 30 (collision detection), and don't understand what some of the variables are as they either don't have very good names, or I just plain don't unserstand them. Could you just help me out a bit and clarify this for me? It's mainly these: double rt,rt2,rt4,lamda=10000; What does rt stand for, and what is lamda used for? Thanks in advance for any help Tera_Dragon Edit: I also am slightly confused with these: TVector pb1,pb2,xaxis,U1x,U1y,U2x,U2y,V1x,V1y,V2x,V2y; If you could just give me some decent names for the variables then I would probably be able t understand the code a lot more... [Edited by - Tera_Dragon on October 1, 2004 4:07:45 PM]

Share this post


Link to post
Share on other sites
Advertisement
I thought I would post this here instead of starting another topic.
I'm having a bit more trouble with this code. Mainly this piece:

if (TestIntersionPlane(pl1,OldPos,uveloc,rt,norm))
{
// Find Intersection Time
rt4=rt*RestTime/rt2;
// If Smaller Than The One Already Stored Replace In Timestep
if (rt4<=lamda)
{
// If Intersection Time In Current Time Step
if (rt4<=RestTime+ZERO)
if (!rt<=ZERO)&&(uveloc.dot(norm)>ZERO)))
{
normal=norm;
point=OldPos+uveloc*rt;
lamda=rt4;
BallNr=i;
}
}
}


Could someone please just tell me how the steps work? I've gone over this I don't now how many times, and I just don't get it :'(

Share this post


Link to post
Share on other sites
It looks as though no one is going to help me with the above, but could some one please explain the timestep to me? This is really confusing me right now. It seems as though he only wants to render the balls every timestep, or 0.6 seconds, and work out collision detection inbetween this. Is this correct, or have I just interpreted it wrongly (more than likely)? If, however, this is correct wouldn't it be better the do the collision detection in realtime?
Tera_Dragon

Share this post


Link to post
Share on other sites
Well basicly bad things can happen if you do colition detection and physics at realtime, even though you have some kind of frame time thingeys that can adjust movement acording to time.
If you have a to low fps the object might just pass trough another object, if you have a to high framrate roundoff errors might come into play causing irratic behaviour.

Thus enter the time steps, basicly every 0.6 seconds you do the physics/movements/colitions and make every thing move ahead 0.6 seconds in time, if 1.2 seconds has passed it does it two times.
IF you seem to do more than a few frames per timestep it might be good to lag behind one frame and interpolate between two frames.

Most modern game engines use this teknuiqe, games like quake 3(uses a timestep of 1/20s) and doom3(uses a timestep of 1/60s).

Share this post


Link to post
Share on other sites
I think I'm beginning to understand it. It just does all of the physics calculations every timestep. The thing that was confusing me was the 0.6 seconds seemed quite a long time. I the timestep was too large would the game 'jump'?

Share this post


Link to post
Share on other sites
Well, basicly what i said first, let it lag behind one timestep and then interpolate the movement between that and the one before that.

And even though your not doing that and you have a timestep of 0.02 you will have an (timestep)fps of 50, so motions will still look fairly smooth.

Then it's just a matter of adjusting the GFX so that it will actuarly render at that speed.

Share this post


Link to post
Share on other sites
Quote:
Original post by lc_overlord
Well, basicly what i said first, let it lag behind one timestep and then interpolate the movement between that and the one before that.


I'm curious about how one would actually go about doing that. It seems to me that this could get very costly, especially in any kind of particle demo because of the amount of memory it requires (practically double in this case).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!