Hi,
In my game The Camera.Renderer takes more than 50% performance, I see that scale of some of my object is set to 0.7 , 0.7 , 0.91, i know it affects on physics performance if there is collider attached with that object,
In my case there is no collder on that object, but on its parent…
does this effect on performance…
Suggestions are appreciated,
thanks in advance
Well. What is the total ms per frame? Camera.renderer taking 50% means nothing if it runs pretty good.
Scaling in general can interfere with batching, so it’s not advised.
Also, I don’t think Camera.Renderer contains the physics.
AcidArrow: Thanks for you reply,…
I am currently checking it in profiler of unity3.3, Camera.renderer takes avaerage of 0.9 ms, rarely goes to 4.2 ms,
I am worried about Camera.renderer because all others take less time ( ms ) while running.
Further more render.transparentGeomettry takes large ms in children of Camer.renderer, For example look at the image
atached
Geometry with different scales do not batch.
Don’t go overboard checking percents. Percents work under the concept that the lower some values are, the higher others are. A high frame time % doesn’t mean that the code is inefficient or slow, it could just mean other things are faster. Your game is running at 1000 fps. The fact that Camera rendering is larger, has more to do with nothing else taking any resources, rather than Rendering taking a long time.
I mean just think if you make the scripts better, it could make rendering even worse, taking up to 75% of the time rendering 
A bit more serious It can disable batching resulting in more draw calls, which can be a bottle neck. But if you are not GPU bound, and the framerate is not skipping, time spent reducing draw calls doesn’t actually do anything.
There are 3 Camera renders per frame as well, which is going to add some weight, especially if they are re rendering the same geometry.
I know from shaders it works like this:
If the object has uniform scale, the mesh’s local vertex positions are not updated from the CPU to GPU. Rather, you multiply or divide by the uniform scale, as necessary. If, however, the object has non-uniform scale, the local positions are updated, and having scale in the shader is useless, because it’s 1.
I don’t know if the non-uniform scaling happens once, and values are cached, or what. But I do know that if your objects use the same uniform scale, they will batch.
To add to the above, percentages are useful in the profiler generally only when using coroutines or load-spreading. Say you have an A* pathfinding routine and want to check that different parts take up a different % of time, its easy to do then in relation.
Generally I just look at ms.
And to add to jessy’s post: objects that are uniformly scaled with the same uniform scale as others will be batched.
So if you have some objects of 1,1,1 they’ll batch but the one that’s 2,2,2 won’t batch with the 1,1,1’s but will batch with other 2,2,2’s. What a mouthful.
Does the scale at which the objects are imported have anything to do with it, or just the scale on stage?
For instance, if i bring in two fbx files, one at a Scale Factor of .01, and one at a Scale Factor of 1. Then put them on the stage with both at scale 1,1,1 → will they blend, err batch?
zipper
The Scale on the Transform is the relevant scale for keeping batching working. The Import scale will modify the model directly and will be able to be batched.
Although if it’s two different models (as it would have to be for different import settings), then you need to make sure they use the same Material using .sharedMaterial property
Are these different? 
In general I’ve found scaling kills frame rate. The part that takes the most time is when the CPU has to re submit vertex buffer objects to the GPU. This shows up in the profiler so it’s easy to spot. I’ve found thebest trick to avoid scaling is simply move things closer to the camera, this works wonders with billboarded objects.
On a slightly unrelated note, make sure your sound effects are set to decompress on load as otherwise they will use 5-10% CPU for each sound playing! And this does not show up in the CPU profiler section, only in the audio section. And to further confuse you, in the CPU section it shows up as random spikes in random functions as the audio thread starves the main thread making what ever is running at the time appear super slow.
lol 
I was brain farting I think.
Thank you guys, this has been very helpful!
Just to clarify… does uniform scale mean that x, y, z scale values match? For example if I have 2 prefabs (with the same material) with scale [1, 3, 5] will they still batch? Or must they be [3, 3, 3] to batch?
Also, is this the only performance hit of scaling renderers, is it only a batching issue?
This is no longer a problem in Unity 5 (scaling has no effect on performance in 5) so I’m locking this thread (please report a bug if it is a problem).