There is nothing complicated. There is no need to "extract". When the original file doesn't have a second UV, then this information doesn't get written to the FBX.

But it makes on the other hand trouble to use a "native" format that doesn't support all needed features. It is simply no good idea to use "the native engine format" in all cases and under all circumstances. There are thousands of engines out there. Can you imagine the chaos that would mean when they would all throw their native engine format onto the table? There is simply a need for a more general file format. A file format that covers most of the needs. And FBX is one of them. FBX is your "standard game oriented file format". X is another.

The best way for the developer of Engine XY is to offer special exporter for each major 3D-Application. This way you dont need in-between-formats like FBX or Callada. Sure... it is a lot of work to support several 3D-Applications.
The advantage is: Only engine-xy-required structures are exported.

Each engine has special requirements for their mesh-file-format. Thats the reason why Gamestudio's mdl, Torque's DTS and so on exist.

The new Torque-Engine (T3D) can import Collada's but these files are converted internally to DTS.

Apart from that... Conitec's way is the correct way. You have your MED to import FBX, X, 3DS and so on. Now you can tweak your model and export it to MDL7.

But: If possible i would always prefer a special (and optimized) exporter for my favorite 3D-Application.

What if I wanted/needed my model to have more than two UV
I've never seen more than two UV for games ?
I can't imagine how game making could be lot more complicated with one more UV
Well it's just an appart remark.

Unreal Engine 3 supports 3 uv-sets (for color, light map and I forgot about the third ).
It reads ASE and Collada. And it supports some special export plugins.

Currently many engines thend to support Collada (C4, Torque, Shiva, Unreal 3, Unity, S2, XNA ...). FBX is another choice. But Collada is more open, you can read it easily, like a XML file. FBX is property of Autodesk and you get "only" a SDK.

Both formats are able to store geometry, several uv-sets, cameras, animations, bones, lights and more. Colldada can even store data for physics and shader.

@AlbertoT: Yes, it can happen that FBX or Collada files work fine in one engine but do not work perfect in another. Each implementation of exporter and importer can differ.

Hey Frank, do you know how much UnrealEngine costs?

Enreal Engine in fact use lot of tricks
For example in some games (Last Remnant,Gears of War 2) :
they put some walls with a very not detailled diffuse map for color variation and they apply a detail texture for the normal map.

But integrating lot more things from a modeller to an engine by plugin (import lights, paths, effects, anything else) make more work in each plugin and more dependant the engine to the modeler !

We are repeating and repeating alwayes the same stuff

Everybody knows that FBX is supposed to be a common standard for graphic application
As Frank said , Collada would be even better from this point of view

However one thing is the theory an other the practice

FBX and COllada are around for a long time nevertheless they are still buggy

I dont care if I nust blame the file itself or the application or the converter or the engine
I know that I must cross my fingers whenever I try to upload these file into my my engine
I know that I have never had a problem with .mdl or Blitz or Milkshape

If even AUTODEX MAX \ FBX converter is not 100 % reliable than this is a serious issue

I really dont know how you insist to claim that these files ate not bloated
"Bloated" of course for game programming, not in general
Ventilator has clearly explained to you the reason why FBX is not 100 % fit for a game engine
If FBX support nurbs, just an example, while game engine work with triangulated meshhes only, ins't a case of redundancy ?

Virtual reality \ movies and Games are of course close relatives but , upt to a certain extent, they are also substantially different

In my opinion the game programming market segment need dedicated tools i.e dedicated files format and dedicated modelling \ animator packages

Yhey might be FBX \Collada and MAx\ Maya light and tweaked version

One word more about " redundancy "

I made a simple tesr

I have a MilkShape animated file , its size is : 900 kb
I converted it into FBX format

Apart from the fact that it does not work any longer in my engine but its size is 3.7 MB
The same file with the same animation is about 4 time bigger


Is it the same for you ?

Hiya.



I'm going to guess that is isn't working any more because when the program does the converting, it's expecting information to be laid out in some particular way...and Milkshape has 'simplified' this info for it's own use (in order to cut down on file size).

Here's a totally fictitious example:

Your test model might have something listed like this:


Now you try and convert it, and the FBX might be expecting to read it as this:


HOWEVER, the problem comes when FBX is expecting to see three separate lines, and doesn't get them. So it tries to make a "guess"...and ends up with something like this:


So, basically, the problem would be in combination of Milkshape's format being "compact", with locations abc being all in one line, while FBX is expecting 3 separate lines, one each for a, b and c. When the conversion happens, all the info is still there, but not in the correct location; ergo, it doesn't work and the FBX file size is much larger.

That's my basic understanding of it all. It's like asking someone to say all the numbers from 1 to 10...but not telling them which order to do it. Most people would say 1,2,3,4,5,6,7,8,9,10...but there is nothing stopping them from saying 10,9,8,7,6,5,4,3,2,1, or even 1,3,5,7,9,2,4,6,8,10.

I think the best solution is for a game engine to develop it's own import/export plugins for a few of the most popular formats, and list the version of those formats supported. This is own the C4 engine handles it. It uses the Collada format, and Eric (creator of C4) keeps it up to date from within the engine. If something changes, he mentions what particular version of Collada is needed. Conitec needs to do this. As long as whatever program you are using to export from is using the correct version, there should be very little problems (if any). It's when the company gets vague on the import/export and simply lists "Imports/Exports PIE"...ok, are we talking any pie? Like apple, cherry, blueberry? What about pumpking? How about shepphards pie? Or bannana-cream? Maybe the 'pie' the game is expecting isn't actually any type of pie...only fruit pies...so the last three times wouldn't import properly. Now all the people who spend all day making the best damn bananna-cream pie get all frustrated when they can't actually import their pie because the game eninge doesn't recognize banana-cream as an actual 'pie'.

...mmmm....banana-cream pie....

...ok, gotta run to the store now! C'ya!

A couple of GameCore videos I made:

Helicopter Test
http://www.vimeo.com/4443711

Render To Texture Test
http://www.vimeo.com/4455928