I am new to the Unity community. During the last month I have been creating a game for the IPhone with the basic version and have a question regarding the perf related to operations done in the CPU for those game objects that enter fr the first time on the camera frustrum.
I have 8 models that when rendered at the same time in the screen push poly count to 10k or so. I am using no lights, brought physics calcs to a minimum (and colliders are all spheres).
I have optimized the code, but the thing is that when four of the models enter the camera frustrum area at the same time, there is a small glitch (less than a sec) that I cannot avoid. Stats show the following on the cpu-player> max 138. Funny thing is that it only happens the first time those models enter the viewable area, and after that everything plays smoothly even if they get out the playable area and then re-enter it. What is more, everything still plays smoothly with 12k+ polys but only after they all enter the field for the first time.
Since all models use the same shader (only textures change) I must ask: is there any set up that Unity does when an object is visible for the first time? I mean, say, instantiating vertex/index buffers when the object hits the camera frustrum for the first time instead of when it is created, or something else that keeps “cpu-player” stat that high for a brief period of time.
Do the models have skinned animation? If so, then the animations might not play until the objects become visible (see animation.animateOnlyIfVisible). It is possible that the animations do some initialisation just as they enter the view frustum.
I assume you’re using Unity 1.7? In versions of Unity prior to 3, textures were loaded the first time they entered the camera frustrum. On an older iDevice, jamming a lot of stuff into memory at once will cause noticeable hitches. The way I used to work around this was to have a “loading screen”, which was just a full screen polygon covering up a bunch of primitives that had my textures applied. This forced the textures into memory immediately, after which I could delete the primitives, loading screen, and go straight into gameplay without worrying about hitches mid game.
In Unity 3, this practice is entirely unnecessary because textures are loaded in advance by default, unless you manually load them via Resources.Load.
Thanks for the responses. It’s good to know that info.
In may case, I’m using v3 and meshes have no animations at all. It’s a top-view shoot’em up space game like, say -saving distances, Ikaruga.
Since I have the basic version of Unity IPhone I cannot profile it further, but it feels as if some “late-settings” were processed in that precise moment when game objects enter the scene. Once visible,10k polys (and more) are render flawlessly on my IPod (3rd gen).
So, since changes in render state are close to none since I 'm using the same shader for all the ships (so, only textures change), the only thing I can think of is vertex/index buffer creation.
Yes, it happens even when I reboot my IPod 3rd gen.
You can see there the “stalls” stemmed from the cpu-player process (132 and 125) which last just some millisecs but still noticeable and then everything renders smoothly.
Is this all just one scene or are you loading some bits yourself, or loading some bits in a previous scene with nodestroy? Does it happen every time objects leave and enter the screen or just the first time?
Does it happen if these models have no textures at all?
The best workaround is a warm start. When the level loads, render it on screen under other geometry or behind a billboard of some kind. This is a solution that will at least work right now.
Sorry for the late response but I decided to get Unity 3.1 before posting any further.
So, I stripped out all textures on models, set shaders to Diffuse Fast, set two layers (one for the background and the other ignoring raycasting) and lower quality to the minimum, but I still get same results even with Unity 3.1.
So I used XCode profiler to assess what’s going on and hereunder you will find a couple of screenshots:
As you can see, when GraphicServices take 90 ms when some objects enter the viewable part of the scene on sample 1101 and 10 on sample 1102. Before and after, everything goes well.
Stalls stemming from this are always present in “i” devices, and ocassionally -which is rare, also happens on other target platforms (Win/Mac/Browser). So, I guess is Unity is doing something “big” when a visible game objects hits the camera frustrum regardless the target platform.
Hummm. I’m using Unity 3.1 but the game was created with 1.7. Is there any way to verify that the mono project is referencing the updated assemblies of the Unity engine? And ditto for the final XCode project?
Perhaps textures, 3D models a/o shaders are being loaded into memory when they hit the camera frustrum for the first time, and that is causing the stalls (which are significant on the “i” devices).
In 3.0/3.1 very is a small performance impact when you render mesh for the first time (internal VBOs are being filled at that moment, so bigger the mesh - longer it takes). We’re currently working on solving issues like that!
Thanks for submitting a bug - it gives us better coverage for testing.
