XtoMdl vertex limit problems...

[RGS]

Tried this on the AVSim forum but no joy as to a definitive response, any help VERY much appreciated.


'Hi guys, wondering if someone could help me out here. I'm trying to compile a high poly model via exporting as an .x file then using XtoMdl to make the model. I've successfully exported elements of this file before using GMax but am aware of the 65K vertex limit of it's .mdl exporter. I've read in many places that this limit had been removed using the XtoMdl approach, but for me at least this is not the case. I did a test with a box - @ 90K verts - got the vertex limit error + 0Kb model file generated whilst @ 60K verts no problems...

I've also read that despite it generating the vertex errors it will just create another vertex buffer + work, well that's not the case here. I am using the XtoMdl.exe from the Max 7 plugins directory although the x.files were generated in Max 9 if this makes a difference.

Any help would be very much appreciated.

Cheers,


Robert'

 

[RGS]

Sorry, posted in the wrong section by mistake. If some one could please move this to the 'Modelling' section that'd be great.

Thanks,

Robert

 

[arno]

Hi Robert,

Not sure if I understand your question completely. Where does it go wrong?

As far as I know GMax should not have this vertex limit as well. GMax also uses XtoMDL in the end and the export will create a new vertex buffer if the old one is too small.

Are you sure that the X file you are using is a FSX X file? The FS exporters add some additional information to the X file that is not available if you use another X file exporter.

 

[n4gix]

Post copied from my reply at AVSIM:
==================================
Robert, while not obviously relevant to your question, I would suggest reading (or re-reading) the four part series on "Performance Art" from ACES developer Torgo3000:

http://blogs.technet.com/torgo3000/

Pay particular attention to part 3 and the part where he emphasizes that what what we should consider is "texture vertices," not the absolute number of geometry vertices. He points out that - depending on how its mapped - even a simple "cube" can have as few as 8 texture vertices and as many as 36!

Other forums where help might be found are:

http://fsdeveloper.com
http://freeflightdesign.com

Bill Leaming

 

[n4gix]

I am using the XtoMdl.exe from the Max 7 plugins directory although the x.files were generated in Max 9 if this makes a difference.

You should ask Chuck Jodry at http://freeflightdesign.com about the FSX_Gamepack for Max9 included with the Acceleration/SP2 SDK. He's found that quite a few of the scripts for the FSX Tools are either completely INOP or FUBARed...

 

[arno]

Pay particular attention to part 3 and the part where he emphasizes that what what we should consider is "texture vertices," not the absolute number of geometry vertices. He points out that - depending on how its mapped - even a simple "cube" can have as few as 8 texture vertices and as many as 36!

Going completely off-topic here, but a cube has always 24 texture vertices, even if you make sure the UV maps match perfectly. That is simply because each of the faces of the cube has it's own normal.

 

[RGS]

Thanks very much for the help guys. Read the articles Bill, very interesting, but unfortunately does not solve my problem.


When I try to convert the X file (yes, FSX one) it throws out an error saying it's reached the vertex limit, 64K etc. Not at home right now + can't remember the exact wording of the error.

If either of you have time would you mind just exporting a cube with a 100K vertices or so and see if it works for you? If it does then I'll try to find some other solutions, if not I'll know that's the limit and get reducing now...

If successful can you tell me which SDK you're using + which version of Max?


FYI:

My mesh is currently untextured.

I'm running Vista Ultimate 64bit on a QX6700 with 4 GB RAM and an 8800GTX if that helps at all...

Thank again in advance,

Rob

(will give Chuck a buzz later also, cheers.)

 

[n4gix]

Going completely off-topic here, but a cube has always 24 texture vertices, even if you make sure the UV maps match perfectly. That is simply because each of the faces of the cube has it's own normal.

Um, didn't you try this example?

"Open up 3ds Max or Gmax (or follow along in your mind). Create a box. Convert it to an editable mesh and apply a UVW Unwrap modifier. Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener window. In the listener output window, you should see the number 8 appear. That means it has 8 texture vertices. That makes sense, 8 physical vertices and 8 texture vertices, right? Now apply a UVW Map modifier to the box and choose "face" as the mapping type. Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener. You should now see the number 36 appear in the listener output. Huh? 36 texture vertices on a simple box? This is because any texture vertex that is not welded gets duplicated."

The difference is that when the box is first created, UVW Mapping is automatically created for the box, and all the "common texture vertices" are welded for you as well. That is why there are only "8 texture vertices..."

However, once you (re)map the box using "faces" and arrange the UVW Mapping in the editor, you will have a total of "36 texture vertices."

If you rearrange the UVW Map in the Editor and weld all the common vertices, then you can reduce the final texture vertice count.

Look at how the "Cube Map" is layed out on the actual, flattened texture sheet. There are a total of 14 texture vertices, because all of the vertices of the adjacent edges have been welded...

 

[arno]

Hi Bill,

"Open up 3ds Max or Gmax (or follow along in your mind). Create a box. Convert it to an editable mesh and apply a UVW Unwrap modifier. Collapse it back to a mesh and type in "getNumTverts $" in the Max Script listener window. In the listener output window, you should see the number 8 appear. That means it has 8 texture vertices. That makes sense, 8 physical vertices and 8 texture vertices, right?

But the normals are also stored in the texture vertices, I also discussed this with Adrian at the DevConf. So a simple cube will always have 3 texture vertices at the corners, simple because each of the three planes has a different normal.

So by mapping carefully you can get between 24 and 36 texture vertices for your cube. But going down to 8 is only possible if you give all faces the same normal direction as well.

So I am not saying you should forget this, but the benefits are bigger if you have a smooth surface where two connecting polygons also share the normal at the edge.

 

[n4gix]

Okay Arno! Thanks for taking the time to discuss this with Adrian, and educating this poor blighter...

I wish I could have been at DevCon this year!

 

[RGS]

Hello, sorry for the shameless 'bump' but still had no luck with this. If anyone can help here to give me a definite answer I'd REALLY appreciate it.

Thanks,

Rob

 

[robby88]

You're possibly confusing vertices per object within a 3DS Max scene with total vertices per scene.

Back when I used to model for CFS3 I encountered a similar problem with its exporter. If a single object (part) within a scene exceeds 64k vertices the model would not export. Making sure that the Max/Gmax scene does not contain any parts exceeding 64k each should work. I have exported and compiled interior models exceeding 100k without problem from 3DS Max 9.

As an experiment try exporting & compiling a model scene containing 4 objects, each containing 25k vertices giving 100k vertices total for the model. Hopefully it should compile ok. (make sure to create a heirarchy as per the SDK)

I think the limit of 64k per part, within a scene, might be a limitation of the x-file format.

 

[Chronocidal Guy]

I've just hit this particular limit too, but I haven't had any luck yet with the above method.

I've got 65 meshes, each 2000 faces, and 1000 vertices approximately. This particular setup exports just fine, but still gives me the "index buffer exceeds maximum size" warning.

If I add one more copy to the group of meshes, bringing the vertex total up over 66000, the model no longer works. It crashes, saying I've gone over 66000 vertices, and the max allowed is 65535.

From this, it would appear that the hard limit really is 65535 per model, not per part. Even though I'm using 66 different small meshes, the exporter still fails.

I've heard conflicting reports about this though. I've heard from some people that they've successfully compiled meshes with much more than this, just by breaking the model into smaller meshes. I don't know for sure if they've been counting the overall vertices though.

There may be an issue with which version of XToMdl is being used. Wouldn't be the first time MS fouled the exporter. But from what I've tried, it does look like 65535 is the hard limit, which gives you roughly a usable range of 130,000 triangle polygons, and considerably less if you use quads, or don't weld every vertex.

 

[robby88]

Yep you guys are correct. I've just carried out my own test and verified that limit. I have received a vertex buffer exceeded warning on a few occasions in the past, however the aircraft compiled correctly on these occasions.

Interestingly a mesh that would not compile using FS2004's makemdl due to the vertex limit being exceeded, exports and compiles without problem for FSX. I've also tested CFS3 to >100,000 vertices ok (though the CFS3 exporter possibly optimised the 3d model).

I can recall reading in Sebby's old blog before FSX was released that the 65535 limit had been removed as FSX supported multiple vertex buffers. Why this limit was re-introduced I don't know? Exceeding 65535 is only going to used on rare occasions and would not add much to the draw call count, for example, in a virtual cockpit, where this limit could possibly be exceeded.

Perhaps x-files have a vertex count restriction?

Maybe it's a case of the sim engine supporting multiple buffers but the tools do not? If the sim engine can support such and the tools do not, then it's almost a form of censorship. The aircraft designer can surely test the perf of an aircraft and make the decision as to whether its perf is functional. This reminds me of some of the silliness surrounding the CFS3 terrain SDK, i.e. inconsistency between tools in the features they supported.

This limit in FS9 almost had me walking away from supporting that sim and, at one stage, I was going to do likewise for FSX if similarly restricted. There's always CFS3 to satisfy modeling needs and modeling for rendering.

Hopefully this can be fixed in FS11, whenever that is. One more for the suggestion box.

 

[Chronocidal Guy]

Well, if fixing the vertex buffer problem for large models was specifically mentioned, I seriously doubt it's on purpose that it's fouled up. I would guess it's just an oversight on the development team.

What I'm hoping is that it's just a bug with xtomdl causing this, or better yet, some command line tag they forgot to tell us about that enables multiple vertex buffers.

 

[robby88]

The answer......

No need to speculate any further. Adrian Woods (Torgo 3000) explains why this problem occurs, in his blog.

http://blogs.technet.com/torgo3000/archive/2008/01/24/let-s-blow-up-the-exporter-real-good.aspx

This makes sense. The first test I conducted a while back involved multiple textures and materials. The test I conducted the other day involved one texture & material, uv mapped to an entire cube which was then copied 10 times to give me a high vertex count.

Designers who map a high triangle count mesh on to one 2048 texture will have to watch out for this.

Very useful information indeed.

 

[RGS]

Hi guys, sorry for the delayed response. Thanks for all the help, yes simply applying new materials breaks the model up avoiding the max vertex count problems.

Thanks again,

Rob

 

[Verran]

Okay, but what about an untextured, unsmoothed model?

V/R

Justin

 

[lionheart]

Hey guys,


This 'might' be something else, and not a Vertice limit.

Aces found that if you have 'one' texture used too much, it will keep the plane from compiling. They found this out on the ultralight in FSX. It wouldnt compile saying the limit had been exceeded. Oddly, all that needed to be done was to make a duplicate material using the same graphics textures and assign it to half of the parts and Voila, it was back to normal again.

Try that.


This information courtesy of Robert Kerr and Chuck Jodry.



Concerning a cube and vertices, this was brought up by Aces also. If, for instance, you have a bolt head, (hexagonal, six sides and a cap on the top) and you have it unsmoothed, the sim creates seperate vertices (seperate) for all polygon surfaces, (flat panels, not triangles). But if you 'smooth' the entire object (so it appears to have no edges, just a blob like appearence), then all vertices of the object will be shared in the polygon assembly in the FS sim engine. Thus, you can save on model complexity with tons of smoothing.




Bill

 

[RGS]

Hi Bill,

Yes I agree with what you say, but that is the vertex limit, no? As in each texture is limited to a maximum number of vertices? As you say this number is not a set amount in 3DSMax as it'll vary depending on your smoothing groups, welded UVs and which maps you have in the material (a normal map will double this number). For me for example I generally have to keep the number of verts/material to under 15K in Max or it'll blow the 65K limit on export. I don't think that there's a limit per object or per file, but maybe there is (it would have to exceed 200K polys though as I've tested that). This is still my first build so I'm not the best person to give advice at all, but that's my understanding of it anyway. Also applying multiple materials to an object will increase the 'draw calls' AFAIK. I'd love to know how much damage this actually does, especially as I'm considering increasing the detail of my VC substantially, which will then result in having to apply multiple materials to avoid blowing the vertex limit. I take it FSX doesn't actually treat these new materials as new textures + try to load them twice for example?

Additionally are there any tools out there that give you some information in game as to how your model's running, as in number of draw calls, texture memory used, poly count on screen and so on?

Cheers,


Robert