I’m about to go bit by bit trying to figure out why my skinning cost in the internal profiler jumped from 6ms to 22ms per frame in between builds. While I do so, has anyone run into this kind of issue before? I’ve eliminated Update When Offscreen (that only contributes about 2 ms per frame) and the new update to OpenFeint 2.6 as possible culprits. Everything else is just script or prefab updates, and there’s no way to drill into the skinned mesh rendering from within the internal device profiler, so I’m not sure WHICH skinned mesh is causing problems, either.
This is on Unity iPhone 1.7.1.
did you alter the model like ad more weights for example or switch to a newer device (newer than iphone 3G / 2nd generation ipod)
I’m pretty sure the model hasn’t changed, but I’ll do a replacement and check. These are examples of two builds on the same device (3GS):
Tuesday build:
iPhone Unity internal profiler stats:
cpu-player> min: 11.6 max: 17.1 avg: 14.2
cpu-ogles-drv> min: 2.7 max: 6.0 avg: 3.3
cpu-present> min: 0.4 max: 1.3 avg: 0.9
frametime> min: 16.8 max: 27.8 avg: 22.9
draw-call #> min: 17 max: 18 avg: 17 | batched: 2
tris #> min: 6099 max: 6123 avg: 6115 | batched: 212
verts #> min: 3101 max: 3149 avg: 3133 | batched: 115
player-detail> physx: 0.0 animation: 0.5 culling 0.4 skinning: 5.4 batching: 0.1 render: 4.4 fixed-update-count: 0 … 1
mono-scripts> update: 2.7 fixedUpdate: 0.0 coroutines: 0.1
mono-memory> used heap: 630784 allocated heap: 643072 max number of collections: 0 collection total duration: 0.0
Friday build:
iPhone Unity internal profiler stats:
cpu-player> min: 24.5 max: 31.2 avg: 27.7
cpu-ogles-drv> min: 2.4 max: 4.2 avg: 2.7
cpu-present> min: 0.4 max: 5.3 avg: 1.2
frametime> min: 31.0 max: 45.3 avg: 34.9
draw-call #> min: 15 max: 15 avg: 15 | batched: 2
tris #> min: 6061 max: 6061 avg: 6061 | batched: 212
verts #> min: 3025 max: 3025 avg: 3025 | batched: 115
player-detail> physx: 0.0 animation: 0.5 culling 0.2 skinning: 21.0 batching: 0.1 render: 2.9 fixed-update-count: 0 … 1
mono-scripts> update: 2.6 fixedUpdate: 0.0 coroutines: 0.0
mono-memory> used heap: 630784 allocated heap: 643072 max number of collections: 0 collection total duration: 0.0
Weird. I just exported everything in my project and re-imported, and although there are some null references now, it looks like the skinning time dropped back down to normal levels. I guess something got corrupted?
I’m going to try cleaning this version up, will post if it gets bad again.
ARGH! This has turned into a major WTF. If I load the scene with the skinned mesh in question using Application.LoadLevel, it takes 22ms in ‘skinning’. If I place it as the first scene in the build, it takes 6ms.
I’m at a loss now. I guess I’ll go back to the working build and see if I can’t pinpoint exactly when this changed. 
that sounds totally fishy that it should make such a difference unless your other scene you use in case of loadlevel has some stuff going on permanentely thats not freed tahts impacting it or something …
never seen such a thing so far
Nope, I created an empty scene with a single script that calls Application.LoadLevel on start. Since this didn’t start happening until a build this week, it’ll be easier for me to trace forward from Tuesday rather than guess backwards from Friday. I’ll go back and try to work my way through everything.