Hey all,
I'm working on a GOP abstraction for the gemwin and am running into a little anoyance.
First off the help for "view" in gemwin incorrectly states all the default views for the gemwin. They are correct except the camera is always at 4 in Z, not -4 as stated in the docs. (futher away from the camera is negative)
Second I really want standard orbit camera control, where the mouse x-y controls the rotatation of the camera around the scene, usually with the camera pointed at the centre of the scene. I was thinking view may do this, but looks like you have to specify the cartesian coords of the camera.
So before I patch it using sph2cart and some luck, what is the likelyhood of the view selector doing that?
Here is an early version of the abstraction I'm working on. (It looks perflect in windows, a little wonky in linux, and who knows in OSX!)
Thanks Ben
On Wednesday, September 3, 2003, at 12:55 PM, ben@ekran.org wrote:
Hey all,
I'm working on a GOP abstraction for the gemwin and am running into a little anoyance.
First off the help for "view" in gemwin incorrectly states all the default views for the gemwin. They are correct except the camera is always at 4 in Z, not -4 as stated in the docs. (futher away from the camera is negative)
Second I really want standard orbit camera control, where the mouse x-y controls the rotatation of the camera around the scene, usually with the camera pointed at the centre of the scene. I was thinking view may do this, but looks like you have to specify the cartesian coords of the camera.
So before I patch it using sph2cart and some luck, what is the likelyhood of the view selector doing that?
Here is an early version of the abstraction I'm working on. (It looks perflect in windows, a little wonky in linux, and who knows in OSX!)
hey ben,
...I've also been working on some better camera-type support, but haven't settled down to a particular solution...on the one side, we should be able to create an abstraction that works thru view messages to gemwin...on the other side, perhaps we need a full [camera] object; this could then have a fps-type control mode with input for forward/backward, strafe left/right, up/down, and roll: and a "follow object" mode, which allows rotation around a particular point...I've been looking into different ways to calculate rotations: using sin/cos can result in "gimbal lock", which is incorrect rotation after multiple similar rotations, or quaternions, which are complex numbers used to do matrix multiplies...
...as far as the patch goes, it looks nice, but reminds me that [gemmouse] isn't working on OSX...
l8r, jamie
Hey Jamie,
I think the simplest solution (perhaps for the next release) would just be to add view support to change the pivot point/rotation of the camera. So you could just specify the 0,0,0 point as the pivot, place your camera and point it at the pivot and then rotating the camera accordingly. A camera object would be pretty cool, how would you attach the view to a particular camera object? It would be nice to be able to use the same translate and rotate objects as with any other geometry... It may be confusing without an objective view though, so you can see the camera's relation to the scene, rather than looking through it...
I've never heard of this gimbal lock issue, I've written a simple little 3D renderer in SDL that just plotted points on a 2D surface. I used:
x' = cos(za)x + sin(za)y y' = -sin(za) + cos(za)y
etc.. I then rotated around each axis consecutivly. I did hear about uding quaternions for this stuff, if you go that way I'd love to see the code.
Is gemmouse aimed to be ported for the next release?
Later Ben
On Wednesday, September 3, 2003, at 12:55 PM, ben@ekran.org wrote:
hey ben,
...I've also been working on some better camera-type support, but haven't settled down to a particular solution...on the one side, we should be able to create an abstraction that works thru view messages to gemwin...on the other side, perhaps we need a full [camera] object; this could then have a fps-type control mode with input for forward/backward, strafe left/right, up/down, and roll: and a "follow object" mode, which allows rotation around a particular point...I've been looking into different ways to calculate rotations: using sin/cos can result in "gimbal lock", which is incorrect rotation after multiple similar rotations, or quaternions, which are complex numbers used to do matrix multiplies...
...as far as the patch goes, it looks nice, but reminds me that [gemmouse] isn't working on OSX...
l8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
ben＠ekran.org -
tigital