Hi,
I’ve an initially more or less empty Unity scene (plane object with texture, camera, a few light source). When I’m initializing the Unity view in my iOS native project the memory use jumps by ~ 80 MB (from 16 - to 95) which does not leave that much memory for objects loaded dynamically later on…
Any comments on this, please?
Ekki
how do you check that? By “Allocations” (sounds like a bug) or by “Activity Monitor” (which shows virtual memory, which is not really directly linked to really used memory, and includes allocs for gles driver etc)
Hi,
I’m referring to Instruments → Allocations → Live Bytes
Ekki
that sounds scary lot, yes. Please bug report with repro project attached (the project you created to test) and post case number here (or send me, whatever suits you best ;-))
I can provide either the Unity project, or the generated Xcode project. The final application is a parallel Xcode project which references the created Xcode project. I can provide whatever you want. Here’s a movie of the App, BTW looks slow due to the simulator, http://intelligentgraphics.biz/solutions/FMM_GT.mov
Can you give me some advice where to create a bug report?
Thx Ekki
It is probably not an issue with the stand-alone Unity project but happens only in the specific iOS integration. So what I’m basically doing is reparent the Unity view controller into another place inside the view controller hierarchy (see below). That all works just perfect including event handling, Unity pause control, device orientation change, etc. Later on, I’m adding some overlay widgets to the Unity view controller which also works as expected.
But when the Unity view becomes visible for the first time that huge memory allocation happens - one big jump from 16 to ~ 60 MB, another one from 60 to 90 or even more.
Looking fwd any comments… Thx
Ekki
extern void ebPL3AssignUnityController(void *);
void OnUnityReady()
{
UnityStopActivityIndicator();
HideSplashScreen();
/* original
[_window addSubview: _view];
_window.rootViewController = _viewController;
[_window bringSubviewToFront: _view];
*/
NSArray *tSubviews = [_window subviews];
[_window addSubview: _view];
[_window bringSubviewToFront:tSubviews[0]];
ebPL3AssignUnityController(_viewController);
UpdateOrientationFromController(_viewController);
[UIView setAnimationsEnabled: UnityUseAnimatedAutorotation()];
}
http://unity3d.com/BugReportingFAQ
As for your setup: we are working on making this setup easier to do (like, no need to tweak trampoline code etc), but anyway it shouldn’t behave like that (unless you are running on some “strange” ios - some versions of ios gles drivers uses malloc so it goes to “allocations” instruments).
So:
Hi,
yes there are some bigger allocs… all created from glsmLoadTextureLevelBuffer:
2 x 16 MB
2 x 12 MB
3 x 3 MB
9 x 0.25 MB
Obviously this is my ‘issue’… Need to figure out if global settings cause this or specific code in my components. Any hints are greatly appreciated.
Ekki
these are used for texture uploads. Meaning you have 2 things to check:
Thx for feedback and patience.
I’m sure that HideSplashScreen() is called properly. So it must have to do with the textures. At the level of App initialization there’re only a few textures with size around 700x700 px, 400-500 kb max, this would probably correspond to the 9 smaller chunks but I’m still out of ideas concerning the 2+2 huge chunks. Can it be that those are reserved in advance, maybe due to some global project setting, and without any specific texture?
Thx again,
Ekki
well, not so fast. First of all - prior to Unity 4.1 there was no support for NPOT textures, so they are padded to POT.
Second, how do you measure 400-500 kb? Assets size (png/jpg/whatever) have nothing to do with runtime size. So, for example, if you have 700x700 uncompressed texture (True Color in texture importer) it will be padded to 1024x1024 32bits = 4mbs. If you add possible mipmapping - even moar, and (due to internal stuff you should search forum about) because they are npot - you will have second copy. AND (yes, sure, stuff on top), if you didnt mark the textures as non-readable (honestly i dont remember the default setting - change texture type to advanced and see for yourself ;-)) they will be left in memory for whole lifetime.
But still 16mb looks a bit too much: it looks like 2048x2048 uncompressed
Alexey,
yes when I said 400-500 kb I spoke about the asset size.
Still no idea what causes the 2 x 16 MB and 2 x 12 MB chunks, pretty sure it has nothing todo with those textures mentioned above. Thx anyway
Please get used to using the most excellent GitHub - handcircus/Unity-Resource-Checker: Editor utility for unity to help check resources in the current scene (including active textures, their sizes, materials, meshes and which objects are using them)
Every developer needs it. Currently, unity 4.1 still doesn’t allow discovery in scene or project, so this utility is still very good for tracking down “surprises” - which will creep in!
We got TOB’s ram consumption down from 80mb of texture and mesh usage down to just 30 for each scene 
it would have been almost impossible to trace this in a scene with thousands of objects without resorting to code or utilities.
It seems that the 2 x 16 MB are allocated due to enabled hard shadows. If an object is created in the scene that creates shadows, the two chunks will be allocated. By turning off shadows, I can cut down the load by 32 MB.
it seems that you have “high res” shadows. If you dont need shadows - sure disable it. Or try lowering down quality