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

FSXA Index buffer exceeds maximum size

jtanabodee

jtanabodee

Resource contributor
Messages
3,924
Country
thailand
Hi,
I have searched about this in threads. But I don't know the simple answer to my question. I have a model that only about 19,000 polygons but when I export these building, this warning "index buffer exceeds maximum size" comes up.
I don't think these polygons amount is too many. I know that I can split this building into two mdl but it irritates me since such amount of polygons should not get the warning like that. Funny thing is, another model contains 35,000 poly get exported easily without any warning.!!!!
Are there anything we can do about this? Are there anythings control the "Index Buffer".
Best Regards,
Tic
 
Last edited:
Hi Tic,

This warning is about the vertex buffer, so it is the amount of vertices, not the amount of triangles that gives the problem. So if you can make sure some more vertices are shared, the error might go away.
 
Hi Arno,
Thanks for your reply.
What you mean is the vertex of the model or the vertex that we unwrap polygon to the texture. I got confused.
Since the model has already fuse the vertex as much as possible already.
 
It would be texture vertices here, so an unique combination of position, normal and texture coordinates.
 
Thanks Arno.
I did try that. Manage as many as possible vertexs to be the same places, but I still get the warning.
What is the maximum vertex per material? Is that around 65K vertexs.
What I'm trying is making a big structure of the airport and use LOD as big as possible. So the drawcall should be minimized.
 
Last edited:
Hi,

Should be around 64k indeed.

It's on my todo list to figure out what the exact limitations are, so that I can implement a workaround in modelconverterx.
 
I have had this twice. Both times it was in a project with about 5-10 objects, the actual vertex count was probably below 300, apparently I had over 72,000 or something. I had to give up and start again.
 
Hi Arno,
I often used small sheet of texture, such as 128x1024 for a repeated texture. Something that often repeat itself like rail, side walk.
I was wondering the bigger sheet 1024x1024 with less repeated times and the smaller sheet with much more repeated times would be better for performance.

Let's an example, if I wan to do sidewalk with red and white stripe on it (no parking) then I use 256x1024 sheet (width x height). In one meter it will be repeated 4 times. If I use 1024x1024, it will be repeated only once for one meter. The first method I use less texture, more repeated times. The second method I use more texture but repeated less time. Which one is better for performance? I don't care about repeat texture since the thing I use usually small. You don't see the detail more than 10-15 meters, so you don't see the repeated texture anyway.
 
Hi Tic,

I don't expect how many times you repeat the texture to influence the performance. The only difference might be that the bigger texture takes longer to load :).
 
So, as I thought the lesser size of texture would be better.
The reason I ask is the model that I have problem is the model that use repeat texture.
It seems to me that the more repeating the more texture vertex is generated. That might be the problem of "index buffer exceeds maximum" warning.
 
Hi,

No, the repeating of textures does not add any texture vertices. That is all done on the GPU.
 
Isn't the problem that by repeating the material more, more vertices are being applied to that material so the limit on vertices per material is being exceeded?

I think you should fix the problem if you make a copy of the material with a small change and then apply that to half the objects.
 
No, tiling a texture does not add any extra vertices. It is done completely on the gpu.

Once I know exactly where the limit is, I indeed plan to let modelconverterx create more materials to keep each part under the limit. But I need to figure out first how much optimization is done by xtomdl.
 
Hi Arno,

I found something here. I searched in the thread and someone recommend changing some of the material properties. But some people warned that might increase draw call to the model.

I copied the material and I changed the specular power of the base material but I also checked "on" to "No base material spceular". Then I got a successful export.

I went to MCX and checked on DrawCall. There was only one draw call even I changed the specular power. Since there were two "No base material spceular" and specular map texture, base material properties were ignore. The DrawCall remains the same.

I changed other things such as Z-alpha test level and I got two draw calls.

I think this trick might be helpful.
 
Thanks, that's interesting.

I still haven't had the time to look into this, but I am curious to see how much you can do in the X file and how much optimization XtoMDL does by itself. I hope XtoMDL does not do too much, as then by just making sure the parts are small enough in the X file we can probably work around this.
 
You must log in or register to reply here.
Back
Top