Dynamic batching doesn’t seem to be working. Static batching does. Here’s the stats for my testbed scene for my current project in 1.7 and 3 beta. Same exact scene other than whatever gets changed by Unity when it updates a pre-3 project:
Has anyone else seen this? I sure hope it’s just a beta thing, dynamic batching is great and I’d be in a bad way if it’s gone. I’ve not compared frame rate when building with U3 vice 1.7, going to do that now.
I think its a stats error. either that or u3 is so freaking much faster that it just ends up faster without it
though on the 3GS+ that could really be the case as U3 when I recall right now supports neon, while Unity iPhone 1.x relied on the cpu (or better used the VFP which incase of 3GS+ means cpu as they don’t have vfp and cause the cpu will then emulate the vfp)
hehe I’m from switzerland so even considering the iphone 4 is “impractical” cause we do not even know when it will happen here (we tend to be wave 2 but apple has had some serious problems to keep up their plans for wave 2 already with the ipad) and I don’t develop for platforms I can’t test even less if the manufacturer thinks that “sue-heaven” (-> USA) is more important than those who pay the apple premium luxury fee (europe)
I tend to agree, although there’s a part of me that hopes dynamic batching really is broken in the beta and that U3 IS so much faster that when DB is fixed we’ll get even better performance. But that’s probably not the case. At any reate, U3 does seem to give a performance boost even on my iPhone 3 with iOS4. iOS4 has choked that poor thing half to death. My 3GS was running my test scene right at about 30 FPS anyway. I’ve not tried it yet on my iPad but I’m not targeting that device for this project.
I won’t be able to test on an iPhone 4 until August 4th, at least that’s when the Apple store is telling me mine will get to my house. I’m hoping the big press conferrence today RE iPhone 4 doesn’t through a wrench in the works.
I had to go out and buy my wife a 3Gs because iOS4 about killed her 3G. It is so slow that it became unusable. I had an iPhone 4 on order but canceled it until Apple works out this antenna issue or I absolutely have to for game dev. I think next year’s model will be a better phone, so I hope I can wait until then to buy a new iPhone. I can’t see spending that kind of money to get a 3Gs +.
I’m a frame rate whore, so I tend to build for 2nd gen Touch and get it until its around 30fps or better… So when I test it on a 3GS its silky silky smooth
Yeah, I still set my kFPS to 240 I dunno why, it amuses me.
Wish I would have seen this earlier! I spent some time trying to figure out why nothing was batching but it wasn’t like it was running terribly.
Now I need to look into my potential issue where on import, even though blender meshes use the same texture, they’re generating new materials for every mesh…
I notice that there’s still batching issues going on… Ie, I’m still not seeing ANY batching going on in the stats window, but I know the objects will batch.
Yet the performance seems fine on the device? My scene jumps from 8 calls to 22, enough to notice a drop in performance, but it doesn’t seem to drop at all. So either devices are far more awesome than I remember, or its working perfectly but not reporting
hehe mine from 48 to 120 and it still ran faster than on iphone 1.x on my itouch 3GS …
I concluded that the reporting is the cause but I think it was mentioned that the reporting is fine, that batching is broken and that it is just that hell faster.
who knows potentially the usage of Neon on 3GS helped on that end?
The following image has 1 model, 1 material… Cloned 12 times.
It seems to me that it’s only combining objects for a total of 300verts… I thought (and could be wrong) that it would batch any group of objects if they had <300 verts, instead of combining several ‘to a maximum of 300 verts’…?
the original was combination of objects of < 300 verts up to a total of about 4000 verts (the point where updating the mesh takes more time than you safe through batching)
with never devices and especially Neon support (given it happened) the border likely dropped further down cause the overhead from the dynamic mesh generation etc vs just having the different draw calls moved towards “more draw calls” with the stronger cpus
