Thanks, very interesting. I just started to read more about Blender with the idea of looking for some exporting tools later.

May I ask why you decided to go for direct MDL export? I think the preferred way is to write the X file and let XtoMDL make the MDL file. This is also easier as XtoMDL can do a lot of optimizations for you.

And I agree with Bill on the MDL import functionality. That is something we should be really careful with (especially in loading it into a modelling tool), as it would allow people to steal and modify other peoples work a lot easier.

May I ask why you decided to go for direct MDL export? I think the preferred way is to write the X file and let XtoMDL make the MDL file. This is also easier as XtoMDL can do a lot of optimizations for you.

Click to expand...

Not to mention that by doing so, one could not use MakeMDL.parts.xml file (for FS9), or the modeldef.xml file (for FSX)...

May I ask why you decided to go for direct MDL export? I think the preferred way is to write the X file and let XtoMDL make the MDL file. This is also easier as XtoMDL can do a lot of optimizations for you.

Click to expand...

Actually the exporter does save a .x file, and then invokes XToMdl on it. I was tempted to write the .MDL file directly (so removing the requirement to have the FSX SDK installed) but I haven't. So the user can hack the saved .x file and re-run XToMdl on it if they need to.

The reason that I invoke XToMdl directly rather than just leaving this step up to the user is that I suspect that most users find running command-line tools difficult, don't know how to hack the .x file, and have no wish to hack the .x file.

I cannot for the life of me imagine why any modeler would need to "import" their compiled model back into Blender

Click to expand...

If you're a modeller interested in using Blender you need some way of getting your existing models out of gamx and into Blender. You're unlikely to want to junk all your existing models and re-create them from scratch in Blender [*].

I would have written a Blender gmax importer or a gmax exporter, except for the fact that the gmax file format is undocumented and gmax appears to be deliberately crippled to discourage people from importing or exporting. So importing the .MDL file appears to be the only practical option.

I don't condone copyright infringement, but I'd point out that if people want to rip off your models they can already do so - they can use your textures and aircraft or scenery MDLs. Adding the ability to load an MDL into Blender doesn't significantly change this situation in my opinion.

*: As an aside, I learned about the importance of providing users with ways to migrate their content from existing apps from reading an account of how Jeff Raikes, who ran the Microsoft Applications team in I think the early 90s, took on WordPerfect. In short, if you want to supplant an existing product then you have to provide ways for users to get their content out of the existing product and into your product. Ideally, and perhaps non-obviously, you should also provide users with a way of getting their content out of your product and into the existing product so that they feel that they can safely try your product without getting locked in.

I intend to add support for animations. But what do you mean by "custom" animations - are there animations that you can't create using gmax and for which you have to hack the .x file?

Click to expand...

Many animations in FS9 and ALL animations in FSX are defined in XML scripts, which is then parsed by MakeMDL.exe for FS9, and XtoMDL.exe for FSX.

Complicating matters is that the XML Schema used for FS9 is very different to the XML Schema developed for FSX, so you would have to branch your script depending on which platform the user is exporting for...

...or have two different scripts at a minimum.

In addition, an FSX model requires an ProjectName.xamim file, which together with the ProjectName.x file are parsed by XtoMDL.exe to compile the finished .mdl file.

Max/GMax simply exports animation tracks; i.e., a key-frame matrix. The conditions and all other driving information comes from the XML scripts.

For example, here is an nnn.xanim for an object with a "rudder" animation file. This file would have to be generated by your Python script (or whatever handler you pass control to). It combines data from the model's animation matrix with data from the modeldef.xml file:

Requirements
Windows 2000 or later. FSX Acceleration or SP2 SDK.
Microsoft .NET Framework Version 2.0.
Blender 2.45 or later - download and run the "Installer" build of Blender.

Click to expand...

I really the FSX Acceleration or SP2 SDK needed ? Exsist there no converter for the "simple" FSX SP1 ? Or even for FS9 models to convert to a Blender file ?

As FS SP2 gives so many problems... maybe I should wait until a better way is developped or simple start from zero with Blender ? Can I install directly SP2 without SP1a and uninstall it without damage ?
Or can I export from GMAX to Blender ?
The discussion here is interesting but not always easy to understand.

Actually the exporter does save a .x file, and then invokes XToMdl on it. I was tempted to write the .MDL file directly (so removing the requirement to have the FSX SDK installed) but I haven't. So the user can hack the saved .x file and re-run XToMdl on it if they need to.

Click to expand...

That is great to hear. I agree that most users will be happy that they don't have to compile the X file manual, so that is a good feature.

If you're a modeller interested in using Blender you need some way of getting your existing models out of gamx and into Blender. You're unlikely to want to junk all your existing models and re-create them from scratch in Blender [*].

I don't condone copyright infringement, but I'd point out that if people want to rip off your models they can already do so - they can use your textures and aircraft or scenery MDLs. Adding the ability to load an MDL into Blender doesn't significantly change this situation in my opinion.

Click to expand...

I agree that in the future we would need an upgrade path to be able to edit our own work. But personally I am not sure if importing the MDL files directly is the best way. For my ModelConverterX tool I have also worked on a MDL importer, but I have not released it (yet) for these reasons.

In my opinion the copyright trouble when somebody can actually edit my model, is a lot bigger than when they just use the texture or MDL file as is.

But this is indeed a tricky point, maybe it would be a good idea to start a separate discussion about this topic.

I have been thinking about other import option that would "prove" the user actually has the source. For FS2004 MDL files you can think of importing the ASM files (I haven't seen MDL decompilers yet). Unfortunately for FSX I did not find something that could be imported and only made if you have the sources.

Hi,
In my opinion the copyright trouble when somebody can actually edit my model, is a lot bigger than when they just use the texture or MDL file as is.
But this is indeed a tricky point, maybe it would be a good idea to start a separate discussion about this topic.

I have been thinking about other import option that would "prove" the user actually has the source. For FS2004 MDL files you can think of importing the ASM files (I haven't seen MDL decompilers yet). Unfortunately for FSX I did not find something that could be imported and only made if you have the sources.

Click to expand...

Hi Arno,
understand the copyright concerns but what about a special object that must be merged by the author e.g. in Gmax or FSDS and which will be compiled together with the object itself. This could be used in the MDL-file for the provement, that you own the source file?

I have been thinking about other import option that would "prove" the user actually has the source. For FS2004 MDL files you can think of importing the ASM files (I haven't seen MDL decompilers yet). Unfortunately for FSX I did not find something that could be imported and only made if you have the sources.

Click to expand...

The .x file would be a good choice for FSX (and FS9) - it would be easier to parse than trying to reverse-engineering .MDL files. But I don't think it's possible to get the FSX gmax gamepack to produce a .x file?

Complicating matters is that the XML Schema used for FS9 is very different to the XML Schema developed for FSX, so you would have to branch your script depending on which platform the user is exporting for

Click to expand...

I'm hoping to ignore FS9, on the assumption that most people have moved on to designing solely for FSX (?)

For example, here is an nnn.xanim for an object with a "rudder" animation file. This file would have to be generated by your Python script (or whatever handler you pass control to).

Click to expand...

That looks quite do-able - it's just a case of combining info from the modeldef file with the Pose Bone positions from Blender.

I'm unsure how to handle custom animations. I hadn't realised that the only way to make custom animations in gmax appears to be to edit modeldef.xml. I'm not sure whether to follow that approach, or to provide the user with a way to input the info for custom animations in Blender.

That looks quite do-able - it's just a case of combining info from the modeldef file with the Pose Bone positions from Blender.

I'm unsure how to handle custom animations. I hadn't realised that the only way to make custom animations in gmax appears to be to edit modeldef.xml. I'm not sure whether to follow that approach, or to provide the user with a way to input the info for custom animations in Blender.

Click to expand...

It's not just "custom animations!" It is a case of ALL ANIMATIONS are defined and driven by embedded XML code...

There's a whole lot more than simply animations that is contained in the modeldef.xml file. It also controls lighting conditions, works with custom (L:var,unit) variable types to interact with the gauge system, sets conditional code for attachpoint visibility, et cetera.

All three of the new FSX Acceleration models make use of embedded XML code in the model to drive 3d gauges in the virtual cockpit, and also provide a bi-directional interface to the C gauge portion of the panel system.

Many modelers are now incorporating 3d modeled gauges in their virtual cockpits, and my best guess is that this will continue to gain in popularity with FS11.

In short, there's a lot more in a .mdl file these days than mesh geometry and material properties...

I'm hoping to ignore FS9, on the assumption that most people have moved on to designing solely for FSX (?)

Click to expand...

Hope you don´t ignore FS9, because with the limited features of the FSX-MDL-Format we will need the FS9-objects for a longer time we planned before FSX came out.
I would and really would like to switch to blender in the near future but only with an FS9 exporter available. Otherwise I would stay with Gmax until we know what happens with FS11.

Hope you don´t ignore FS9, because with the limited features of the FSX-MDL-Format we will need the FS9-objects for a longer time we planned before FSX came out.

Click to expand...

I hadn't realised that people still needed to use the FS9 gamepacks with FSX.

I understand that the FSX MDL format doesn't allow you to make ground polygons or BGL tweaks like rotate-to-user, but I had thought that people were using the FS2002 gamepack or ASM for the former, and that the latter doesn't work so well in FSX because of problems with transparent textures. Please forgive my ignorance - what am I missing?

As you can tell, I'm reluctant to put a lot of work in to import/export the FS9 format if there's not a solid reason to keep using it.

I hadn't realised that people still needed to use the FS9 gamepacks with FSX.

I understand that the FSX MDL format doesn't allow you to make ground polygons or BGL tweaks like rotate-to-user, but I had thought that people were using the FS2002 gamepack or ASM for the former, and that the latter doesn't work so well in FSX because of problems with transparent textures. Please forgive my ignorance - what am I missing?

As you can tell, I'm reluctant to put a lot of work in to import/export the FS9 format if there's not a solid reason to keep using it.

Click to expand...

Hi Jonathan,
that is the way I see the things actually and yes it is a tricky situation at the moment and for the next time until FS11 is out. An import for FS9 is not necessary in my eyes because if I have the source file in Gmax or FSDS I could also use the FSX exporter for that case. If you want to import the object in blender, one way for importing would be enough I think. The exporter would be needed for two cases:

Hope you don´t ignore FS9, because with the limited features of the FSX-MDL-Format we will need the FS9-objects for a longer time we planned before FSX came out.
I would and really would like to switch to blender in the near future but only with an FS9 exporter available. Otherwise I would stay with Gmax until we know what happens with FS11.

Click to expand...

I got some feedback from people using my ModelConverterX tool, that the FSX X file output did also compile fine with the FS2004 MakeMDL. So for "simple" scenery objects the same X file might work in both.

The .x file would be a good choice for FSX (and FS9) - it would be easier to parse than trying to reverse-engineering .MDL files. But I don't think it's possible to get the FSX gmax gamepack to produce a .x file?

Click to expand...

Yes, the X file would be great for that, but there is no way to get that from GMax indeed. At the DevCon I heard some things about XML export, but I still have to look into that. Will let you know when I have done that.