Hi,
I’m trying to implement a mouse-controlled camera(sort of Q3A-style).I know this question has been asked tons of times before but a search in the archives didn’t bring up anyting really usefull.Anyway I tried out the following:
,where mx,my are mouse coords,(x0,y0) is the screen center and p is the camera pos.
Apart from the fact that this way I can rotate up to a certain amount,which can be fixed by warping the pointer to (x0,y0) every time and accumulate the rotation angles,this isn’t very smooth.Yet if I do this for every frame like I do now, I don’t see how it can be done better(smoother).Maybe if I poll the mouse every n frames/ms and interpolate the camera inbetween I can get better results?How is this usually done?
[This message has been edited by zen (edited 04-25-2002).]
No,why do I need to use gluLookAt?I don’t need to look at a specific spot in space,I just want to rotate my camera smoothly using the mouse.Is there something I’m missing?Maybe I should take a look at the Quake I/II sources.
Your code looks pretty neat. The only thing might be to take the calculation of angles out of the glRotate function, that might help a bit. Still I don’t see any glaring problem.
What’s the difference in the framerate before and after you use the mouse rotation?
I have the same thing. I’m doing the camera rotation just like that and the rotating is very ‘jumping’. I use allegro’s mouse routines and update the mouse every millisecond. Still it’s ‘blocky’.
Just to make this clear.I can’t say that movement is very blocky.It looks fairly acceptable at 28fps and at 50-60 it looks better but it still isn’t as smooth as seen in games like quake.That’s why I’m curious wether there’s more to it than just a couple of glRotatefs and a glTranslatef.
Zuraffo:fps drop from 29.5 to 28.7 on average but I assume this happens because of the 2 glRotatefs which can be optimized away since we just need rotation about the x and y axii.
blender:the only possible reason I can think of for getting very jumpy rotation is getting too low fps.What kind of fps do you get?Updating the mouse every millisecond would only pay off for framerates close to 1000fps(for the camera at least).BTW what are these allegro routines you’re reffering to?
you may want to store your camera’s look, up and right vectors. for my camera, i get the change in mouse coordinates from previous frame and create pitch and yaw angles. i use the pitch angle and the right vector to generate a rotation matrix. the look and up vectors get transformed by this matrix. i create another rotation matrix using the yaw angle and the vector <0,1,0>. then i transform the look, right and up by this matrix. then, using look, right and up, i create a matrix and use glLoadMatrixf. no rotates or translates, and it works great!
also, this makes moving around easy. to move forward, just alter your position like this:
position += look * 5.0
and strafing:
position += right * 5.0
the only complicated part is creating the rotation matrices, but you can find out how to do that here
good luck
b
[This message has been edited by coredump (edited 04-26-2002).]
I agree that a camera model,such as the RUV model you describe is neccesary but I don’t think this will make things any smoother since you’ll eventually end up with the same rot. matrices.IMO since I poll the mouse position every frame,smootheness is framerate-dependant.Maybe if I poll every say 4 frames and then interpolate betwwen them…but polling every frame would essentially take care of the interpolation anyway.
Nevertheless I should implement a camera model anyway,so I’ll try that first.
zuraffo:no,just didn’t get around to implementing one.
Gavin:is there any info on how to do that anywhere?Anyway I thought it would get down to quaternions but since I’m polling every frame and therefore can’t use interpolation I don’t see how quaternions would make things any better.
I believe the problem is the framerate though.I set quake to run at 25fps and the camera moved sort fo like mine.