koobas.hobune.stream
Questions about Platform Dependent Compilation
Source : http://docs.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html
The scenario is : the above script is attached to many waypoint objects. They are a gameObject with a box collider set to trigger (no renderer).
When I build this project :
does the build still include a script attached to each waypoint object?
Is it just a blank script?
Does Unity still have to spend time on start-up reading all these scripts even though they are blank (to find and execute awake and start functions)?
How do I write this question more clearly? If I have a whole script wrapped in if UNITY_EDITOR , when I build, does a blank script still get compiled and attached to the gameObject? How does this affect optimization when I have 200 objects that Unity has to find and check the script on initialization?
Edit :
what kind of drop in performance or lag at startup is incurred by having many gameObjects with an empty script attached?
Does this performance issue only happen at startup, as there is no Update function on the empty scripts?
Is this whole issue negligible because they are all the same class?
Using this script as my example :
#pragma strict
#if UNITY_EDITOR
function OnDrawGizmos()
{
var col : BoxCollider = GetComponent.< BoxCollider >();
if ( col )
{
Gizmos.color = Color.red;
Gizmos.matrix = transform.localToWorldMatrix;
Gizmos.DrawCube( col.center, col.size );
}
}
#endif
Suitable question checklist :
is it about Unity? : yes
of interest to more than one person? : should be, it's about optimization and gizmos
has a specific answer? : they are yes/no questions, even though I asked more than one question
looking for code or theories? : no, I want to understand the process, insufficient information in the API
duplicate question? : not that I can find (https://www.google.com.au/search?q=Unity+Questions+about+Platform+Dependent+Compilation)
other considerations? : even though more than one question was asked, they all relate to the same main question 'does a blank script get compiled and attached when using Platform Dependent Compilation in a build?'
Why don't you give it a try?
$$anonymous$$ake a simple only IPHONE compile (just for example, could be any platform).
Create a code that is adding a IPHONE component to an object.
Add a script to check if the gameobject has that component.
Run it on standalone and you should get your answer :)
Cool, thanks for posting this question. This is essentially what I needed to know too :)
That was a great idea @dorpeleg , so I did. Unfortunately, the results indicated there was a component script attached to the gameObject, just as I assumed.
So the question is now :
what kind of drop in performance or lag at startup is incurred by having many gameObjects with an empty script attached?
Does this performance issue only happen at startup, as there is no Update function on the empty scripts?
Is this whole issue negligible because they are all the same class?
(no, I don't have profiler, and am not using my pro trial until I really need to use profiler for testing a hopeful release)
using the above script attached to 3 red cubes, this was my test :
#pragma strict
function Start()
{
var gizmoScript : GizmoScript = gameObject.GetComponent( GizmoScript );
if ( !gizmoScript )
{
renderer.material.color = Color.green;
}
}
This must be a common thought. Gizmos are highly documented. $$anonymous$$y presumption is that the platform dependent code is checked but not executed, so only a negligible amount of overhead. Although to know for sure would be nice.
$$anonymous$$aybe the forums would be a better place to ask… $$anonymous$$ore of the Unity developers tend to respond there than here.
For code that is intended to be solely executed in the editor, is it architecturally impossible for you to have a child game object that is tagged as 'EditorOnly'?
Well, like others said already you can't really create a MonoBehaviour that isn't included in a build. Here are the possible problems:
UnityScript
If you use UnityScript and wrap everything in your script in pre-processor tags Unity will still create the class. The class will be an empty class. This is because Unity will create a MonoBehaviour for every *.js file, no matter what you put in the file. So in a build the class will still exist, but it's empty.
C#
If you use C# and wrap the whole MonoBehaviour in pre-processor tags the class itself will not be included in the build. If you had an instance of that script attached to a GameObject in a scene or a prefab you will get this warning at the startup of your build:
"The class defined in script file named 'YourClassName' does not match the file name!"
This is because:
Asset Serialization
When Unity saves a prefab or scene to a file it has to store all the information required to restore an instance of a class in the asset file.
So a scene asset for example has a list of GameObjects that are inside the scene. For each component on the GameObjects Unity will store the type of the component and any additional information that the object needs / specified.
All MonoBehaviour scripts are simply of type "MonoBehaviour". That is because from the engines point of view (so i talk about the native code part) all scripts are "just" MonoBehaviours. The .NET / Mono classes you create in Unity doesn't exist in the actual engine, only in the scripting environment: Mono.
When Unity loads a scene or instantiates a prefab it does two things: It creates the actual GameObject in native code with all it's components, where all your scripts are just MonoBehaviours. It also creates the "managed" representation of each GameObject and component in the scripting environment and wlll link them together. Since Unity analyses each of your class at compile time Unity will only call those methods on your script that have been implemented. Since the class is empty(UnityScript) or missing(C#) it won't call any method at all.
To sum up:
Scripts which are empty but attached to gameobjects in a scene or prefab will go into the build. It will require some space in the serialization data of the scene / prefab and the part that is available will be loaded into memory. Since the script does nothing it has no real impact on Unitys update-business. It might cause a little performance hit when using GetComponent on a GameObject where the script is attached since it has to check an additional component. When you cache your components this isn't a problem at all.
If you really need MonoBehaviours only in the editor, when using C# you could wrap them completely in preprocessor tags but don't attach them to GameObjects in the scene. You could use an editor script (EditorWindow or custom inspector) to temporarily attach your script to a gameobject in the editor. Make sure to set the hideFlags to DontSave. That will prevent Unity from saving the component into the scene. Note: Such a MonoBehaviour will be lost at each playmode change or scene reload since it only exists in memory.
Keep in mind if you wrap a C# MonoBehaviour in UNITY_EDITOR tags the class won't exist in the build, so don't use the script name in any runtime scripts or you can't build your game.
Hell, when does the preview get fixed... (or better the actual post). In the preview a single - or = is enough to create a header, in the actual post only 3 are recognised.
A preview is a nice feature, but if it shows things in the wrong way it would be better without.
Thank you for such a detailed and informative answer. I have a great amount to learn about $$anonymous$$ono and NET, and an answer like this is extremely helpful in beginning to understand the process.
there are a few problems with the 'site atm. For 2 months now send message in the mod que has been broken, user search also not working, and as I type the timestamps and post options are broken (edit, delete, more).
