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

Polygon limit aircraft FS2004

Hi,

There is no hard limit. There is a limitation of maximum 65536 triangles with the same material (colour/texture combination) applied. But as far as I know there is no hard maximum polygon limit. Of course the performance in the end could provide you with a practical limit as well :).
 
There is no hard limit. There is a limitation of maximum 65536 triangles with the same material (colour/texture combination) applied.

Hi Arno,

If 16bit indices are the limitation, should that say 65536 vertices? which would mean 20-30k triangles depending on smoothing.
 
Hi Paul,

The vertex list itself has no limitation as far as I know. It is the amount of vertices in one DRAW_TRI_LIST command (which is normally one material/texture). That is limited to 65536, so you are right that the amount of triangles is lower. If vertices are shared most optimal you can have 65534 triangles maximum, but normally it should be more in the 20k-30k range you mention.
 
Interesting - there seems to be a belief on some other forums (in the UK) that there is around a 30K limit for FS9 aircraft.

I'd love to see an unlimited value as I have an FSX aircraft that I "backdated" to FS9 and it worked OK.
I then updated it to above 32K polys and it stopped working in FS9. One of the draw calls in FSX was 22K polys.

I'm not an expert in the FS9 format, but if 16 bit indexed triangle lists are used in DirectX then the limit is exactly 21.33K
Triangle Strips would get to the figure you mention but these are very rarely used by 3D apps.
Shared vertices only reduces the number of vertices, not indices.
 
Hi,

From my understanding of the FS2004 format (which comes more from scenery objects than from aircraft) there is no limitation on the amount of triangles (three vertex indices) that can be provided. The limit is that the vertex indicates are given as uint16 and that the header of the DRAW_TRI_LIST has the vertex offset and vertex count given as uint16 as well. I think think the command forces the use of a triangle list or triangle strip. That is up to the compiler and optimization there. But I agree with you that in general it will not be a perfect triangle strip because the normal and texture mapping can often not be shared.

A solution to get around this limitation would be to have two DRAW_TRI_LIST commands of course with the same material used. Then I think there is no real limit. But the MakeMDL tool does not support this unfortunately...
 
Why in the world cant we 'adjust' the MakeMDL compiler? I should think in this age of time, there would be a way to tweak a compiler for this.

But, if we alter and increase the poly counts and draw calls of an FS9 MDL and it does not work in FS9, then I guess it would be of no use.

There must be a way...



Bill
 
I think that is exactly what the XtoMDL compiler does for FSX. Any single draw call over 64K indices is split into multiple draw calls.

I suspect if the model is built with large parts split over more than one group then turning off the Optimize option in MakeMDL may do the same thing.
 
Why in the world cant we 'adjust' the MakeMDL compiler? I should think in this age of time, there would be a way to tweak a compiler for this.

MakeMDL.exe is a compiled C executable. We do not have the source code for it, we will never have the source code for it, so there is -obviously- nothing we can do about it...

It's rather pointless to continue whining and opining about that over which we have no control whatever. :ziplip:
 
MakeMDL.exe is a compiled C executable. We do not have the source code for it, we will never have the source code for it, so there is -obviously- nothing we can do about it...

It's rather pointless to continue whining and opining about that over which we have no control whatever. :ziplip:


Oh yee of little faith!

Where there is a will, there is a way.

Remember, FSDS has their own compiler...

I will keep the faith.


(I hope I do not sound like I am whining..)
 
My FSX->FS9 conversion problem turned out to be a rogue DXT5 texture, 32K polys works fine so far.

iiyg1otnm2uzax0mml4z.jpg
 
Remember, FSDS has their own compiler...

Had, Bill. Had. Louis wrote his own BGL compiler for FS2002 models, that just happens to still be mostly supported by FS9, and FSX to a far less degree.
 
Looking good Paul!

Glad its compiling fine now.





Roger that Bill,

The new FSDS does use the FSX SDK Compiler. The older version had their own BGL compiler.


I did ask Adam if 'Constantine' (is that his name?) would be into making a newer compiler and how much it would cost to perhaps consign its creation, but Adam said it was doubtful but would pass it along.


Bill
 
Hi Bill,

Yes, I remember the other thread we had about this. Technically it would be possible to make a new compiler, but I still doubt it is worth the time it would take. It would only be useful to a few people. Given that ACES was shutdown since that discussion, FS2004 might have a longer live now. Maybe I should think again about it :D.
 
Hi Bill,

Yes, I remember the other thread we had about this. Technically it would be possible to make a new compiler, but I still doubt it is worth the time it would take. It would only be useful to a few people. Given that ACES was shutdown since that discussion, FS2004 might have a longer live now. Maybe I should think again about it :D.

Hey Arno,

Roger that. Man. I was sitting here last night looking at this thread, wondering how it could be done... I spent about 2 hours redoing gauge bazel rings over and over trying to get them to compile without crumpling up from having Vertices being too close together. It would be so much easier if the parts could be the same for FS9 as with FSX.

It seems to me, that we have, already, 2 fully working compilers. Why couldnt they be mixed together to create a new FS9 compiler? The FSX compiler creates a totally diff model, yes. But what if you could take the guts from the compiler, and its simplistic construction, and use that as the platform to make the FS9 compiler, and for the FS9 compiler, copy/paste the various animation calls and things into the new one.

I am trying to invision this, (I know nothing on how all of this works). Doesnt a program exist in a more basic language until you are ready to burn it into a EXE program? Wouldnt Aces still have the old basic platform code for these? I wonder if it would be possible to obtain them and wire up a new compiler code?

Surely its possible.


If only there was some symbols or letters in the code that one could delete that would cause the compiler to 'not' weld Vertices together.

You know what really gets me, is that the VC is the area where they have autoweld 'locked' on. The exterior does not get this, and the distance of visibility for this would cause you to realise this wouldnt be needed. Autoweld should have been for the exterior model. Not the interior.

If then, in the original compiler code, one could copy/paste the exterior compiler section to the 'interior' compiler section commands, then it should then create a VC with no auto-welded Vertices.



Also, and this might be beside the point. Can 'length of names' cause the compiler to eventually lock up?

For instance, if one has a plane with 3 hundred parts, and you have extremely long names, could all the code writing cause the compiler to trip/stumble? I say this because the actual weight of a MDL file measured as 'text format' size, can be around 4,700 megs or less. If one had super short names, that file will jump down really low in size. Does the size of the file 'count'? Would shorter names help the situation?

Also, if we had a draw call warning on textures, perhaps we could make dual or even tripple 'redundant' textures to help the compiler run a full model.


Bill
 
Last edited:
For one material yes, that is because the exporter optimizes all polygons with the same material in one drawcall.
 
Arno,

Can one have 2 Materials with the same texture or will the compiler combine the two materials if they share the same texture?



Bill
 
Back
Top