FBX pipeline progress
by Phil Carlisle · 07/07/2007 (8:14 am) · 6 comments
Oh man, this FBX SDK is cryptic at times. There are a billion ways to get whatever data it is you want and a whole slew of "mapping" and "reference" modes.
I'm slowly sifting through it, essentially recursively visiting each node in the FBX scenegraph and constructing my own much simpler scenegraph nodes. Then I'll simply write an exporter that traverses the internal scene and outputs the format information I want.
So basically a DTSTraversal will output DTS files. A DTXTraversal will output a newer format with multiple UV's etc.
Then I'll take a look at a ShaderTraversal to output shader attributes. Maybe outputting a bunch of shader defs for TGEA to parse for example.
Thankfully, the project is starting to take shape. I can parse the FBX alright now, plus my basic scenegraph is in place (although its not very well tested). Still a ways to go, in that I need to write some unit tests in there and my basic output logging is frankly making me ill :)
Next up really, is to make sure I can handle the various mapping modes in a clean way. That is, producing scene nodes with mesh, uv, texture attributes etc.
One cool thing that will come out of this I hope, is that we can have multi-pass shapes with the various blend options and even vertex colouring etc. Basically all setup from within your DCC tool of choice. So for instance in max, you'd setup a couple of materials, or a single material with a couple of texture passes (one set to blend with the other) etc.
Once the basic mesh import/export pipeline is in place. I'll look at starting some of the other functionality, for instance convex hull generation, bounding box creation etc. But those should be relatively simple in that they take an input node (a mesh node) and create an output node (hull node, bounds node) and then you simply add handling support for that node type in the scene traverser you are using to output with.
I need to also get started on documenting the internals of this. To be honest I'm not really sure WHY I'm doing this (other than I got interested in adding another UV layer to DTS shapes), but it makes me think what the ultimate purpose is. As I go beyond simply adding another UV layer for myself, I've got to think about the overall goal. I guess my own goal is to make art production as simple as it possibly can be.
Anyway, here is the screenshot. Dont get too worked up, its basically visual studio and a window showing the console output of a FBX file! :)
Enjoy!
I'm slowly sifting through it, essentially recursively visiting each node in the FBX scenegraph and constructing my own much simpler scenegraph nodes. Then I'll simply write an exporter that traverses the internal scene and outputs the format information I want.
So basically a DTSTraversal will output DTS files. A DTXTraversal will output a newer format with multiple UV's etc.
Then I'll take a look at a ShaderTraversal to output shader attributes. Maybe outputting a bunch of shader defs for TGEA to parse for example.
Thankfully, the project is starting to take shape. I can parse the FBX alright now, plus my basic scenegraph is in place (although its not very well tested). Still a ways to go, in that I need to write some unit tests in there and my basic output logging is frankly making me ill :)
Next up really, is to make sure I can handle the various mapping modes in a clean way. That is, producing scene nodes with mesh, uv, texture attributes etc.
One cool thing that will come out of this I hope, is that we can have multi-pass shapes with the various blend options and even vertex colouring etc. Basically all setup from within your DCC tool of choice. So for instance in max, you'd setup a couple of materials, or a single material with a couple of texture passes (one set to blend with the other) etc.
Once the basic mesh import/export pipeline is in place. I'll look at starting some of the other functionality, for instance convex hull generation, bounding box creation etc. But those should be relatively simple in that they take an input node (a mesh node) and create an output node (hull node, bounds node) and then you simply add handling support for that node type in the scene traverser you are using to output with.
I need to also get started on documenting the internals of this. To be honest I'm not really sure WHY I'm doing this (other than I got interested in adding another UV layer to DTS shapes), but it makes me think what the ultimate purpose is. As I go beyond simply adding another UV layer for myself, I've got to think about the overall goal. I guess my own goal is to make art production as simple as it possibly can be.
Anyway, here is the screenshot. Dont get too worked up, its basically visual studio and a window showing the console output of a FBX file! :)
Enjoy!
About the author
#2
Bobby Leighton
Imagn' Games and Media
07/07/2007 (1:12 pm)
While i read this it makes me think of a goal of mine....to re-do some of the DIF exporter stuff, not that it needs a lot of work or anything, but I wanted to know if it is possible to write UV texturing into DIF models, I'm sure i can use torque and build a paint-like program, simple though it will be, it will just be for mostly importing maps, and then possibly arranging an alpha layer or two. I'm sure i can do that, but i know little about the DIF format, will it allow me to use different forms of texture projection, or will something like this take a complete re-write? Sorry to ask a question like this in your blog, but it seemed appropriate giving the topic:)Bobby Leighton
Imagn' Games and Media
#3
07/08/2007 (6:43 am)
Do you use UnitTest++ for unit test? Because there is also a simple framework to unit test shaders! UnitTestCg is a unit test framework for Cg and HLSL programmes. What you think about procedural textures like FxGen.
#4
One thing I've been toying with is looking at alternative terrain solutions for TGE(A) in terms of texturing etc. Seems like FxGen might be useful there.
I'll have a look at UnitTest++, I was looking at another unit test lib (name escapes me), but I'll review this one too.
07/08/2007 (9:46 am)
Stephan: I had a look at that FxGen, it sounds like a nice library. But of limited use initially.One thing I've been toying with is looking at alternative terrain solutions for TGE(A) in terms of texturing etc. Seems like FxGen might be useful there.
I'll have a look at UnitTest++, I was looking at another unit test lib (name escapes me), but I'll review this one too.
#5
07/10/2007 (1:48 am)
We had trouble moving animations around with FBX, it changes the hierarchy which packages don't like. Still it is very good for mesh data
#6
It's similar in concept to FBX or Collada, but much more lightweight and extensible than either of those. (And easier to work with, in my opinion -- not so much "cryptic"). The SDK is more low-level, so you have to do a little more work, especially for animation, but in my experience you end up having to do a lot of this stuff anyways to work around FBX weirdness.
I'm looking at using GTO with Torque, I have some stuff now but it's kind of a mess. If I clean it up, I'll make a resource out of it. If anyone is interested, let me know.
Joel
07/10/2007 (6:33 pm)
Hey, since you're looking at FBX, just wanted to plug the GTO format (http://www.tweakfilms.com/main/twk3_gto.html). It comes out of the fx industry but I know it's been few games pipelines on shipping games. It's similar in concept to FBX or Collada, but much more lightweight and extensible than either of those. (And easier to work with, in my opinion -- not so much "cryptic"). The SDK is more low-level, so you have to do a little more work, especially for animation, but in my experience you end up having to do a lot of this stuff anyways to work around FBX weirdness.
I'm looking at using GTO with Torque, I have some stuff now but it's kind of a mess. If I clean it up, I'll make a resource out of it. If anyone is interested, let me know.
Joel
Torque Owner Tim Heldna