FSX Gmax error again

[N2056]

Just a thought...do you happen to have any textures used in Gmax that are 4096? That's a guaranteed failure!

 

[hcornea]

Erm, the vertex counter is in Max 7, not gmax... But never mind, the gmax help and tutorials are at TurboSquid's Gmax page.

You can count tverts in Gmax, by typing

getnumtverts$ into the MaxScript listener window

A couple of caveats:

This only works on Mesh objects ... and contrary to popular opinion .. welded tverts in Gmax don't equate with the same tvert reduction in the exported Gmax model

More discussion here:

http://www.fsdeveloper.com/forum/showthread.php?t=19918

 

[lionheart]

Thanks for the heads up HCornea.

Now.. Why wont this thing convert??? What have I missed... (stares into the screen.... )

....more staring...
















more staring......

 

[lionheart]

Just a thought...do you happen to have any textures used in Gmax that are 4096? That's a guaranteed failure!

Hey Robert,

Negative.

 

[lionheart]

Ok... its Saturday, week 3 into the cascade of issues. Something in me just snapped...

I am opening up Blendor, exporting my bird and see if I can get it in XP9. We'll see if it has the same issues.

 

[Heretic]

You do remember that it IS a separate install, right? As are the tutorials?

Actually, I've never picked that information up in the first place. Kind of shows that Gmax is just second tier to me. Oh well...

Erm, the vertex counter is in Max 7, not gmax... But never mind, the gmax help and tutorials are at TurboSquid's Gmax page.

(Finally) noted for later use.

 

[Vitus]

LOL you guys made my day! This thread is hilarious despite the serious problems discussed here.

Just a thought...do you happen to have any textures used in Gmax that are 4096? That's a guaranteed failure!

I do that and it works fine! The only problem with large Textures is that loading them takes aaaaaaaaaaaages, both in PS and gmax. Another downside is that I usually have to save the model in wireframe mode (all viewports) and restart gmax. Otherwise I often get the system.out.of.memory error.

Thanks for the heads up HCornea.

Now.. Why wont this thing convert??? What have I missed... (stares into the screen.... )

....more staring...

Hey Bill,
can you write down the complete error message? I know it sucks as most of the time they can't be copy'n'pasted but it would certainly help to get an idea of what's going wrong.

Cheers,
Vitus

Those ex Gmax guys really get to laughing over this one...

View attachment 9152

omg!

 

[lionheart]

Hey Bill,
can you write down the complete error message? I know it sucks as most of the time they can't be copy'n'pasted but it would certainly help to get an idea of what's going wrong.

Vitus

Hey Vitus,

Yip. Voilla...

 

[Vitus]

Ok:

Message one: When I get this system out of memory error I change all viewports to wireframe, restart gmax, load the model and export again. Usually it works then. Sometimes I also have to close PS and other memory-heavy programs. Note that you HAVE TO restart Gmax after that error, otherwise Gmax won't behave.

Message two-five: is basically one error. It is another splendid example for the humor of the ACES guys (or whoever programmed that exporter). First of all check out the number of vertices. Despite the strange calculation methods described here I suggest something more simple: File->Summary Info... -> "Mesh Totals"->"Vertices"
Your mesh should of course have MORE faces (=triangles) than vertices. That is because one vertex can be shared by a number of triangles. If that is not true for your model you probably have a huge problem with your mesh!

Now comes the part that is a bit confusing: even though your mesh has - say 50,000 vertices in total, the number given by the error message of the exporter will be different. Once I had a rogue mesh with a total of ~10,000 verts but the exporter spilled out that it can't export due to a vertex count of ~70,000.

As Bill said before the exporter "retriangulates" the mesh. And this process includes the UVW maps as well! You have to appreciate that this ~65,000 vertex limit applies to ONE material and has nothing to do with the limitless (?) number of vertices for the WHOLE model.

That is the reason why usually the cheap trick of duplicating the material, changing an unimportant parameter of the new material and assign it to some of the parts CAN help. However it can happen that ONE PART alone can produce this error! Therefore you have to find the part that is causing this trouble. Best practice would be the goodol' trial & error. Start with an empty model and merge one part after the other from your original model and export. If you have multiple materials you can also start by exporting ALL parts with the same material to find the group of parts that cause the error. Also try to export different groups of parts to get more information.

There are two possible outcomes for this tedious investigation:
1. You'll find that ONE specific part is causing the error. In this case you probably have a rogue mesh. That happened to me once and I ended up rebuilding the whole part from scratch (it was the engine, approx. one week of work). When mapping your new mesh, make sure that your UVW-map-vertice-lines in the editor don't cross the boundaries of the map! That sort of "tiling" is poison for the exporter as it will increase the number of vertices drastically.

2. You can't nail the problem to ONE part because even when exporting different groups of parts you get the same error. In this case there are two possible scenarios: you either have more than one rogue mesh as described above OR you REALLY exceeded the limit
In the first case you won't get a vacation very soon.
In the second case you have to reconsider you materials. Maybe use smaller but more materials (even though that is a blow for the performance). Or simply put some vertex-heavy parts on other materials -> "split the load".

I hope that helps! Good luck
Vitus

 

[n4gix]

I've examined Bill O's .gmax source file and noted the same errors he's shown in the screenshot. Here's the diagnosis:

Unfortunately, the error is that you've simply got too many vertices assigned to the same FSX Material.

For example, the vertices assigned to your FSX Fuselage Material won't export...

ERROR: Vertex list has too many vertices (88688), max allowed: 65535
ERROR: Attempting to add an invalid vertex buffer!
ERROR: Vertex list failed allocating. Most likely exceeds the 65535 limit.

Do you have the Maxscript "Select by Material" installed? It allows you to select one object, then "Select by Material" to grab every part that is assigned to the same FSX Material.

I've attached the script. Unzip it to this folder: C:\gmax\stdplugs\stdscripts

1. In GMax, open Customize/Customize User Interface/Quads menu.
2. In the Action window, scroll down and locate the Select by Material script, then select/drag it to the right window and drop it just below Start Parameter Wiring.
3. Close the popup menu.

Now, from the Viewport, select one object (such as the fuselage), then right-click to open the Quad Menu. You should see "SelectByMaterial" just above the last item on the list Convert To: >

What I did was to select about one-half of the objects assigned to "FSX Fuselage", then made a "Copy of FSX Fuselage" and then set the Specular Level to 21 (instead of 20). You can use the Polygon Counter tool to select about an equal number of polys for both FSX Materials.

Now ALL of the objects will export and create a valid model (.mdl) file.

There are at least FOUR "FSX Materials" which simply have too many vertices assigned to them, and will need to be split into two *slightly different* FSX Materials.

This *may* allow you to export the entire project without running into an "out of memory error," but...

...we can cross that bridge later if necessary!

P.S. Bill Ortis, I've tried calling both numbers to speak with you, but apparently they are for the "wrong" Bill Ortis! Even though they are the numbers YOU sent me months ago!!!

 

[lionheart]

Hey Bill and Vitus,


Many thanks for the input. Bill had a valid point on the fuselage. I hadnt realised the fuse had that many polygons, so I created 2 new Material clones from the original Fuse Material, and I was again able to export the plane minus the Females and the two backpacks.

Oddly, I can export the backpacks and the females separately, but not with the entire plane. Thats where I got to thinking that maybe I am having a RAM issue. I pray I am wrong as I dont have the funds right now to update Windows and get more expensive RAM.

Thanks a million Bill for testing that for me. Thanks Vitus for the info. I'll try exporting parts per their Material and see if I can find some more Materials that need to be cloned...


Bill

 

[n4gix]

There are at least three more. You really only need to "copy" the "FSX Fuselage" FSX Material once, and split the objects evenly between the original and the copy.

I just checked the test model of my experiment with Arno's "Drawcall Monitor," and the results are interesting!

2 drawcalls
34759 triangles
88638 vertices

If after "fixing" the other three FSX Material's "overload" problem you still can't export, then we might need to use an Attachpoint to load an .fx file which will in turn load each of your male and female characters.

 

[lionheart]

Thanks Bill.

Those are some interesting findings.

I remember you talking about this neat little trick, using an Effects file to bring in other models, lol... Man, that opens up possibilities...

 

[Vitus]

Indeed an interesting idea. Whats the benefit? Does it work with the VC as well?

 

[n4gix]

Indeed an interesting idea. Whats the benefit? Does it work with the VC as well?

Honestly, that's an "unknown" for me. I've never actually found the time to try it out. What it's most commonly used for is in scenery, as a technique to display specific models at designated times, such as the Air Venture display at KOSH.

I've read about other aircraft modelers using it to display ordinance on their models based on conditions. Since any .fx file can be Attached to a poly in a compiled model, or the modeler can create an "empty" AttachPoint, it would seem to be a very flexible concept.

Also, bear in mind that any .fx file can also be designated in the aircraft.cfg file as well!

The obvious advantage is that the mesh isn't loaded unless it's called for, and it will reduce the size of the .mdl file.

 

[lionheart]

Very interesting, Bill.

Would then your FX file be stored in Scenery? or would you have this in the Effects folder?

I can only imagine that the FX file would be functioning like a Viz XML Gauge in a panel folder telling something to appear on the airframe.

 

[Vitus]

Thanks for the heads up Bill. I'll check it out when the time is right

 

[n4gix]

Very interesting, Bill.

Would then your FX file be stored in Scenery? or would you have this in the Effects folder?

I can only imagine that the FX file would be functioning like a Viz XML Gauge in a panel folder telling something to appear on the airframe.

You know what? I must have just dreamed this while on drugs after surgery or something, because I can't for the life of me find ANY reference to this "supposed idea" anywhere now...

 

[lionheart]

I think... I think... I think Arno should rename this place. Instead of FSDeveloper.com, it should be FSAsylum.com...

 

[FelixFFDS]

I think... I think... I think Arno should rename this place. Instead of FSDeveloper.com, it should be FSAsylum.com...

You will note that Arno rarely steps inside the "Aircraft Design/Modeling" boards.....