• 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.

Very high poly model - XToMdl limitations - A call for help.

  • Thread starter Thread starter RGS
  • Start date Start date
R

RGS

Messages
100
Country
unitedkingdom
Hi guys,

I'm having some serious issues with my export and before considering any drastic measures I thought I'd try asking here first.

Sorry for the long post, am really stuck here and not sure how best to proceed. I know it's a lot to get through but I'd *really* appreciate any help as right now I'm in a deep hole.

Here's the problem:

My model (VC) is around 560,000 polygons (note polygons NOT triangles). I have split it up correctly in 3dsMax 2008 so all elements are within the 65K vertex limit. I can export the x-file without issues and it comes in at around 140MB. When I try to convert the x-file to an FSX model using the 'send to' method the conversion will fail listing ' Exception of type 'System.OutOfMemoryException' was thrown' as the error.

I've been speaking to Bill (Lionheart) who has run into these issues himself and it would appear that there is no work around for this problem other than to reduce the polycount. For me to reduce my model to an export viable number I'm looking at a reduction of ~250,000 polygons or ~50%. Whilst I have about 10-15% fat that can relatively easily be trimmed off without loss of detail 50% is going to be a real killer (not to mention a ton of work).

If any one has any thoughts whatsoever for solutions to fix this I would greatly appreciate it. I'm up for trying *anything,* no matter how 'out of the box' it might be.

Here are some possible solutions that come to mind (in slight desperation):

1. Is there *any* way of attaching some of the static mesh as another model file, so for e.g. the actual VC would comprise of the all animating parts and whatever extra mesh I can add up to the poly limit + then there would be another file(s) consisting of purely static geometry (seats, floor etc) which would be referenced from the VC export as an' effect,' 'missile,' or something set to be loaded/displayed permanently. Can you allow elements of the exterior model to be viewed from the VC for e.g.? -Not that this would solve the problem, but there might be a cheeky hack in it to get another 100K polys as the exterior model is much lower than the VC.

2. Is it possible that my computer simply doesn't have enough RAM to complete the conversion? I have 4GB Corsair Dominator RAM, whilst not a lot by today's standards I doubt lack of physical memory's the issue as when I monitor the RAM usage via task manager during the process there is always a decent chunk free. I assume the problem is that XToMdl is a 32-bit application and can only access so much. Would love to hear from someone with 8-16GB. Whilst my motherboard can only take up to 8GB total I'm willing to upgrade my entire rig to get this export through.

3. I *think* someone mentioned that there is some form of FS9 export tweaker that gets over the poly limits it used to have, making it comparable with FSX's supposed no upper limit, ho hum... It looks like FS9 models are very limited compared to FSX though (no spec or bump maps?). So I doubt this'd be a good way to go. Would like to know if anyone's tried it though, is there really no upper limit now + what features would I be missing?

4. Prepar3D has new export tools for the latest versions of 3dsMax. Is it possible that LM might have a newer version of XToMdl or possibly be able to create a new one which actually truly has no upper poly limit. Clearly I don't expect to just send them an email and then out pops a nice 64-bit XToMdl, but if you join their development program *maybe* they could help? I'm assuming that models would be compatible between the two?

5. Give up on FSX (really don't want to do this) + look into what X-Plane 10 has to offer. Clearly the program is still in dev and will be properly supported unlike the abandoned FSX. If I have export issues here at least there is hope of new tools through talking with the dev team. + Once MS FLIGHT is released there will hopefully be a communication channel here also which should get things working if there's a prob exporting for that platform. Clearly FLIGHT is very much an unknown right now though.

6. Bite the bullet and just chop the polys. There is no magical solution or clever hack. Keep the high poly model for other titles, such as X-Plane 10, MS FLIGHT (hopefully...) and future releases. This options as with the previous one is pretty heart breaking really.

I *know* I should have exported and been testing the model during it's dev, rather than going for such a long time without. I exported a test model over a year ago which checking the FSX model with DrawCallMonitor comes in at ~540,000 triangles. Shortly after this export I had a totally unrelated HDD crash and didn't want to get everything set up again until I'd finished the model (which I thought unrealistically would only be a few months). I knew that FSX was meant to have no upper poly limit and I knew that current gen graphics cards could deal fine with the high poly mesh. I have around 10 years industry experience as a game artist so I knew from what I could see in Max and previous exports just how the model would look in FSX when complete (and the bits of it I can export in isolation do look just as desired). I was a little worried about performance but not overly concerned + could deal with reducing the polys somewhat if needed - a hard export limit though I clearly can't deal with! So, I'm aware I should have been exporting frequently, *normally* I would have + it was foolish of me not to.

Sorry again for the length of this post, thanks for reading if you're still here. I'm not *quite* at my wits' end yet, but getting there fast. This model has been an absolutely *insane* amount of work and the thought of losing most of it due to what is likely a 32-bit exe memory limitation is frustrating beyond words.

Thanks very much in advance for any help/suggestions,


Robert
 
Yes in FS9 you can do what's called "Unlimited Export", search for that string here if you want - cough - but the amount of backconversion needed would be prohibitive.

Why don't you try, just for the heck of it, the standard batch file invocation of XtoMdl?

Or, why not send that 140 MB x file to a friend with all the RAM in the world, and see if it can be done at all?
 
Thanks for your info regarding the FS9 export process Mjahn, I'll do a search here as you suggest. Sorry for not looking into it more thoroughly prior to my post - I guess I consider it (FS9 export) a real fallback position - If I couldn't get anything else working and someone here said "actually it's not too bad, you'll only really lose x and y" then I'd give it a shot.

I'll check the standard batch file, I assume it's covered in the SDK, I've always just used the tutorial here in setting up the tools.

Unfortunately I don't know anyone with *vast* amounts of RAM, a guy I work with has 8GB so I might give that a shot when I see him next week. Again though, I'm not too hopeful as I don't think the process is even using all of my 4GB. I could be wrong though.


Right now I'm trying all sorts of export combinations, here are my findings:


• I can export more if I remove normal maps. I haven't quite pinned down the specifics of just how much this is saving yet though. Off topic slightly: It's odd that you hit the 65K vertex limit so easily with normal maps applied (sometimes I have objects of around 12,000 polys that hit it!) .

• The maximum export I've managed in terms of triangles is around 768,000 (22.6MB model file). However this doesn't translate to me needing to reduce the mesh by 25% and then we're all good as some parts of the model seem to require a lot more than their sheer polycount suggests (even then 25% would still hurt anyway). As I've removed normal maps from *all* my materials I'm not quite sure why this is. All I can think is that these objects are probably consisting of lots of small elements with separate UV shells. In terms of file size my largest 'success' is 29MB, but that was 'only' 370,000 triangles...

• Going to try experimenting with whether or not objects are attached or separate in Max, see if that makes any difference.

• It seems right now like the best solution might be some way of referencing in part of the mesh, thus splitting the export. As this is my first aircraft I've no idea about any procedures beyond building + exporting the mesh so I'm not sure whether anything like this is even remotely possible or not.

• Could I export part the mesh as an effect, odd as it sounds surely beacons etc actually use mesh and textures, or better still a library object?

• Is it at all possible to force FSX to render multiple models at once, through a program like FSUIPC or even in the aircraft config file?

• Similar to the above point; I assume there is no way to tell the VC view to draw parts of the exterior view. Things like rotors, propellers and so on are normally exported in both the exterior model *and* replicated in the VC model rather then being simply referenced, right?


Anyway...

I'll get back to the testing, see if I can find out any more info that might lead to a more efficient export.

Please keep the thoughts coming guys, I really appreciate it + sorry if I'm duplicating some of my Qs in this reply.


Robert
 
Last edited:
Okay, first it's important to keep in mind that the 65k limit isn't limited strictly to mesh vertices...

...which should be obvious based on your acknowledgement that removing Normal maps changes the results.

Mesh Vertices + (Texture Vertices X number of bitmaps) = Total Vertices

What I suggest that you do is to selectively export only those objects that use the same FSX Material (use Select by Material), then try to compile a viable model file.

If a model is successfully generated, then you can consider that FSX Material object selection done. Hide it and check the next FSX Material.

If the model compile fails, then create a new FSX Material, alter one parameter of the FSX Material (reduce Reflection Scale by -1 for example), then apply that new FSX Material to about 1/2 of the objects in the selection.

Select both FSX Material objects and try export/compile again. It should be successful this time.

Repeat and Rinse as Required until the entire project will export/compile successfully! :D
 
Hi Bill,

Thanks for the info, but that's not the problem I'm having. I fixed all the 65K issues yesterday in exactly the way you suggested :). I only mentioned the normal map thing as I was surprised at just how low some of my meshes needed to go to avoid it (under 10K polys in some cases).

I can export the entire mesh, but I have to do it in two parts. This is not because of objects being over the vert count but due to XToMdl complaining about running out of memory. The maximum I am able to do in one go is 768,000 triangles + this goes lower depending on which meshes I'm exporting i.e. I can't just say, "right 750K triangles is my limit, I'll take it on the nose and poly chop till I hit that" as some objects are more memory intensive than others, regardless of whether they have a similar polycount (no doubt down the the reasons you mention).

If you have any thoughts on ways round this (please if you have time take a look and see what I'm suggesting above) I'd really love to hear them as otherwise it looks as though I've got some very severe poly reduction ahead of me + given the immense time and effort I've put into this model it really is the very last thing I want to have to do.

Thanks again for replying, it is very much appreciated,


Robert
 
Robert, you may wind up just having to export only the virtual cockpit, and keep the door closed.

Can you export/compile just the cockpit by itself? If so, you might able to do most of the "poly pruning" in areas that aren't normally in view of the cockpit crew... :o
 
Hey Bill,

Thanks for your reply.

The model's already set up so that you aren't meant to roam from the two pilots' positions. You can track IR all you want from here within realistic parameters, but If you were to venture back into the cabin you'd see there are no back faces on things such as the pilot's seats and so on. The textures are all set up with this in mind also, so close stuff is textured to a far greater density than stuff at the back of the cabin. Also the cockpit/cabin is an open design; there simply is no door to close. The whole thing is designed for maximum visual impact from the pilots' seats, as opposed to multiple camera angles, aisle and toilets etc ;) (just imagine the polycount then!).

It's *incredibly* frustrating as have fired up both separately working sections in FSX and they look just how I'd hoped they would + the frame rate seems fine also. But this darn memory error is stopping me from proceeding any further and potentially costing me months of work (even if the lack of exporting was my own stupid fault...).

I seem to be passing the day hitting F5 over this page (even though subscribed), re-exporting the model time and again in different configurations to see if I can make it more efficient/export a higher polycount and reading through the SDK in the hope of finding some out of the box workaround for such an issue. Thing is even if I managed an 800K+ export as I've mentioned previously it's not really a set 800K as the actual panels (switches, dials etc) are more 'expensive' than other high poly items where the UVs can be stripped better.

Can you think of *any* other way I can get another model to show up from the VC *at all?* I'm happy to try some pretty odd sounding solutions if there's even a small chance they might work!
 
Sorry for the double post, but didn't want this Q to get lost in my previous paragraph.

It seems as though I *might* be able to get somewhere using the AttachPointTool. I'm far from certain but it looks as though it *may* be possible to reference in other objects without having them included in the actual file. As I've never used the tool before however I'm not sure of it's actual functionality.

As a test I'm trying to export the floor as the primary VC model and reference in the pilot's seat as the attached item (library object).

If it can't find the LOD_100 it loads a marker point. Unfortunately this either doesn't seem to get exported or doesn't show up in FSX. *If* I name the seat Seat_LOD_100 it will load the seat mesh into the scene (with a script error), but then it just appears as mesh and is exported in the same way. I'm not sure if I actually need to save the LOD properly and/or create a FSX model of the seat also (as opposed to just the xfile), I assume it'd need one?

Anyone used this tool much? Can it reference in other objects without them needing to be contained within the model file?

Sorry for the constant stream of newbie questions guys, just I can't really move on until I crack this one way or another.
 
You cannot use the Attachpoint to load another .mdl file, if that's what you're asking.*

*Nota Bene: This statement is flat wrong... I've since revisited the FSX SDK and discovered that my memory was faulty. See page 2 of this thread for details.

I know that it's possible to use a SimConnect module to "inject" compiled .mdl files into a scene with an exterior model, but whether it's possible to do so with an interior model I haven't a clue. That is, after all, how some developers are hanging deployable bombs and rockets on their warcraft. :D

In any case, I'm not at all familiar with how to code a SimConnect module in C, so I'm of no help whatever in that regard. :o
 
Last edited:
Hi Bill,

Bummer about the AttachPointTool (that was my Q). Thought it seemed too good to be true, looked like it was setting up a ref nicely until it actually began loading in the full model...


That's very interesting info regarding the use of SimConnect. Unfortunately I'm not a coder myself, but it seems as though something like this *should* work (assuming it's VC do-able). I mean there must be a lot of more difficult stuff going on with the weapons to actually make them 'fire' and so on. All I'm looking for is a very simple 'display static mesh' option :).

I assume these weapons are visible *from* the VC when fired so the only problem might be hiding the cheeky 'weapon VC' when in the exterior mode. Of course I suppose there maybe some other issues also...

I'll make a post over on the SimConnect forum tomorrow, is there anyone specifically you'd recommend I speak to?


Export testing is progressing interestingly btw - will report more as I understand the situation better, but I can say for sure that an object's memory requirements are not always linked to either it's face count, vert count, or texture vert count.


Thanks *a lot* for the SimConnect heads up - You *might* have just saved my bacon here!

Cheers,


Robert
 
560,000 polys for a VC!?!?! Boy you must have used Mesh-Smooth or something. I would love to see this VC, you guys really put FS to the test with these ambitious creations. :cool:

You have a couple of options here...one, no need to bite the bullet...chopping some polys might be a good idea 'where needed' for example a flat area full of polygons is a waste of polygons because
a flat area will shade the same way if it had several polys or not. Every part of a mesh has a 'critical shading point' where an X amount of polys will achieve the desired results rather than an 'overload'
of polygons.

The other option? You don't have enough memory to compile a project of this magnitude ... you might want to consider having someone with a more capable system do the compiling for you, that's
called team work, 'team work makes the DREAM work'. remember that!
 
Last edited:
Hi Mr.FaosFX,

Thanks for your thoughts. Nope, no crazy mesh smoothing going on here - just a lot of detail and curved surfaces with enough polys to not appear faceted from the pilots' eye points at a screen res 2560x1600.

I've a fair bit of experience creating artwork for games, so there are no flat planes consisiting of many 'unused' polys or stupidly round spheres. Polys are only used where they're needed to add geometric detail or to give the impression of a chamfered edge on a corner (for better lighting). Don't get me wrong - I can stand to lose *some* polys - I reckon I've about 10% fat that I could lose without any real noticeable loss of detail. Going beyond that though and the visuals *will* be affected. This is a very high poly model for sure and of course you do hit the point of diminishing returns with so much detail - that said, you *can* see all the details and that's what I *hope* will really make the model something special.

Also the 750,000 triangle model that will export is still delivering good frame rates (with 4096 textures in place also, just no anims), so it would be huge disappointment for me if I can't find a solution.
 
RGS said:
Hi Mr.FaosFX,

Thanks for your thoughts. Nope, no crazy mesh smoothing going on here - just a lot of detail and curved surfaces with enough polys to not appear faceted from the pilots' eye points at a screen res 2560x1600.

I've a fair bit of experience creating artwork for games, so there are no flat planes consisiting of many 'unused' polys or stupidly round spheres. Polys are only used where they're needed to add geometric detail or to give the impression of a chamfered edge on a corner (for better lighting). Don't get me wrong - I can stand to lose *some* polys - I reckon I've about 10% fat that I could lose without any real noticeable loss of detail. Going beyond that though and the visuals *will* be affected. This is a very high poly model for sure and of course you do hit the point of diminishing returns with so much detail - that said, you *can* see all the details and that's what I *hope* will really make the model something special.

Also the 750,000 triangle model that will export is still delivering good frame rates (with 4096 textures in place also, just no anims), so it would be huge disappointment for me if I can't find a solution.
Click to expand...

Understood. :-] If the issue seems to be a memory error work on that. I remember I once got Windows to think my 32Gb flash drive was system memory BUT, it was VERY VERY slow. System memory is expensive because of its access speeds.

It is also strange that you are running out of memory, the minute windows detects its running out of memory, it starts using the hard-drive to emulate RAM, so you shouldn't be running out of memory, what you should hear is the hard-drive screaming his lungs off as Windows allocates more virtual memory.

It may be possible that the program is designed to spit out that particular message for any error it encounters. It's funny how they invest so much into the simulation but invest so LITTLE into the development kit.
 
AFAIK before FSX the SDK was done on a semi-volunteer basis, just good enough to get something out the door. Very little error checking, etc.

They did hire someone to do the *documentation* for the FSX SDK, as I remember, but AFAIK he didn't actually work on the tools - those (as usual) are mostly what MS used to create the objects. I'm sure there has always been a little effort put into making them "user friendly" for the general public, but obviously not much quality control. :)
 
Yeah, I have a feeling that it's not really running out of memory or at least as I've said previously it simply can't access any more. When I monitor it's memory usage during the conversion process my machine always still has memory free + it seems to make no difference whether I run it with Max and other progs open or close absolutely everything and try and squeeze a tiny bit more out of it.

Going to try a file that must be *just* over the limit on my 4GB rig on a 6GB laptop this eve. If an extra 2GB fails to process a file consisting of only a tiny bit more mesh than a file that works with 4GB I'll know it's not the max amount of system RAM causing a problem.

Quick question actually: I've been using the 'Send To' method for compiling for a while now but not wanting to bother setting this up on the laptop I looked over the SDK again to see how to run XToMdl 'normally.' It says open a command prompt window and type etc etc... Why would I want to do this when I can simply drag the xfile onto the XToMdl.exe located in the 3DSM7/Plugins folder with the the SDK directory?

I think I'll do it the desktop shortcut way on the laptop anyway, adding in the buildlog.txt section so I can be sure that the failure is down the 'out of system memory' error (shortcut approach described here: http://www.fsdeveloper.com/wiki/index.php?title=XtoMDL).

Have downloaded and installed the Prepar3D SDK and tried using the XToMdl.exe files from that. Not just replacing the .exe of the FSX version of course, but using the xfile with the full Prepar3D SDK tools, however no joy there either... Only thing I didn't do was re-setup the Max plugins with those of Prepar3D - reason being I'm pretty sure they'll confilct with the FSX ones which it seems are the same, barring 'FSX' references being replaced with 'Prepar3D' in some cases. FYI xfiles that do work with the FSX version of XToMdl also work with the Prepar3D one.

Think I'll post over on their forum, hopefully the devs will be able to give me some insight as to a solution. Seem to be going round in circles atm.
 
It might be possible that what you're actually bumping into is a case of insufficient Virtual Address Space. That is, the "table of addresses" that every running application has maintained for it by the OS keeping track of what is kept where in memory.

The maximum VAS available for any 32bit application is 4GB even with Win764 or Vista64.

As for the "Send To" method I described in the Wiki article, it is in no way different from either typing the commands in manually in a Command Box, or running a .bat file. In any case, a simple drag-n-drop of the .X file on XtoMDL.exe will never work properly because you'd then have no flags indicating what the program should do!
 
Last edited:
Just a small heads up, you can adjust the on-drive memory max amount.

Right click on 'My Computer' and select My Properties. Click Advanced / Performance Settings / Advanced / Virtual Memory / Change, and select a new 'amount' for your OS to max out at on the hard drive. Mine is presently at 2048 megs for some reason. I used to have it at something like 2 Gigs. I wonder what would happen with something crazy like 10 Gigs. ;)

Just be careful.
 
Yes, the 32-bit problem is def what I think is going on *if* it is indeed a memory issue. However I suspect that the amount it can access is less than 4GB (3.2-3.5 maybe?) as otherwise I would be able to squeak out a bit more by closing certain memory intensive programs whilst running the export, but it doesn't really seem to make any difference. FYI I'm running Windows 7 Ultimate 64-bit.

*If* it is a 32-bit app limitation I wonder how hard it would be to create a 64-bit version. Obviously that'd be something that only Lockheed Martin could do now (I'd imagine), hopefully I'll be able to get some concrete info on the issue from them soon.

@ N4gix:

Odd what you say about the drag and drop method not working - I'm not surprised as otherwise why say you have to type this stuff etc in the SDK and so on, but what *is* odd is that it seems to work for me... The command box opens and processes the file seemingly in the same way that it would when used with 'Send To' but instead of generating the buildlog text file the info is processed in real time in the command window. When it's complete the window closes + there I have a finished model.

I've always used the 'Send To' method (thanks for that btw!), but if not I would actually have to type 'cmd' in the 'run box' in the Start menu and then manually type the instructions every time I wanted to export?


@Lionheart:

What do you mean by 'on-drive memory max amount?' What doesn this *actually* affect?


Cheers for the help once again guys!
 
Okay, let me be more clear on the topic of drag-n-drop.

  1. For aircraft models, drag-n-drop will never work because the ModelDef.xml file will not be parsed, nor will an .XANIM file be created.
  2. For scenery models, drag-n-drop will work, but will not create an XML sample placement file. This may or may not be of importance to you.

Now, that said, the main advantage of the "SendTo" method is that you can then export the .X file anywhere you like, then compile the .mdl with a simple right-click operation, and have the .mdl file generated in the same folder where the .X file was saved.

My normal procedure is to export the .X file directly to the folder where the .mdl file will be placed to begin with, which in my case is my flightsim computer kept in another room in the home office! :)
 
Last edited:
Ah, thanks for clearing that up Bill.

What would be the easiest way to test whether I can get a slightly larger file to convert successfully on the 6GB laptop? Do I actually have to install the SDK or can I just copy over some files and do it via the desktop shortcut route?

Id' rather not go through the full installation unless I have to.

Cheers,


Robert
 
You must log in or register to reply here.
Back
Top