I’m bring some of my old projects forward to 1.5 and there are many confusing things. For instance, in one I have a static city that I spent many hours carefully CombineChildren’ing sets of buildings. Each building is labeled “static”. But, now when I hit play, the buildings disappear!
If I set them to dynamic, then they appear just fine, but it looks like my number of draw calls is no longer as good as it was. Also, I’m guessing CombineChildren does not try to combine non-static children?
I’ve had this problem too.
My buildings were marked as static which was fine previously. After upgrading to iPhone unity 1.5 (basic) they disappeared when playing. The errors produced were misleading and mentioned vertices out of bounds.
If I made these buildings non-static, the errors went away and the buildings render at runtime.
I do have some warnings about meshes being marked static, but haven’t been able to find the culprits! By inspecting each object and prefab I thought I had marked them all non-static.
that indead would be disturbing, as that means that it tries to compile all static geometry into a single object and runs over the short vertex indexing, which definitely should not happen (it shouldn’t even try to combine them at edit time with the editor camera should it?)
No culprit. Thats an informative warning (from the amount of threads on this, a dead annoying one too), that you can’t use static batching in iphone basic.
Yes, I noticed the new feature list indicating that static batching isn’t available for the basic version.
I would expect then that if that is all that the static checkbox is used for then it should be disabled like the other unavailable features. If however there are other optimisations that occur behind the scenes when the static checkbox is used, well they are no longer possible with the error that’s produced.
Regarding the warnings, yes they’re informative (although it wold be nice if they indicated the name of the offending object) - I must have missed some objects in a hierarchy somewhere, although I would expect to get the showstopping errors in that case.
By the way, the static objects are rendered in the scene when not playing, it’s only when you “play” that they disappear (as suggested by the errors).
In short, I just have to not use the static check box at all with the basic version. Only a problem for existing projects that already have static objects in them, but easily fixed once you know.
We’re investigating whether Unity [iPhone Advanced] would be appropriate for a title we’re looking at potentially doing, and running in to this exact same problem.
Basically, a test level we have has a lot of modular meshes (like 500+) that have a single, atlased material on all of them. In Max the reported vert count is 32k verts or so. In Unity it balloons up to 67.2k. Presumably it’s because of all the degenerate tris it’s generating to batch the world down to a single draw. The problem lies in the fact that it’s trying to draw a batched mesh that’s greater than a short-indexed vertex buffer can handle (greater than 65k verts), and when I try to play the level parts of the geometry disappear.
The problem is that I can’t just turn off the static flag on a lot of the models, because in order for this level to be rendered at a reasonable speed we need to have the meshes be static so that occlusion culling will work.
So our options to still use unity at this point with this static batching bug are 1) make smaller levels (which is hard to do as this level is already pretty short as it is), or 2) not atlas the materials and combine meshes in Max so that presumably there aren’t as many degenerate tris being generated.
The second option would potentially lead to worse-than-ideal performance due to the fact that different materials = more passes, and larger meshes = more tris being drawn than needed when occlusion is being taken into account.
And one more option would be to contact Unity iPhone team (using bugreporter is fine) and request a feature in the Editor that would take out your pain
In most cases we can quickly react to feature requests and in the next build you’ll have required feature. Though please understand that highest priority would have feature requests from which majority of Unity users may benefit.
You should not have any static batching issues with Advanced license. And with the next release Standard license owners should be happy with Unity experience as well
Please, SUBMIT bug reports if you have problems with static batching. So far we have ZERO bugs related to this issue in our database and we can not reproduce it.
That means we CAN NOT FIX IT.
Reminder: forums is NOT the place to report bugs. We can NOT fix things until we can reproduce the problem. Please help us help you!