Render.enabled = false for offscreen sprites improves performance?

[bluelotus]

Subject line says it all.
Perhaps Unity is already doing this?

Or is it best to tell unity to not render all those sprites off the screen.

Ive run a test and I cannot see much difference..
anybody else been through this?

cheers,

Bl.

[unikronsoftware]

Shouldn't make any difference, unless you can cull your sprites much more efficiently than the highly optimised built in Unity culling code. There are cases where this will be true (where you can make high level decisions and disable a significant amount of them in one go, for instance), but unless you have LOADS of sprites, it shouldn't make much of a difference.

It will make a difference for animated sprites, though.

[bluelotus]

Cool thanx for the fast response -

interesting about the animated sprites.
So, would there be gains from anim.Stop(); and also renderer.enabled = false, for Off screen animated sprites?
My frame rate is no longer stable, it sometimes drops 1 or 2 or even 5 frames on iphone.  - Trying to stabilise it.

Bl

[unikronsoftware]

With the animated sprites, the best thing to do is disable the entire thing if you can. If you can't then simply disable the tk2dAnimatedSprite component.

[bluelotus]

Hello again-

So I tried deactivating the animated sprites - but once they are deactivated its hard to reactivate them. They disappear. Bam! gone.
I have now deactivated the tk2dAnimatedsprite component for offscreen objects.

This helped but I still get Frame rate spikes.

I have the profiler and the spikes seem fairly evenly spaced every 2 seconds or so.
It says that they are coming from,

The update()  in my script on the animatedsprite object. (with 20 of these its ok) but with 40 it starts to spike.
Physics.Simulate (mainly)
and also, Overhead.

my goal is to have 80 - 100 animated sprites. Interestingly, with 100 there is not that much difference to 40.

So I began playing with the Fixedtimestep and maximum allowable timestep to try and adjust performance.
Setting these low - 0.01 and 0.01 gets a perfect framerate with no spikes but the animation frame rate becomes really slow.

Any advice on where to go from here? 
I am thinking of using co-routines but maybe this will not help?

Bl.

[unikronsoftware]

What version of tk2d are you using? You should be able to disable & enable animated sprites no problem.

[bluelotus]

I'm using 1.8 final + patch 3.

Just to clarify from last post -

gameObject.SetActive(false);

But how to make it active again?
Active = False Seems to turn off the object and all scripts - meaning a parent or manager object would be required to set it to active again.

anim.enabled=false;
Also works,
where anim = GetComponent<tk2dAnimatedSprite>();
This one is easy to turn on again.

Perhaps there is another way to disable and enable the animated sprites - Ive been up and down the google but can't seem to find another?

Any advice here is most welcome.

Bl.

[unikronsoftware]

Oh yeah that makes sense if you're controlling it from the script itself, there will be no way to turn itself back on again. In that case you can simply toggle the tk2dAnimatedSprite component.

[bluelotus]

Hey so Toggling helped avoid the tk2dAnimatedSprite.LastUpdate from creating a super spike on are occasions -  which is good.
30 Fps and away we go!

Cheers,

Bl.

[dakeese]

Shouldn't make any difference, unless you can cull your sprites much more efficiently than the highly optimised built in Unity culling code. There are cases where this will be true (where you can make high level decisions and disable a significant amount of them in one go, for instance), but unless you have LOADS of sprites, it shouldn't make much of a difference.

It will make a difference for animated sprites, though.

Does tk2d recreate all geometry for all static sprites every frame, or only for sprites that wouldn't be culled by the camera?  If it's the first one, is this not a problem simply because recreating geometry is trivial compared to actually rendering it?  If it's only recreating some geometry, does it do this for each camera in the scene, or all at once?

If I have a level made up of a maybe a few hundred non-animated sprites, I can get away with not bothering with any of my own manual culling?

[unikronsoftware]

If you have a few hundred static sprites, the most obvious optimzation would be to merge them using static sprite batchers. Merge sensibly based on location, and you'll be able to reduce a few hundred static sprites to something much much smaller. Again, only if culling is an issue - it rarely is when you only have a few hundred sprites.

When you go into thousands / tens of thousands, then perhaps you'll have to worry.