Camera problem: rolling

This is a discussion on Camera problem: rolling within the Game Programming forums, part of the General Programming Boards category; That's an interesting way of doing it Darksaidin. I don't see any reason why it shouldn't work. Do you have ...

  1. #31
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    That's an interesting way of doing it Darksaidin. I don't see any reason why it shouldn't work. Do you have enough coded into your engine that you can test it out to make sure it doesn't gimbal lock?

    If you do:
    Yaw 90 degrees
    compare pitch and roll
    reset to original orientation

    Pitch 90 degrees
    compare yaw and roll
    reset to original orientation

    Roll 90 degrees
    compare pitch and yaw
    reset to original orientation

    If anything's messed up and you follow those directions - you'll know it. If everything appears correct, go celebrate
    Away.

  2. #32
    *******argv[] - hu? darksaidin's Avatar
    Join Date
    Jul 2003
    Posts
    314
    mhm, I've just had funny 30 minutes of flying through ut_swim. I didn't notice any problems. The angles beween the vectors were sometimes off by a few 1/10000 degrees but they always reverted back to 90 as expected.

    So, I think I'll do something easier now. It's about time for the interface class that maps userinput to the engines different objects and functions. The next thing after that has to be collision detection - unless I find a good reason to postpone it. I guess I'll have to open another thread about that in a few days...

  3. #33
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    Cool. I didn't know you had model loading and the world in there :P

    >>sometimes off by a few 1/10000 degrees<<
    That's just floating point innacuracy. A float can hold 7 (I repeat, seven) digits accurately. That includes both numbers before and after the decimal, for a total of seven. After that, they aren't guarenteed to be accurate, and probably won't be. Why are you even storing your numbers as degress, though, when you will end up converting them to radians? Why not keep them in radians the entire time, and save all the conversions? Radians really aren't hard to work with...

    >>It's about time for the interface class that maps userinput to the engines different objects and functions.<<
    How did you fly around without that? Anyway, learning enough directinput to make my movementhandler and actually coding it took less than an hour, so you shouldn't have any trouble with that. I know you aren't using DirectX, but input is even easier from the WinAPI with the exception of the mouse, and it's not bad with other APIs either.

    >>The next thing after that has to be collision detection<<
    I haven't coded mine yet either, but it isn't hard. There have been a couple threads about it recently, and it's just a little bit of simple math, which you'll have to stick inside a loop which goes through all the objects you're checking for collisions.
    Away.

  4. #34
    *******argv[] - hu? darksaidin's Avatar
    Join Date
    Jul 2003
    Posts
    314
    Originally posted by confuted
    >>sometimes off by a few 1/10000 degrees<<
    That's just floating point innacuracy. A float can hold 7 (I repeat, seven) digits accurately. That includes both numbers before and after the decimal, for a total of seven. After that, they aren't guarenteed to be accurate, and probably won't be. Why are you even storing your numbers as degress, though, when you will end up converting them to radians? Why not keep them in radians the entire time, and save all the conversions? Radians really aren't hard to work with...
    I already use radians . Thats why the input is multiplied by (PI/180). It's just there because outside of the camera everything is in degrees. I did that because OpenGL does the same.

    Originally posted by confuted
    >>It's about time for the interface class that maps userinput to the engines different objects and functions.<<
    How did you fly around without that? Anyway, learning enough directinput to make my movementhandler and actually coding it took less than an hour, so you shouldn't have any trouble with that. I know you aren't using DirectX, but input is even easier from the WinAPI with the exception of the mouse, and it's not bad with other APIs either.
    How I controlled the camera? Mind control of course!
    No, just kidding. What I was talking about was a programmable object class that maps userinput to the existing object input functions. Gah... again I can't explain what I mean...

    Code:
    	float speed = 100 * p->poRenderer->getFrameInterval();
    	if (p->oKey.get(VK_UP)) {
    		p->poCamera->pitch(speed);
    	}
    Thats in the engines main loop right now. It's hardcoded keyboard control. Thats not what I want. I need a programmable interface. Something like engine.interface.bind(kMouseAxisX, &poCamera, 'yaw') that makes sure that every change of the mouse x axis calls an interface function in poCamera (like performInterfaceCommand(CommandString, Parameter) in the cameras abstract baseclass. Well something like that. More or less...

    Originally posted by confuted
    >>The next thing after that has to be collision detection<<
    I haven't coded mine yet either, but it isn't hard. There have been a couple threads about it recently, and it's just a little bit of simple math, which you'll have to stick inside a loop which goes through all the objects you're checking for collisions.
    ya, the math is the problem. This thread proves it .

  5. #35
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    Oh, this math isn't much of a problem. You'll actually use bounding ellipsoids (or whatever an oval in 3d is called), but I'll give an example with bounding spheres, because I'm tired and it's easier.

    Let r1 and r2 represent the radii of two spheres.

    Let <x1,y1,z1> represent the location of the center of the first sphere, and <x2,y2,z2> represent the center of the second sphere.

    Let D represent the distance between the centers of the spheres.

    Let <x,y,z> represent <x2-x1,y2-y1,z2-z1>

    D= sqrt(x^2+y^2+z^2)

    If the two spheres are tangent, D = r1+r2, ergo

    if r1+r2 >= D we have a collision

    -------

    Bounding spheres would suck. You'll want bounding ellipsoids. They aren't much harder. Well, maybe they are harder, because you'll have three different axes, each of which could have a different length. If you need help figuring out the radius of that at different points, let me know, and I'll try to work out the math.
    Last edited by confuted; 08-12-2003 at 09:03 PM.
    Away.

  6. #36
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    a way of doing bounding ellipsoids for collisions against the world is to use a sphere but shrink the world in half (it's called sphere mapping and afaik its actually an acceptable method, not a work around, although an odd one)

  7. #37
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    Can you elaborate on that Silvercord? Or point me to where you learned it so I can bookmark it?
    Away.

  8. #38
    Banned
    Join Date
    Jan 2003
    Posts
    1,708
    if you are doing polygon collision detection shrink the Y components of the polygons verticies before performing the collision tests.

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 07:54 PM
  2. Model orientations in 3D
    By VirtualAce in forum Game Programming
    Replies: 11
    Last Post: 11-14-2006, 12:21 AM
  3. directx problem with camera , nothing happens
    By Anddos in forum Game Programming
    Replies: 1
    Last Post: 04-10-2006, 04:14 AM
  4. Laptop Problem
    By Boomba in forum Tech Board
    Replies: 1
    Last Post: 03-07-2006, 06:24 PM
  5. Replies: 5
    Last Post: 11-07-2005, 11:34 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21