Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

65535 vertices limit

Discussion in 'Editor & General Support' started by boolfone, Jan 30, 2015.

  1. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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.
     
    Devil_Inside likes this.
  2. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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.
     
    Last edited: Feb 5, 2015
  3. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    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 :rolleyes:

    Even mobile devices can do hundreds of draw calls with decent shaders but the memory is scarce there.
     
    angrypenguin likes this.
  4. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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.
     
  5. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    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.
     
  6. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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.
     
  7. Ostwind

    Ostwind

    Joined:
    Mar 22, 2011
    Posts:
    2,804
    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 :)
     
  8. BIG-BUG

    BIG-BUG

    Joined:
    Mar 29, 2009
    Posts:
    457
    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.
     
  9. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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.
     
    Ostwind likes this.
  10. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,750
    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.
     
    Last edited: Feb 6, 2015
  11. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    That's a great idea. :p
     
    Ryiah likes this.
  12. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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 :rolleyes:

    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.
     
    Last edited: Feb 6, 2015
  13. simcovr

    simcovr

    Joined:
    Jul 3, 2012
    Posts:
    43
    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.
     
  14. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    @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 ...
     
    Last edited: Feb 6, 2015
  15. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,750
    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.
     
    RJ-MacReady likes this.
  16. RJ-MacReady

    RJ-MacReady

    Joined:
    Jun 14, 2013
    Posts:
    1,718
    Now that is a cogent and polite way of putting it.
     
  17. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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.
     
    Ryiah and Ostwind like this.
  18. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    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.
     
  19. SpookyCat

    SpookyCat

    Joined:
    Jan 25, 2010
    Posts:
    3,742
    @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.
     
  20. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    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.
     
  21. SpookyCat

    SpookyCat

    Joined:
    Jan 25, 2010
    Posts:
    3,742
    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?
     

    Attached Files:

    ksam2 likes this.
  22. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    "and 65534 tris"
    did you not figure it out by yourself?
     
  23. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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.
     
  24. SpookyCat

    SpookyCat

    Joined:
    Jan 25, 2010
    Posts:
    3,742
    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.
     
  25. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    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.
     
  26. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    http://forum.unity3d.com/threads/me...tices-at-the-moment-or-is-it-triangles.170030
     
  27. RJ-MacReady

    RJ-MacReady

    Joined:
    Jun 14, 2013
    Posts:
    1,718
    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.
     
  28. SpookyCat

    SpookyCat

    Joined:
    Jan 25, 2010
    Posts:
    3,742
    @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.
     
  29. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    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 :)
     
  30. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    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...
     
  31. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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.
     
  32. Tiles

    Tiles

    Joined:
    Feb 5, 2010
    Posts:
    2,481
    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
     
  33. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    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 :).
     
  34. jcarpay

    jcarpay

    Joined:
    Aug 15, 2008
    Posts:
    561
    +1 Spot on
     
    AndrewGrayGames likes this.
  35. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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?
     
    AndrewGrayGames likes this.
  36. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    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.
     
  37. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
    Ony and Ryiah like this.
  38. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    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.
     
  39. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    Hmmm.......
     
  40. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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 :p
     
    angrypenguin likes this.
  41. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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?
     
  42. SunnyChow

    SunnyChow

    Joined:
    Jun 6, 2013
    Posts:
    360
    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
     
  43. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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.
     
  44. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    I wonder how chunking would work for a single large mesh. Sounds gross.
     
  45. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,750
    What's stopping someone from subdividing their meshes?
     
  46. SunnyChow

    SunnyChow

    Joined:
    Jun 6, 2013
    Posts:
    360
    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?
     
  47. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    Only 3D model viewers :D
     
  48. SunnyChow

    SunnyChow

    Joined:
    Jun 6, 2013
    Posts:
    360
    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
     
  49. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,610
    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.
     
  50. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    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.