VISIBILITY & runtime & processing

blob

Visibility used to not be switchable at runtime.
Hence an actor with visibility on false would not be loaded in the scene and would not render at runtime saving CPU cycles

With the visibility attribute switchable at runtime is it still saving CPU? or is it now equivalent to setting the alpha to 0 which still draws on the processor almost just as much as if alpha was set to 1

Socks

@blob said:
With the visibility attribute switchable at runtime is it still saving CPU? or is it now equivalent to setting the alpha to 0 which still draws on the processor almost just as much as if alpha was set to 1

There seems to be no difference between the two.

blob

thanks .. @Socks
I had this fantasy that maybe Visibility false still took the actor overhead off the CPU like before.....
Cookbook is so outdated on these sort of things.

Socks

@blob said:
thanks .. @Socks
I had this fantasy that maybe Visibility false still took the actor overhead off the CPU like before.....

I spawned enough actors (with three constrains each) to bring an iPad 3 / iPhone 6 and iPad Air 2 to their knees, then backed off until the devices could handle all the actors with their constrains (depending on the device around 100-200 actors / 300-600 constrains) whilst still playing at around 50fps (I took the project to 50fps to allow room for frame rates to increase as well as decrease) . . . . . doing this test and jumping between alpha=0/visibility=1 and alpha=1/visibility=0 saw the frame rate change no more than 1fps, and even here it wasn't consistent, sometimes the alpha route would edge ahead by half a fps sometimes the visibility route would edge ahead by half a fps . . . so basically neither seems to be more efficient than the other.

blob

@Socks
Ahh!! Very interesting.. good to know.That's exactly what I needed to know:)

Thank you.