65535 vertices limit

I'm trying to bring some DAZ Studio characters into Unity, and I ran into an issue. Apparently, there is a 65535 vertices limit for a mesh:

Meshes may not have more than 65535 vertices at the moment. Mesh 'FullTop_42769-skinInstance' will be split into 2 parts: 'FullTop_42769-skinInstance_MeshPart0', 'FullTop_42769-skinInstance_MeshPart1'.
UnityEditorInternal.InternalEditorUtilityrojectWindowDrag(HierarchyProperty, Boolean)
UnityEditor.DockArea:OnGUI()



Anyone know if this limit will be going away anytime soon?

The character I'm importing doesn't look right, and I suspect it may be because it is being broken into multiple meshes.

Thanks.

 

I know nothing of DAZ, but have encountered the vert limit and experienced the mesh splitting before perhaps you could reduce the detalis a bit on the model? a quick google gives me this but as stated I know nothing of modeling

 

The limit has been in place for years.

 

There is still an issue in the mesh importer in Unity as it will split meshes with less than 65535 vertices, for some odd reason that no one at Unity seems to understand they split meshes based on the number of tris as well can be seen in the Unity post at http://forum.unity3d.com/threads/bu...port-it-does-not-need-to.247046/#post-1724471 Would love to know why Unity has to split meshes when it has more than 65535 tris?

 

You need to use the Decimator tool from Daz to lower the poly count before bringing it into Unity. You'll most likely want to use the Texture Atlas tool they offer as well, to help cut down on the material count. There are a few other things you'll want to do if you plan on using Daz characters in your game. They're not really made for straight up importing.

 

I could have sworn I heard somewhere that in Unity 5 this limit would be gone, but I know I'm still getting that limit (I know this isn't for Unity 5).

But I heard somewhere that Unity5 would get rid of this limit. But now idea when lol.

 

I hear there's also a limit on texture sizes as well.

"65535 occurs frequently in the field of computing because it is the highest number which can be represented by an unsigned 16-bit binary number. Some computer programming environments may have predefined constant values representing 65535"

It sucks because everybody knows that the only difference between amateur and professional games are things like poly counts, texture sizes, frames per second, input response delays and, of course, anti-aliasing algorithms.

 

Heh this looks like their mesh importer still stuck on 16 bit era for some reason... where 64 is standard nowaday...

Maybe unity could consider replacing old importer for, let's say, assimp? this is written in c++ and have c# wrapper support various formats and close all mesh features like blend shapes, in addition have export feature which would be cool for some plugin developers.
Only problem is that mesh representation in code is completely different which may cause backward compatibility issue but this can be solved via 'bridge' which could convert assimp representation to unity version...

 

Uh huh. Graphics capabilities are certainly a difference. But not the only one. And possibly not even the most significant one.

 

Um, so unity can represent vertex indices for a mesh that has less than 65536 vertices using 16-bit ints. If you have a mesh with 65536 verts, then the mesh index will need to be stored as 32-bit ints, doubling the memory size used for the mesh indices. That may not bother any of you, but keeping the memory size down was a design goal. If you do submit a mesh with more than 65535 verts, Unity splits into a number of meshes. This happens automagically, so there is nothing in Unity that means you cannot have high poly models. (There is a similar limit on the number of triangles, but I forget the value, and how it's imposed.)

 

@Misterselmo - You won't impress any professional developer with a high vertex count, rather the opposite. The true definition of a AAA artist is someone that can push realistic models with the lowest vertice count, texture size etc possible.

Here is an example:


Anyone that is curious can also Google the main character from Witcher 2... think his name was Geralt (?). I remember that they made an image breakdown of the model that showed the quads/triangles, bump, normal and diffuse etc... It looks great and is also far away from braking the vertice limit in Unity.

(Hope the qoute tag thingy is working)

 

I was thinking the same when I was reading Misterelmo's comment earlier but then while replying to it the whole sentence started to sound like a troll bait and I canceled. With so many "AAA" games being fps locked down to 30 or high poly being AAA...

As a programmer even I can model decent models fast via sculpting but then the models will be really high poly and unusable in "real" games unless heavily optimized down which is a thing that I don't master.

Here is some of the older AC characters in both views:

http://www.zbrushcentral.com/showthread.php?97394-Assassin-s-Creed-Brotherhood-Characters

 

That was what I though too, but I seldom work with models, so I wasn't sure. I'd expect a bunch of models over this limit to start causing performance issues at some point.

 

There are already characters in games with up to 50 k tris. The old Unity demo had a soldier with 22k tris already. It's just a matter of time when you hit the 65 k limit and you need to split the stuff. Nasty for a terrain mesh for example. Those lovely gaps ...

The bottleneck is not the tricount anymore. Modern graphics cards can handle megapolys in an eyeblink. Shaders and code have ways more influence.

That said, wouldn't it be nice to have 32 bit ints when you really want and need them? Would make certain tasks much easier. Especially those where you try to load, modify and save a mesh at runtime. Yes, i know, Unity is a game engine. But even here, see above

 

Not only a game engine! ofc this is main goal everything else is a bonus but unity is used for something else too (archviz, customizing product via website for example) and there you more times need more than 65k limit due to often using procedural mesh creating in runtime which isnt handled by unity (i mean automatic splitting)

for example this limit is problematic for road/river tool (i tried create them for better understanding unity)- if you use relatively high poly density for smoother edge and have very uneven and long shape then this limit become problem very fast....

in addition as someone mentioned above splitting isnt perfect. As i think perfect would be new property/enum for mesh like for bones where you can specify that how many one vertex could have bones, so this will allow us to choose between less memory consumption and more polys& convenience in workflow

 

Doesn't Poser open Daz Models? I have poser game dev and it reduces polys while keeping the morph proportions and such. I'd look into it.

I think a bigger problem is why do you want to use models with more than 65k vertices? Is it a high end PC game or the feature in a complex visualization? If not, you need to reduce the poly count. There are tools in various 3d modeling programs for doing it. There are tools in Unity for doing it as well but it'll split the original mesh beforehand when you import it, so you need to do it before it gets to Unity.

 

@Graham Dunnett - Can you explain why is there a split on tri counts, it makes no sense to me. I can make a procedural mesh with 65535 vertices and say 500,000 tris and Unity will render it fine so why does an imported mesh with only 40,000 vertices and 90,000 tris need to be split into multiple objects?

 

To build on this, not everyone uses Unity for gaming... I use it for engineering visualisation and removing the restriction makes a lot of sense when I'm dealing with survey data that generally gets broken up into 10 or more pieces due to this limit.

 

I already told one example. My last game used terrain meshes with up to 150 k tris. And there were visible gaps between the splitted parts. Gaps that wouldn't be there when it would be one geometry. Floating point errors ...

And even with characters we come more and more close to the 65k limit in the modern games.

Another example is everything where you import and export at runtime. I made a little tool to convert a greyscale image to a mesh. And had to use chunks, because i can easily produce megapoly meshes with it, which is a pain in the ass to handle. And that was already the stop point for the tool that i initially wanted to develop. This image to mesh tool was just a test case to see how far it can go.

A special 32 bit mesh filter would be a fine thing. That's 4 billion vertices already. Or maybe even a 64 Bit one. That's definitely future proof for the next two years then

 

@Ostwind - You are almost there if you got a high poly mesh done (sculpting or any other tool combinations), next step would be to "retopologize" the mesh so you get a low poly version of it. Followed by using both meshes to "bake" your "normal map" and any other textures that want or need (ambient occlusion map is a really good idea). Now, just paint the diffuse texture(s), connect all the pieces in Unity and you are ready to go....
So if you can do what you claim, I would highly recommend that you learn the last steps because you are probably 80% away from understanding and being able to produce HQ work

@Tiles - Yes, there are games with bigger meshes but that doesn't make the artist good... the only case where I see such models as acceptable during production is when you need to model all the clothes and hair separately so that you can hide data in the mesh for physics and advanced shading techniques. Those kind of cases makes it unavoidable that the body part as an example may have a chest, t-shirt and a jacket mesh covering the same area and thus increasing the overall vertex count.

Terrain meshes shouldn't have gaps between the chunks... dunno if it was your own or a pre-made system but it wasn't properly don in this case.This is even a perfect example when you don't want a gigantic mesh but instead several meshes... you don't want to waste resources on details that you can't see anyways... it is a lot easier to reduce the geometry in the mesh when it is separated into several objects, you just poll for all meshes that are at a certain distance and then run a quick algorithm to reduce it 2, 4, 8 times in size... it is now also possible to have a greater view distance

Longer vertex arrays also got a pitfall, they are longer and thus take more time for the graphics engine to search and traverse... the extra milliseconds that are lost every now and then will add up sooner or later.

Also, the future of computer graphics isn't more vertexes in the way you think... it is more vertexes through tessellation but that is handled by the graphics card and nothing that have a huge impact on 3D artists or their current vertex limitations.

Best example I could find during a quick search, know that there is better examples if you dig around:

@SpookyCat - Really sounds like some author of the importer treated all arrays like the vertex array and split them all up if they hit 65535 or maybe it is something funny with vertex groups going on?

 

You seem to miss the point. High poly count does not automatically mean to have a bad artist. When that would be the case then you would label all current top game artists as bad artists since the current games generation uses a very high poly count for its characters, compared to the usual 5k to 10k characters that you can buy at turbosquid or similar places.

When you need closeups then your geometry better does not look too blocky. And a terrain mesh (not a heightmap terrain) is such a case where you quickly run into the blocky look with just 65k tris.

Sure, i can create a level or a character also with 1000 triangles. But the best artist cannot make it as good looking as a 50k level or character. Detail can be done with techniques like normalmapping to some extend. But the best detail at a mesh comes from geometry. Guess what stuff like micro tesselation is good for.

What makes a good artist is to use as much polygons as needed, and as few as possible, given the limits of the current project. This could mean to have the almighty 1000 tris character, but this could also mean to have a character with 100 k tris or even more.

Graphics area evolves still heavily. Not long ago we had just 256 colours for the whole image stuff in a game. 8 Bit. Then we had 65k colours. 16 Bit. Then 16 million colours. 24 bit. Nowadays we are at 32 bit per colour channel. And 64 bit per channel is at the horizon. Nowadays PBR is the new holy grail, and so on.

Same goes for mesh size. Not long ago 1k tris was high poly for games. Then it was 5k, then 10k. Now we are at 50k ... . Same goes for texture size. There were times when you have put all graphics of a game at a single 1024x256 chipset. Nowadays you use a 4096 texture for just a face of a character ...

Would you use a game engine that uses 8 bit, means 256 colours, nowadays? Would you play a game like Assassins creeds or Witcher 3 with a character made of 1000 tris? I highly doubt so

We have the same limit dilemma for the meshes with the lightmaps in Unity too. The size is capped at 2048 since years. But using a 4096 lightmap runs just fine, there's a extension for that around. And the bigger size makes simply more sense in some situations, like for the shadows of the trees at a landscape. The heightmap size is also capped when i remember correct.

Unity should deliver freedom, not limitations. It's the artists decision where to set the limits. Better said, the target platform and your current project decides that for you. A game with a dozen 50k characters onscreen will most likely lag a bit when you try to play that game at a mobile phone. But might just work fine at a PC. It's all about the target platform and how many polygons just works. And as told before, polycount isn't the bottle neck anymore.

You can find an interesting read about poly count here. It's a bit aged nowadays. But nevertheless interesting: http://www.rsart.co.uk/2007/08/27/yes-but-how-many-polygons/

For example, 8 years ago, Lost Planet. :

Bad artists?

Indeed. And what do you do with a level mesh (notice that i do not mean a heightmap based terrain here) that has over 65k vertices, and where i simply don't need chunks for performance reasons? It gets split, and that means to have gaps. There is just no way around the floating point errors when you have several independant meshparts. And this results into visible gaps where the light shines through and the antialias fails.

Of course there are workarounds. The usual workaround is to extend the areas around the gaps, to extrude faces out of the involved edges, and bend them a bit backwards so that you have a X kind overlapping at the cutting edge. But that shouldn't be necessary at all. It's extra work. And it's a workaround, not the solution.

 

You can make seamless chunks. It's not always simple, but it's just about always possible.

http://scrawkblog.com/2013/06/04/massive-terrain-in-unity/
http://scrawkblog.com/2013/03/21/creating-seamless-terrian-tiles-in-unity/

 

Just to prevent further misunderstandings, and the third time, i talk about mesh terrains, mesh level geometry. Handshaped levels. Not heightmap based ones, not the inbuilt Unity terrain

Of course, everything is possible. I already named the workaround for the gaps problem. It's just the question if there are better/easier solutions around for the problem. The best fix for the 16 bit limit dilemma would be a 32 bit mesh component.

The question is of course how hard or easy it is to implement such a 32 bit mesh component in Unity. And how many years it may take.

As told, i have abandoned a project because it was ways too much effort in Unity because of the 65k limit. And you better don't hold your breath for promised features. That's why i'm looking for other solutions at the moment where i could realize my project. Unreal 4 for example doesn't have such a 65k limit anymore afaik.

The question is, does Unity 5 still have this limit. That's unanswered. Maybe somebody with Unity 5 Beta can answer this?

 

Every engine has limitations, so long as you don't have full source access. Unfortunately, sometimes an engine with limitations most meets your needs in other respects, and you wind up spending more time on workarounds than development. Still beats writing an engine from the ground up.

 

How many vertices do you think are in this mesh? How many seams do you see? It's not unity terrain.

 

But it is also not a closed levelmesh like inside a castle neither. Nothing where the sun could shine through the seams. What you show here was based at a heightmap at one point. And a closed levelmesh like a castle has lots of such seams, while you stumble across the seams at your shown terrain just every now and then. Last but not least, for this kind of terrain it makes more than sense to chunk the parts for performance reasons. But not for a castle level.

And again, i know it is possible, but to make the seams bulletproof is pain in the ass and lots of work. Work that would not be necessary when there would be a 32 bit mesh filter. And for special things besides such levelgeometry it is too much work, not worth the effort. Unity is behind here.

 

Or you simply migrate engines. A little searching seems to indicate that Unreal 4 does not have this limitation. I don't want to turn this into a comparison thread, but at some point Unity will have to step up and provide support for more vertices.

 

Maybe an optional 32-bit int index could be a future Pro-only feature.

 

Maybe this is better then:

Or maybe take it one step further and build something like this:

Infitie worlds must be impossible with 16 bit limitations

 

Not really better, sorry. Still no closed levelmesh where the sun could shine through the gaps in the level geometry as it usually does then without a workaround. It's not about infinite levels. It's about the 16 bit limitation of the mesh component, which is in the way here and there.

This thread starts to make me heavily scratch my head why the 16 bit limitation of the mesh component gets defended so hard here. It's a limit. And a limit is limiting as the name says.

And to repeat me again, it is not the point what is possible with 16 Bit when you use the right workarounds. But the point that several tasks would be much easier or even possible at all with 32 Bit. Have fun with mesh operations that goes across several chunks for example ...

And as told before, and just to repeat me again and again (i don't give up hope that it gets read at one point) , Unity should offer freedom, not limitations. Unreal 4 has 32 bit, Cry engine has 32 bit, Unity has 16 bit. Unity is behind.

 

@Tiles - Doesn't matter if it is 16, 32, 64 or 128 bit limitations... sure, Unity can increase the limitation but I honestly think they got much more important things to work on as a 16 bit limitation isn't even worth shrugging at...

Instead of trying to force a technical change to solve your problem... I would ask myself why so many others aren't even bothered by it? The best part of the whole discussion is that you will end up at square one the next time you try to top yourself with an even bigger, majestic chunk of mesh and need even more bits...

Just to be fair, mesh operations that span chunks is an everyday thing with voxel engines and that doesn't scare me one bit... sure... I might scratch my head if I do a poor implementation but that is completely my own fault, not the game engines or computers Heck, even regular games got their own version of "chunks" that you have to deal with, one famous type you might know about is called octree's...

Every engine offers both freedom and limitations in their own ways

 

I don't know how much more work it would be for Unity to maintain 2 different systems or even possible with their current implementations. It does not sound a good idea to just switch to 32b if the current problem affects only minority of user base and even then it is probably possible to overcome by different visual or technical design solutions in most cases.

Unreal 4 and Cry Engine are not exactly lightweight engines.

 

That's true. The biggest difference between AAA games is how badly the customer gets screwed over by the integration of in house DRM of the publisher

Ah, I just got back from my little 2 month journey of UE4. It would seem Unity is the better environment for me. Never got my free source access from github (applied in November btw, damn they are backed up!) and as nice as it looks, I'm not one of those graphics > gameplay weirdos. I can get started faster and accomplish more in less time with Unity, and it's got a head start on my VR tool of choice, the stem! Unity may cost more but it's just too good to leave.

Also, why is this an issue, people? It's not like the model breaks and unity crashes, the model gets split into pieces. Why can't you just model and rig the model in parts? If they move together, people won't even notice!

 

Well, @Tiles says his terrain ends up with cracks. The vertices across the sub meshes are meant to be identical, so I suspect it's when the terrains end up with different levels of detail, so one side has a straight edge between verts, and the other has an additional vert put where the terrain engine thinks the terrain would be based on the sloping of the terrain.

 

Also re: limitations: why does it all have to be one mesh? Why not just import two? do your characters need to be 65535 up close? If so it'd probably be a game industry first. As for a building, or terrain, that can be split up nicely too. I'm pretty sure it's possible to go full movie quality with this limitation, and if it gives us more speed, then so be it.

 

Just to be clear, I was never defending the limitation, just stating that all engines have limitations. It's just something to consider when deciding to use a particular engine for a particular job. UE4 has limitations. Not this same particular limitation, but the limitations are there.

 

It does matter for what i wanted to do. Unity is technically behind here, and made my life too comlicated. So i stopped the project, and look for alternatives now.

That's one posibility. In my case it was clearly a floating point problem not a lod problem. The vertices didn't match in all cases after import. Which ended in visible seams where the light came through.

And just to explain it once more: it is not a terrain thing. We talk about the 16 bit limitations. A levelmesh is just one case where this could disturb. It doesn't necessarily have to be a terrain.

Fair point. But there is clearly a resistance against an improvement here. And i wonder where this comes from

Unreal 4 and Cry Engine uses 32 bit nowadays. That's the direct competitors. Now why didn't they stick with 16 bit when all is fine with it?

Of course, every engine has limitations. And the art is to get your things done, even with the limitations. It's usually not a problem as long as you can work around in a way that doesn't bother you this much that it is wiser to switch the engine. The right tool for the right job. Unfortunately i have reached this point here.

Dunno how often i have repeated it now. But just for the sake to repeat it one more time ^^

Because it CAN produce gaps with several submeshes. Not necessarily, but it can happen. Happened to me.
Because it CAN cause shading and AA problems where you need to work around. Happened to me.
And because it's more complicated to work with chunks when you could work with a single mesh. Not impossible, but more complicated. Under special circumstances not worth the hassle because it becomes too complicated then. Happened to me.

And to repeat this point also: there are situations where you even need chunks for performance reasons. But that should be the decision of the artist or programmer. Not a hardwired limit of the engine.

 

This pretty much sums up the argument I thought was taking place. Hardware will always have limitations, and chunks are the best way to handle those limitations. Whether that's now with chunks of terrain with 65,535 vertices or in the future with chunks of terrain with 9,223,372,036,854,775,807 vertices. The only decision the artist / programmer is making is whether or not they're going to be unreasonable.

It's the same thing with unity using floats for transforms. Using doubles instead to fix spatial jittering only puts a band-aid on the underlying problem of reality - no system is ever going to overcome the problem of dealing with infinity. The answer is always going to be chunks and a bit of woo

 

Fair points all. But you wouldn't work with 256 colours anymore, would you? Hardware evolves. And so should the limits of the software

 

Too lazy too read everything, but Unity cannot handle more than 65k vertices per mesh automatically? Really?

Even Ogre3D does that automatically for you. Let's not even speak of other engines.

Also Assassins Creed models are low poly because there are many on screen at the same time, sometimes 30 or more. Look at fighting games with just 2 models on screen at once, very different numbers.

 

If you don't bother to read the thread then don't post cause everything else you just commented was wrong or out of context.

 

I read enough of it to get that they split it. That is smart, but could be done without the user knowing or caring, so do it transparently for the user (like others solve this problem).
And why not add an option to use 32-bit buffer in this case if the user knows what he does?

 

Did you try to use the same origin for all the meshes?
If all the individual meshes have the same origin, e.g. (0, 0, 0), all the vertices from the different meshes would have the same "imprecision" and as such should fit perfectly together. But just to make it clear, I have never tried it out.

 

Except he said he's using mesh chunks, not the Terrain system. My first guess is mesh compression.

Like others, I suspect that there'd be solutions to Tiles's problem that doesn't involve simply brute forcing larger data sets. Also, as Deon Cadme says, brute forcing larger data sets is only a partial solution when it comes to "infinite" worlds, since it'll just push the issue out further. (That may be good enough, it may not.)

Not only they can be split up, they almost always are. Take a character, for instance - how often is a high-quality character all the same material? You're typically going to want at least a skin, a clothing, an eye and a hair material, plus often other materials for accessories or detachable bits. The head will often be separate so the face can be animated. So on and so forth. So even if you do actually need a character with, say, 256k verts, once you split that over the materials and sub-meshes you're likely to want anyway it's unlikely you'll be hitting that limit.

The same applies in other areas, too. If you've got a building with a million verts is it likely to all be the same material? And even if it is, wouldn't you want to cut it up a little to help out with culling in the rendering pipeline?

 

That's of course also a valid point. But that different materials splits the rendering into different drawcalls is a different chapter. The 16k limit is about the pure mesh data. 32 bit can avoid gaps and shading problems, it's one mesh then. And you can work at the whole mesh data without fighting with several chunks for that.

The final solution for my next project is to use another engine now, and leave Unity for the told project. I want to deal with meshes in megapoly range in worst case. A single mesh makes my life for that project this much easier that it's well worth the change. Just not sure yet which one. Still at evaluating the posibilities.

Nicest solution would be of course when i could stay with Unity. Here i know how everything works. And another engine might bite me at another end. That's why i wanted to wait for Unity 5. But it seems that Unity 5 still comes with 16 bit.

Of course i did. I did nothing wrong. It's just that i got hit by a 16k limit, in this case floating point errors that did sum up, and which needed the usual workarounds then. As told, it's a common technique to extend the geometry at the seams a bit to close such gaps.

 

I know it is common to close seams like that. Usually the vertices don't match exactly when they are relatively far away from the mesh's origin which is due to numerical issues caused by the vertices. If a mesh has the origin (0, 0, 0) and a vertex at (1000, 0, 0) and you have another mesh with the origin at (10000, 0, 0) and a vertex at (-9000, 0, 0), such that it matches the other vertex, this can lead to numerical issues and having the side effects you mentioned. It gets almost impossible to match the vertices if scaling and rotations are involved.
However, if both meshes have their origin at (0, 0, 0), both vertices will be stored as (1000, 0, 0) and match perfectly together from a numerical point of view.

 

They all had their origin at 0/0/0, and were scaled and rotated equally

My guess is that the inaccuracies appeared while im- and export. I worked with the chunks in my modeler already.

Anyways, while it is somehow interesting to know how it can come to those numerical inaccuracies, the cause is not this important really for our discussion here. Important is that it can happen. That it is more complicated to work with chunks than with a single mesh. That you may need workarounds. It's simply an example where the 16 Bit limit can bite you.

 

Using more than one mesh to split a huge mesh up is a standard technique, even without a 16 bit limit. If a scene needs to be optimized, those kinds of huge meshes are often split up. So it is very likely that the issue will bite again, with or without the 16 bit limitation.

However, if I remember correctly, Unity has planned to improve the mesh related functionality for 5.x. I am sure the 16 bit limitation will be considered.

 

Yes, i know. And we all know the workarounds. But as told numerous times now, that should be the artists decision when and where to split. Makes no sense to split a mesh that is just 5k above the limitation for example, and cause one more drawcall by that.

5.x? Or more like with the new UI, which was promised for Unity 3? ^^

While promises are a nice thing, you better never rely at promises at software development. They may or may not be fulfilled

 

What I meant is that getting rid of the 16 bit limit won't magically resolve the problem you had in general.

I didn't write anyone should rely on it and didn't write they promised anything. Another interpretation could be that it is unlikely they are going to deal with the 16 bit limit before the work on those mesh improvements starts.