1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

XToMDL Problems? x64 Solution!

Discussion in 'Tools programming' started by theisomizer, 19 Nov 2011.

  1. theisomizer

    theisomizer

    Joined:
    15 Jan 2007
    Messages:
    175
    Country:
    us-newyork
    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?
     
  2. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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 !
     
  3. theisomizer

    theisomizer

    Joined:
    15 Jan 2007
    Messages:
    175
    Country:
    us-newyork
    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: 25 Apr 2012
  4. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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: 25 Apr 2012
  5. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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?
     
  6. hairyspin

    hairyspin Resource contributor

    Joined:
    8 May 2010
    Messages:
    2,389
    Country:
    unitedkingdom
    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.
     
  7. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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 :)
     
  8. hairyspin

    hairyspin Resource contributor

    Joined:
    8 May 2010
    Messages:
    2,389
    Country:
    unitedkingdom
    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.
     
  9. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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.
     
  10. hairyspin

    hairyspin Resource contributor

    Joined:
    8 May 2010
    Messages:
    2,389
    Country:
    unitedkingdom
    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.
     
  11. Angelus1971

    Angelus1971 Resource contributor

    Joined:
    17 Dec 2006
    Messages:
    167
    Country:
    scotland
    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 :)
     
  12. theisomizer

    theisomizer

    Joined:
    15 Jan 2007
    Messages:
    175
    Country:
    us-newyork
    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.
     

Share This Page