That’s a great idea. 
1 Like
Do i? I’m always surprised about all the things i just have to have said to make other people’s arguments look right. No i am not. You put the wrong stuff into my mouth here.
Again, it should be the artists decision with what he wants to work. This implies that the artist has a choice here. I don’t want to take you away the 16 bit component, i personally want and need a additional 32 bit component.
Yeah, let’s just declare all examples to non valid to have a better base for your discussion. And let’s put stuff into other people’s mouth too. See above 
Could we please stop this kind of discussion style? Both are very valid examples, and both happened to me. The gap problem is a common problem. Like it or not.
Your concern is that it ends in an either or case. Either Unity can deal with 16 bit or with 32 bit only. And that it breaks your pipeline then. That’s a valid concern which i can understand.
It’s just not a practical one. Unity has to take all export cases into account, it is multi platform. And this means also to deal with both, 16 and 32 bit indexes. OpenGL relies at 16 Bit for example. So there always needs to be a way to deal with 16 Bit indexes. There is no danger that we end in 32 bit indexes only in the nearer future. Well, maybe at the editor’s and importers end. But there could be worse than not longer to care about possible gaps and splitted meshes. Pc games with state of the art hardware on the other hand may benefit from the 32 bit indexes. As told, Unity needs to take both into account.
A possible case could also be that the Editor deals with pure 32 bit, and the meshes gets split at export when needed, dependand of the target platform and how big the chunk really is.
But that’s all speculation. At this point it’s not about practical solutions and to have it implemented tomorrow. But about the decision to play with 32 bit indexes too. If and how this could be implemented into Unity is a completely different chapter where the Unity devs have the last word. They have the source code and the technical knowledge. They are the ones who can say if and how it can be implemented.
Anyways, please don’t forget, Unreal and Cryengine have already 32 Bit mesh indexes. Seems that i am not the only person in the world who needs 32 bit mesh indexes 
So it’s definitely nothing impossible and pipeline breaking as you fear so much. More the opposite, or those two big boys wouldn’t have switched to it.
The for me much more important part is to have 32 bit at runtime available. Not just at importing into the Unity Editor.
I still disagree. Modern graphics cards are most of the times idling when dealing with pure mesh data. The performance eaters are shaders and game code. And shaders is where you can save with drawcalls.
We need more than 64k vertices on our meshes. We work in driving simulation, so would be cool to be able to import our road surfaces only for visualization and analysis purpose.
@RJ-MacReady , dunno what my quote has to do with your image. Never said Unity sucks. That the two direct Unity competitors uses 32 Bit indexes is just a fact. Not an accusation.
This thread reminds me more and more at the discussion with Bmesh for Blender. Nobody needs Ngons, and no matter what argument came, nobody ever needs Ngons. Basta!
The same people now happily uses Ngons …
It is likely because both engines are aimed more at AAA, as well as generally more demanding, titles than Unity has been in the past. I do believe Unity should add support for them because, at the very least, a game engine is supposed to make your life easier. Not force you to spend additional time working around its limitations.
1 Like
Now that is a cogent and polite way of putting it.
In my experience, some people are already offended by breathing. But this thread is not about what offends you. So i would be glad when we could stay ontopic, without war polemic and trolling attempts.
2 Likes
Wow much thread.
I frankly did not read al of it, but the summary is:
- We do split large meshes into sub-64k chunks. That should not produce any visible artifacts or rendering issues! If it does, that sounds like a bug, please please file a bug with a repro project.
- We do the above because many platforms we have only support 16 bit index buffers. Yes, some platforms do support 32 bit index buffers too, but for 95% of typical use cases 16 bits are plenty and saves a lot of storage/memory space & rendering bandwidth. For cases with more vertices we split them up, see above.
- Maybe someday we’ll have 32 bit index buffer support, but so far no one has implemented it here.
- As to why we also limit number of triangles to 64k… I frankly don’t remember. Could have been that some OSes/drivers/GPUs fallback to the “slow path” when rendering too many triangles in one batch; not sure.
4 Likes
@Aras - Can you explain why meshes with less than 65535 vertices get split, and that is the total amount of vertices in Unity not in the fbx, I can import a mesh with 40,000 odd vertices and Unity will split it into one of about 30,000 and one of 10,000, why does it do that? I had an email from a bug I submitted saying Unity will split on vertex count of > 65535 or index count of > 65535 * 3 (why does it split on that as well?) but no one will say why Unity will split a mesh that has less that 65535 vertices.
If it’s really 40000 or so vertices and Unity splits it, then that sounds like a bug. Repro please.
However, often what looks like “40k or so” vertices in 3dsmax or Maya or any other modeling app is really “more vertices” because UV seams, normal seams, tangent seams all cause “new vertices”. E.g. cube for realtime graphics (& Unity’s) purposes typically has 24 vertices, not 8.
Yes I know that, the test object is a plane, no uv seams, no smoothing groups, the vertex counts given are ‘after’ import into Unity. Attached is an fbx, it is a simple plane with 48481 vertices in Max, importing that into Unity results in the error message of 65535 vertices and a split mesh, mesh one has 33137 verts and 65534 tris, mesh 2 has 15926 verts and 31266 tris, so a total of 49063 Unity vertices, so why has it been split?
1952325–126265–vertsplit.rar (312 KB)
1 Like
“and 65534 tris”
did you not figure it out by yourself?
Thanks for chiming in and giving us some food Aras 
Mh, this sounds like my workflow has to be to create one monster mesh, and let Unit decide at import where the seams are.
But in practice that’s not how it works when i have to work with chunks anyways. Usually you split your mesh up by hand in your modeler to decide by yourself where the seams are. Practically where your materials end to have optimum draw calls, and/or where the seams are not so visible. Means i do not import one mesh and let Unity split the mesh into sub-64k chunks. I import chunks already that i have created in my modeler. With all the problems caused by that, like shading issues and gaps because of floating point errors.
I can give you such a level geometry with gaps. But i doubt that it is of use since the gaps were not introduced by splitting the mesh with the Unity importer. But while the usual workflow.
Too bad. I need 32 bit for what i wanted to do in my next project. To work with chunks gives me simply to much headache.
There is no limit on the number of tris, the tri index list is made up of 16 bit values but it can be any length, I regularly make procedural meshes with more than 65535 tris in the index list, for example that plane in the fbx file could be made procedurally in Unity with the same number of vertices and tris and Unity would happily render it, I have made test meshes with 65535 vertices and 500,000 tris which render fine as well.
Who knows, it could even be reduced further but behind the scenes be split up into a series of perfectly fitting meshes. Or maybe in the future unity will use the data from the fbx files to build a mesh in some unity specific format that reduces poly count and uses all kinds of tricks / optimizations and settings to make things look even better.
Just want to turn you on to the concept of pre-processing your assets using editor scripting. You can create sub meshes by iterating through your vertices. I saw a video tutorial from a Unity conference one time where a guy chopped up a golf course in order to optimize it for mobile this way.
@funshark - Yes I know that thread, the point is there should not be a limit on the number of tris, Unity is splitting a mesh on import that can quite easily be rendered by Unity if it is generated procedurally so the original question stands why is Unity splitting a mesh into two which it can quite happily render.
Like I said above… “As to why we also limit number of triangles to 64k… I frankly don’t remember”. Maybe someone from graphics team will show up and answer the question
couldnt be possible to add constraints on alternative components? as i think there is already some pieces which dont work on some devices like linear space on mobiles, and i guess alternative mesh component could be handled in similar way…