• There seems to be an uptick in Political comments in recent months. Those of us who are long time members of the site know that Political and Religious content has been banned for years. Nothing has changed. Please leave all political and religious comments out of the forums.

    If you recently joined the forums you were not presented with this restriction in the terms of service. This was due to a conversion error when we went from vBulletin to Xenforo. We have updated our terms of service to reflect these corrections.

    Please note any post refering to a politician will be considered political even if it is intended to be humor. Our experience is these topics have a way of dividing the forums and causing deep resentment among members. It is a poison to the community. We appreciate compliance with the rules.

    The Staff of SOH

  • Please see the most recent updates in the "Where did the .com name go?" thread. Posts number 16 and 17.

    Post 16 Update

    Post 17 Warning

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

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


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....
 
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:
 
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.
 
Thanks for that Chuck, some understanding is dawning.

@Lionheart: glad there is a solution, where would we be without the Sage of Modelling?
 
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.
 
You must log in or register to reply here.
Back
Top