• 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 Bill,

If all settings are the same the compiler will combine them. Maybe if you have a different diffuse colour set or so, but I am not sure if that one is ignored by the compiler for textured faces.

Another option would be to just export and edit the ASM code manually afterwards to fix the problem. I assume the error is after the ASM files have been generated.
 
Here is a little dream fantasy idea for automating a scaled up VC with close proximity vertices.

* In Gmax; have a Max Script that scales up 'selected' parts to a certain scale, then clears their 'scale' settings (for animated parts) so that all scales are reset and extreme scale.

* Run compiler.

* Secondary program. Open your X file (or ASM file) with it, and select 'Set Scale to 1' (Wozza's scaling trick, reset scale back to normal size).

* Compile the model.


It would require a Script, and a small program that resets the scale back.

The second program could be done like MiddleMan, in that it could open the file, adjust the scale, then turn on the compiler automatically and compile the two ASM or X files into the MDL file.


I forget on the file types that are adjusted.


Off to experiment on that.



Bill
 
arno said:
Hi Bill,

If all settings are the same the compiler will combine them. Maybe if you have a different diffuse colour set or so, but I am not sure if that one is ignored by the compiler for textured faces.

Another option would be to just export and edit the ASM code manually afterwards to fix the problem. I assume the error is after the ASM files have been generated.
Click to expand...


Thanks Arno.
 
You know what would be cool is a little program or script in Gmax that alerts you to parts that have vertices under 4MM distance in proximity.

Example;

Select a group of parts, run Vertice Proximity script, and all parts with Vertices under 4MM in distance are flagged and left selected or are produced on a list.

Bill
 
Well, I have been trying the Wozza scaling trick to get my Epic to compile in FS9 with tight Vertice proximities, and the model will not even compile.

I have half a zillion parts and probably 1/3rd of those (at least) are animated and all are in Hierarchies. Not much luck in one day trying to get all parts to clear their Scale errors. Some will not clear.

I was hoping to see if I could do a speed-Scale-Compilation to see how fast I could get a regular model to go through a 'scaling' compilation.

Not good..

<-- rubs ointments into eyebrows and talks them back to life..


First time I had to use my 9volt battery and two wires to bring one of my eyebrow hairs back to life..

He had turned a color that was ultra-silver. I can only think its the next color of stress they turn into.. its wierd. Like a plastic translucent shiney look..


Bill
 
Let me revisit this very old thread, as recently while adding FS2004 aircraft export has been added to MCX questions about this appeared again.

I now think the information I posted before is not accurate. You can have a maximum of 65k vertices in one drawcall/material indeed, so that is typically around 30k triangles. But the code that draws the triangles also has an offset in the vertex list and that is also an 16 bit unsigned int, which means that that offset is maximum 65k either. So with MakeMDL there is indeed a 65k limit for the maximum number of vertices you can have.

I think technically that could be worked around by splitting the vertex list of the object into multiple lists, so that each part can reference a shorter list. But that is not what MakeMDL does. It seems to put all vertices of the object into one long list.
 
arno said:
I think technically that could be worked around by splitting the vertex list of the object into multiple lists, so that each part can reference a shorter list. But that is not what MakeMDL does. It seems to put all vertices of the object into one long list.
Click to expand...
You're right, makemdl for FS2002, CFS2 and FS9 works that way (probably a performance reason?).
However, you can have an unlimited number of vertex tables. The only limitation is a maximum size of 64k for each one.
We discussed this a long time ago here and also on the freeflight-design forum. As I recall, Lionheart even wrote some pdf guide.
 
Thanks Luka. I found a post with the tutorial of Lionheart, but the link to the pdf is dead.

How did you force MakeMDL make multiple tables? Did you tweak the ASM files manually and recompile them?
 
Hi Arno,

If I am not mistaken, you are referring to the PDF published by Lionheart on its ULE method, which allowed to push the limit of polygons on an object for FS2004.
At the time, I carefully read his post and PDF and I had translated it for the French forum (2010-2012) that I was moderating. I still need to have this PDF on my hard drive.
I can send you the original version (it's not my PDF so I cannot publish it on line). You can always find on Internet and Youtube a video on this process:
The process involved splitting the model into several elements, scaling them (x32). The different elements of the plane must be cut according to the LOD and the way the rendering engine operates to visualize the object.
Then compiling with makeMDL/BGLC_9.exe to obtain an ASM file. These files were then modified in Notepad to delete/replace certain strings and reassemble them via MCX

Subsequently, with a friend we interpolated this method to develop planes with a very large number of polygons for FSX and Prepar3D (v1 or V2).
On my website, French-VFR in the Knowledge section, I published a PDF that briefly describes the different steps of this ULE2/3 process.

This new proces is based on the use of the P3D's SDK v1.x (compatibility for FSX and P3D) or v2.x (only P3D).
1 - with Gmax and the SDK v2.x, you export your model and obtain an .X file
2 - with XtoMDL (SDK v1.x or v2.x) you should then compile your X and XANIM

All this process can be build via BAT files
 
Last edited:
arno said:
How did you force MakeMDL make multiple tables? Did you tweak the ASM files manually and recompile them?
Click to expand...
Manual editing of asm files. The trick is to display multiple smaller models in the same cycle. The simplest way is to break the whole model into smaller parts represented as LOD models (this way we will avoid problems with the DICT table!). Then in the header of the main asm file just replace a few commands BGL_JUMP_32 LOD_XX with BGL_CALL_32 LOD_XX and finally compile with BGLC_9.exe.

Can't find the original discussion because the FFDS forum is dead, but I found Lionheart's pdf.
 

Attachments

Thanks for sharing the PDF. I remember I have seen it many years ago now.

I have put it on the MCX wishlist to support this approach. I guess it should be possible to automate this process so that ASM files don't have to be edited manually.
 
That would be very helpful when the new capability to convert FSX and later aircraft to FS9 format becomes available. :)
 
You must log in or register to reply here.
Back
Top