Hi All,
Is this the max limit per scene or per object. I’m a little confuse with this one. tried searching it here and in the docs but cant find anything.
Thanks,
Ray
It’s a per mesh limit.
That was quick, thanks,
Ray
65,000 per mesh is roughly 20,000 triangles. How does this compare to the average human figure/mesh?
64k vertices is not 20k triangles. In most real-life models (except a cube :)) majority of vertices are shared between several triangles.
Good point Aras. Take a simple cube with each face being 2 triangles. Wouldn’t that have 8 vertices for 12 triangles? Although a simple example, it shows quit a difference. For a pyramid you would have 5 vertices for 6 triangles and for 2 pentagrams connected by flat sides you would have 10 vertics for 16 triangles. I would guess that in a normal model a great majority of triangles would share all 3 vertices.
When will we get rid of the 16bit limit?
Yes. Cubes and pyramids are the almost the worst cases (while something like a grid or a sphere being the nice cases - almost all vertices are shared). Typical game models usually have about the same number of vertices and triangles.
The average human character these days is roughly 5000 polys, assuming there would be about 15-20 guys on the screen at once. Less guys, more polys. More guys, less polys.
For example, a soldier in our engine has 7656 polys with props, but only 4049 vertices. It is assumed that there would be 15 or less of these at a close enough distance to use this LOD.
When will we get rid of the 16bit limit?
<<<
I still wouldl like to know if we could pass this border.
bump
I’ll run into this problem any time in the future, so I’d really like to know if there’s a way to have more than 65k verts in your object.
Until a few weeks ago I used Quest3D for almost all my realtime 3d jobs and one client needs me to create an app that demonstrates his products from time to time. Those objects are very huge in their poly count, since they are very detailed aviation parts like actuation systems and clima packs. Despite of some screws and smaller parts it’s absolutely usual to have poly counts up to 300k, sometimes 500k - per shell, that is. The complete objects may sometimes have up to 1.5 million polys. So I desperately need a way to surpass the 65k vertex limit in order to draw objects with that many polys. I never had any problems with this in Quest3D, it seems to handle this barrier internally, though I don’t know how exactly. All I know is that DirectX MAY have the same 65k-barrier, but I’m not sure.
So, my question is: Has someone ever successfully cracked the 65k-barrier with Unity? And if yes, can you point me into the right direction? I’d like to avoid having to split up the larger objects by hand into many smaller ones - especially because I’d like to preserve smooth edges on the then resulting border edges.
Any input will be highly appreciated.
AFAIK 65K is a hard limit for most game engines. I’m working on reducing a SolidWorks model right now (started at about 400,000 vertices, I’ve got it down to about 50,000 at the moment and still working on it). We typically are able to get them down to 5-10,000 when we’re done, but it takes days to get it right. If there’s a shortcut to this whole process I’d sure like to know what it is. We’ve tried mesh reduction software and it’s pretty worthless.
How in the world does Quest3D do it I wonder? Perhaps it breaks larger meshes internally? How do slower performing computers handle this?
When hardware starts to support vertex index buffers with more than 16bit indices.
Afaik all modelling apps that go higher don’t use single meshes.
To get something like this under control, Unity would need to enforce the iPhone Cull system to be used on any model thats larger (hard, troublesome, annoying for designers) or at least, Unity would need to have standard capabilities aka SceneGraph (quad / oct tree) present that splits up geometry into sub geometry for collision, rendering and handling.
Reducing a model is absolutely no option for me since the high level of detail is crucial for the overall look and feel.
Maybe you’re right that Quest splits the objects up into sub-objects. I’ll need to have a look into this.
A word from the Unity dev team (especially someone with deeper knowledge about the inner workings of Unity concerning vertices) on this topic will be appreciated as well.
Edit: No, Quest doesn’t split the objects up in pieces small enough to display. I just read about this in the Quest support forum where one of the guys from Act-3D wrote that they fixed this problem by switching to 32bit to store the vertex data when needed.
Now here’s the million dollar question: Would it be possible to implement that in Unity as well? Switching to 32 bit when needed would make room for up to 16.7 million vertices. Sure, such a high count would make no sense for games and such, but in cases like mine it’s absolutely crucial! I hope the fathers of Unity don’t see this software as a game engine only… 
Without seeing your model I’m only guessing, but in our case we are able to maintain a very high level of quality and still get the poly count to less than 10K. It isn’t easy, and it takes a very good artist a lot of time to do it. But with very good texture and normal map painting skills you’d be amazed at how good a quality we are able to achieve. The model I’m working on right now (I do most of the grunt reduction before sending it off to the artist) and I’d guess half the polys aren’t even seen. Just deleting those parts that are hidden by other bits of mesh has got me down to about 10% of where we started.
But believe me, if there was an easier way to do it I’d be all over it!
About the way to change that barrier: Take a look at my previous post. I added some lines, but you were obviously faster. ;p
And about reducing the objects: I hear you. But it is still no real alternative. In most cases I’m the only artist on the project and we are talking about production times of max. six weeks. In that time I have to program the engine behavior, create the front end and interface design, clean the poly data I received from the CAD department (polygonal exports of Catia and, I think, Pro/Engineer) of that client, create animations for cameras and objects, shade objects, etc.
And we’re talking about roughly 30 to 40 objects per job.
I just don’t have the time to comfortably reduce and normal-map those amount of data.
And exporting them already reduced out of Catia and Pro/Engineer is no option as well. We already tried that and the result looks not nearly as perfect as it does the way I want it to look.
The easiest way would be to expand the addressable space to 32 bit in the cases where it is necessary. That would still save memory in cases we don’t need 32 bit, because those objects would still use only 16 bit, and it would break the very low 65k barrier as well. Plus only ONE person has to have his head broken over this topic: The guy implementing the switch to 32 bit - instead of every single Unity user.
Maybe this would be a great addition to the list of new features released with Unity 2.2
Just split the mesh into submeshes in the engine would be simpler and end with a broad support unlike the 32bit vertex adressing
Yes, being able to take engineering models and display them directly in a game engine would help us enormously. Fortunately I don’t have as many models to do as you so I have a bit more time to dedicate to each model.
Another thought though is to break up the mesh in your 3D app. The mesh I’m working on right now started off as a SolidWorks model. After exporting and converting the mesh it ended up being about 400K vertices. Although it imported into my 3D app as a single mesh (I’m using Blender BTW) it already had 16 separate materials. It would be a fairly trivial task to pick a material in Blender, then have it select all the polys of that material and then save it as a separate model. Then I’d have 400K divided by 16 which equals 25K vertices per object. Unity should be able to handle that (although not very efficiently). I just spent about an hour with the mesh and reduced it down to about 20 parts with a total of 80K vertices by deleting parts that are hidden by other parts (like the shafts of screws, and such). I tested it and it loads and runs fine in Unity on my machine. If you wanted to use Unity, then this might be an option for you. Otherwise, you might have to find another way.