• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

XToMDL Problems? x64 Solution!

Uh oh. I'll send you a debug build over PM so I can get a proper stack trace.

What were the specific settings you used?
 
theisomizer said:
Uh oh. I'll send you a debug build over PM so I can get a proper stack trace.

What were the specific settings you used?
Click to expand...

I didn't change anything. Just load the .x file into the gui
It could be the pandasoft generated .x file. I've heard it has some bugs. it doesn't seem to like textures, that i do know and it doesn't like my model as it is really complicated in bits.

If the 3ds exporter in Max 2013 hadn't changed from 2012, i wouldn't be exploring .x files !
 
Oh, okay. That is the problem. My tool can only work with files generated by the Microsoft/Lockheed exporter plugins. They use specific extensions to the .x format and have a rigid hierarchy that must be followed for the mesh to be displayed and animated properly. The pandasoft exporter only uses default .x file templates, but leaves out a lot of data that is necessary for the model to be represented properly in the FSX scene graph.

If you go over to LM's Prepar3d forums, you might be able to nag them into releasing a version of the exporter compatible with Max 2013 in the next SDK update.

Out of curiosity, what were you using the .3ds format for? I'm not aware of any method that can export a 3ds directly to a FSX .mdl.
 
Last edited:
theisomizer said:
Oh, okay. That is the problem. My tool can only work with files generated by the Microsoft/Lockheed exporter plugins. They use specific extensions to the .x format and have a rigid hierarchy that must be followed for the mesh to be displayed and animated properly. The pandasoft exporter only uses default .x file templates, but leaves out a lot of data that is necessary for the model to be represented properly in the FSX scene graph.

If you go over to LM's Prepar3d forums, you might be able to nag them into releasing a version of the exporter compatible with Max 2013 in the next SDK update.

Out of curiosity, what were you using the .3ds format for? I'm not aware of any method that can export a 3ds directly to a FSX .mdl.
Click to expand...

I need to export out of 3ds Max into gmax so that I can export to mdl, but Max 2013 has changed the 3ds format slightly so I have still to use 2012 for the moment.

The other problem with nearly every exporter is that people and companies don't have or won't develop x64 versions. Everybody I know uses x64 machines and software and have for years. We need the power!

And the guy who wrote pandasoft .x wont answer his email to get some support on most of his bugs.
 
Last edited:
HI Sean

I've downloaded your latest 2016 version as the XtoMDL from the P3D patch of th v1.4 SDK doesn't seem to be in the x64 dir. And it doesn't do what it says in the pdf.

Your 2016 update still has a problem with over 65K vertices (like the P3D version!!) - The version of XtoMDL from V2 and above manage to compile my .X file perfectly which is fine but I cannot compile for FSX - I dont know how the developers (iris software) say they can compile 403K vertice files as it just doesn't work - i'm not even sure its a 64 bit program as it wasn't in the 64 bit dir!

Any chance of an update please?
 
Angelus, are you talking about 64K vertices total for the model or more than 64K texture vertices per material. This has been discussed here many times and although the model might be 400K+ vertices in total, there is still a 64K texture vertices limit per material in P3D as well as FSX.
 
No, not vertices total. However the v2 onwards XtoMDl works perfectly, with the same .X file and there are mor than 64K texture total so its not that. I really just need a v2 onwards XtoMDL to write with the FSX header :)
 
The v1.4 XToMDL is the only FSX-compatible version and will work with an .X from v2.x or v3. The 64K texture vertices per material limit is an FSX limitation, I'm afraid.
 
Is that per material file or per material in the material editor (I'm using using MAX)???

The reason I ask is, would making another material slot, different name obviously, and using that get around the FSX limitation?

At themoment I've only texture my main rotor's, tail rotors and both hubs, nothing else has a meterial on it.
 
That's per FSX material in the Material Editor. You can get around it by making another FSX material using the same texture, but there must be a difference from the first one, like a 1% difference in specular or reflection strength. That's how Iris et al do it.
 
Thanks. Its all starting to make sense. Now if I could only get 3DS Max to behave then I wouldn't have to keep back tracking on my edits to see what I did that has crashed XtoMDL this time :)
 
Sorry, a little late to the conversation here. However, after looking back at the thread I linked in the original post, let me clarify the original intent of this solution. There was a problem with x86 builds of XToMdl that would crash as they ran out of memory in a 32 bit address space. The solution was to run a x64 build to overcome the crash so it could access more ram.

There was no intent to get around the 65k vertex limit.

IIRC, the deal is index buffers. Most DirectX progams use 16 bit index buffers, with 2^16 possible offsets into the vertex buffer array. XToMdl implements these objects as a "Part", which contains a "Material". So that is where you can trick the exporter into creating a different material that splits the part as @hairyspin mentioned. If the P3D2+ has solved the problem, either they are using 32 bit index buffers in DirectX (unlikely, perf penalty + not all hardware supports it), or they have come up with a workaround where they have a creative way to split parts. I'd have to look into the code.

Man, I really need to go back through the last decade's worth of FS code and see what I can clean up and open source.
 
You must log in or register to reply here.
Back
Top