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

Gmax - Poly limit

Messages
73
Hi everyone !

I have a problem using gmax. In fact, i can't export my project to a mdl file because the number of polygon is bigger than 65k. It's a plane for fsx.

Someone have a idea ?

thx.
 
apply different materials to subparts so that each is less than 65k

It should then export
 
I have to ask this. Why are you just now discovering there's a problem? Haven't you been exporting test models as you build?

Fortunately, as noted above the fix is relatively easy to accomplish. Make a copy of your existing FSX Material, make any minor change to one of the parameters (such as specular level), then apply the new FSX Material to some of the objects in the scene that're overloaded with texture vertices.
 
Or have you hit the 65K vertex limit for one object in FSX? A model is usually made up of lots of objects, but 65K vertices is an absolute limit per object.
 
Hi everyone !

I have a problem using gmax. In fact, i can't export my project to a mdl file because the number of polygon is bigger than 65k. It's a plane for fsx.

Someone have a idea ?

thx.

You'll get there man. With FSX, it is usually the 'too many parts attached to one single material' issue. Creating a Copy of that material, changing a small detail, making the name something like 'my_texture2' and then 'Apply' that to half of those objects that are applied to the other texture in huge numbers, and then try to export.
 
Also, I should note that the 65,000 POlygon limit no longer applies to the 'FSX' version of Gmax. Only the 65,000 poly limit with 'Material Apply' instances where too many parts have been applied with the same material which freaks out the compiler.

The older FS2004 65,000 Polygon limit is not in the new compiler.

But.... It does have a limit. Vitus and myself have found it. Grim... But its with models in the 400,000 polygon ranges...



Bill
 
But its with models in the 400,000 polygon ranges...

It's actually not a limit of the FS. If your model gets too complex, the Gmax Exporter runs out of memory, hence fails to export. I ran into this problem at about 220,000 polygons (2GB RAM), Bill had this problem at ~400,000 polys. If you have sufficient memory (and both windows and gmasx can handle it), there shouldn't be any problem.

Vitus
 
It's actually not a limit of the FS. If your model gets too complex, the Gmax Exporter runs out of memory, hence fails to export. I ran into this problem at about 220,000 polygons (2GB RAM), Bill had this problem at ~400,000 polys. If you have sufficient memory (and both windows and gmasx can handle it), there shouldn't be any problem.

Vitus

Cool! So this is where it will come in handy for me to have a Mac Pro Tower with 2 6-core Chips, dual GC's with 1 Gig of RAM each, and a 12 or 16 pack of high speed RAM. Then I can compile an 800,000 Poly model into FSX format.

:D :D :D
 
Errm no ... 32bit executable ... runs out of memory even on a "big rig" on a 64bit o/s.

Thankfully I make scenery .. so if I have that many polys I know I have done something seriously wrong.
 
But here's a thought, off the top of me head, so probably not worth a cent...

If as Vitus says it's a question of gmax RAM then ... what if after texture mapping you move all of your texture bitmaps away to a backup folder. Gmax will complain about missing textures but it will leave the names in the material slots, as far as I know. So that should free huge amounts of memory, right?

Another alternative - make your gmax map files (not the originals) jpg's rather than psd's or bmp's. In fact, reduce them to an absurd value such as 32 x 32. Then gmax won't even complain and still have the benefit of more memory. Of course in the sim folder you have your 2048 or 4096 sizes.
 
I think it's the plugin, rather than Gmax ... and I don;t think it cares how big your textures are (or whether they're present)
 
Since nothing but the "texture names" get's compiled anyway, the texture's absolute file sizes is irrelevant.

However, the point of having the textures loaded into RAM is a valid one, because they do take up a lot of memory!

The simple solution is to save your scene in wireframe mode, close Max/GMax, then restart the program, load your file, then export. Since no textures were loaded, less memory is consumed!

I've sometimes had to do precisely this in order to get a successful export of a model which was "heavy in textures..."
 
However, the point of having the textures loaded into RAM is a valid one, because they do take up a lot of memory!

I totally agree. I hadnt thought of that. ALL of my textures are in huge massive 2048 x 2048 PSD stacked layer files, TONS of them...


The simple solution is to save your scene in wireframe mode, close Max/GMax, then restart the program, load your file, then export. Since no textures were loaded, less memory is consumed!

I've sometimes had to do precisely this in order to get a successful export of a model which was "heavy in textures..."


I 'have' to do this or mine will 'always' crash, so this must be evidence that this is the right path of thinking in the consumption of RAM during an export...

Great thinking MJahn

Bill
 
MS Flight team would no doubt like to hear a wish for a 64-bit exporter (in addition to the likely 32-bit one)? :rolleyes:
 
Well. if they ain't gonna do us one after the product ships, we better let them know now! :duck:

Amen to that! It would be cool to have a compiler for Gmax, Max, as well as Lightwave and Rhino 3D.

That team in Japan seem to know what they are doing concerning making compilers that adapt with other 3D design engines. Man, I wish I had saved that news article... arrgh.
 
Back
Top