koobas.hobune.stream
About Optimization, Garbage Collection, Unused Scripts.
So hello everyone, I need to know something about the Unity's process of optimizing unused scripts. So let me explain, I have one huge scene, it's like there are 3-4 floors, some passages and some extra rooms etc. I've created checkpoints, where the player will not be able to return back. For example, there is a huge livingroom, when player is done with it, it goes to the floor below and won't be able to turn back to the livingroom. Now my question is, I already achieve graphics optimization via Occlusion Culling and LOD. But, when the player gets to the lower floors, there will be a lot of inactive objects with gameplay scripts on them. Will this affect the gameplay or the memory a lot? Should I do something like a loading screen, when the player gets down to the lower floors, just for a few seconds, and while at it, run a coroutine to delete all the gameobjects on the upper floor which has scripts on it ( some are disabled, some are enabled ) and then request a Garbage Collection right afterwards? Or should I just leave the objects like that, will the automatic GC process handle those objects?
I don't necessarily delete gameobjects on the gameplay, in every gameplay script I wrote, I did:
gameObject.SetActive(false);
instead of
Destroy(gameObject);
So, considering that there will be a lot of checkpoints, there will be a lot of ( from 10 to - 110 according to the player's process on the level ) unused, both active & inactive gameobjects that have both active & inactive scripts on them, what should I do to prevent those unused objects to affect further gameplay?
I would not 'delete/destroy' game objects seeing how that is expensive, set active is fine. There are a few more things you can do.
batching: http://docs.unity3d.com/Manual/DrawCallBatching.html.
Object pooling: https://unity3d.com/learn/tutorials/modules/beginner/live-training-archive/object-pooling
You can even go as far as change or turn of materials how far away the user is from the object. Turn off as many Colliders as you can or have the ones you need turn on when the player gets to a position in the game.
If you really need to, yes put checkpoints in the game. I would also suggest to have a manager for the objects you need and not have 100 components that have diffrent memory in them, example: 100 checkpoints with each one calling it's own functions. You should have a manager that checks to see what objects collider has gone off and then call the managing function. If one checkpoint has gone off turn that one off and activate only the next checkpoint in the array. The Collider checks are expensive as well.
It won't cause an overload but it's still checking if there is an on trigger every frame, so yes this is fairly expensive dependent on how many objects you have.
It sounds like your interactables checks a collider, right? If you have a lot of objects just write something that will either control each objects state like a object manager, or turn them off when a player is in a room or something similar. It sounds like you should use a manager so the engine is not continuously checking states of objects.
Can you explain a little more about how and what you are doing?
Ofcourse, I have a lot of interactable objects, like doors, drawers, cupboards, any objects that can be found in the household. Now, all of these have Interactable.cs script on them, which checks if the player is in the correct position by checking OnTriggerEnter, if the trigger is correct, then it continues on checking the player angle, camera angle etc. Then if everything is okay, the script enables the UI ( simple interaction UI, press E to open etc. ), then if the player presses the desired key, Interactable.cs sets a gameobject active. That gameobject may have different scripts on them, as I call them Action scripts. So all these actions scripts are dependant on the OnEnable function, since the gameobject that they are attached to will be set active by the Interactable script, and they perform different actions according to the interaction, like calling an animation, or a sound, enabling another interactions etc. So it's basically like this, a lot of Interaction.cs script attached game objects, which has a box collider set as a trigger on them. But I wonder, I know that OnTriggerEnter function still checks if the script is inactive, but will it still check if the game object is inactive?
Oh boy, a lot of overhead for things. One last question until I am able to offer help. Is there a reason you are not using Raycasts? If you are checking the player rotation and position to see if the player is looking at a door that is extremely expensive.
Simply because Triggers have more functionality when it comes to the matters of "area". $$anonymous$$y checks are not done on the "player" side, but on the interactable object's side. The reason for that, for example, I want an object to be interacted only from a certain area around it, not from any angles. If the player is in that area, and if the player is looking at the object, I want it to be interacted. If I were to use raycasts, it would consume lots of performance to point the raycasts to only one area, because I want my checks to be precise.
By the way, other angle checks are done "after" the trigger check. So if the player is not in the trigger, there won't be angle checks.
