Thread: Camera problem: rolling

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...

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 .

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)

if you are doing polygon collision detection shrink the Y components of the polygons verticies before performing the collision tests.