I have loads of prefabs in my scene upon starting my level. I have over 1200 scripts. Is it good practice to disable all of the scripts in the inspector before staring my game? as it seems if i disable them on awake it lags. So it may sound dumb but just curious.
Also i have a script which enables the prefabs when close by (trigger area).
if you have over 1200 scripts at some point in your life you made a huge mistake. or you are not expressing yourself clearly.
What do you mean by script?
If you want to disable the behaviour of the objects you have in your scene a simple way of doing that is to parent them all under a gameObject and set that active status to false in the inspector.
Be warned though, activating all these objects at once will lag anyway.
Hey, i mean that i have C# scripts. I have a scene with alot of prefabs (which have 4 scripts per object) most of them are OnTriggerEnter and i cant think of a way of reducing the amount down. So i could just disable the inspector C# script in the prefab and they will all update? ill have to try later on.
So i just thought that if i only enabled the closest ones then it would drop the total scripts running down to around 100. Is this still too much? or shall i just rethink the logic more?
each parent has a OnTriggerEnter enter so i guess that my approach will be pointless as you mentioned that its Unity weirdness, why is this? or cant it be explained haha
I thought that deactivating them on awake as i thought it would be ok, i thought wrong. i have a scene which has a varied amount of prefabs in it, i cant instantiate them as its a 3D puzzle game and i place them manually where i require them and they all use the same structure and scripts. So for example when i have a larger scene (200 prefabs) all with (6 scripts on) adds up to 1200 scripts firing on awake.
I assumed that not enable the prefabs that are far away from the players position would help. i have no other way of reducing the number of scripts down. Even if i could i would need a minimum of 200 scripts active for the above example.
Why are you deactivating them in the first place, though? Is the game performing poorly?
If that’s the case, open the profiler and figure out what’s causing it. If it’s physics, there’s two things you’ll want to do:
Make all of those 1200 triggers not collide with each other. You can do that with layers and modifying the layer collision matrix (Edit->Project Settings → Physics). Just put all of the triggers on a layer that doesn’t collide with itself.
Turn of far away Colliders, not scripts. If they’re out of view, you can turn off the entire gameobject.
But profile first. It might be something else than the physics system slowing you donw.
You would be better off using a central manager to manage that kind of load, having so many behaviours will add overhead
Or you could merge those scripts behaviour into only one. makes debugging easier.
Btw you are not really making clear what you are trying to achieve.
And please stop referring monobehaviours as scripts, it’s confusing.
Also note that you should not check for performance issues in the editor as many built in methods of unity are way faster in the final build (like GameObject.Instantiate)
If you disable all colliders (including child colliders if you have a RigidBody attached) then OnTrigger can’t be called. The reason OnTrigger is called on disabled Monobehaviors is like it says in the documentation to allow you to enable disabled Monobehaviors with Triggers.
ok thanks for the responses, ill upload screenshots later if your suggestions dont work as i will post screenshots and breakdowns.
Baste,
I have made all of the triggers have tags, will this work just as well as placing them onto their own layer? Regarding the profiler, i can see that its the total number of calls which is causing the lag, im testing on a Samsung Galaxy J3 (my minimum target device for it to work on). Also now you mentioned to “turn off the far away Colliders not scripts”… i think that’s where ive been going wrong. ill retest and let you know, thanks!!
ZZantal,
thanks, yes im testing in the profiler using Unity Remote, but i was just asking about the enable/disable of attached C# files on Game Objects. I have an issue where my game takes 10.3 seconds to run, the only obvious issue i can identify is theres alot of Monobehaviors running when the game runs. So my thought was ill ask to see if by disabling them when not in close range to the player, so i could improve the load scene time. The game runs fine (around 58FPS) after the first frame. Its just that the first frame takes over 10 seconds, due to me disabling the C# upon awake (attached to each game object). Hope that makes sense. I keep using the wrong terms for what I’m trying to refer to.
Pengocat,
i’ll give this a go, i have a player which has a RigidBody with a sphere collider and a custom layer and tag assigned, so when the player approaches the Trigger events can call only when the this tag has entered. No other object uses this to avoid any unnecessary conflicts. Its interesting to know what can and cant be done in disabled colliders.
Tags are just tags. They don’t do anything at all. You can check if an object has a tag, that’s everything a tag does.
Layers are used for two things:
You can set layers to collide with or not collide with other layers. This allows you fine-grained controll of what collides with what. If you have a very large amount of Trigger calls, it might be because objects that you’re using to check if the player is next to them are triggering each other. By using layers, you can remove the majority of the trigger calls that you won’t care about.
Layers are used by the camera, lights, and projectors to specify what they care about. So you can have a camera only show certain layers. This is often used for GUI, or for showing hands/tools in first person games.
Thankyou for the detailed explanation, i get why to use layers instead of tags now.
I did this drawing (attached) to explain why i want to do this, if you dont mind taking a look that would be great.
What i don’t understand still is that let say i have 100 OnTriggerEnters running when the scene starts, if i have disable the box colliders upon awake then will this be costly on performance? as surely the first frame will spike as it will run 100 scripts (using OnTriggerEnter).
Or shall i do the same approach but instead switch the layer they use (for the ones that are not in range)?
The pink represents the character and the dotted line is the trigger area. The image on the right shows which colliders are active (grey boxes). So i wanted an approach to be on the lines of how LOD works. But i control the radius and activation/deactivation of monobehaviors which are not close by.
First of all, if your game is running fine on what you want to run it on, don’t worry. The first frame will spike, but that just feels like loading. You can event hide it with a screen overlay that you fade out.
If it is running poorly - are those boxes always in a grid? Because then you don’t need colliders. You just round your position, and do a distance check to the boxes that are within ±3 on the X and Y axis. Or something along those lines.
Well my game runs fine for a level with 100 blocks in it, sometimes i have 800 ish. So i get a spike at the start going to 20fps. Im testing for Android using USB Unity Remote Profiling. But its only an issue for the first frame only. after this i get a steady 60fps. So it must bee the sheer number of scripts which are enabling and then instantly disabling.