# lesson 30 variable clarification

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

## 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 on other sites
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 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 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 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 on other sites
yea, it would start to jump, try a value between 0.1 and 0.02.

##### Share on other sites
And it should render each timestep? What if a frame passes but it is still in the same timestep?

##### 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 on other sites
ok, thanks. You've been very helpful. *rating up!* ;)

##### Share on other sites
Quote:
 Original post by lc_overlordWell, 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 on other sites
Simple, don't.
Since particles normaly don't have any contrast or sharp edges like regular polygons do, you will be ok with just updating it only 20 or so times a second without any type of interpolation.

as for objects and so on, well if your computer is choking on a couple of kilobytes(unless you have thousands and thousands of objects), Get another computer.

If it still chokes, then you really don't have to interpolate everything, infact if you only want to interpolate one thing, then do it to the camera.

##### Share on other sites
I finally finished writing up the tutorial, and got about 1000 errors (I'm not using the classes that the guy who wrote these tutorials is). I got round to fixing all of these, but then when I ran it it seemed to get stuck in the idle function. So I changed one line of code (not sure if it's the problem though) and get an error. Here's the code:
Vector3 pb1,pb2,xaxis....//changed from:xaxis=(pb2-pb1);xaxis.normalize();//toxaxis=(pb2-pb1).normalize();// Here's the normalise code:void Vector3::normalize(){	float magSq = x*x + y*y + z*z;	if(magSq > 0.0f)	// check for divide by zero	{		float oneOverMag = 1.0f / sqrt(magSq);		x *= oneOverMag;		y *= oneOverMag;		z *= oneOverMag;	}}

And This is the error:
error C2679: binary '=' : no operator defined which takes a right-hand operand of type 'void' (or there is no acceptable conversion)

Any ideas?

##### Share on other sites
The problem is exactly what the compiler is telling you. The member function 'normalise' modifies the object it operates on and returns nothing. I'll walk you through the code as the compiler sees it:
(pb2-pb1) : call operator-(pb2, pb1) and store the result in a temporary.
xaxis=(temp).normalize() : call normalize() on the temporary just created and store what is returned from normalize() in xaxis. Error: normalize() does not return anything.
What the original code does is:
(pb2-pb1) : call operator-(pb2, pb1) and store the result in a temporary.
xaxis=(temp) : copy temp into xaxis.
xaxis.normalize() : call normalize() on xaxis.

Hope that's clear enough.

Enigma

##### Share on other sites
Errm, but still, why doesn't it work?

##### Share on other sites
It might be clearer if I rewrite it as it would be in pure C.
xaxis=normalize(pb2-pb1);
Correct way:
xaxis=pb2-pb1;
normalize(xaxis);

The member function normalize() normalizes its argument and returns nothing. When you try to do xaxis=normalize(pb2-pb1) it normalizes the temporary created by subtracting pb1 from pb2 and returns nothing to be assigned to xaxis.

Assume that we're working with 2D vectors and pb1 = {1, 0} and pb2 = {1, 2}.

pb2-pb1 : creates a temporary with value {0, 2}.
normalize(temp) : normalizes the temporary to {0, 1} and returns nothing.
xaxis=void : this is an error.

Correct way:
pb2-pb1 : creates a temporary with value {0, 2};
xaxis=temp : copies the temporary to xaxis, leaving xaxis with value {0, 2};
normalize(xaxis) : normalizes xaxis to {0, 1} and returns nothing.

Enigma

EDIT: A couple of typos.

[Edited by - Enigma on October 4, 2004 6:34:00 AM]

##### Share on other sites
Ah I see now. Sorry about that. :-/

##### Share on other sites
w00t!!!! Found my problem, it had nothing to do with that or whatever I thought it could be. I was so certain I had done everything correct. Turns out I had missed a brace ( } ) somewhere and must have just thought it went onto the end of the idle function, this is what was causing my loops to screw up. Thanks for all the help :-D

##### Share on other sites
Something is not working right. When I ncrease the size of the balls to 4 instead of 2 (I correct the double radius in the ball against ball collision detection to 8) the balls collide incorrectly with planes. I hav to minus 2 to the folowing line of code:
l2 = (plane._Normal * (plane._Position - position))/DotProduct;

So it becomes:
l2 = (plane._Normal * (plane._Position - position))/DotProduct - 2;

I can understand this, but isn't anything like this needed for the bals of size 2?

Tera_Dragon

Edit: I just found out that minusing 2 can cause errors, and make the ball able to slip passed the plane. What is the correct way to work out the point of collision for larger spheres please?