|
TSDK posted:Collision detection has always been, and still is, about spatial partitioning. Use bounding boxes for quick checks to trivially reject collisions that can't possibly happen. Maybe subdivide the screen with either a kd-tree or quad-tree so that you don't check object versus object when they're completely contained in different leaves. Similar to this, how do I go about 3d collision detection for non-regular objects? They won't be massively complex, but something like a bounding sphere or aabb won't be precise enough. I had a look at http://www.gamasutra.com/features/20000203/lander_02.htm which was kinda helpful but fairly old, and the journal articles I want to read on the subject aren't available to me We're not allowed to use external libraries, it all has to be coded by us. Obviously I can use the above stuff to cut down the possibilities, but what about lower-end methods?
|
# ¿ Feb 22, 2008 15:55 |
|
|
# ¿ Apr 24, 2024 18:06 |
|
Quaternion camera question~ The way I'm doing it is basically this; if key = a m_x -= 1.0f if key = d m_x += 1.0f .. so on for y/z (m_y, m_z) drawloop { m_camera = quatmultiply(m_camera, eulertoquat(m_x, m_y, m_z)) m_x = m_y = m_z = 0 matrix = quatcreatematrix(m_camera) glMultMatrix(matrix) glTranslatef(-m_position.x, -m_position.y, -m_position.z) } Which works great. Except in one case. It suffers from standard rotate x then y != rotate y then x. It does not suffer from gimbal lock, however. As an example, if you yaw left 20 units, pitch up 20 units, yaw right 20 units, pitch down 20 units, you'll end up rolled right very slightly from your previous rotation. Any ideas?
|
# ¿ Mar 20, 2008 16:08 |
|
HB posted:You're not taking the camera's current orientation into account when rotating, so all rotations are being performed around the same 3 axes. You need to take the axis the key command is supposed to rotate around and rotate *that* to be relative to the camera before using it to change the camera itself. So if I'm understanding right, to yaw I should be getting the "y" axis from the current rotation and multiplying the current rotation by the quat generated by (m_x, ("y")) instead, then doing the same for the other axes that need to be rotated that frame?
|
# ¿ Mar 20, 2008 16:37 |
|
HB posted:Pretty much. You already have the current camera orientation as a quat. You take the natural Y axis and rotate it with this quat, so that from the camera's perspective it's where the Y axis should be. Then you rotate the camera around this new axis by the amount the user inputted. This is still absolutely destroying my head. http://code.bulix.org/9mib1o-66195 Using the code above, the camera twists slightly after yaw right+pitch up+yaw left+pitch down or any combination as such. The camera will end up twisted like 5-10 degrees from its initial orientation. Is this just a function of quaternions, or is something in my code horribly wrong? For clarification, playership.m_x/y/z are floats representing user input last frame, a toggle. playership.m_camera is the rotation quaternion stored each frame. I use a quaternion to store axis/angle information in the bottom 3 functions simply because it's an appropriate datatype (vector+scalar).
|
# ¿ Apr 18, 2008 20:26 |
|
Another semester, another delightful project unit - this time we're allowed to use C++ though :v Same trouble as before (many pages ago), Quaternion twist. ie. When in free-look mode with the camera (space-sim style), a rotation of left-down-right-up or any similar combo will end up with a slight twist around the z axis. Code is here: http://chimtest.game-host.org/CameraExample.rar Please ignore the lovely glbase code, I'm just using it to drop in the class and test it. Function that probably causes it: Camera::glCamera() (Camera/Camera.cpp) You're also welcome to mock my unfinished code and suggest improvements / berate me for doing stupid things. e; logic in my brain suggests that this is intentional quaternion rotation (which I can explain properly with my hands but not on paper) ee; vanja is gay Murodese fucked around with this message at 15:48 on Jun 25, 2008 |
# ¿ Jun 25, 2008 15:39 |
|
Trying to make a 3d person camera in opengl that can be attached to objects and will stay m_zoomLevel distance behind it, no matter the orientation. I have it set up so that using the cursor keys will turnleft/right/pitchup/down the player object. The camera object is attached to the player object and should just follow it around, but I'm running into problems related to my dumbness and opengl's matrices. Some very rough psuedocode explaining how I have it; (note that the class variable layout is not actually how I have it, but is indicative of the variables available to the classes) code:
Is this the right way to do it and I'm missing something in the player's transformation step, or am I retarded for doing it like this? Murodese fucked around with this message at 19:08 on Aug 12, 2008 |
# ¿ Aug 12, 2008 18:55 |
|
|
# ¿ Apr 24, 2024 18:06 |
|
OneEightHundred posted:Generally you want to do zoom in the projection matrix by changing the FOV. This isn't actually zoom, it's just indicative of the number of units the camera sits behind the attached object in third person mode.
|
# ¿ Aug 13, 2008 04:05 |