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

.x File Compilation so slow. Why?

Messages
206
Country
us-idaho
Good evening gents.
I'm to that stage in my current model where .x export is taking a good while. (Into the hours). I'm using Blender 2.78 with the latest versions of both fsx and p3d toolsets.

Currently manually doing the conversion of the .x with xtomdl, and that's not a problem.

It's the dang .x exports that are really dragging.

I'm assuming max users have the same difficulty?

Any quick and dirty methods that might help speed things up?

Decreasing triangle count in't an option. I'm well aware of the do's and don't's there and am not having any trouble with the .mdl.

Thanks!
- Joseph
 
While still in the development state, I only export/compile a carefully selected sub-set of objects. This saves a ton of time!
 
While still in the development state, I only export/compile a carefully selected sub-set of objects. This saves a ton of time!

Naturally I've been doing the same for the last couple years. It's when I'm trying to export one part to check things over, and have enough time to run to the grocery store for a gallon of milk in-between! I guess that's what's bugging me!

- Joseph
 
How big a model are we talking here, in terms of polys, animations, etc...and what hardware does your developer PC have?
 
Exporting to .X should not take any longer than 60 to 90 seconds on a modest system. Anything longer, than you should look for background process' that may be using a large amount of processor time.
 
Heretic;
Right now a model with about 70 triangles and zero animations, with one material, takes 5-7 minutes.
A full exterior model at around 280,000 triangles, and zero animations, is taking around 3 hours.

I've exported up at around 600,000 tris with animations. But forget keeping track of the time!

I have a Sandy bridge i7 Quad at stock clock of 3.4ghz, 16gb of memory, and GTX 960 4gb card. Just my medium duty modest machine.

Paul;
That's what I was thinking. If I export to any other format, it's almost instant. Even all the way up to 800,000 triangles. .3ds, .obj, .dae, standard Direct X .x files. It only hangs when specifically exporting FSX or P3D .x files.

Edit.. To note my average CPU usage when just cruising the web hovers around 1%-2%. I run a very streamlined and well maintained system. During a Blender export to .x for FSX / P3D blender jumps to about 11%-12%.

- Joseph
 
Last edited:
Whoa! That's not compiling, it's composting speed... Surely other Blender2FSX users get way faster than that?
 
Heretic;
Right now a model with about 70 triangles and zero animations, with one material, takes 5-7 minutes.
A full exterior model at around 280,000 triangles, and zero animations, is taking around 3 hours.

I've exported up at around 600,000 tris with animations. But forget keeping track of the time!

I have a Sandy bridge i7 Quad at stock clock of 3.4ghz, 16gb of memory, and GTX 960 4gb card. Just my medium duty modest machine.

Paul;
That's what I was thinking. If I export to any other format, it's almost instant. Even all the way up to 800,000 triangles. .3ds, .obj, .dae, standard Direct X .x files. It only hangs when specifically exporting FSX or P3D .x files.

Edit.. To note my average CPU usage when just cruising the web hovers around 1%-2%. I run a very streamlined and well maintained system. During a Blender export to .x for FSX / P3D blender jumps to about 11%-12%.

- Joseph

Joseph,

The numbers you get are terrible! I recognise the longer export times, but with my T.5 interior (.X file of 90 MB), it doesn't even take 5 minutes.

You can probably try to append all objects into a new Blender file, and see if it works.

Luck!

Daan
 
Joseph,

The numbers you get are terrible! I recognise the longer export times, but with my T.5 interior (.X file of 90 MB), it doesn't even take 5 minutes.

You can probably try to append all objects into a new Blender file, and see if it works.

Luck!

Daan

Thank-you Daan. I guess my suspicions are well founded then. I'm going to keep looking into it. I'm sure there's a fix. I did try doing some test with append, and even a new scene with new, similar objects. No better results.

More digging ...

- Joseph
 
Thank-you Daan. I guess my suspicions are well founded then. I'm going to keep looking into it. I'm sure there's a fix. I did try doing some test with append, and even a new scene with new, similar objects. No better results.

More digging ...

- Joseph

I'd say: check every object and, for example, check if there are oversized objects. I'll explain. I once had troubles with a file. In the end, I had an object which I duplicated and scaled so big in edit mode that I couldn't see it from my viewport (accidentally). So, for example, I had a cube of (say) 1x1 m and I accidentally duplicated the mesh and scaled it. Something like that. It screw me up then. Segmented export and I found the faulting object.
 
@fsxar177, you might have someone with Blender try compiling your mesh and see if they encounter the same problem. This would be a quick way to determine if the problem is mesh or system related.
 
Thanks for the logical answers guys. Unfortunately I've already done all of the above.

The findings we are having at the moment, are that the mathematical geometry of the object has a significant role in the fsx/p3d x.file export times. Not just the polycount. For example a 30k poly cube will export faster (Maybe as much as 400% faster) than a 30k poly hand shape. I'm thinking of running some tests on the an object with 30k. Then divide that object into 4 separate objects, and export them all at once and see if the compile times are any different.

I have the same hang-ups even if I start a fresh scene with very rudimentary geometry.

Again, only when writing .x for fsx, or .x for p3d. .x for Direct X is super snappy. Results in the same filesize. Same mesh. Looks the same in MCX. Same triangle count.

So it's directly related to .x files for the simulator. And for the life of me I have no idea why. I tried running with a simplified modeldef.xml as well. No difference.

I'm having huge breakthroughs in other areas of development. I just can't afford to let the computer take 1/2 day to compile s simple file. Let's face it, video and photo editing is more strenuous on hardware than FSX models!!

- Joseph
 
Latest tests indicate the following:

If 1 object/material is exported, let's say around 60k triangles the export to .x file is approx 5-6 minutes.

If I divide that same exact object into four objects, with four materials. And export them all at once, the export to .x file is just over 1 minute! Go figure?

Interesting... continuing tests.
- Joseph
 
Perhaps try those four objects with the one material. It seems to me you're getting near the 64K texture vertex limit.
 
Will try that as well Tom. But this problem is completely un-related to the 65k FSX xtomdl material limit. In this discussion I'm strictly de-bugging the compile of the .x file.

Unless the .x file is known to 'hang' when there's a material present with "close to" the fsx limit. That wouldn't make sense at all to me. But I've seen stranger things..

- Joseph
 
Okay, so I tried those same 4 objects with one material. Still, a quick 1 min 10 second compile. So the speed-up is directly related to breaking that 1 object into four chunks.

If I merge those all back together as one object, and change nothing else. The compile is nearly 6 minutes.
 
Since it shows only 11% CPU usage during compiles perhaps it's something about opening up the program to other processors?
 
Thanks. Could be? Not really sure what my next step would be. I was considering one possible reason. My SDK / modeldef.xml is on my sim drive. But I operate Blender on my windows drive. Both drives are healthy. But I wonder if there's a hiccup someplace in between?
 
Back
Top