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

Paul C Skertich

Members
  • Content count

    351
  • Joined

  • Last visited

Community Reputation

805 Good

About Paul C Skertich

  • Rank
    Member

Personal Information

  • Location
    Connecticut
  1. I went back to my SSAO sample for my engine after reading some others complaints getting it running. I viewed youtube video and it clearly doesn't look like mine. When you reconstruct the position from depth isn't it suppost to look like how normals in view space? Also is it the inversed perspective multiplied by the view when calculating the SSAO term on a screen quad? Or is it ortho and view inversed multipled?
  2. I'll get Bounding Sphere bounding volume to render shortly. I just wanted to render a AABB. Awesome thing is it's now fit to the actual mesh. Sometimes when the mesh gets imported - it has to be scaled down a bit leaving the min max verticies for the AABB to be the same. I'll fix that after loading time - so it's best fit bounding box. Also I added blinn-phong in the scene too. Also forget the green background - it'll be put black again.
  3. the lines aren't antialiased but perhaps i can work on thickening them out a bit. I may just resort to a quad but render a texture that looks like a selected box.
  4.   You said the file you're using (unspecified) works in the assimp viewer, so you do have a model that "works." If you're recoding OGL to DirectX 11, you're definitely going to need known data to test your code, as, at this point, it appears you may be writing code you're not sure of, and hoping it works with data you don't understand. Not a good thing.   Others may have better suggestions, but writing code without being able to test it is definitely not the way to go.   1. Use a very basic model, perhaps something with just 1 or 2 bones, with a very simple animation, perhaps just 1 or 2 frames of simple rotation. That may require working with a modeling program, such as Blender. Export it in a format that Assimp accepts, and which you can examine in text format. I.e., look at the matrices in the file and see if that's what you import.   2. google for something like "directx 11 animation example" and find code that is likely to work (rather than writing your own).   Just my opinion, but debugging code without a way to tell if the code is good or bad, with data that you don't know is good or bad ... futile.   The assimp viewer program plays back the animation perfectly - so I know it's my app that's messing it up. You're right on that. I'll be exporting the offset transformations from the assimp imported animation to txt file then comparing the two.Also will be explorting global transformation, parent transformation and offset matrices as well.   The dancing pill only has three bones I believe that just goes side to side then back to front. That's as simple as it gets actually inside 3DS Max. I'll keep you posted.
  5. I understand openGL and DirectX run things differently - so I can understand translating openGL to DX will be a challenge to some extent. I don't know how to validate if the matrixes I'm looking at are valid because I don't have a working one to validate with. I went through the debugging process but the matrices are confusing.  So from telling apart from the matrices I'm unable to understand at all what the matrices are suppose to mean - what is correct vs what is not.
  6.   Sounds like you're almost there. What global transformation do you have, and what transformation should you have? You should be able to compare the two, and, at least, determine if it's a scale problem, or orientation about the wrong axis (or axes), etc.   If you set the global to the identity matrix, how do things look? I.e., is the animation correct, but the mesh isn't oriented correctly? Is the scaling correct?   What's weird when going through the debugger - the Z Scale wasn't at 1.0 it was 0.99 or something.  I stepped through over and over again - I'm not sure if this is normal but it seems the globalTransformation is multipled each runthrough. void SkeletalMesh::readAnimationNode(float animationTime, const aiNode *pNode, XMMATRIX &ParentTransform) { std::string NodeName = pNode->mName.data; const aiAnimation* pAnimation = scene->mAnimations[0]; XMMATRIX NodeTransformation; ConvertUtil::aiMatrix4x4ToXMMatrix(&pNode->mTransformation, &NodeTransformation); const aiNodeAnim* pNodeAnim = FindNodeAnim(pAnimation, NodeName); if (pNodeAnim) { // Interpolate scaling and generate scaling transformation matrix aiVector3D Scaling; CalcInterpolatedScaling(Scaling, animationTime, pNodeAnim); XMMATRIX ScalingM; ScalingM = XMMatrixScaling(Scaling.x, Scaling.y, Scaling.z); // Interpolate rotation and generate rotation transformation matrix aiQuaternion RotationQ; CalcInterpolatedRotation(RotationQ, animationTime, pNodeAnim); XMMATRIX RotationM; ConvertUtil::aiMatrix3x3ToXMMatrix(&RotationQ.GetMatrix(), &RotationM); // Interpolate translation and generate translation transformation matrix aiVector3D Translation; CalcInterpolatedPosition(Translation, animationTime, pNodeAnim); XMMATRIX TranslationM; TranslationM = XMMatrixTranslation(Translation.x, Translation.y, Translation.z); // Combine the above transformations NodeTransformation = TranslationM * RotationM * ScalingM; } XMMATRIX GlobalTransformation = ParentTransform * NodeTransformation; //-- this is where everything gets funky. if (m_Bonemapping.find(NodeName) != m_Bonemapping.end()) { UINT BoneIndex = m_Bonemapping[NodeName]; XMMATRIX offset = m_BoneInfo[BoneIndex].boneOffset; XMMATRIX worldinv = XMLoadFloat4x4(&worldInverse); m_BoneInfo[BoneIndex].finalTransform = worldinv * GlobalTransformation * m_BoneInfo[BoneIndex].boneOffset; } for (UINT i = 0; i < pNode->mNumChildren; i++) { readAnimationNode(animationTime, pNode->mChildren[i], GlobalTransformation); } } void SkeletalMesh::EvaluateAnimation(float animationtime, std::vector<XMMATRIX> & transforms) { XMMATRIX Identity = XMMatrixIdentity(); float TicksPerSecond = (float)(scene->mAnimations[0]->mTicksPerSecond !=0.0f ? scene->mAnimations[0]->mTicksPerSecond : 25.0f); animationtime *= TicksPerSecond; float animationTick = fmod(animationtime, (float)scene->mAnimations[0]->mDuration); readAnimationNode(animationTick, scene->mRootNode, Identity); transforms.resize(numBones); for (unsigned int i = 0; i < numBones; i++) { transforms[i] = XMMatrixIdentity(); //-- maybe bad idea - original idea was to flatten then transpose it. transforms[i] = m_BoneInfo[i].finalTransform; } } If anyone was asking what was worldInv matrix inside the m_boneInfo[x].finalTransformation - it's when the model gets loaded it gets tranposed into a Float4x4.   The whole skeletal reading I got from this : http://ogldev.atspace.co.uk/www/tutorial38/tutorial38.html   I looked at some others and even the assimp_viewer when you build assimp - i can't find the header files inside VStudio project files. It was in pieces and I kept on looking over it and over it.   Maybe if I get around to it - I'll send the data to CPU than GPU and see how it does. IF it goes through the CPU without no problem then I will definately know the globaltransform is to blame.   Another thing to mention while debugging - the global transform gave me some weird floating points like 5.484884e-05 for instance in one of the rows; i'm not entirely sure what the whole e-05 bit i'm guessing it's exponent -5?  All I know is I never saw that before.  Another to mention is I'm transposed before going to shader inside render loop.   The shader code inside the vertex shader: float4 weights = input.boneWeight; float4 boneID = input.boneID; input.position.w = 1.0f; float4x4 animationmat = gBones[boneID.x] * weights.x; animationmat += gBones[boneID.y] * weights.y; animationmat += gBones[boneID.z] * weights.z; animationmat += gBones[boneID.w] * weights.w; float4 localPos = mul(input.position,mWorld); float4x4 viewProj = mul(mView, mProj); output.position = mul(float4(localPos.xyz,1.0f), viewProj); output.position = mul(output.position, animationmat); There's only three bones or four - can't remember but gBones is configured to allow 100 bones. Which the gBones get fed into by m_boneInfo[x].finalTransform.   the input element description for the bonesID and boneweights are (BoneID : DXGI_FORMAT_R32G32B32_FLOAT; BoneWeight: DXGI_FORMAT_R32G32B32_FLOAT).   I just wanted to fill out possibly all what could be raising issue.
  7. Once I get this assimp animation mesh loading - I will make a tutorial for you guys if anyone is interested!
  8. as I said I love assimp - it's a great utility but the animation is a pain. So far my animation is stretched out but plays fine in assimp viewer. I looked at assimp viewer and it's hard to follow because I can't find any header files containing some of the functions. Like one function uses a vector and a boost:tuple for storing the position keys, rotation keys, and scaling keys of the animation. Also the code animation part runs on CPU - the ATSPACE.CO.UK runs on GPU and that's where my code came from.   I narrowed it down it's due to the global transformation. the offset transform is fine, the parentnode matrix is fine the nodetransform is fine but the globaltransform martrix going into finaltransformation to be sent to gpu is messing things up.   I quickly grabbed ieDoc's MD5 Animation loader and the dancing pill works - just a pill shape mesh dancing back and forth then side to side. I don't like MD5 mesh model because I tried to make a simple vehicle and it only imported just the front chassis of the vehicle not the wheels unlike unreal engine or unity could do.   Ah the frustrations!
  9. *high five to everyone*   Pretty interesting actually - it works now. I transposed the mWorld, mView, mProj matrices. However, before I set the mWorld, mView, mProj I flatten them with XMMatrixIdentity.   Inside the shader code I did this:   input.position.w = 1.0f; float4 vertexWorldPos = mul(float4(input.position),mWorld); float4x4 bViewProj = mul(mView, mProj); output.position = mul(vertexWorldPos, bViewProj); So what I had to do was to transform the input positions to the world matrix, create a matrix for the view * proj matrices. Finally output the vertex position to the world transformed vertexes to the view projection matrix.   Now I'll be getting the animation up running possibly tonight.
  10. I forgot to mention my mesh layout for the shader as is: D3D11_INPUT_ELEMENT_DESC meshInputDescription[] = { { "POSITION", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, 0, D3D11_INPUT_PER_VERTEX_DATA, 0 }, { "TEXCOORD", 0, DXGI_FORMAT_R32G32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 }, { "NORMAL", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 }, { "TANGENT", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 }, { "BINORMAL", 0, DXGI_FORMAT_R32G32B32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0 }, { "BONES", 0, DXGI_FORMAT_R8G8B8A8_UINT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA, 0}, { "WEIGHTS", 0, DXGI_FORMAT_R32G32B32A32_FLOAT, 0, D3D11_APPEND_ALIGNED_ELEMENT, D3D11_INPUT_PER_VERTEX_DATA,0 } }; I looked at the skinning10 from the directx samples and saw the bones id were configured as a DXGI_FORMAT_R8G8B8A8_UINT. I'm using a 32 bit index buffer. the bonesID and bone weights are stored in the vertex structure as is:   struct Vertex { XMFLOAT3 position; XMFLOAT2 uvs; XMFLOAT3 normals; XMFLOAT3 tangents; XMFLOAT3 biTangents; XMFLOAT4 boneIDS; XMFLOAT4 boneWeights; }; I know before any time I ran into rendering issues - it mostly constant buffers, or how the input element lay out.
  11. yup all of them are transposed before going to shader. D3D11_MAPPED_SUBRESOURCE commonMap; CBCommonPerObject *cbCommonPerObject; canvas->getDeviceContext()->Map(commonConstantBuffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &commonMap); cbCommonPerObject = (CBCommonPerObject*)commonMap.pData; cbCommonPerObject->mWorldViewProj = XMMatrixTranspose(wvp); cbCommonPerObject->World = XMMatrixTranspose(mWorld); cbCommonPerObject->View = XMMatrixTranspose(view); cbCommonPerObject->Proj = XMMatrixTranspose(proj); canvas->getDeviceContext()->Unmap(commonConstantBuffer, 0);
  12. Why wouldn't i be able to set the worldviewproj matrix in the shader? When I do it turns out to be covering the whole screen. When I configure it inside the render loop of mesh - it looks fine.   I need to be able to translate the meshes bones being sent to the shader - I can't do that unless I am able to: float4x4 bwvp = mWorld * mView * mProj * bonematrix; output.position = mul(input.position, bwvp); the bones matrixes have their own constant buffer in array of 100. a common cb per object was created holding the World, View, Proj. I've tried: input.position.w = 1.0f; output.position = mul(input.position, mWorld); output.position = mul(output.position, mView); output.position = mul(output.position, mProj); That doesn't do anything just renders the mesh covering the whole screen. Where it should look more like this: [attachment=28736:ScreenCaptured_nossao26616756.jpg]   not like this:   [attachment=28737:ScreenCaptured_nossao52295916.jpg]   the mWorld has scale * rotation * translation from the model's world space.   Any insight what may be happening? the first image posted was from the commonperobj cbuffer's mWorldViewProj matrix.   The commonperobj cbuffer is layout is:   cbuffer cbCommonPerObj : register(b0) { float4x4 mWorldViewProj; float4x4 mWorld; float4x4 mView; float4x4 mProj; }; Anyone possibly knows why?
  13. Each mesh asset either static or skeletal has different constants, texture samplers, depth stencil states and vertex shaders, pixel shaders and the whole 9 yard.   I created a interface for Mesh which allows opening to StaticMesh, SkeletalMesh, Billboard, EditorPlacementMarker, MeshLight etc..   Maybe I'm over thinking this and I have a cat jumping on my desk annoying the hell out of me.   A billboard is different from static, skeletal mesh and a screen quad - I wouldn't use the same constant buffers over and over again in the shaders. Perhaps the mesh interface will alleviate   most of my issues.   The most common constant buffer like WorldViewProj, View, Proj can stay - for each model uses them.   In general there wouldn't be a huge constant buffer because that would be a waste of space - so I would imagine there would be at least somewhere each constant gets initialized for the particular shader for that particular mesh to be drawn on screen. Right?
  14. I'll be sure to measure performance details. Now I'm trying to get assimp animation working and apparently nothing is being rendered on screen. Has to do with the final bone transform matrix being a poopie. Once I get that working - I'll work on getting performance details out.
  15. Sadly the team that developed ASSImp haven't updated within a year. So a crude adjustment when importing FBX file would just be to rotate it manually by 90 degrees on X AXIS.   the XMMatrixRotationAxis function takes in a XMVECTOR then the radians of angle. To get the 90 degrees just perform:   (angle wanted) * 3.14 / 180 = (radians).   My case:   90.0 * 3.14 / 180.0 = 1.57   So: float degreeAngle = 90.0f * 3.14 / 180.0f; XMVECTOR axisX = XMVectorSet(1,0,0,0); XMMATRIX r = XMMatrixRotationAxis(axisX, degreeAngle); ..... world = scale * rotation * translation; it's a fix but until the team at Assimp fixes it then that's the fix is as for now. I would imagine the rotation of the bones has to be fixed - which I haven't got there yet.