Meshes may not have more than 65000 triangles at the moment!

Hi

The subject of this post is a message error of the Unity Console.
PLEASE, need support for MORE triangles than 65000!
Now I have to reduce the triangles with another application that destroy all the UV mapping and RE-UVMapping again everything for this great limitation to 65000 triangles only.
Please, support more triangles now
Thanks.

 

You mean vertices, not triangles...the triangle limit is 32 bit. But anyway, lifting the vertex limit would require vertex indices to use 4 bytes instead of 2, which probably won't happen for a while. In the meantime, use a different app that doesn't destroy the UV mapping when reducing polys. For example, Blender has a mesh reducer script that keeps UVs intact.

--Eric

 

Or just split the mesh up into several smaller meshes.

 

I am not sure if you really want to make GeForce 7 generation the minimum requirement, double the VRAM usage of all meshes (as all is stored as int instead of short) and get the related performance hit.

The way to go is really splitting up the model. Would be nice if Unity did that itself on import, replacing meshes with too much through reasonable OctTree represented submeshes. (perhaps Umbra will adress that with Unity 3 Pro automagically)

 

Interactive rendering rarely has that high of a polygon count per model. I am curious as to what you are working on that requires such resources. Typical polygon counts for high detail character models are rarely over 10,000 polygons(triangles)[I think that number is still high for most games even today]. Higher polygon meshes than that are usually only used for generating normal maps.

 

Rarely, but not never. For instance Racing games often have cars well into the six-figure polycounts nowadays.

 

Right but these cards don't use models with a single mesh. There are many submeshes for the required damage models.

Also there is no proof that they don't split them up as I highly doubt that they use int indexing due to the consequences, aside of the DX10 - DX11 engines where its granted to be no problem.

 

Yes, indeed that is why I chose the word RARELY :wink: . If only DX10/11 have int indexing, then no console game has that high of polycount per mesh. PS3 uses OpenGL 1.1 and 360 has dx9.0c(wikipedia.org) and Wii, yeah we know thats got low specs .

However, I am not a graphics programmer, so I know nothing about how its actually done. I do know that polygon counts that high are rather on the high side. I guess it depends on who your target market is.

I would like to note that the user asked for this feature because he can't decrease his polygon count without ruining his UV maps. Thus he probably wont be using a LOD system. You would need some kind of extreme LOD system or a super powered GPU($700 NVIDA/ATI card anyone?) to use such models in an interactive way on most machines.

He needs to chop up the model for best performance and create a LOD system if he chooses to have many high polygon objects on screen.

 

Couldn't Unity 3 give the option of using a raised poly limit?

 

To be clear, it would require the support of 4 byte indices, so wouldn't have to increase the size of anything not requiring it (not that memory consumption on that data is a big deal anyways). IMO it should be fixed on next version, since it seems a bad limitation for a modern engine.

The consequences of 32bit indexing are negligible, of course, the consequences of a mesh big enough to need them, that's highly subjective. In the end, supporting the ability seems a no-brainer to me, it's nearly trivial in my experience, and might make the lives of some people easier, and it's not hard to imagine it stopping someone from using Unity completely.

 

Yes, because it is sooo difficult to open that model up and split it. Oh, I am feeling the pain. My rist just jut cracked...

Sorry.

I don't think so.

 

Guess what, not everyone develops the same content you do and in the same way. In Max, I've seen no good way to automatically split objects, and if you're building things that use modifiers that means you're having to break the model manually every time you make a change to underlying elements, and smart developers consider those pointless time-sinks when picking an engine (not to mention, that limitation would be a big red flag, I'd assume other similar limitations). I know of no modern app besides Unity that has that limitation, so it's reasonable that 3D apps don't try to make it easy to deal with it.

I support Unity, but I don't stick my head in the sand on every shortcoming it has, it's not productive. The whole point of licensing an engine is saving time, so don't tell me a problem isn't a problem just because if you spend time, you can get around it.

 

Are you sure your model is targeted at realtime gaming at all if you have more than 65k polygons on a single material?


If such a thing is a red flag to you I would really love to have your money tree if you rate such a feature as reason enough to invest 100 grands and more per title in a technology when a simple export script could do all the work (export multiple models, one per material and then combine them on the Unity side into a single prefab again)


That does not mean that I wouldn't like to see Unity to generate OctTree representations out of imported meshes with reasonable sizes for the assets provided.
But its really by far no deal breaker, as it is trivial to work around it if the models were created for the purpose of gaming and not just render models one tries to export into a realtime environment which in no way deserves support as its a plain stupid thing and the earlier people learn about that the more time your devs can save when they struggle over FPS stutters caused by such errorous models

 

It might be a uneeded limitation tech wise? and I guess that there could be rare times where you go above the threshold. But splitting up a big model usually isn't really a hassle but more of a convenient way to work even in Max from my experience.

A house or a car for instance consists of lots of elements that are separated from each other and if so the work of splitting up the model is a matter of seconds. Select element, detach, done.

And as being said if you have models that detailed where all the vertices are connected and you use a single texture its gotta be a huuuge texture to motivate that amount of meshdetail on it. So maybe looking over the way you create you real-time models would be a better thing to do.

 

WE ALL PRAY, THAT UNITY 3D VERSION 3.0 WILL HAVE REMOVED THAT NASTY LIMITATON!!

 

pretty surely it won't because I doubt that UT intends to write on the page: You need a Geforce 7300 / Radeon 3400 or higher with at very least 128mb, optimally 256mb of VRAM as min. Intel is not supported. and that would be the consequence of that step.

 

Very funny! We don't have that limitation in other 3D tools like Cinema4D, Lightwave and co. They also have to displays meshes with much over 65'000 polygones via OpenGL on older grafic boards...And nothing speaks against to have the choise, if we want use such a high number of polygones in our Untiy 3D presentations or not!

 

they commonly don't do that no.
They use many meshes internally to manage the stuff (octtree and other spatial tree structures to reduce the amount of rendering especially with stuff out of view)

Thats why I would like to see something similar happening with Unity 3 too that imported meshes are processed and replaced by internal octtree or k-tree repesentations of the mesh.
But who knows, potentially that is going to happen anyway as part of the work to be able to integrate umbra in a meaningfull way.

I think you are not getting the fact that this is nothing about UT not liking the fact but the hardware not doing so when they just replace the short indexing on the meshes (-> gpu representation) with ints.


as for having the choice: I agree on that partially but that partially is restricted to the deferred renderer in unity 3. That one guarantees that mid to high end hardware is present anyway.

but as long as you want to be able to switch the renderer, using int indexing isn't an option at all because on all cases where not the int indexing is used the models wouldn't show at all if they have more than 65k vertices / triangles.
that simple it is

 

I've only hit that limit when importing insanely inefficient models.

Or models/environments that were created in Unreal that we exported and tried to reuse in Unity.

Yeah, Unreal doesn't do pretty things with meshes.

 

I'm not sure what your point is here, are you saying that it's an insignificant limitation because very expensive solutions would fix it? I mean, there are free solutions that do it, in fact, no solution comes to mind that even has this limitation, so I'm not sure why you'd assume that only expensive options are available besides Unity. Seeing this as a limitation has nothing to do with your project's budget, but your project's technical goals (or are individual polygons taxed now? ). HW from half a decade ago could handle more than 65k polys on a model, just depends on how many you're drawing and with what effects, assuming everyone's doing the same types of things seen in the average game is unnecessarily limiting (and I'm assuming that more than just game developers would be interested in the engine).

When evaluating an engine, if I couldn't even get a rough prototype going without spending a good deal of time circumventing an engine specific limitation, that'd certainly keep me looking for other solutions, even if in the end I came back and dealt with the limitation(s). In the end, as I said, it should be VERY easy to fix, and seems long overdue these days. You're talking about something that should take a coder a day (assuming an average code design), we're not talking about a lot of work here, seems time well spent. Unity's a very cool engine, there's just no reason, IMO, to run into this limit (other rendering limitations I have a beef with are FAR harder to fix, this is easy).

 

They should let us have 65,000 polygons on a model. If you are smart you will keep track of how many you use overall. If you are not you will learn the hard way.

 

My suggestion, like someone else, is to split your model into smaller chunks. Each chunk will add a draw call BUT when parts of the model are partly on-screen and partly off-screen it's going to allow Unity to cull the non-visible parts and thus reduce the draw calls. I did this with a procedural landscape, splitting it up into lots of pieces so that Unity could cull the parts that are not on-screen, otherwise Unity would try to draw every single part of it even off-screen which is very slow.

That said, the maximum heighmap you can have is 255x255 to fit into the size limit, so I had to chop up my landscape into blocks of 255x255 triangles. Not bad though, based on my camera angle I see about 30 draw-calls.

 

Nothing off-screen is drawn. However, all the geometry is uploaded whether it's drawn or not, so there's still some benefit to cutting down the amount of geometry that's uploaded.

--Eric

 

I have a model with a polycount of 8903 with a subsurf modifier set to 1, and it causes this error. Without the subsurf the model looks blocky.

Could someone send me a link, or describe this separation technique you've been talking about?

 

1) I can't possibly see why anyone would need so many vertices in a single object. Unless they were doing it wrong.

2) Both ZBrush with Decimator and Lightwave with Polycruncher retain UV maps and seams when decreasing polycount. Decimator especially is INSANELY good at keeping an object look high poly even after bringing the polygons down to a small amount.

-

Oh and I noticed someone else in this thread comparing vertex limits in pre-rendered use with real time use.. Really? You went there? lol.

 

As has been mentioned, there are people that might want to use Unity with wildly different requirements than your own. What if someone wants to use it for, oh, I dunno, in-browser medical illustrations? It's something where you're typically showing only a handful of objects but they may need to be modeled in excruciating detail. There's a lot of other uses, too.

I'm with RElam on this one.

 

doesn't change the fact that it would be useless though.

Do you think stuff like ZBrush handles 2M vertices with such a plain stupid approach through "just more and more"? Nope.

What you need to do and what unity should do out of box is load models and process them in a form similar to how physx does for mesh colliders: Create a spatial seperation tree of some form (even a stupid octtree crushes the plain stupid approaches that people believe to want by having int indices instead of short) and then seperate the content accordingly into submeshes which you render as required.

Thats something you can do through having an own model importer for example, but you can also do it by having a corresponding exporter script in your modelling software.

 

can you tell me how ?

 

If you want to prototype something quickly then the 64k limit becomes a minor issue in that you can't just drop things in as-is - a large landscape or level model for example.

No engine I have worked with had this limit so it seems a bit old-school but then Unity was designed to support almost any card so if some do not handle 32bit indices... well that could be an understandable reason... but perhaps they should be dropped... (I mean how many years old are those now?)

 

Not very old. If you drop GMA 950, for example, then you drop the card which is most used according to the Unity web player stats.

--Eric

 

Raising the limit will mean unity will run slower. I know what I would prefer: splitting my mesh.

No offense to silly people asking "how do i split a mesh" come on, you're hurting yourself with questions like that.

Select and detach a bunch of faces
Use your imagination, its there for a reason.


Getting TIRED POINT BLANK of people being spoon fed now. Come on guys, you are a bit brighter than that.

Then you'll be saying "why isn't unity as fast as engine x"

More bytes shoved in one go into the card = slower. It will run slower. Back in the old days that was fine because you weren't shoving multiple uv sets, normals, shaders and everything else up the graphics card's arse.

 

Yes that 64k limitation becomes to an issue!
Think about prototyping of design stuff like furniture. A couch or chair for example, made with very soft edge (Hyper-Nurbs). If you must split that mesh, you get artefacts!

You will only have this object on a stage in your scene and want shows it to your customer on a stereoscopic monitor, means you will have the right hardware... You wouldn't have seriouse performance problems!

I guess, Untiy should implement >64 vertices as a choosable option for those others who realy need it, even if there are other limitations on the other hand.

 

"other limitations" is nicely put for a major performance hit.
But naturally for ARCH VIZ, its unavoidable that it becomes and option more sooner than later, while game devs clearly favor a fixed import pipeline that seperates "too full meshes" into multiple meshes or an oct tree mesh graph.

 

You can either request a source license if you're that serious and pro about it,

Or split the mesh but retain normals across the split like everyone else does. Or just decimate it and use a normal map. If you can tell the difference with 32k triangles and a normal map applied then I will be pretty damn suprised.

 

I'd prefer they allow the use of various data types, which would fit right in with overcoming this limitation. I've worked on a project which procedurally generates meshes, which can have 65k+ vertices, and frankly this limitation of Unity (and not being able to create vertex lists using bytes instead of integers) has made me consider other engines more than once.

And it's a little disappointing to see people argue against a feature which could be of use. Sorry, but that's a good way to keep tools from moving forward.