D
Deleted member 1281
Guest
You read the link I posted? It offers an unlimited XtoMdl exporter module, even if "only" a test version.
-
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.
Question; Max and Gmax Exporters
- Thread starter lionheart
- Start date
You read the link I posted? It offers an unlimited XtoMdl exporter module, even if "only" a test version.
n4gix
Resource contributor
- Messages
- 11,674
- Country
That is a replacement COMPILER, which is a separate critter entirely from the export .dll file.
D
Deleted member 1281
Guest
Ach, I keep forgetting that there are two component involved, both with their individual limitations. Thanks for the reminder.
Confused I still am because:
(1) the XtoMdl limitation has been cracked with Sean's custom-made XtoMdl, here:
http://www.fsdeveloper.com/forum/showpost.php?p=288370&postcount=1
... and (2) Robert (RGS) has apparently managed to successfully export his gigantic VC (750,000 triangles) to an x-file, here.
http://www.fsdeveloper.com/forum/showpost.php?p=287980&postcount=82
Edit: Just exported 120,000 polies to an x-file myself, on a seriously RAM challenged system. Takes some time and HD activity, but out comes a perfectly fine x-file.
Just a thought now, even if we cannot export immensely large numbers of polies, could we not export the model in chunks like we do for FS9 UNlimited Export and then write some program that collates the x-files creating one large xfile to be input to Sean's XtoMdl?
Confused I still am because:
(1) the XtoMdl limitation has been cracked with Sean's custom-made XtoMdl, here:
http://www.fsdeveloper.com/forum/showpost.php?p=288370&postcount=1
... and (2) Robert (RGS) has apparently managed to successfully export his gigantic VC (750,000 triangles) to an x-file, here.
http://www.fsdeveloper.com/forum/showpost.php?p=287980&postcount=82
Edit: Just exported 120,000 polies to an x-file myself, on a seriously RAM challenged system. Takes some time and HD activity, but out comes a perfectly fine x-file.
Just a thought now, even if we cannot export immensely large numbers of polies, could we not export the model in chunks like we do for FS9 UNlimited Export and then write some program that collates the x-files creating one large xfile to be input to Sean's XtoMdl?
Last edited by a moderator:
- Messages
- 10,158
- Country
Supposedly we cannot. The reason was/is that there is no way to intercept the progress points of the file now, which is why it is crashing the computers and compiler is because of the shear size of the ram during the model stages 'dumping' into the data stream, causing the 'out of memory' crash.
The reason the steps are not available is per the requirement of autodesk who said 'aces cannot use gmax unless they can make the compile system so impossible to modify'. Evidently they didnt like how we could make better models with the older FS9 compiler (for some reason).
If I were selling 3D design systems, I would;
* Try to work best with people so that I could sell the maximum amount of editions (instead of just saying no, no, no, no, no, no, nope, no way, nope, no, no, no, no...)
* Make it more affordable
* Have excellent working export tools so that people could go right in and start using it.
At $4500.00 USD, they sure dont do very much, except make it hard on us to use their product. Do they have a marketing department? If so, is it like one man, who cannot talk, stuck in a small room in the lowest floor in the basement, unable to speak to anyone????
Bill
hairyspin
Resource contributor
- Messages
- 3,253
- Country
Some confusion here:-
@lionheart: if we're talking about XtoMDL, we're talking 3ds Max.
@mjahn: RGS is using 3ds Max 2008 which uses the FSX exporter; the P3D exporter is the only option for those with 3ds Max 2009-2012 since the FSX exporter won't work with these versions of Max.
Hopefully LM will get their exporter working with bigger models and FSX/P3D modellers will have a real opportunity to use the recent versions of Max to match those fortunate enough to have Max 7, 8, 9 and 2008. Failing which, concatenating .X files may be the only route.
@lionheart: if we're talking about XtoMDL, we're talking 3ds Max.
@mjahn: RGS is using 3ds Max 2008 which uses the FSX exporter; the P3D exporter is the only option for those with 3ds Max 2009-2012 since the FSX exporter won't work with these versions of Max.
Hopefully LM will get their exporter working with bigger models and FSX/P3D modellers will have a real opportunity to use the recent versions of Max to match those fortunate enough to have Max 7, 8, 9 and 2008. Failing which, concatenating .X files may be the only route.
Last edited:
D
Deleted member 1281
Guest
Tom, I exported today's 120,000 polies from Max 2011 using the P3D exporter, and I don't think it was the limit. People here were saying the limit was 65,000. What can I say? However, re-reading the posts over at P3D it seems that the exporter is indeed buggy when it comes to "larger" models. That does seem a "limitation".
Last edited by a moderator:
n4gix
Resource contributor
- Messages
- 11,674
- Country
Not necessarily, since GMax also uses XtoMDL.exe...
It's just transparent to the user since the GMax export module passes control over to XtoMDL.exe then hangs around after the compile is finished to "delete all the intermediate files..."
- Messages
- 286
- Country
Confused? Read this.
Guys, there appears to be quite a bit of confusion in this thread. Let's clear a few things up...
A) My exporter is of no use to Bill, as he works with FS9. My version of xtomdl is just that, it is ONLY xtomdl. It is not suitable as a replacement for FS9's makemdl (? or whatever its called, I don't remember). It also doesn't replace the 3ds Max X file exporter for either version of FS. It is just the FSX MDL compiler.
B) As far as my replacement xtomdl, it is applicable to FSX/Acceleration/ESP/Prepar3d. They all use the same version of the X and MDL file formats. Anybody modelling for these simulators should use my exporter as it has improved performance and fixes a number of bugs with the supplied exporters.
C) My exporter can be used with ANY version of max or with gmax. It has nothing to do with exporting from these programs, so it is version independent. They all produce (relatively) the same .X file. The only reason there are multiple versions of the export plugins is because the plugin API changes between max releases, often rendering old plugins incompatible. The exporters for different versions of max are identical, just recompiled to support the newer max versions. It appears even the gmax one does just about the same thing, there are just minute differences (that non-programmers won't care about).
D) The problems with high-poly exports are in xtomdl, not in the max exporters. I haven't heard any case as of yet of the exporter plugins crashing for any reason on a valid model. Please correct me if I am wrong and someone has experienced an in-max exporter plugin crash. This would be a serious issue that would need separate attention.
______________________________________________________________
Long story short: if you are using FS9, I can't help you (yet). The only thing that could help is lionheart's excellent guide on overcoming the vertex limit in FS9. Very good stuff.
If you use FSX or above, use my exporter and your problems should be solved. Any differences between FSX/ESP/Prepar3d are irrelevant.
Guys, there appears to be quite a bit of confusion in this thread. Let's clear a few things up...
A) My exporter is of no use to Bill, as he works with FS9. My version of xtomdl is just that, it is ONLY xtomdl. It is not suitable as a replacement for FS9's makemdl (? or whatever its called, I don't remember). It also doesn't replace the 3ds Max X file exporter for either version of FS. It is just the FSX MDL compiler.
B) As far as my replacement xtomdl, it is applicable to FSX/Acceleration/ESP/Prepar3d. They all use the same version of the X and MDL file formats. Anybody modelling for these simulators should use my exporter as it has improved performance and fixes a number of bugs with the supplied exporters.
C) My exporter can be used with ANY version of max or with gmax. It has nothing to do with exporting from these programs, so it is version independent. They all produce (relatively) the same .X file. The only reason there are multiple versions of the export plugins is because the plugin API changes between max releases, often rendering old plugins incompatible. The exporters for different versions of max are identical, just recompiled to support the newer max versions. It appears even the gmax one does just about the same thing, there are just minute differences (that non-programmers won't care about).
D) The problems with high-poly exports are in xtomdl, not in the max exporters. I haven't heard any case as of yet of the exporter plugins crashing for any reason on a valid model. Please correct me if I am wrong and someone has experienced an in-max exporter plugin crash. This would be a serious issue that would need separate attention.
______________________________________________________________
Long story short: if you are using FS9, I can't help you (yet). The only thing that could help is lionheart's excellent guide on overcoming the vertex limit in FS9. Very good stuff.If you use FSX or above, use my exporter and your problems should be solved. Any differences between FSX/ESP/Prepar3d are irrelevant.
n4gix
Resource contributor
- Messages
- 11,674
- Country
Sean, one point with regards to GMax...
Since the call for xtomdl.exe is hard-coded in the export .dle (gmax_FSModelExp.dle), the only way your custom version could work would be if it is renamed to XtoMDL.exe (and the original renamed for backup purposes)...
As for any confusion, I think it was pretty well sorted out in the thread... but it's nice to have a concise summary.
Since the call for xtomdl.exe is hard-coded in the export .dle (gmax_FSModelExp.dle), the only way your custom version could work would be if it is renamed to XtoMDL.exe (and the original renamed for backup purposes)...
As for any confusion, I think it was pretty well sorted out in the thread... but it's nice to have a concise summary.
- Messages
- 286
- Country
* A clarification 
There are two separate problems in this thread that are being used interchangeably. First, there are the crashes experienced when running high poly models through xtomdl. This is unrelated to the vertex limit. It is caused by CLR memory allocation errors inside xtomdl. My exporter solves this by re-targeting to the x64 .Net Framework 4.0 and certain efficiency improvements with how xtomdl deals with xml internally.
I'm not too familiar with the vertex and index limit issues, but I'll make a few assumptions. The reason for the 65k limit is due to Direct3D. Graphics cards can use either 16 or 32 bit index buffers to access, or index, the vertices when rendering the polygons. FSX, being designed to deal with legacy hardware, forces the use of 16-bit index buffers. This means the maximum accessible vertex in a buffer is 2^16 or 65,536. Now when compiling the model in FS9, I believe this results in an error (unless you follow Bill's techniques). In FSX this is a compilation warning, so the model will still compile. I believe FSX will split up vertex buffers for a single part if it is over the 0xffff size. However, the more vertex buffers the worse the performance, so this should be kept to a minimum using appropriate modelling techniques. For one, please don't let the vertices for a single part go over 65k.
Please, someone correct me if I'm wrong (It has been a LONG time since I have done FS development work and I am just now getting back into the swing of things)!
Sorry, just saw this. This looks very interesting, I think this could prove extremely useful in the foundation of any sort of maxscript import/export system!
I will definitely have to take a look at this and see if I can do something with it! Obviously it will have to be extensively modified to be able to deal with FSX materials, animations, and such, but I think this could be a great start! I've been very busy with school and life over the past few weeks so I haven't been very active on here, and I have finals this week and my anniversary so give me a few days. For the next month at least I have plenty of time to continue work on my tools. I hope to have a whole integrated MDL tool suite ready sometime around mid-January or so as freeware. Or maybe dontaionware
you guys want to help feed a starving computer science student, right! Especially since my part-time day job (EMS) doesn't pay jack **** 
There are two separate problems in this thread that are being used interchangeably. First, there are the crashes experienced when running high poly models through xtomdl. This is unrelated to the vertex limit. It is caused by CLR memory allocation errors inside xtomdl. My exporter solves this by re-targeting to the x64 .Net Framework 4.0 and certain efficiency improvements with how xtomdl deals with xml internally.
I'm not too familiar with the vertex and index limit issues, but I'll make a few assumptions. The reason for the 65k limit is due to Direct3D. Graphics cards can use either 16 or 32 bit index buffers to access, or index, the vertices when rendering the polygons. FSX, being designed to deal with legacy hardware, forces the use of 16-bit index buffers. This means the maximum accessible vertex in a buffer is 2^16 or 65,536. Now when compiling the model in FS9, I believe this results in an error (unless you follow Bill's techniques). In FSX this is a compilation warning, so the model will still compile. I believe FSX will split up vertex buffers for a single part if it is over the 0xffff size. However, the more vertex buffers the worse the performance, so this should be kept to a minimum using appropriate modelling techniques. For one, please don't let the vertices for a single part go over 65k.
Please, someone correct me if I'm wrong (It has been a LONG time since I have done FS development work and I am just now getting back into the swing of things)!
Sorry, just saw this. This looks very interesting, I think this could prove extremely useful in the foundation of any sort of maxscript import/export system!
I will definitely have to take a look at this and see if I can do something with it! Obviously it will have to be extensively modified to be able to deal with FSX materials, animations, and such, but I think this could be a great start! I've been very busy with school and life over the past few weeks so I haven't been very active on here, and I have finals this week and my anniversary so give me a few days. For the next month at least I have plenty of time to continue work on my tools. I hope to have a whole integrated MDL tool suite ready sometime around mid-January or so as freeware. Or maybe dontaionware
you guys want to help feed a starving computer science student, right! Especially since my part-time day job (EMS) doesn't pay jack ****
- Messages
- 286
- Country
Sean, one point with regards to GMax...
Since the call for xtomdl.exe is hard-coded in the export .dle (gmax_FSModelExp.dle), the only way your custom version could work would be if it is renamed to XtoMDL.exe (and the original renamed for backup purposes)...
As for any confusion, I think it was pretty well sorted out in the thread... but it's nice to have a concise summary.
Ah, didn't realize this.
I don't use gmax.Now that I've (over)summarized
, hopefully we can redirect the thread to the original topic (gmax <-> max interoperability). Regardless of reasons why, it appears to be a thing many people want!
n4gix
Resource contributor
- Messages
- 11,674
- Country
Ah, didn't realize this.
Now that I've (over)summarized
The only reason I still have to use GMax is because a good many of my older models were done in GMax, and there isn't any really good way to migrate them to Max9, which is what all my new modeling is done with...
In fact, I've got a half-dozen or so mostly complete aircraft meshes, but would prefer to move 'em to Max for eventual completion.
D
Deleted member 1281
Guest
Errr ... I admit it was just a collection of large spherical objects purely for the purpose of testing. I now realize that may have been an improper procedure. But then how absurd can you get - that the exporter they bought from MS cannot do the thing it can on Max 2008?? Anyway, they are working on it, so there's hope. And once we have Flight it will all be obsolete anyway.
- Messages
- 829
- Country
I am glad he got it working, performance will always be optimal on un-textured models. I have my fingers crossed for him when he texture maps 750,000 triangles that is where the real rendering works, when texture states are changed and for a model of that size, well, we will just have to wait and see. His model is the equivalent of 7 copies of DOOM3 running at full blast on 7 different computers.
And to point out some other interesting stuff that affect fps...
Most of us just make models and export them but little do we know about what's going on deep inside the core. You can either learn from history or you can repeat it.
Hey, anything is possible and it was just proven in this thread, a big congrats to him!
And to point out some other interesting stuff that affect fps...
- DrawCalls - every time a model is drawn to the screen you have to issue a drawCall to the gpu. Unfortunately its not as simple as 1 call per model. Its more like 1 call per material within your model. So if you have a single model, but with 5 sub-meshes, that will be 5 drawCalls. Alas that is not the end of it, you also have to factor in if using per pixel lighting that you get a drawcall per light pass or if you have dynamic reflections (or similar effects) you'll be rendering the scene at least twice, potentially doubling draw calls.
Something that can help here is material batching, or rather model/mesh combining that share the same material and are spatially local.
- FillRate - this is the amount of pixels that can be drawn a frame or to 'screen per second'. This is pretty hard to pin down as you'll never reach the manufactures stated values, at least not with typical usage. The main aspect to be aware of here would be to minimise overdraw , especially with regard to transparent textures, though I guess these days with multi-pass shaders they can burn up your fillrate too.
An easy test to see if you are fillrate limited is run the game windowed at a small size, check the framerate, then increase the size, checking framerate each time. If you reach a window size and the fps drop off dramtically you've hit the fillrate limit.
Most of us just make models and export them but little do we know about what's going on deep inside the core. You can either learn from history or you can repeat it.
Hey, anything is possible and it was just proven in this thread, a big congrats to him!
Last edited: