I think I made a plane too big for FSX to compile. :S

[Lionheart]

Well gang,

They said that the FSX SDK for Gmax was unlimited and that you could throw in a plane of incredible magnitude and that the FSX SDK Compiler would turn that baby into an FSX MDL.

oops....

400,000 polygons plus and it will not compile. I can compile it in sections, but not all in one piece.

Now that I have FS2004 models 'unlimited' and now exporting models at 560,000 polygons (former limit in FS9 was 65,000 polygons), now, the same model, minus the shadow model for it, will 'not' compile through the FSX version compiler.


I wonder if its possible to patch 3 MDL files together to make one big FSX MDL file? Could it be done?



Bill

[Prowler1111]

While i admire your intentions, i wonder what kind of pc i´ll need to run a 400k model..
I´ve bend sometimes the "fsx sdk laws" from time to time, but always with hidden stuff, so performance wont be a problem, but 400k´s seems something that not your regular pc would run comfortably, just IMHO.
Best regards

Prowler

[Kiwikat]

Why do you need so many polys? Polys != detail.



Having a fancy model doesn't change the way the plane flies or feels. I would rather have something fully optimized that gives me great FPS like the A2A Spitfire. It has more "feel" than any other aircraft I've flown in FS. Not because of the physical model or textures, but because of the flight model, systems, and sounds. The Lotussim L-39 is one of the most extreme examples of efficiency. It is still one of the best addons available for FSX and its not because of its "high poly model". Oh wait, it is one of the LOWEST poly models! It too has a "feel" that 95% of other addons do not achieve.


I don't understand the point of pushing so many polys into any sim. It isn't necessary, nor does it make a plane feel more real in the sim.

[Lionheart]

Hey Prowler,

This particular bird is an Aerospool Dynamic. In FS2004, it runs like glass on my now-becoming vintage iMac with Intel core duo 2.8GHz chip, 3 Gigs of RAM, Windows XP 32bit, and an ATI Radeon 2600XT.

The FS2004 version model runs fine in FSX, with 32bit resolution Bitmaps. The frames are only about 2 FPS slower then the stock FSX Cessna 172, so I dont think the poly mesh magnitude is a huge load on a 'normal' sort of basis. I could be wrong as the mac I have could be a bit more powerful then standard computers.

I have been needing to upgrade my rig. I want a dual quad core i7 Mac tower with 8 to 16 gigs of RAM, dual GC's, etc.. But having a mainline rig helps keep me humble with making things that run on 'everyones' computer and not just the top few.

I take that back. A computer with a 386 chip, 512 megs of DDR1 RAM might stumble on this. ;)

[Lionheart]

Why do you need so many polys? Polys != detail.



Having a fancy model doesn't change the way the plane flies or feels. I would rather have something fully optimized that gives me great FPS like the A2A Spitfire. It has more "feel" than any other aircraft I've flown in FS. Not because of the physical model or textures, but because of the flight model, systems, and sounds. The Lotussim L-39 is one of the most extreme examples of efficiency. It is still one of the best addons available for FSX and its not because of its "high poly model". Oh wait, it is one of the LOWEST poly models! It too has a "feel" that 95% of other addons do not achieve.


I don't understand the point of pushing so many polys into any sim. It isn't necessary, nor does it make a plane feel more real in the sim.


Hey Kiwikat,

How have you been? Great to see you around. :)

[Daube]

From what I could read here and there, it seems that the number of polygons has a very small impact on the FSX performance. It's more likely the textures that could kill it. Am I wrong ?

[Lionheart]

From what I could read here and there, it seems that the number of polygons has a very small impact on the FSX performance. It's more likely the textures that could kill it. Am I wrong ?


Yes. You are correct. The only limitation they could find in the FSX Compiler was a 64,000 Vertice limit 'per' Material.. So if you had over that on a Material assignment, you took about half of those parts, cloned the Material and assigned that to the half you have selected, and that remedied the issue. I have done that with the parts clusters and now have it all compiling, but only able to compile in sections.


What I think it might be, (just a theory) is that the RAM I have with Windows XP32bit is not enough, being 3 Gigs. (4 Gigs, but only 3 can be seen by XP-32bit).

I am having a friend test it to see if this is indeed the issue. (says a prayer).

[stiz]

This particular bird is an Aerospool Dynamic.

Dont take this the wrong way bill, but 400k polys for such a small plane is totally overkill! 100k maybe, but 400! :isadizzy: Remember .. more doesnt always = better, most people wont be able to tell the difference between a 100 poly tire and a 100 million poly tire. Plus lower the polys = easier to work with :)

If ya want someone to go through it with a tooth comb just shout up :)

[Desert Rat]

Ouch!!!

I think Bill maybe thinking ahead and saving himself work in the future. A model of this magnitude would nigh on never need rebuilt, just update it for Flight, Flight2, adum finitum..... no need to rebuild, the details done :d Saving himself LOTS of work in the future, lol. nothing wrong with pushing the boundaries now and then, we'd still be in trees if we didn't.

Jamie

[stiz]

Ouch!!!

I think Bill maybe thinking ahead and saving himself work in the future. A model of this magnitude would nigh on never need rebuilt, just update it for Flight, Flight2, adum finitum..... no need to rebuild, the details done :d Saving himself LOTS of work in the future, lol. nothing wrong with pushing the boundaries now and then, we'd still be in trees if we didn't.

Jamie

*points to tire* you can have a perfectly smooth tire nowadays that wouldnt need redoing (unless you wanted to model the tread!) so why use 100 million polys when 100 would do? I'm not haveing a go, if it was 400K for a big 4 engined bird i wouldnt be suprised, but for a tiny little thing like that .. :)

[SkippyBing]

What I think it might be, (just a theory) is that the RAM I have with Windows XP32bit is not enough, being 3 Gigs. (4 Gigs, but only 3 can be seen by XP-32bit).

The problem is as gMax is a 32-bit program it won't be able to make use of any more memory if you run it in a 64bit OS. However I have found running in Safe Mode allows you to eke a bit more out of the exporter...

[krazycolin]

We've managed to get a plane that had over 600K into the sim. so.. it can be done.

[Lionheart]

Awesome. Thanks Colin and SkippyBing.



Bill

[anthony31]

What sort of an error message are you getting from the compiler Bill?

I've only run into the 64000 vertex limit problem myself when making a test model.

I may try and have a look at making a 400,000 poly dummy model and seeing if I can compile.

BTW Sometimes I think making smaller aircraft require more detailing than the big ones.

On a larger aircraft you can get away with reducing the complexity of landing gear and small external parts as not many people will zoom into those parts and will usually just look at the whole aircraft. But on smaller aircraft those small parts are bigger relative to the overall size of the plane and sometimes need more detailing.

[Lionheart]

Roger that Anthony.

I dont know how it got up to that high of a Poly package, but it did. I was trying not to go overboard, but at the same time, to include as much as possible of all the detail that the actual plane has. Not working with limitations was a good feeling.


Bill

[N2056]

"So if you had over that on a Material assignment, you took about half of those parts, cloned the Material and assigned that to the half you have selected, and that remedied the issue."

You missed the important part. After cloning the material you must go into the editor and change it's settings slightly. ;)

[Lionheart]

Nope. I did that. ;)

[roger-wilco-66]

The 64k limit in the mdl compiler applies to vertices __per drawcall__, IMHO.
I've had that problem before when I tried to reduce drawcalls and therefore the vertice count went up.

Cheers,
Mark

[Chuck_Jodry-VJPL]

Compiler logs are the key to figuring out the reason , post your text output , it will detail any vertex based errors with a count , when all the parts on a given texture are selected the triangle count is a baseline you can use to identify the culprit , remember each sheet applied is another set of texture vertex so a material with diffuse and specular maps will double the T V count , three sheets triple it , so a fully bumpmapped fuse with spec map can fry the compiler with fewer than 30,000 polys.

[Mathias]

Rule of thumb that works for me:
Not more than 12.000 geometry triangles per shader when it has diffuse+spec+bump+fresnel.

[Chuck_Jodry-VJPL]

The best post i ever read on it was during the production of FSX Performance Art 3: Polygons don't matter. (http://blogs.technet.com/b/torgo3000/archive/2007/06/19/performance-art-3-polygons-don-t-matter.aspx)

[roger-wilco-66]

The best post i ever read on it was during the production of FSX Performance Art 3: Polygons don't matter. (http://blogs.technet.com/b/torgo3000/archive/2007/06/19/performance-art-3-polygons-don-t-matter.aspx)


That's an excellent post, Chuck! Thanks for mentioning it!

Cheers,
Mark

[Lionheart]

Rule of thumb that works for me:
Not more than 12.000 geometry triangles per shader when it has diffuse+spec+bump+fresnel.


Mathias, you forgot two.

that would be diffuse+spec+bump+fresnal+self illum+reflection unless you are using fresnal as reflection. (I could be wrong there). I usually have 5 materials on the main FSX textures. Flat black and materials like that do not have that many.


Thanks Chuck for the info and input.


Taking a look at this, it is a big limit, and from what Arno said, it is based on a compile that is only 16 bit driven. If the compiler was designed to handle 32bit, and if there was a way to 'not' have a memory trigger 'crash' in the compiler, and if also the compiler could run in 64bit mode optionally, then we could run what ever sized files we wanted through the 'compiler' (not FSX) and burn a MDL file fast without having to worry about this Vertice issue.

Another words, I cant see why this limit exists, except that it might be designed to not use too much of a computers resources to keep it from crashing the computer itself, not necessarily the compiler.


Another thing I found out on this latest obstacle is that we have no way to 'measure' the Vertice limits 'before' we compile an FSX model file. Another words, we can only guess whats going on. Granted, Chuck, the files 'sometimes' tell you what is going on in the crash logs, but yesterday, sometimes it just gave me a couple of generic crash statements if anything, and they are generic, stating '...most likely caused by going over the limit of 65,535 Vertices limit'. That doesnt tell you which material(s) are causing the compiler crash.

In 3DS Max, you have a 'Vertice Count' available to view to see how many Vertices you are hovering at. Not in Gmax. It would be nice if someone could create a script/window panel/Vertice counter for instances like this, but I doubt this would help as we are dealing with objects that are covered with up to 5 or more different material sheets or textures 'per' Material. So having 5 textures on one object, that is 5 times the vertices. I just learned that a simple cube can have perhaps 24 or more Vertices (I think I actually heard 36) if the Smoothing is done right, meaning each surface of the cube (two polygon triangles, un-smoothed) would have 6 vertices, if no Smoothing is done, thats two triangles per surface or two faces per side. (I think then the count would be 36 vertices), and then multiply that by 5 material 'layers', you have 180 Vertices in a sigle 'cube' shape. heh...

Having a 'limit' in the compiler is what I feel could be a downfall in the near future as models become more and more complex and elaborate.

I heard yesterday that a 1,000,000 polygon model was created through the CFS 3 compile (one powerful compiler if I may add, as I hear nothing but what it 'can' do). The model performs well in CFS. So my 565,000 poly model is nothing compared with that thing. And thats for FS2004. My 413,000 polygon model (Poly's not Vertices) is smaller then the FS9 variant.


Barriers... arrghh....

[n4gix]

Nota bene: I've examined Bill O's model and explained to him how to identify and fix the excessive vertices problem(s).

I found four instances where the part(s) assigned to a specific FSX Material exceeded the vertex limit. Once divided evenly between the original and a slightly modified copy of the FSX Material, it compiles just fine on my dev machine. :bump:

[Chuck_Jodry-VJPL]

You can get an accurate count if you type in > getNumTverts $ < into the Max Script listener ( Gmax has one ) , this only works on a collapsed mesh so use it on a cloned copy of your object , or all the copied parts on one sheet attached together after being collapsed to mesh to see the total for a given map.

[Lionheart]

Nice Chuck! I didnt know about this. It will help us all out.

[hairyspin]

Thanks for that Chuck, some understanding is dawning.

@Lionheart: glad there is a solution, where would we be without the Sage of Modelling?

[Lionheart]

@Lionheart: glad there is a solution, where would we be without the Sage of Modelling?

Amen to that!

[anthony31]

Glad Bill was able to help you out.

As I said earlier I did try making a big model in FSDS to see if I could get the same problem but big models just slow FSDS down sooo much that I couldn't finish it.