XToMDL Problems? x64 Solution!

#1
In response to this, I developed a 64 bit build of XToMDL. You will find it attached:

Be sure to check the readme for all pertinent information!

Please make sure you have the Visual C++ 2010 runtime installed! Download here:
x86
x64

Please leave me feedback, bug reports, etc! :)

Note - P3D has fixed these limitations in their more recent SDK builds. However, P3D v2 broke backwards compatibility with the existing mdl format, so I have re-attached the tool here for anybody still developing for FSX. - theisomizer, Mar 2016
 

Attachments

Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#2
Hi Sean,

That's interesting. I assume that all the command line arguments are the same as the normal XtoMDL? In that case users of my ModelConverterX tool could point to this version as well from the tool.
 
#3
The real download

Sorry, my school's webserver seems to be having bandwidth problems, so included file as an attachment in this post. Enjoy.
 
Last edited:
#4
Hi Sean,

That's interesting. I assume that all the command line arguments are the same as the normal XtoMDL? In that case users of my ModelConverterX tool could point to this version as well from the tool.
Yes, it accepts all of the same command line arguments. That would be a great idea! However, let's test it a bit first and make sure I've got all of the kinks worked out ;)
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#5
Well it is up to the user to decide which path he enters for the compiler :). But it would probably be better to test it first indeed.
 
#6
Good job getting this to run with a larger memory model. I hope RGIS has success with this and I know I will as well if I ever get to projects of this magnitude, anxious to hear how well it will perform!
 
#7
New Release of this tool is now up!

Get it here!

I now consider this tool to be stable. Highlights for this release include a numerous minor bugfixes, a new (optional) makemdl style GUI, and an x86 version for those without access to 64 bit hardware. Be sure to check the readme for full info.

Enjoy! :D
 
#8
Hi Theisomizer,

Great job for this software, it's a pleasure to have a windows for the XToMDL ;)

Today, I try your XToMDL software a x file generat with MCX.

No problem with the x86 version but a bug with the x64.

In output windows I have this message (sorry in french):

Creating output MDL file: C:\Users\David\Desktop\DLA_Jodel_DR-1050_V_0_0_3.MDL
XToMdl.exe Unhandled Application Exception
System.IO.FileNotFoundException: Impossible de charger le fichier ou l'assembly 'SlimDX.dll' ou une de ses dépendances. Le module spécifié est introuvable.

Nom de fichier*: 'SlimDX.dll'

à p..ctor(String A_0)

à al.b()

à al.a(ap A_0, TextBox A_1)

Impossible de charger le fichier ou l'assembly 'SlimDX.dll' ou une de ses dépendances. Le module spécifié est introuvable.

Stack Trace:
à p..ctor(String A_0)

à al.b()

à al.a(ap A_0, TextBox A_1)
XToMDL create a MDL file with 0 octet.
 
#9
Bonjour David. Je ne sais pas pourquoi il ne fonctionne pas. Désolé, mon francais est terrible.

Anyways, I'm puzzled by the FileNotFound Exception. You're sure the original SlimDX.dll is in the same folder as xtomdl (this is a specific x64 slimdx.dll, so it is different than the one in the x86 folder)?

As it says it might not be able to load some of slimdx's dependencies, so perhaps this is the problem. Do you have the latest version of DirectX installed? There is a link to the installer in the readme.

Other than that I don't know. I have tried it on a couple of other computers and it works fine. This worries me, has anyone else had a similar issue to this?
 
#10
Thank you for your reply.

I have different "SlimDX.dll" with different size in the directory x64 and x86

In x86 SlimDX.dll 3 305ko and in x64 3 631 ko

Maybe the problem is Direct X 11
 
#11
Hmm, those sizes are correct, they are the right files. If you have DirectX11 then you also should have all necessary DirectX9 components.

To be safe, could you run a DxDiag and post it here? Also, are you sure you have .Net Framework 4 installed?

Really sorry this is happening, I'm quite puzzled!
 
#12
Hi,

Do you need more information ?

Code:
------------------
System Information
------------------
Time of this report: 2/3/2012, 22:22:59
       Machine name: WORKSTATION
   Operating System: Windows*7 Édition Intégrale 64-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.110622-1506)
           Language: French (Regional Setting: French)
System Manufacturer: System manufacturer
       System Model: System Product Name
               BIOS: BIOS Date: 01/28/10 13:41:45 Ver: 08.00.15
          Processor: Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz (8 CPUs), ~2.7GHz
             Memory: 6144MB RAM
Available OS Memory: 6136MB RAM
          Page File: 3839MB used, 8428MB available
        Windows Dir: C:\Windows
    DirectX Version: DirectX 11
DX Setup Parameters: Not found
   User DPI Setting: Using System DPI
 System DPI Setting: 96 DPI (100 percent)
    DWM DPI Scaling: Disabled
     DxDiag Version: 6.01.7601.17514 32bit Unicode
 
#13
Not necessary, that covers it. You have almost exactly the same machine as me, I don't see any reason there why it wouldn't work.

One thing that might have something to do with this is the updates of d3dx installed. Go to your Windows\System32 folder and note the multiple d3dx9_XX.dll files, where XX is a number. Note the highest number, if it is less than 43 please rerun the directX web installer to get the latest versions.

Later I will send you a version of my compiler with debugging symbols enabled in a PM, that way I can get a good stack trace on it.
 
#14
Ok everyone, David has helped me trace down the problem to not having the Visual C++ 2010 runtime installed. You should already have the x86 version installed if you have the sdk (in fact you probably have it anyways, lots of software requires it), but you might not have the x64 version installed. Links are now included in the original post for installers for these.

Please keep the feedback coming! :)
 

Lefteris Kalamaras

Administrator
Staff member
FSDevConf team
#15
Sean,

as a nice way to keep this thread current, would you be kind enough to consider opening the source code up for others to see?

I am particularly interested in the part where XToMDL barfs when exporting MDLs for FSX with more than 65,535 vertices for a certain material... it would be really cool if you could present some more information on what material exactly barfed and the guilty parts...

Thanks,
Lefteris
 
#16
Hi Lefteris,

Unfortunately I cannot release the code in its current state. I am in the middle of making a lot of breaking changes in the code as I am in the process of integrating it into my MDLMagic tool (see here: http://www.fsdeveloper.com/forum/showthread.php?t=151396). It is nowhere near a releasable state. The code as it existed when I released this does contain some proprietary code that I don't have the rights to release. I am in the process of refactoring all of this out.

I will gladly open up the code when MDLMagic and SimFramework (the bigger library that this code is a part of) ship. Hopefully not too much longer now, I am about to go into public beta. :)

I can tell you lots about the vertex limit though! I'm not sure how familiar you are with direct3d programming, so I'll try to give some relevant background. Direct3d uses data structures called vertex buffers and index buffers to store 3d geometry data. They are both simply linear arrays. The vertex buffer obviously contains an array of vertices, in the case of FSX it is a structure containing 3 floats for position, 3 floats a normal vector, 2 floats for UV's, etc. The index buffer is a list of offsets into the vertex buffer that define what points constitute a triangle. For example, if the index buffer is 6 elements long and contains the numbers 0, 3, 1, 1, 4, 2, then the first triangle would defined by the points VB[0], VB[3], and VB[1]. Likewise, triangle two would be defined by the points VB[1], VB[4], and VB[2], and these would be rendered in a clockwise fashion (since direct3d uses a left-handed coordinate system).

Now by default, D3D uses 16 bit shorts for each element of the index buffer. This means that theoretically the maximum element in the vertex buffer that could be indexed by the buffer would be 2^16-1: 65,535. This number limits the size of any one vertex buffer to 65,535 vertices. D3D will allow you to use 32-bit indices, but only newer, high-end cards support this (and supposedly there is some performance penalty associated with this). Since FSX was developed back in 2006 and had lots of legacy hardware to cope with, it is hard wired to only use 16 bit indices.

The mdl format supports multiple vertex buffers, so multiple parts can go into multiple buffers and thus there is not an overall vertex limit for the file. There are several cases that can cause a vertex buffer limit to be exceeded, though. The most obvious is having a single part that has greater than 65k vertices. XToMDL could just simply split this into several different vertex buffers, but as stated here this was a feature that just simply didn't make it in. As part of the effort to reduce draw calls, parts with certain parameters that are the same are automatically merged together so they can be draw call batched together. The precise algorithm that determines this is given in this function: (sorry, a bit messy)

Code:
internal void MergeParts()
{
    foreach (SceneGraphNode node in this.Children)
    {
        node.MergeParts();
    }
    for (int i = 0; i < (this.Parts.Count - 1); i++)
    {
        PartMesh mesh = this.Parts[i] as PartMesh;
        for (int j = this.Parts.Count - 1; j > i; j--)
        {
            PartMesh other = this.m_Parts[j] as PartMesh;
            if ((((mesh.Type == other.Type) && (mesh.MouseRectID == other.MouseRectID)) && ((mesh.VisibilityID == other.VisibilityID) && !mesh.HasSkinning)) && 
                ((!other.HasSkinning && mesh.IsVisible) && ((mesh.AssociatedMaterial.CompareTo(other.AssociatedMaterial) == 0) && (mesh.LOD == other.LOD))))
            {
                mesh.AbsorbPart(other);
                this.Parts.RemoveAt(j);
            }
        }
    }
}
This can cause parts to arbitrarily be merged that combined have a larger verts than can fit into a single vertex buffer, causing an error.

I hope that answers your question. There are several other quirks relating to vertices that are somewhat unrelated to this problem. I think I will give them a more in-depth treatment in a blog post in a few days, using this post as a starting point.

Let me know if you guys have any other xtomdl questions!
 
#17
Hi Lefteris,

Unfortunately I cannot release the code in its current state. I am in the middle of making a lot of breaking changes in the code as I am in the process of integrating it into my MDLMagic tool (see here: http://www.fsdeveloper.com/forum/showthread.php?t=151396). It is nowhere near a releasable state. The code as it existed when I released this does contain some proprietary code that I don't have the rights to release. I am in the process of refactoring all of this out.

I will gladly open up the code when MDLMagic and SimFramework (the bigger library that this code is a part of) ship. Hopefully not too much longer now, I am about to go into public beta. :)

I can tell you lots about the vertex limit though! I'm not sure how familiar you are with direct3d programming, so I'll try to give some relevant background. Direct3d uses data structures called vertex buffers and index buffers to store 3d geometry data. They are both simply linear arrays. The vertex buffer obviously contains an array of vertices, in the case of FSX it is a structure containing 3 floats for position, 3 floats a normal vector, 2 floats for UV's, etc. The index buffer is a list of offsets into the vertex buffer that define what points constitute a triangle. For example, if the index buffer is 6 elements long and contains the numbers 0, 3, 1, 1, 4, 2, then the first triangle would defined by the points VB[0], VB[3], and VB[1]. Likewise, triangle two would be defined by the points VB[1], VB[4], and VB[2], and these would be rendered in a clockwise fashion (since direct3d uses a left-handed coordinate system).

Now by default, D3D uses 16 bit shorts for each element of the index buffer. This means that theoretically the maximum element in the vertex buffer that could be indexed by the buffer would be 2^16-1: 65,535. This number limits the size of any one vertex buffer to 65,535 vertices. D3D will allow you to use 32-bit indices, but only newer, high-end cards support this (and supposedly there is some performance penalty associated with this). Since FSX was developed back in 2006 and had lots of legacy hardware to cope with, it is hard wired to only use 16 bit indices.

The mdl format supports multiple vertex buffers, so multiple parts can go into multiple buffers and thus there is not an overall vertex limit for the file. There are several cases that can cause a vertex buffer limit to be exceeded, though. The most obvious is having a single part that has greater than 65k vertices. XToMDL could just simply split this into several different vertex buffers, but as stated here this was a feature that just simply didn't make it in. As part of the effort to reduce draw calls, parts with certain parameters that are the same are automatically merged together so they can be draw call batched together. The precise algorithm that determines this is given in this function: (sorry, a bit messy)

Code:
internal void MergeParts()
{
    foreach (SceneGraphNode node in this.Children)
    {
        node.MergeParts();
    }
    for (int i = 0; i < (this.Parts.Count - 1); i++)
    {
        PartMesh mesh = this.Parts[i] as PartMesh;
        for (int j = this.Parts.Count - 1; j > i; j--)
        {
            PartMesh other = this.m_Parts[j] as PartMesh;
            if ((((mesh.Type == other.Type) && (mesh.MouseRectID == other.MouseRectID)) && ((mesh.VisibilityID == other.VisibilityID) && !mesh.HasSkinning)) && 
                ((!other.HasSkinning && mesh.IsVisible) && ((mesh.AssociatedMaterial.CompareTo(other.AssociatedMaterial) == 0) && (mesh.LOD == other.LOD))))
            {
                mesh.AbsorbPart(other);
                this.Parts.RemoveAt(j);
            }
        }
    }
}
This can cause parts to arbitrarily be merged that combined have a larger verts than can fit into a single vertex buffer, causing an error.

I hope that answers your question. There are several other quirks relating to vertices that are somewhat unrelated to this problem. I think I will give them a more in-depth treatment in a blog post in a few days, using this post as a starting point.

Let me know if you guys have any other xtomdl questions!
Hi Sean,
Do you think this file can solve the problem I'm having when exporting 100K+ polys from 3ds max 2012 it always crashes. I usually monitor the ram and it goes up to around 3.2Giga then max crashes. I'm using the Prepard 3d sdk. I have tried to put both slim.dx and xtomdl file in the plugin folder but with the same result.

Regards,
 
#18
Hi Sagga,

It depends on exactly where the program is crashing. If it is crashing directly inside 3ds Max on export then this won't fix anything. The plugins haven't been updated in years (only recompiled for newer versions of Max). They have stated on the Prepar3d forums that updating the export plugins is a very low priority right now.

If it is XToMdl that is crashing, this should almost certainly fix your problems.
 
#19
Hi Sagga,

It depends on exactly where the program is crashing. If it is crashing directly inside 3ds Max on export then this won't fix anything. The plugins haven't been updated in years (only recompiled for newer versions of Max). They have stated on the Prepar3d forums that updating the export plugins is a very low priority right now.

If it is XToMdl that is crashing, this should almost certainly fix your problems.
Thanks,
I think it may be due to 3ds max because it does the same thing from time to time.
 

Angelus1971

Resource contributor
#20
Got a little problem

Here the crash text

XToMdl.exe Unhandled Application Exception
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.

Parameter name: index

at System.Collections.ArrayList.get_Item(Int32 index)

at w.c()

at y.r()

at y.ah()

at g.b()

at al.b()

at al.a(ap A_0, TextBox A_1)

Index was out of range. Must be non-negative and less than the size of the collection.

Parameter name: index

Stack Trace:
at System.Collections.ArrayList.get_Item(Int32 index)

at w.c()

at y.r()

at y.ah()

at g.b()

at al.b()

at al.a(ap A_0, TextBox A_1)




Its a very hig vertex poly as well.

Thanks
 
Top