Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

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.

Once you've pruned out all of the collisions that can't happen at a high level, then you're left with those that may happen at a lower level. How you check those will depend on what sort of sprites you've got and what sort of collision you want.

It may be good enough just to subdivide the sprite down further and do overlapping box checks on a smaller scale. If you want to go pixel perfect, then you could alway render the overlap region offscreen using a logical-and mode and then scan through the vram with the cpu to check for non-zero results. Or you could store the min and max extent values for each line of pixel data in the sprite, and then for the overlap lines you're doing a 1d min-max overlap check.

Basically, there are loads of options out there, and you'll only figure out which one is best after trying a few, profiling and weighing the cost up against memory footprint etc...

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?

Adbot
ADBOT LOVES YOU

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.
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?

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

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.

I made a fairly long post about this a few pages back. You already have most of it down, so just look at the last two blocks.

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?

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

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

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.
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

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.
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:
class Camera inherit BaseObject
{
    float m_zoomLevel;
    Quaternion m_orientation;
    Vector3 m_position;
    BaseObject *m_attached;
}

class Player inherit BaseObject
{
    Quaternion m_orientation;
    Vector3 m_position;
    BaseObject *m_attached_to;
}

// in init function

void init()
{
    camera->attach(player);
}

// in renderscene (again not actually within renderscene but an example without functions so it's centralised)

void renderScene()
{
    //opengl clearcolor etc, already set to modelview
    glLoadIdentity();

    // set the camera's orientation to the same as the attached object
    // i figured this should be ok, as the camera will always be set to be directly
    // behind the attached object
    camera->m_orientation = Quaternion(camera->m_attached->m_orientation); 
    
    // i would think that this should set the camera's position to m_zoomlevel units directly behind
    // the object
    camera->m_position = camera->m_attached->m_position + (camera->m_attached->m_orientation.getFront() * -camera->m_zoomLevel);

    Matrix4 transform(camera->m_orientation.toMatrix());
    
    // add translations to the transformation matrix
    transform[12] = camera->m_position[0];
    transform[13] = camera->m_position[1];
    transform[14] = camera->m_position[2];

    glMultMatrixf(transform.getMatrix());

    glPushMatrix();
        Matrix4 objtransform(player->m_orientation.toMatrix());
        objtransform[12... set positions etc

        glMultMatrixf(objtransform.toMatrix());

        // draw stuff

    glPopMatrix();

// rest of stuff
}
The camera never seems to be able to get itself to the right position, and I am assuming this is because player is still being translated to its position after the mvmatrix is set to the camera's position, ending in horrible results of global rotations and vomit on the window.

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

Adbot
ADBOT LOVES YOU

Murodese
Mar 6, 2007

Think you've got what it takes?
We're looking for fine Men & Women to help Protect the Australian Way of Life.

Become part of the Legend. Defence Jobs.

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.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply