65535 vertices limit

What it would do is allow larger contiguous areas of the same material, so that there doesn't have to be as many seams to be able to cause precision errors. If the world is small enough that the seams don't fall within it's boundaries it's a practical solution even if it's not a theoretically perfect one.

What? Yes it does, especially in that case. You're talking about doubling the memory spent on indexing for a minor increase in required capacity, rather than just splitting the data over two containers and adding very little. A "draw call" isn't the plague some people here seem to think it is.

The fact that all of this discussion centers around a single example also suggests to me that it was a reasonable call. The occasions where it causes a practical issue are very few and far between, yet it's saving memory with every single mesh that's loaded.

Perhaps a solution would be to build in a "DenseMesh" and "DenseMeshRenderer" in Unity that uses a 32bit index, and add an import setting that uses those rather than splitting, along with docs saying to only use that setting where visual issues are observed with the defaults. That way the default behaviour is no different, and we don't lost its benefits, but for those people where a larger index/less splitting is a practical solution it's there at no cost to the rest of us.

Out of interest though, @Tiles, you definitely had mesh compression turned off throughout your entire pipeline? That regularly messes with seams.

 

Memory is cheap. Drawcalls not

Two examples. One was the terrain, better said a level geometry. And this one happens often enough that you have official workarounds for it available. Reasonable enough that every somehow experienced graphics artist knows about the issue, and how to fix it.

The other was my abandoned project because it became too much effort to work with chunks. It's a showstopper for what i wanted to do.

So we have a practical example where we need workarounds. And we have an example where it was the end of the project. At least in Unity.

Sorry, i thought i had answered this one already. Yes, off. That's the first thing i do at importing, turn that nagger off. I still don't understand why it has to be on by default. It's a nasty default.

 

That's kinda wrong statement or view for game development. One or few extra drawcalls that *might* happen in certain views vs permanent memory use that takes away from everything

Even mobile devices can do hundreds of draw calls with decent shaders but the memory is scarce there.

 

There is nothing wrong with it just because it is not your point of view. When you have enough ram available, and you can save draw calls by using this memory, then it's the better way. It's the draw calls that influences performance. When you can reduce the draw calls then your game will run faster.

Ram, while still a limiting issue, shouldn't be the problem anymore. Mobile devices three generations back is not the platform to measure at anyways. Unity is multiplatform, mobile phones not the only target platform. And gaming usually uses always the actual hardware. Hardware evolves heavily. Game development evolves heavily. And so should evolve the limits.

 

I'm not sure if that is an artist view or developers point of view

When we are talking about few draw calls that might happen with an edge case models versus constant memory use that potentially takes away from all aspects of game it matters on all platforms if you want to have maximum customer base. Note that mobile was just an example as there are other platforms too like consoles or webgl.

I'm not against having two mesh filters at all if its possible but doubling the existing one for everyone just cause of some rare situations that may be probably solved my artistic tricks or other improvised hacks is a not that good idea at least yet in my opinion.

 

Sure, everybody has his own view at the things

Where i still disagree is that it is a "rare" case where 16 bit is limiting in the one or another way. As told, it is common enough that official workarounds exists. It's just that people are used to the workarounds, getting told "that's the way it is, deal with it".

Sticking with the 16 bit mesh component only is imho no solution neither. Best solution would be to have both when possible, and let the programmer / artist decide what to use. Hm, the direct competitors Unreal 4 and Cryengine uses 32 bit now. Would be interesting to know how they deal with it.

 

Well maybe @Aras or someone else from Unity could maybe share some info if they have one.

UE 4 and CryEngine are also known to have highest spec requirements when it comes to engines and target platforms

 

I would be interested why most of you defend this limitation? It does not matter if there are workarounds or not as this does not change the question:
Why is there still such a limitation?

What I found:
WebGL currently supports only 16-bit index
Open GL ES 2.0 compliant hardware may support only 16-bit index

I guess for desktop it doesn't make any difference nowadays if you use 16 or 32 bit indexing but I could be mistaken.

 

Like I said, you're talking about increasing the memory required for all models. Also, individual draw calls are plenty cheap, and I wouldn't even take them into consideration where you're talking about them averaging over 30k verts anyway.

Yes, overall draw calls are in important performance metric, but this drive some people seem to have towards single draw calls for everything regardless of what it is or where actual bottlenecks may be is irrational. Adding one draw call to an already dense mesh is not going to ruin your performance, and taking the rendering pipeline into account chunking could potentially lead to improvements of its own.

Either way it's not a regular occurrence. General use of meshes sub-65k polys and/or where the splitting makes no difference are exceptionally regular occurrences.

But this has been addressed. There's a design goal of reducing memory usage, raising the limitation globally would double the indexing memory used for all meshes, and the vast majority of meshes would see no benefit from it.

I do think that an alternative system for large/dense meshes would be a good idea, though, because then the workarounds for this wouldn't be required and the solution wouldn't force a cost on the people not effected by the problem.

 

Memory may be cheap, but memory bandwidth is much less so.

Why would all models have to use the same memory? Why not support both 16-bit and 32-bit with the engine optimized for the former?

I'm in favor of supporting 32-bit meshes if it allows me to reduce development time. If more performance were needed the mesh could always be broken into 16-bit chunks.

 

That's a great idea.

 

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.

 

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.

 

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

 

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?

 

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

 

http://forum.unity3d.com/threads/me...tices-at-the-moment-or-is-it-triangles.170030

 

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.

 

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

 

Apologies, when I wrote that I was under the (mistaken) impression that you wanted to give developers the choice just by changing from 16 to 32 bit indexing.

 

No, it is really not my intention to take away the 16 bit mesh component. I want an additional 32 bit mesh component, not a replacement for the 16 bit mesh component really. It's of course up to Unity how to solve that problem technically.

Just in case, there already exists a vote at Unity Feedback. Please support the idea of 32 bit mesh indexes:

http://feedback.unity3d.com/suggest...ffers-and-larger-that-64k-vertex-buffer-sizes

 

There really shouldn't be a need for new component (which I think would be very bad), or any change at all from the user perspective. It really should just be code in Unity's end that switches to a 32 bit buffer allocation and copy methods when needed. It's kinda odd to me that this problem has gone on so long, I wouldn't be surprised if it has already burned more of UT's dev time just responding to and documenting the limitation than to just fix it, much less the time it's burned for all it's users that have bumped their head on the limit.

The use cases where you are bumping your head on this limit AND targeting hardware that doesn't support 32 bit would be quite rare, I'd think. It's true that easily 95% of use cases don't need it, and for those cases, nothing changes, but for the things that need it adding 2 bytes to the reference of a vertex that's likely well above 30 bytes already is not something I'd characterize as 'a lot'. For me, having to write code to get around these limits is a lot worse than adding up to 10% size to up to 5% of items (which is hella generous since <1% is more likely, and we're assuming the alternate solution is 'free') and making their rendering potentially sub-optimal.

Ultimately, yea, I'm lazy, but I've got additional reasons I don't like adding code .

 

+1 Spot on

 

Cool, although I'm more interested in seeing Unity spend time increasing performance and stability. 32 bits does not increase performance or stability. It also isn't stopping anyone from doing things right now as far as I understand?

 

I'm all for improving stability, performance in Unity is I think pretty decent (certainly not a gating item). It is unwise to think it isn't stopping anyone from doing things, you can't waste a devs time working around an issue and think you didn't stop him from doing something. Dev time is the most important resource for average Unity users, I'd think (certainly is for me). I do not want to see this fixed because it's a gating issue, I want to see it fixed because it's a very high bang-for-the-buck fix, far higher in my mind than the vast majority of things I see in patch notes in recent years. And it's certainly a red flag that makes Unity look bad.

 

Well you'd be wrong. You're entitled to be wrong though.

I'd have expected poor stability and working on pointless things to make unity look bad.

The fact is there aren't any games in general which require a single mesh to be that many verts. On the contrary, 99% of AAA games will fit fine within 16 bits, regardless if it will or will not support 32. This is because less verts are generally preferred for performance.

I can see it affecting niche situations and things like arch vis or bespoke stuff, but for pretty much all of Unity's main users, this is not a limit.

Most people don't know what they're doing when they're making games so they assume 65k verts on a single mesh is clever.

 

Really... wrong? I'd say features your competitors have and you don't should always be red flags, but then, I try to evaluate software objectively, I'm crazy that way.

Agreed, I think it's perfectly fair to argue that no game needs it, potentially till the end of time, but that was never the point, not sure why this is so hard to understand (technically... maybe we only 'need' 2-bit indexes ). It doesn't matter how many times code handling an edge case is run, what matters is a developer had to deal with the edge case. And even if only .1% of Unity's users ever had to deal with it at all, that still seems way more than enough to fix it (again, this really shouldn't be a hard fix). Do not assume that because it hasn't been done it's because it's hard to do, just means people in charge haven't cared enough.

Yes, people can be prone to bad assumptions. From the use cases here, you drew the conclusion people were trying to be 'clever'? Cause I'd bet the general reason, like me, is that they're taking the path of least resistance and running into the limit because they're just creating larger data sets than you. You can view this as inherently wrong or borne of ignorance, but I do not, and I still think it's better fixed at the source. And again, I do not think it's a big deal, hardly the end of the world if it's never fixed, but like daylight savings time, I don't think I should have to deal with it and I'm surprised it's still a thing.

 

Hmmm.......

 

Well there is a place for it, and I'm not saying it's wrong to support it, only that it's hardly the reason Unity looks bad. Unity looks bad for reasons like the ui spawning tonnes of garbage every frame with drop shadow on text, or looks bad when it's networking generates garbage. And looks bad when garbage takes too long to collect.

Those are typical problems facing people, problems that ruin VR, and so forth (beyond making small demos) long before meshes being > 65k verts makes it look bad

 

As has been explained by a developer, different platforms have different behaviour. Unity supports 20+ platforms, so something that would seem a simple fix in a small project could be a completely different matter for something on the scale of Unity.

And would you really rather them spend time on something that one in a thousand users run into instead of things that improve use or extend capability for the majority of their users?

 

http://unity3d.com/unity/industries/aec

Hey guys, Unity is not just for making games. Even their website said that they are also for application. I know Unity can automatically split a high poly model to several part. But there also is chance a developer need to generate a dynamic high poly mesh. If Unity want to target ARCHITECTURE, ENGINEERING AND CONSTRUCTION, they must change the 65k limit

 

My day job is making "not-games" with Unity.

Absolutely, I've had to work around mesh limitations myself when dynamically creating stuff. (And that was for collision meshes, where the limit is much lower!) Can you give an example use case where 65k chunks can't achieve the desired goal?

I agree that not having to split stuff into chunks would be nicer. Still... when we do stuff like arch vis, one of the major parts of the job for us is cleaning up the crazy high poly results that CAD packages and the like spit out. They're simply not optimised for the same type of real-time interaction we're looking for, so even if we could import them as-is and not run into the 16bit limit I'm not sure we'd want to. Our use cases aren't necessarily everyone else's use cases, though - hence the question.

 

I wonder how chunking would work for a single large mesh. Sounds gross.

 

What's stopping someone from subdividing their meshes?

 

I actually have made a prototype "game" that has to deal with 3D scan model (so yep it's very high low). However it's just a prototype for a concept, so I was using a preset model, which Unity can split it automatically. With all depth cameras like kinect and device like project tango, I think real time 3D scanning will be a upcoming feature.

Have you seen some applications that just display a model in the center of the screen?

 

Only 3D model viewers

 

for some exhibition or education set up. the client may like to have a multitouch screen for use to view a 3D model. They usually just send us high poly models (which was modeled for animation or CAD i guess). And sometimes the client want the app load models from a folder so that they can add more models later without we doing it with Unity

 

Absolutely. Still, that's another case of the source data needing to improve regardless of whether Unity is limited to 16 bit indices or not. Same deal with CAD data, which I think Unity are already working on.

 

Of course that would depend on the damage ratios involved, but making an assumption about what you mean I'd say no. But that a poor characterization of what I'm saying, I'm all about saving overall dev time and reducing bugs, and this simply seems like low hanging fruit. Surely you wouldn't say the average patched item benefits most users? I'm saying I have implemented such support in a smaller engine (nobody here, including UT devs, have likely previously worked on an engine near as large as Unity), and that experience and my instincts tell me it's better to fix it. The engine is closed source, so accurately evaluating the benefit is not possible.

I agree completely, but these things you describe seem WAY more expensive to fix (or are already being fixed), or have existing 3rd party solutions. But I'm sure if I'd bumped my head on those limits, and also had implemented the solutions easily before, I'd be championing their fixes as well.