lesson 30 variable clarification
Author
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]
Author
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:
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 :'(
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 :'(
Author
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
Tera_Dragon
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).
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).
Author
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'?
Author
And it should render each timestep? What if a frame passes but it is still in the same timestep?
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.
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.
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
