Jump to content

  • Log In with Google      Sign In   
  • Create Account


Useful things you might want to know about FBXSDK


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 tlang1991   Members   -  Reputation: 453

Like
13Likes
Like

Posted 17 February 2014 - 05:46 PM

Useful things you might want to know about FBXSDK
 
I have wanted to make a FBX Exporter to convert FBX file to my own format for a long time.
And the entire process is not very smooth, mainly because FBX's offcial documentation is not very clear.
Plus, since FBX format is utilized by a number of applications, rather than just game engine, the sample code provided is not
using the slogans we use in game development. 
 
I have searched almost all the corners on the Internet to clarify things so that I can have a clear mapping from FBXSDK's data to what I need in a game engine.
Since I don't think anyone has ever posted a clear and thorough tutorial on how to convert FBX file to custom format, I will do it.
And I hope this could help people.
 
This tutorial would be specifically about game engine. Basically I will tell the reader how to get the data they need for their game engine.
For things like "how to initialize FBXSDK", please check the sample code yourself, the "ImportScene" sample would be very useful in this aspect.
 
 
 
1. Mesh data(position, UV, normal, tangent, binormal)
The first thing you want to do is to get the mesh data, it already feels pretty damn good if you can import your static mesh into your engine.
 
First please let me explain how FBX stores all its information about a mesh.
In FBX we have the term "Control Point", basically a control point is a physical vertex. For example, you have a cube, then you have 8 vertices. These
8 vertices are the only 8 "control points" in the FBX file. As a result, if you want, you can use "Vertex" and "Control Point" interchangeably. 
The position information is stored in the control points.
 
The following code would get you the positions of all the vertices of your mesh:
 
// inNode is the Node in this FBX Scene that contains the mesh
// this is why I can use inNode->GetMesh() on it to get the mesh
void FBXExporter::ProcessControlPoints(FbxNode* inNode)
{
	FbxMesh* currMesh = inNode->GetMesh();
	unsigned int ctrlPointCount = currMesh->GetControlPointsCount();
	for(unsigned int i = 0; i < ctrlPointCount; ++i)
	{
		CtrlPoint* currCtrlPoint = new CtrlPoint();
		XMFLOAT3 currPosition;
		currPosition.x = static_cast<float>(currMesh->GetControlPointAt(i).mData[0]);
		currPosition.y = static_cast<float>(currMesh->GetControlPointAt(i).mData[1]);
		currPosition.z = static_cast<float>(currMesh->GetControlPointAt(i).mData[2]);
		currCtrlPoint->mPosition = currPosition;
		mControlPoints[i] = currCtrlPoint;
	}
}
 
 
Then you ask "how the hell can I get the UVs, Normals, Tangents, Binormals?"
Well, please think a mesh like this for a moment:
You have this body of the mesh, but this is only the geometry, the shape of it. This body does not have any information about its surface.
In other words, you have this shape, but you don't have any information on how the surface of this shape looks.
 
FBX introduces this sense of "Layer", which covers the body of the mesh. It is like you have a box, and you wrap it with you gift paper.
This gift paper is the layer of the mesh in FBX.
And in the layer, you can acquire the information of UVs, Normals, Tangents, Binormals.
 
However, you might have already asked me. How can I relate the Control Points to the information in the layer?
Well, this is pretty tricky part and please let me show you some code and then explain it line by line.
Without loss of generality, I will use Binormal as an example:
 
void FBXExporter::ReadNormal(FbxMesh* inMesh, int inCtrlPointIndex, int inVertexCounter, XMFLOAT3& outNormal)
{
	if(inMesh->GetElementNormalCount() < 1)
	{
		throw std::exception("Invalid Normal Number");
	}

	FbxGeometryElementNormal* vertexNormal = inMesh->GetElementNormal(0);
	switch(vertexNormal->GetMappingMode())
	{
	case FbxGeometryElement::eByControlPoint:
		switch(vertexNormal->GetReferenceMode())
		{
		case FbxGeometryElement::eDirect:
		{
			outNormal.x = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inCtrlPointIndex).mData[0]);
			outNormal.y = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inCtrlPointIndex).mData[1]);
			outNormal.z = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inCtrlPointIndex).mData[2]);
		}
		break;

		case FbxGeometryElement::eIndexToDirect:
		{
			int index = vertexNormal->GetIndexArray().GetAt(inCtrlPointIndex);
			outNormal.x = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[0]);
			outNormal.y = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[1]);
			outNormal.z = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[2]);
		}
		break;

		default:
			throw std::exception("Invalid Reference");
		}
		break;

	case FbxGeometryElement::eByPolygonVertex:
		switch(vertexNormal->GetReferenceMode())
		{
		case FbxGeometryElement::eDirect:
		{
			outNormal.x = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inVertexCounter).mData[0]);
			outNormal.y = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inVertexCounter).mData[1]);
			outNormal.z = static_cast<float>(vertexNormal->GetDirectArray().GetAt(inVertexCounter).mData[2]);
		}
		break;

		case FbxGeometryElement::eIndexToDirect:
		{
			int index = vertexNormal->GetIndexArray().GetAt(inVertexCounter);
			outNormal.x = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[0]);
			outNormal.y = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[1]);
			outNormal.z = static_cast<float>(vertexNormal->GetDirectArray().GetAt(index).mData[2]);
		}
		break;

		default:
			throw std::exception("Invalid Reference");
		}
		break;
	}
}
 
Well, this is pretty damn long but please don't be scared. Actually it is very simple.
One thing to keep in mind is that outside of this function, we are using a loop to traverse all the vertices of all the triangles in this mesh.
That is why we can have parameters like "inCtrlPointIndex" and "inVertexCounter"
 
The parameters of this function:
FbxMesh* inMesh: the mesh that we are trying to export
int inCtrlPointIndex: the index of the Control Point. We need this because we want to relate our layer information with our vertices(Control Points)
int inVertexCounter: this is the index of the current vertex that we are processing. This might be confusing. Ignore this for now.
XMFLOAT3& outNormal: the output. This is trivial to explain
 
This gets us the normal information in the layer
FbxGeometryElementNormal* vertexNormal = inMesh->GetElementNormal(0);
 
The first switch statement is about MappingMode().
For a game engine, I think we only need to worry about FbxGeometryElement::eByControlPoint and FbxGeometryElement::eByPolygonVertex
Let me explain the 2 modes.
As I said, Control Points are basically the vertices. However, there is a problem. Although a cube has 8 vertices, it will have more than 8 normal if you
want your cube to look correct. The reason is if you have a sharp edge, each face of your mesh would have a different normal, which makes your vertices have 
different normals. And to deal with this, we have to assign more than one normals to the same control point(vertex).
 
As a result, FbxGeometryElement::eByControlPoint is when you don't have situations like sharp edge so each control point only has one normal.
FbxGeometryElement::eByPolygonVertex is when you have sharp edges and you need to get the normals of each vertex on each face because each face
has a different normal assigned for the same control point.
So FbxGeometryElement::eByControlPoint means we can pinpoint the normal of a control point by the index of the control point
FbxGeometryElement::eByPolygonVertex means we cna pinpoint the normal of a vertex on a face by the index of the vertex
 
 
This is why in the above code I passed in both "inCtrlPointIndex" and "inVertexCounter". Because we don't know which one we need to get the 
information we need, we better pass in both.
 
Now we have another switch statement nested inside, and we are "switching" on ReferenceMode()
This is some kind of optimization FBX is doing, same idea like index buffer in computer graphics. You don't want to have the same Vector3 many times; instead, 
you refer to it using its index.
 
FbxGeometryElement::eDirect means you can refer to our normal using the index of control point or index of face-vertex directly
FbxGeometryElement::eIndexToDirect means using the index of control point or index of face-vertex would only gives us an index pointing to the normal we want,
we have to use this index to find the actual normal.
 
This line of code gives us the index we need
int index = vertexNormal->GetIndexArray().GetAt(inVertexCounter);
 
So this is the main steps to extract position and "layer" information of a mesh. Below is how I traverse the triangles in a mesh.
 
void FBXExporter::ProcessMesh(FbxNode* inNode)
{
	FbxMesh* currMesh = inNode->GetMesh();

	mTriangleCount = currMesh->GetPolygonCount();
	int vertexCounter = 0;
	mTriangles.reserve(mTriangleCount);

	for (unsigned int i = 0; i < mTriangleCount; ++i)
	{
		XMFLOAT3 normal[3];
		XMFLOAT3 tangent[3];
		XMFLOAT3 binormal[3];
		XMFLOAT2 UV[3][2];
		Triangle currTriangle;
		mTriangles.push_back(currTriangle);

		for (unsigned int j = 0; j < 3; ++j)
		{
			int ctrlPointIndex = currMesh->GetPolygonVertex(i, j);
			CtrlPoint* currCtrlPoint = mControlPoints[ctrlPointIndex];


			ReadNormal(currMesh, ctrlPointIndex, vertexCounter, normal[j]);
			// We only have diffuse texture
			for (int k = 0; k < 1; ++k)
			{
				ReadUV(currMesh, ctrlPointIndex, currMesh->GetTextureUVIndex(i, j), k, UV[j][k]);
			}


			PNTIWVertex temp;
			temp.mPosition = currCtrlPoint->mPosition;
			temp.mNormal = normal[j];
			temp.mUV = UV[j][0];
			// Copy the blending info from each control point
			for(unsigned int i = 0; i < currCtrlPoint->mBlendingInfo.size(); ++i)
			{
				VertexBlendingInfo currBlendingInfo;
				currBlendingInfo.mBlendingIndex = currCtrlPoint->mBlendingInfo[i].mBlendingIndex;
				currBlendingInfo.mBlendingWeight = currCtrlPoint->mBlendingInfo[i].mBlendingWeight;
				temp.mVertexBlendingInfos.push_back(currBlendingInfo);
			}
			// Sort the blending info so that later we can remove
			// duplicated vertices
			temp.SortBlendingInfoByWeight();

			mVertices.push_back(temp);
			mTriangles.back().mIndices.push_back(vertexCounter);
			++vertexCounter;
		}
	}

	// Now mControlPoints has served its purpose
	// We can free its memory
	for(auto itr = mControlPoints.begin(); itr != mControlPoints.end(); ++itr)
	{
		delete itr->second;
	}
	mControlPoints.clear();
}
 
Note that there is some code related to blending info for animation. You can ignore it for now. We will come back to it later.
 
 
Now we move onto animation and this is the hard part of FBX exporting.


Sponsor:

#2 tlang1991   Members   -  Reputation: 453

Like
10Likes
Like

Posted 17 February 2014 - 06:53 PM

2. Animation
So let's think about what we need from FBX to make animation work in our renderer(game engine).
1. The skeleton hierarchy. Which joint is which joint's parent
2. For each vertex, we need 4 SkinningWeight-JointIndex pairs
3. The Bind pose matrix for each joint to calculate the inverse of global bind pose 
4. The transformation matrix at time t so that we can transform our mesh to that pose to achieve animation
 
 
1. To get the skeleton hierarchy is pretty easy: basically we perform a recursive DFS from the root node of the scene
and we go down levels. If a node is of skeleton type, we add it into our list of joints and its index will just be the size of the list
Therefore, we can guarantee that the index of the parent is always gonna be less than that of the child

void FBXExporter::ProcessSkeletonHierarchy(FbxNode* inRootNode)
{

	for (int childIndex = 0; childIndex < inRootNode->GetChildCount(); ++childIndex)
	{
		FbxNode* currNode = inRootNode->GetChild(childIndex);
		ProcessSkeletonHierarchyRecursively(currNode, 0, 0, -1);
	}
}

void FBXExporter::ProcessSkeletonHierarchyRecursively(FbxNode* inNode, int inDepth, int myIndex, int inParentIndex)
{
	if(inNode->GetNodeAttribute() && inNode->GetNodeAttribute()->GetAttributeType() && inNode->GetNodeAttribute()->GetAttributeType() == FbxNodeAttribute::eSkeleton)
	{
		Joint currJoint;
		currJoint.mParentIndex = inParentIndex;
		currJoint.mName = inNode->GetName();
		mSkeleton.mJoints.push_back(currJoint);
	}
	for (int i = 0; i < inNode->GetChildCount(); i++)
	{
		ProcessSkeletonHierarchyRecursively(inNode->GetChild(i), inDepth + 1, mSkeleton.mJoints.size(), myIndex);
	}
}
 
 
 
2,3,4 Now we need to get the SkinningWeight-JointIndex pairs of each vertex. Unfortunately, my code is not very clean on animation so 
the function below does steps 2,3,4 all at once. I will go over the code so please do not lose patience
 
Before seeing any code, please let me explain the terms used in FBXSDK. This is the part where I think most people find confusing because
FBXSDK's keywords do not match ours(game developer)
 
In FBX, there is such thing called a "Deformer". I see a deformer as a way to deform a mesh.
You know in Maya, you can have skeletal deformers but you can also have "contraints" to deform your mesh.
I think you can think of "Deformers" as the entire skeleton.
Inside each "Deformer"(I think usually a mesh only has one), you have "Clusters".
Each cluster is and is not a joint......
You can see a cluster as a joint, but actually, inside each cluster, there is a "link".
This "link" is actually the real joint, and it contains the useful information I need.
 
Now we delve into the code:

void FBXExporter::ProcessJointsAndAnimations(FbxNode* inNode)
{
	FbxMesh* currMesh = inNode->GetMesh();
	unsigned int numOfDeformers = currMesh->GetDeformerCount();
	// This geometry transform is something I cannot understand
	// I think it is from MotionBuilder
	// If you are using Maya for your models, 99% this is just an
	// identity matrix
	// But I am taking it into account anyways......
	FbxAMatrix geometryTransform = Utilities::GetGeometryTransformation(inNode);

	// A deformer is a FBX thing, which contains some clusters
	// A cluster contains a link, which is basically a joint
	// Normally, there is only one deformer in a mesh
	for (unsigned int deformerIndex = 0; deformerIndex < numOfDeformers; ++deformerIndex)
	{
		// There are many types of deformers in Maya,
		// We are using only skins, so we see if this is a skin
		FbxSkin* currSkin = reinterpret_cast<FbxSkin*>(currMesh->GetDeformer(deformerIndex, FbxDeformer::eSkin));
		if (!currSkin)
		{
			continue;
		}

		unsigned int numOfClusters = currSkin->GetClusterCount();
		for (unsigned int clusterIndex = 0; clusterIndex < numOfClusters; ++clusterIndex)
		{
			FbxCluster* currCluster = currSkin->GetCluster(clusterIndex);
			std::string currJointName = currCluster->GetLink()->GetName();
			unsigned int currJointIndex = FindJointIndexUsingName(currJointName);
			FbxAMatrix transformMatrix;						
			FbxAMatrix transformLinkMatrix;					
			FbxAMatrix globalBindposeInverseMatrix;

			currCluster->GetTransformMatrix(transformMatrix);	// The transformation of the mesh at binding time
			currCluster->GetTransformLinkMatrix(transformLinkMatrix);	// The transformation of the cluster(joint) at binding time from joint space to world space
			globalBindposeInverseMatrix = transformLinkMatrix.Inverse() * transformMatrix * geometryTransform;

			// Update the information in mSkeleton 
			mSkeleton.mJoints[currJointIndex].mGlobalBindposeInverse = globalBindposeInverseMatrix;
			mSkeleton.mJoints[currJointIndex].mNode = currCluster->GetLink();

			// Associate each joint with the control points it affects
			unsigned int numOfIndices = currCluster->GetControlPointIndicesCount();
			for (unsigned int i = 0; i < numOfIndices; ++i)
			{
				BlendingIndexWeightPair currBlendingIndexWeightPair;
				currBlendingIndexWeightPair.mBlendingIndex = currJointIndex;
				currBlendingIndexWeightPair.mBlendingWeight = currCluster->GetControlPointWeights()[i];
				mControlPoints[currCluster->GetControlPointIndices()[i]]->mBlendingInfo.push_back(currBlendingIndexWeightPair);
			}

			// Get animation information
			// Now only supports one take
			FbxAnimStack* currAnimStack = mFBXScene->GetSrcObject<FbxAnimStack>(0);
			FbxString animStackName = currAnimStack->GetName();
			mAnimationName = animStackName.Buffer();
			FbxTakeInfo* takeInfo = mFBXScene->GetTakeInfo(animStackName);
			FbxTime start = takeInfo->mLocalTimeSpan.GetStart();
			FbxTime end = takeInfo->mLocalTimeSpan.GetStop();
			mAnimationLength = end.GetFrameCount(FbxTime::eFrames24) - start.GetFrameCount(FbxTime::eFrames24) + 1;
			Keyframe** currAnim = &mSkeleton.mJoints[currJointIndex].mAnimation;

			for (FbxLongLong i = start.GetFrameCount(FbxTime::eFrames24); i <= end.GetFrameCount(FbxTime::eFrames24); ++i)
			{
				FbxTime currTime;
				currTime.SetFrame(i, FbxTime::eFrames24);
				*currAnim = new Keyframe();
				(*currAnim)->mFrameNum = i;
				FbxAMatrix currentTransformOffset = inNode->EvaluateGlobalTransform(currTime) * geometryTransform;
				(*currAnim)->mGlobalTransform = currentTransformOffset.Inverse() * currCluster->GetLink()->EvaluateGlobalTransform(currTime);
				currAnim = &((*currAnim)->mNext);
			}
		}
	}

	// Some of the control points only have less than 4 joints
	// affecting them.
	// For a normal renderer, there are usually 4 joints
	// I am adding more dummy joints if there isn't enough
	BlendingIndexWeightPair currBlendingIndexWeightPair;
	currBlendingIndexWeightPair.mBlendingIndex = 0;
	currBlendingIndexWeightPair.mBlendingWeight = 0;
	for(auto itr = mControlPoints.begin(); itr != mControlPoints.end(); ++itr)
	{
		for(unsigned int i = itr->second->mBlendingInfo.size(); i <= 4; ++i)
		{
			itr->second->mBlendingInfo.push_back(currBlendingIndexWeightPair);
		}
	}
}
 
 
 
At the beginning I have this:
 
// This geometry transform is something I cannot understand
// I think it is from MotionBuilder
// If you are using Maya for your models, 99% this is just an
// identity matrix
// But I am taking it into account anyways......
FbxAMatrix geometryTransform = Utilities::GetGeometryTransformation(inNode);
 
Well, this is what I saw on the FBX SDK Forum. The officials there told us we should take into account 
the "GeometricTransform". But according to my experience, most of the times, this "GeometricTransform"
is just an identity matrix. Anyways, to get this "GeometricTransform", use this function:
 

FbxAMatrix Utilities::GetGeometryTransformation(FbxNode* inNode)
{
	if (!inNode)
	{
		throw std::exception("Null for mesh geometry");
	}

	const FbxVector4 lT = inNode->GetGeometricTranslation(FbxNode::eSourcePivot);
	const FbxVector4 lR = inNode->GetGeometricRotation(FbxNode::eSourcePivot);
	const FbxVector4 lS = inNode->GetGeometricScaling(FbxNode::eSourcePivot);

	return FbxAMatrix(lT, lR, lS);
}
 
The very most most most most most most most most important thing in this code is how I get the 
inverse of global bind pose of each joint. This part is very tricky and screwed up many people.
I will explain this in details.
 
FbxAMatrix transformMatrix;
FbxAMatrix transformLinkMatrix;
FbxAMatrix globalBindposeInverseMatrix;
 
currCluster->GetTransformMatrix(transformMatrix); // The transformation of the mesh at binding time
currCluster->GetTransformLinkMatrix(transformLinkMatrix); // The transformation of the cluster(joint) at binding time from joint space to world space
globalBindposeInverseMatrix = transformLinkMatrix.Inverse() * transformMatrix * geometryTransform;
 
// Update the information in mSkeleton 
mSkeleton.mJoints[currJointIndex].mGlobalBindposeInverse = globalBindposeInverseMatrix;
 
 
 
So let's start from this GetTransformMatrix
The TransformMatrix is actually a legacy thing. It is the Global Transform of the entire mesh at binding time and all the clusters have exactly the same
TransformMatrix. This matrix would not be needed if your artists have good habits and before they rig the model, they "Freeze Transformations" on all channels
of the model. If your artists do "Freeze Transformations", then this matrix would just be an identity matrix.
 
Now we go on to GetTransformLinkMatrix. This is the very essence of the animation exporting code. This is the transformation of the cluster(joint) at binding time
from joint space to world space in Maya.
 
So now we are all set and we can get our inverse of global bind pose of each joint.
What we want eventually is the InverseOfGlobalBindPoseMatrix in "VertexAtTimeT =  TransformationOfPostAtTimeT * InverseOfGlobalBindPoseMatrix * VertexAtBindingTime"
 
To get this, we do this: transformLinkMatrix.Inverse() * transformMatrix * geometryTransform
 
 
Now we are 2 steps away from animation. We need to get the SkinningWeight-JointIndex pair for each vertex and we still need to get the transformations
at different times in the animation
 
Let's deal with SkinningWeight-JointIndex pair first.
 
In our game engine, we have this relationship:
Vertex -> 4 SkinningWeight-JointIndex pairs
However, in FBXSDK the relationship is inverted.
Each cluster has a list of all the control points(vertices) it affects and how much it affects
The code below gets the relationship in the format we favor
But please recall that when I process control points, I stored all the control points into a map based on their indices.
This is where we can profit. With this map, here we can lookup and update the control point a cluster affect in O(1).
 
// Associate each joint with the control points it affects
unsigned int numOfIndices = currCluster->GetControlPointIndicesCount();
for (unsigned int i = 0; i < numOfIndices; ++i)
{
BlendingIndexWeightPair currBlendingIndexWeightPair;
currBlendingIndexWeightPair.mBlendingIndex = currJointIndex;
currBlendingIndexWeightPair.mBlendingWeight = currCluster->GetControlPointWeights()[i];
mControlPoints[currCluster->GetControlPointIndices()[i]]->mBlendingInfo.push_back(currBlendingIndexWeightPair);
}
 
 
Now we only the last piece in the puzzle: the Transformations at time T in the animation:
Note that this part is something I did not do well
My way is not very optimized since I get every keyframe
What should ideally be done is to get the keys and interpolate between them
But I guess this is a trade-off between space and speed
 
// Get animation information
// Now only supports one take
FbxAnimStack* currAnimStack = mFBXScene->GetSrcObject<FbxAnimStack>(0);
FbxString animStackName = currAnimStack->GetName();
mAnimationName = animStackName.Buffer();
FbxTakeInfo* takeInfo = mFBXScene->GetTakeInfo(animStackName);
FbxTime start = takeInfo->mLocalTimeSpan.GetStart();
FbxTime end = takeInfo->mLocalTimeSpan.GetStop();
mAnimationLength = end.GetFrameCount(FbxTime::eFrames24) - start.GetFrameCount(FbxTime::eFrames24) + 1;
Keyframe** currAnim = &mSkeleton.mJoints[currJointIndex].mAnimation;
 
for (FbxLongLong i = start.GetFrameCount(FbxTime::eFrames24); i <= end.GetFrameCount(FbxTime::eFrames24); ++i)
{
FbxTime currTime;
currTime.SetFrame(i, FbxTime::eFrames24);
*currAnim = new Keyframe();
(*currAnim)->mFrameNum = i;
FbxAMatrix currentTransformOffset = inNode->EvaluateGlobalTransform(currTime) * geometryTransform;
(*currAnim)->mGlobalTransform = currentTransformOffset.Inverse() * currCluster->GetLink()->EvaluateGlobalTransform(currTime);
currAnim = &((*currAnim)->mNext);
}
 
This part is pretty straightforward the only thing to be noted is that:
Maya currently does not support multi-take animations (Perhaps MotionBuilder does)
 
 
 
 
I will decide if I write about exporting materials based on how many people read this post
But it is pretty easy and can be learnt through "ImportScene" example
 
 
 
 
Conversions:
 
As we know, ideally Maya uses the same coordinate system as OpenGL does, which is (X-Right, Y-Up, Z-Out).
However, what if we want to use our animations in DirectX?
 
Basically
Position, Normal, Binormal, Tangent -> we need to negate the Z component of the Vector
UV -> we need to make V = 1.0f - V
Vertex order of a triangle -> change from Vertex0, Vertex1, Vertex2 to Vertex0, Vertex2, Vertex1(Basically invert the culling order)
 
Matrices:
1. Get translation component of the matrix, negate its Z component
2. Get rotation component of the matrix, negate its X and Y component
3. And we need to take the transpose


#3 Ashaman73   Crossbones+   -  Reputation: 7002

Like
1Likes
Like

Posted 18 February 2014 - 01:07 AM

This might be quite useful. You should think about posting this as an article (Menu->Articles->Post an Article).
 Good work.



#4 ddengster   Members   -  Reputation: 138

Like
0Likes
Like

Posted 09 March 2014 - 03:52 AM

Thanks, this article certainly helped me with my fbx converter.

However, I noted that you extract the vertex information into seperate vertices, without checking for duplicates and such; therefore leading to unoptimized meshes. How feasible would it be if I use the addresses to the source data as comparison for duplicate vertex information?



#5 tlang1991   Members   -  Reputation: 453

Like
0Likes
Like

Posted 23 April 2014 - 12:30 AM

Thanks, this article certainly helped me with my fbx converter.

However, I noted that you extract the vertex information into seperate vertices, without checking for duplicates and such; therefore leading to unoptimized meshes. How feasible would it be if I use the addresses to the source data as comparison for duplicate vertex information?

Hi. I actually handled the duplicate vertices. You can access my entire project(through my git repo) at this article: http://www.gamedev.net/page/resources/_/technical/graphics-programming-and-theory/how-to-work-with-fbx-sdk-r3582.

The de-dup process is straightforward but in my opinion it might not be the most efficient one. 

Please let me know if you can figure out a better method.



#6 bioglaze   Members   -  Reputation: 496

Like
0Likes
Like

Posted 25 April 2014 - 06:20 AM

Not trying to capture the thread, but how easy/feasible would it be to parse ASCII FBX manually without SDK? Does the format change often, any potential pitfalls etc.?



#7 tlang1991   Members   -  Reputation: 453

Like
1Likes
Like

Posted 25 April 2014 - 11:01 AM

Not trying to capture the thread, but how easy/feasible would it be to parse ASCII FBX manually without SDK? Does the format change often, any potential pitfalls etc.?

Well. I think ASCII FBX changed before, but don't quote me on that.

I am not sure why you would want to parse it directly instead of using the SDK.

It is definitely feasible.....but not easy.....

Plus, if you use the SDK, when Autodesk decides to change something, probably at worst you need to refactor/change some API calls, but if you parse it yourself, each time they change something, it is gonna be a huge pain.

 

Personally I do not recommend it.



#8 bioglaze   Members   -  Reputation: 496

Like
0Likes
Like

Posted 26 April 2014 - 05:40 AM

 

Not trying to capture the thread, but how easy/feasible would it be to parse ASCII FBX manually without SDK? Does the format change often, any potential pitfalls etc.?

Well. I think ASCII FBX changed before, but don't quote me on that.

I am not sure why you would want to parse it directly instead of using the SDK.

It is definitely feasible.....but not easy.....

Plus, if you use the SDK, when Autodesk decides to change something, probably at worst you need to refactor/change some API calls, but if you parse it yourself, each time they change something, it is gonna be a huge pain.

 

Personally I do not recommend it.

 

 

Ok, I think i'll go with the SDK for now. The reason I asked was because I want to keep my dependencies to the minimum in cases where doing things by myself is doable quality/time-wise.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS