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

FSX MDL & 65K vertex limits

N

norman99`

Messages
20
Country
hongkong
Trying to export a FSX .mdl using the P3D v1.4 SDK, and I'm running into the 65K vertex limit.

I've read a few threads where Arno says that MCX should split parts to help avoid this problem, but I guess that is not happening in my case. I've tried using the v1.3, v1.4 and dev release versions of MCX but haven't had any luck.

So, does automatic part splitting work? If so, when is it carried out, on reading of the imported file, or on writing of the X file during export? Are there any file format or version limitations that would prevent this from functioning?
 
Hi,

It works in many cases, but there are also some situations where it doesn't. I have never been able to fully reproduce that.

The optimization is done when exporting the X file when you save the MDL file.
 
Thanks for the reply. I thought that's how it worked.

Possibly related, I seem to get a lot of degenerated poly warnings on the same model. Whilst not necessarily the direct cause, I guess it could be a symptom of issues with the model itself?
 
Hi,

Those do not have to be related. But that seems to indicate that you have many tiny polygons. Normally MCX should filter these out for you on import.

How many triangles does the model part with the most triangles have? Is it close to the limit?
 
I'm not sure all of the following is relevant or helpful, but I'll run through a test that I have done to try and isolate the problem a little.

Firstly I imported the original mdl file, the object information shows the following;

Drawcalls 449
Triangles 443304
Texture Vertices 374070

The part with the most texture vertices has 16772.

I exported the model initially as an X file only, once using each P3D SDK, V1.4 thru to 4. Each resultant X file had object information similar to the above, as expected.

I then tried to export as a mdl file, again one with each SDK.

v1.4 failed due to parts exceeding the 65K limit. It seems 3 parts were over this limit. One part had 115,697 vertices, one 96,182 and the other 80,606.

v2 & v3 produced OOM errors.

v4 produced a working mdl. When opening this file and examining the object information, it had the following;

Drawcalls 420
Triangles 443302
Texture Vertices 374033

The part with the most texture vertices now had 111,813.

Both the v1.4 & v4 XtoMDL are running some optimization during the compile, reducing the number of drawcalls and therefore increasing the texture vertices count on a number of parts. This is fine with the v4 XtoMDL which can handle the higher texture vertices per drawcall, but a problem when using the v1.4 XtoMDL.

I assume this happens as it combines everything with the same material together. I have checked the material editor, and each instance of similar materials has subtle difference to ensure they are not identical, so I thought this shouldn't happen.

Is there anything I can do, such as additional material modifications or MCX settings, that will prevent the XtoMDL from combining these parts and exceeding the 65K vertex limit?
 
Hi,

On export MCX should make sure that it splits the parts into pieces with a different material as well. That way the 1.4 XtoMDL should be able to compile the object.

What's interesting is that in the original MDL file you have the most complex part with only 16772 vertices, which means you should not even hit this limit.
 
Yeah it does seem a bit strange. The X files that are exported from MCX all have the lower part vertex count of the original model too. So everything seems correct from the MCX side.

It seems it’s XtoMDL that for some reason is combining these parts back together again. I just can’t figure out a way to prevent it from doing this.
 
I'll try to have another look at this. Is the model you use a model I can download somewhere to try?
 
You must log in or register to reply here.
Back
Top