if ( xm < ((zoom * tan(22.54))/2) || xm > -((zoom * tan(22.54))/2))
{
xmoveb = !xmoveb;
}
if ( ym < ((zoom * tan(22.54))/2) || ym > -((zoom * tan(22.54))/2))
{
ymoveb = !ymoveb;
}
if ( zoom >= -20.0 || zoom <= -50.0)
{
zom = !zom;
}
Very Interesting problem
Author
Some of you may notice this is like the 4th time this has come up, but you ppl wont help me, and i have asked many ppl, nobody knows what i should do. Im trying to get a cube to bounce around the screen but the screen size gets bigger depending on how far back the cube is on the Z-axis. I got this, but it still wont work, it goes off screen at certen points, and its like shaking at certain points, although i think i have the shackign fixed:
DarkHunter,
I think your problem may be that you are negating your vectors instead of explictly setting them . If the situation arises where the center point is outside the boundary for more than one iteration your cube will end up going in the wrong direction (causing shaking and disappearing).
Try this instead:
if (xm < ((zoom * tan(22.54))/2) )
xmoveb = +xVec;
if (xm > ((zoom * tan(22.54))/2) )
xmoveb = -xVec;
if (ym < ((zoom * tan(22.54))/2) )
ymoveb = +yVec;
if (ym > ((zoom * tan(22.54))/2) )
ymoveb = -yVec;
Where xVec and yVec store the delta values for the cube.
btw ,a more accurate test would be to test each point of the cube, not just its center for collision with your boundary.
You also need to be aware that you are testing against a pyramid specified in world space - and that the perspective projection of world space into view space (where objects further away are shrunk to mimic perspective) will distort this pyramid, therefore you might not get the results you expect.
Perhaps a more accurate approach would be to use Frustum Culling (see www.morkmorley.com) to determine whether or not your cube has reached the edge of the visible screen. Its more complicated to set up but would come in handy in many other areas so is worth while.
Cheers
Keef
-----------------------
glDisable(WORK);
glEnable(GL_CODING);
Author
omg sombody actually responded with help! Thanks so much, that will help alot. Peace
Please don''t wish us bad things when we do not answer.
Perhaps there''s something in your topic that does not help for answering (eg we don''t understand the question) or perhaps we don''t know what to answer because the problem is too complex or too specific.
If you feel that your question is forgotten, I''d recommend to rephrase the problem instead of flaming around.
Flaming only serves to give a reason for moderators to close a thread, which obviously does not help the problem.
I''m just trying to help by writing that. Please don''t blame me. Thanks.
Perhaps there''s something in your topic that does not help for answering (eg we don''t understand the question) or perhaps we don''t know what to answer because the problem is too complex or too specific.
If you feel that your question is forgotten, I''d recommend to rephrase the problem instead of flaming around.
Flaming only serves to give a reason for moderators to close a thread, which obviously does not help the problem.
I''m just trying to help by writing that. Please don''t blame me. Thanks.
Author
your right tho. Im sry if i came off as a mean person, it wasn''t that i was mad or irretated that i wasn''t getting a responce, its that i couldn''t figure it out. I dont blame any of you for not answering, cause some of your guys questions are way to complex for me to answer, so i sry if i came off as a jerk. that was not my intent, just trying to get a answer.
This is not about collision detection, just some suggestions that may help.
1)It looks like it is C code and your argument (22.54) to the tangent function looks too big to be in radians. It looks like it is in degrees. C expects the tangent argument to be in radians.
2)It is best to restrict the tangent argument between -pi/4 to pi/4 if you can.
3) The tangent function is expensive to calculate so it would be best to calculate the term ((zoom * tan(22.54))/2) once outside the if statements. Your compiler optimizer may take care of this for you, but it is best to do this yourself.
1)It looks like it is C code and your argument (22.54) to the tangent function looks too big to be in radians. It looks like it is in degrees. C expects the tangent argument to be in radians.
2)It is best to restrict the tangent argument between -pi/4 to pi/4 if you can.
3) The tangent function is expensive to calculate so it would be best to calculate the term ((zoom * tan(22.54))/2) once outside the if statements. Your compiler optimizer may take care of this for you, but it is best to do this yourself.
Author
interesting...I didn''t think it had anything to do with collsion detection either, but if i had to, i would use it. I will keep that in mind about the tangent. I HATE TRIG! just geting that point across. Anyways, i forgot to give credit were credit is due, i dont remember who it was, but sombody in a earlier post pointed out the zoom * tan(22.5) / 2 would work. He actually had it * 2, and * (3/2) for the height. Anyways, just babbling. btw Keef, xmoveb is a booleon value, true or false. If it hits the side, it bounces back, if its true it adds xmove, if its false it subtracts xmove, same for y and z.
the code wont work mainly cause your screen is not a circle 
read the faq (www.opengl.org) theres info there on how to extract the planes from the viewing frustum then u can do a plane->box plane->point test
also one thing that helps in times like these is to draw the planes (or the code from your example eg if ( xm < ((zoom * tan(22.54))/2) || xm > -((zoom * tan(22.54))/2))) + visually see why it doesnt work
btw watch out when mixing intergers + floating point numbers itll lead to grief
http://uk.geocities.com/sloppyturds/gotterdammerung.html
read the faq (www.opengl.org) theres info there on how to extract the planes from the viewing frustum then u can do a plane->box plane->point test
also one thing that helps in times like these is to draw the planes (or the code from your example eg if ( xm < ((zoom * tan(22.54))/2) || xm > -((zoom * tan(22.54))/2))) + visually see why it doesnt work
btw watch out when mixing intergers + floating point numbers itll lead to grief
http://uk.geocities.com/sloppyturds/gotterdammerung.html
quote:Original post by j p
This is not about collision detection
What is it then?
Perhaps I shouldn''t have used the phrase ''collision detection'', as it implies a whole bunch of other stuff as well, but I still think comparting to the view frustum in the most accurate way to go.
An alternative is to set up your own view planes rather than use the ones from the model view matrix.
Either way, in reality your are trying to detect of your cube intersects with a boundary in world space and that IS a collision detection problem, even if it does not fit into the classic "I wanna ray cast to find out if the player has hit something" mode.
All that aside, if you stop negating your vectors and specifically set them to the direction you need to go you should get improvements.
Keef
-----------------------
glDisable(WORK);
glEnable(GL_CODING);
Clarification to Group:
I meant that my comments were not about colision detection per se. They were mostly about the math. Sorry about the confusion.
I meant that my comments were not about colision detection per se. They were mostly about the math. Sorry about the confusion.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
