koobas.hobune.stream
transform.localScale very slow on device (contrary to Android Remote)
For some reason, transform.localScale is very slow when app is deployed independently to device, but it works smoothly in Android Remote
I've tried defining a global var to store the transform, but that doesn't make a difference. localScale appears to be dependent on framerate, and I am wondering if there are cons to putting this operation in FixedUpdate instead of Update?
The slowdown issue is not the GameObject itself which you want to rescale, but its collider. Even if never using the collider, it is actually there and will be updated with a call to transform.localScale result in a more complex scaling.
The collider is used for physics and collision detection, if you do not need this, the solution is quite simple - just destroy the collider of your GameObject.
GameObject.Destroy ( myGameObjectrenderer.collider );
Happy Scaling!
Should mention that it is only a problem for $$anonymous$$esh Colliders- anything else can be scaled as much as you like. Also, this is not nessesarily the problem here.
Scaling 15 planes/frame (representing flickering fire) dropped me from 80 to 3 fps. Sure enough, the Unity plane comes with a mesh collider (why not a very skinny box? Beats me.) Taking it off solved the problem.
EDIT: Since it was fire. I didn't even want a collider. But even when I took off the meshCollider and test-added a box, frame rate was still fine.
@Owen Reynolds - so you just removed the mesh collider at runtime when scaling, and added it back later?
@ina - when using a collider the scaling is slow. No matter if you destroy and then recreate it. Destroying works for me at runtime, right after creating it. I guess if you want to scale often and need a collider it's kind of a dilemma. Hope that will be fixed by the Unity guys somehow.
When something is running in the remote it's running on your computer, which is likely 10-50X faster than whatever phone you have.
localScale appears to be dependent on framerate
Nothing is dependent on framerate unless you program it that way. (Or, perhaps, everything is dependent on framerate unless you program it not to be.) In other words, there's nothing special about localScale.
I am wondering if there are cons to putting this operation in FixedUpdate instead of Update?
The usual cons, yes. FixedUpdate should only be used for applying physics forces.
As I understand, each time you invoke .transform.localScale (etc), it's actually .GetComponent("Transform").localScale - which was why I assigned a global to avoid having to traverse each time... I'd like a smooth transition of localScale, hence why it is in the update state.
What is the usual con for FixedUpdate anyway? Would it be the app crashing due to the interval being too frequent and device not being able to catch up with it?
1) Tying transform operations to FixedUpdate means they don't update at the same rate the camera does, so they wouldn't look smooth. 2) If you're not actually using physics, you want to set the fixed timestep as high as possible to save CPU time (since you can't turn physics off completely), in which case code in FixedUpdate will also only run occasionally. 3) If you set the fixed timestep to a reasonably high rate, that means code in FixedUpdate is forced to try running at that speed even in low fps situations, which is the opposite of what you want in that case.
As far as caching transform in a variable, that's fine, and so is using localScale in Update.
hm do you have any tips on improving localScale efficiency on device
