Monday, February 8, 2010

FBX, skinning and exploration

Finally I came up coding an importer that can give me the possibility to access data that include mesh, skeleton, animations and materials.
This is a HUGE step ahead in importing asset for the engine, and this lead me to other type of battles and thoughs.
I found FBX lacking of documentation, the only serious source code is made by a guy that created an FBX importer using DirectX10 and very kindly provided the source.
Still, I wanted to use FBX as an INTERMEDIATE format, that is translated in my own internal format, for speed purpose: I'm also using Collada as intermediate format,
but still I have problems in exporting in Max2010 (a beautiful CRASH).

Next days I hope I'll publish some pics (or maybe a video) showing the skinning.
The BIG improvement coming from the skinning integration is the focusing on the problem concerning the render of different kind of geometries...this is really fascinating, because
I know for sure I'll change all my rendering code very soon. Why that? Simply because I want to *explore* other way of rendering, I've always used direct rendering but now I want to change to other solution, and found in deferred rendering (not deferred light rendering, this with light-pre-pass was done on the previous iteration of Hydra) a new way of thinking: create a command buffer, one for each thread, and then add commands from every thread.
A final merge and the rendering, and you have deferred rendering.
I read some posts around the web, and also the emergent presentation about this, and I found really a good way of thinking the rendering as a multithreading process.

The other BIG improvement is the way of thinking "data oriented"...it is really amazing, basically it is a way of thinking based on data ACROSS objects, and not only objects...so objects became a set of properties and data, but not in a constraint way.
It is really 'holistic' way of thinking about the code, and I want to try very different way of doing the same thing.
Strange is the fact that coding is the process of transform informations, nothing more, nothing less. And we are experiencing a BIG process of letting all more complicated.
Multithreading is taking to the road of seeing programming with a different level of detail, no more safety and simple flow, but a more wider use of the machine and its power.

Speaking of exploration...I'm really sad about the announcement about Castlevania:Lord of Shadows. It will be another GodOfWar clone with no more exploration...

1 comment:

DEADC0DE said...

Using intermediate formats is usually extremely painful.

Exporters all work differently, on different 3d authoring applications, so the independence they promise is just a dream.

Also, you always need to add custom stuff to those formats, tags, properties etc.

Collada is the worst of the bunch. It's engineered by monkeys that never seen a real 3d engine.

XML is dog poo when it comes to managing 3d data.

And anyway, most of the problem won't be exporting/importing 3d data, but processing and optimizing it. So those formats do not really save anything.