• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0

3D Coordinate Systems confusion

4 posts in this topic

So I seem to have made somewhat of a mess with 3D coordinates and rotations between my code, D3D11 and Bullet, and want to try and get back to having a common understanding of the maths involved (not try this, ok wrong, try inveresing the yaw passed to an API, etc.).



How I logically have various parts of the game currently setup

  • +x is east
  • +y is up
  • +z is north
  • a yaw of 0 is facing north
  • yaw goes clockwise, so north, east, south, west, north (so same as compass bearings)
  • pitch, not really sure, 0 is obviously flat, from there positive seems to be down

And so with D3D11 my matrices are

XMMATRIX xmproj = XMMatrixPerspectiveFovLH(fov, aspectRatio, near, far);

XMMATRIX xmview;
xmview = XMMatrixTranslation(-x, -y, -z);
xmview *= XMMatrixRotationY(-yaw);
xmview *= XMMatrixRotationX(-pitch);

XMMATRIX xmviewProj = xmview * xmproj;

//...multiply with world matrix as needed, can also use xmproj and xmview as is for DirectX::BoundingFrustum
xmShaderTransform = XMMatrixTranspose(xmShaderTransform);
//store in constant buffer for shader output.pos = mul(input.pos, transform)

So far so good, things seem to render as expected fine, but then once looking at logic...

Vector3F Camera::getForwardVec()const
    auto c = std::cosf(-pitch);
    Vector3F facing(
        c * std::sinf(yaw),
        c * std::cosf(yaw));
    return facing;

Vector2F Player::getMovementVec(Vector2F move)const
    //move is such that +z is forward, +x is strafe right
    //only rotates on XZ plane (pitch is camera only and slopes/steps handled later)
    auto c = std::cosf(-yaw);
    auto s = std::sinf(-yaw);
    return Vector2F(moveX * c - moveZ * s, moveX * s + moveZ * c);

...drawing some object...
btTransform transform;
XMFLOAT4X4 world;
XMMATRIX xmworld = XMLoadFloat4x4(&world);
XMMATRIX xmmatrix = xmworld * xmviewProj;
xmmatrix = XMMatrixTranspose(xmmatrix);
//use xmmatrix in shader

I am really not happy with having to have the -yaw and -pitch there to make those work... I also get a similar thing with my currently simple integration with bullet, e.g. I have to pass -yaw as the rotation to ghost object for my btKinematicCharacterController, yet if I use the Bullet getOpenGLMatrix to get a world matrix and then do "world * view * proj" I seem to get correct results?


Are those to be expected, I am kind of feeling I stuffed something up somewhere, especially with how I am handling yaw? But simply saying it goes the other way I am still not sure is correct (and leaves -yaw in getForwardVec instead...), since that changes the view matrix, and on the grounds that I am "rotating the world around the camera" being my understanding there, an inverse value makes sense (rotate the entire world counterclockwise rather than the screen/camera clockwise)...



Share this post

Link to post
Share on other sites

I have already read those articles, they don't cover my issue in any way that I see....


  • Yes D3D11 as I am using it is left-handed with row-major matrices. D3D supports right-handed as well, but some parts of DirectX math I used don't, and now a fair amount of other code is based around left-handed as well, and I also understand generally the GPU itself for D3D11 uses column-major, but it seems again DirectX Math does not, requiring that XMMatrixTranspose in my code.
  • The main difference I am aware of from those articles is that the z axis is reversed. I also know that OpenGL is column major.
  • As far as Bullet goes, I understand internally it should not matter. As long as all object positions, meshes, velocities, etc. are consistant. It even has options for putting say gravity on the Z axis if the XY plane is horizontal.
  • I think the fact the OpenGL matrix it creates is right handed AND column-major has something to do with why I could use it "directly" like I showed.
  • The only semi-relevant thing I saw to rotation was "To rotate a figure counterclockwise around the origin by some angle 50d91f80cbb8feda1d10e167107ad1ff.png..." which suggests that (regardless of left or right hand?) yaw should go counterclockwise. But simply doing that does not solve all my issues, it gets rid of the -yaw being passed to Bullet sure, but then the getForwardVec maths has -yaw instead, so at least part of my maths there must be wrong still? And is thinking that it should be counterclockwise right anyway? I cant find a solid answer, at least not in a context I am positive relates to use with D3D's left-handed row-major matrices.
Edited by SyncViews

Share this post

Link to post
Share on other sites
Looks like you've got everything working fine, except for conversions between vectors and Euler angles.

Can you look at the code inside XMMatrixRotation* and compare it to your own sin/cos functions?

Btw if you store your camera/view matrices, the getForwardVec function can just extract the z-axis instead of calculating it.

Share this post

Link to post
Share on other sites

Not sure if I understood your problem well but the way I retrieve information from Bullet before I generate a world matrix for rendering is that I get an object's origin & orientation as a btVector3 & btQuaternion, convert them to XMVECTORS, then use DirectXMath to generate a rotate and a translate matrix, multiply them to get my worldmatrix.


Like so:

btVector3 objectorigin = m_physicsManager->getCollisionObjectOrigin(i);
btQuaternion objectrotation = m_physicsManager->getCollisionObjectRotation(i);
XMVECTOR SIMDobjectorigin = XMVectorSet(objectorigin.getX(),objectorigin.getY(),objectorigin.getZ(),1.0f);
XMVECTOR SIMDobjectrotation = XMVectorSet(objectrotation.getX(),objectrotation.getY(),objectrotation.getZ(),objectrotation.getW());
then in your render function:

//create a translation matrix
XMMATRIX positionMatrix = XMMatrixTranslationFromVector(position);
//create an orientation matrix
XMMATRIX orientationMatrix = XMMatrixRotationQuaternion(orientation);
//create a scaling matrix if necessary but omitted for clarity
XMMATRIX worldMatrix = scalingMatrix * orientationMatrix * positionMatrix;
result = Render(worldMatrix,viewMatrix, etc...);


I don't know if this is the best way to do it but I found this on my own and it works for me.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0