Jump to content
  • Advertisement

Ivan Terziev

Member
  • Content Count

    6
  • Joined

  • Last visited

Community Reputation

5 Neutral

1 Follower

About Ivan Terziev

  • Rank
    Newbie

Personal Information

  • Role
    Programmer
  • Interests
    Business
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ivan Terziev

    Divide and conquer broadphase

    Very good discussion and code. All broadphase algorithms are either O(n) if hash based or O(n log n) if sorting SAP or hierarchy based. Based on the use case some do better. If all objects have similar size bounds then hash based are a better choice. The dac_bp is very similar to building an AABB tree from polygon soup for static collision. If all objects move and have different sizes then this is a great choice because it doesn't maintain any data structures and cuts to the meat and its T (N) is likely to be faster than other O(n log n) algorithms. However if game logic requires you to run spatial queries then the lack of fast look up structure is a minus. Also for many use cases few objects move and those are bounded with inflated boxes so you don't have to update the structure every sim step. In practice the dynamic hierarchy is never rebuilt each frame. Imagine a world with 100,000 barrels and the player can interact only with the nearby objects. It is not very optimal do run dac_bp on all objects. For references Box2d and Bullet have different DBVHs but have a good analysis of their choices Box2d uses an AVL tree which in theory is faster for reads and slower for updates while on the other hand Bullet has a runtime incremental balancer for the tree. PhysX has a fast implementation of SAP but then it has to rebuild the tree from sorted objects for scene queries. For keeping unique collision pairs sorting and removing duplicates is good enough (better than inserting into a set) but I find open hashing implementation slightly faster (single table no memory fragmentation). Inflated aabbs do cause more narrowphase checks and ideally the narrowphase should have a fast path rejection.
  2. Ivan Terziev

    Quaternion help

    P2 - P1 will give you a direction vector but you also need an up vector or else you have infinite number of solutions. Imagine you airplane rolling around its tail to nose axis. Most libraries give you a lookat function which returns a rotation matrix which can be converted to a quaternion. In DirectX you can chain XMQuaternionRotationMatrix(XMMatrixLookAtLH(..)); If you want faster code search for better implementations.
  3. Ivan Terziev

    Use assimp for skeletal animation HELP!

    I just noticed you should also reverse the multilcation of GlobalTransformation like XMMATRIX GlobalTransformation = NodeTransformation * ParentTransform;
  4. Ivan Terziev

    Use assimp for skeletal animation HELP!

    Yeah I understand, the problem with linear transformations is that you have to get both the equations and the data right and it is really hard to debug using the standard debugger and on top of this there are the opengl and directx differences. So in my case I only transpose when I read from aiMatrix4x4. I don't transpose when I read quaternions or vectors. const aiMatrix4x4& offset = bone.mOffsetMatrix; XMMATRIX meshToBoneTransform = XMMatrixTranspose( XMMATRIX(offset.a1, offset.a2, offset.a3, offset.a4, offset.b1, offset.b2, offset.b3, offset.b4, offset.c1, offset.c2, offset.c3, offset.c4, offset.d1, offset.d2, offset.d3, offset.d4)); Do the same for (transpose) XMMATRIX(&pNode->mTransformation.a1); If you are sending FinalTransformation matrices to hlsl for skinning on the GPU you may have to transpose them depending on how you calculate your final vertex world position.
  5. Ivan Terziev

    Use assimp for skeletal animation HELP!

    Generally there are three types of transformations scaling, rotation and translation and you should be consistent with the order of multiplication. Usually it is scaling, rotation and translation, which is expressed in DX math as multiplication order S * R * T. So your NodeTransformation should be NodeTransformation = ScalingM * RotationM * TranslationM; and you should not be transposing your matrices when your read them from assimp (depending on your hlsl setting you should transpose your world, view and projection matrices). Then calculating final transformation remains p.second.FinalTransformation = p.second.BoneOffset * GlobalTransformation * m_GlobalInverse; The above equations says the final transformation of a vertex to world space is: transform the vertex to bone space, then transform the vertex to scene space (assuming assimp bone transformations are from bone space to scene space) and finally transform it to world space. It will be simpler if you test with assimp sceneTransform = identity and without scaling and then add them after the bone hierarchy looks good. I hope it works!
  6. Ivan Terziev

    Use assimp for skeletal animation HELP!

    I was able to get assimp animation to work in DirectX. I see you followed an opengl tutorial but in DX matrix multiplication order is reverse of opengl order. In DX if you want to first rotate a vertex by XMMATRIX R1 and then translate by XMMATRIX T1 you do XMVector3Transform(v, R1 * T1) Your bone FinalTransformation should be p.second.FinalTransformation = p.second.BoneOffset * GlobalTransformation * m_GlobalInverse; Also make sure you read correctly from aiMatrix4x4 row-major data structure into XMFLOAT4X4 also row-major before loading into XMMATRIX.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!