Things you may not have known about Unity3D

What's the cart about

I would like to describe the possibilities, and partly the features that are present when developing on this engine. I have been working with Unity3D for about three years, so my thoughts have accumulated enough for an average article like this. In some places I will be wise through chur, and talk about what is unlikely to be useful to you, but for the most part the story will be about very simple and frequently used things (if you know about them of course).

Editor mode for debug.

Do you know such moments when we have a private field for a component, and we need to see its value? I used to either always display its value in the log, or quickly select it with the necessary attributes, or do it at all public. But there is a way much cooler.



To demonstrate, I created a simple component:
')

using UnityEngine; using System.Collections; public class PrivateFieldTest : MonoBehaviour { private int Score; } 

As you can see in the screenshot, everything private is displayed in a darker color. The interface has also changed significantly, this mode is not suitable for operation, and it is terribly inconvenient, but for debug it is. Of course, this is hardly useful if you connect a third-party debager, but the feature is useful. Also, as far as I understand it, all component customizers do not work under this mode. Let's say it looks like a window with the settings of the build in debug mode.

Start, it's trap

The start method can work as corutin. With Update, let's say that there is no such horse move.

 using UnityEngine; using System.Collections; public class StartIsCorutineTest : MonoBehaviour { IEnumerator Start () { print("I'm wait 5 second!"); yield return new WaitForSeconds(5); print("I'm done!"); } } 

This is quite useful when something can cause some delay in the start. Of course, you can call corutin directly from the start, but so agree concisely.

SendMessage. Or a thing that makes you happy.

I wondered for a long time whether it was worth adding a description of this opportunity, because many people already know about it, but I had a couple of colleagues for whom this piece turned out to be a discovery. The chip is what. Suppose we have a certain component and it needs to urgently inform the other component of something important. What is the usual approach:

 gameObject.GetComponent<Health>().TakeDamage(60); 

Very exciting, slightly massive syntax (but still we saw C ++ according to new canons). But the main problem lies in the fact that we need to know the type of component to which we get the link. SendMessage helps to get rid of this nuance, and it only needs to know the name of the method and the arguments.

 gameObject.SendMessage("TakeDamage", 60); 

The problem is, of course, that it does not return what the called method should return. But you can create a trap plan, and get your little JS which by the way is, but it is not really JS. Suppose passing in the arguments call back function to accept values ​​for return. It is stylish, fashionable, youth and should not be censured in a modern and tolerant society. And there may be problems if the component that has a method with the same name is weighing.

Scale of object breaks batching mesh

Recently, there have been frequent questions on this topic. Partially this is so, the picture above would have come in perfectly. There is a great chance that it will break, but it may not break. There are many factors, let's turn to the off help :

- For Dynamic Batching, as a rule, objects must have the same Scale, the exception is that if all objects are not evenly scaled, they can stick together.

What this means, I myself did not fully understand, for this I simply do not scale. If the batching fails, it will increase Draw Call, which is very bad.

The selected object can be fixed in the inspector

It is useful when we have a lot of objects in the scene, and we need to put a link to one of them in some component that is already on one of the objects. As a rule, there is enough selection of an object with a component, and dragging an object from the hierarchy. But there may be a problem when both objects are far enough from each other (in the hierarchy) because of which a nervous tic can begin. But there is a small lock which the inspector fixes on a certain object.



You can also open many tabs with the inspector and clamp the right on the right objects.

WWW Memory leak.

The WWW class has a very serious problem that makes itself felt when you need to load a lot of textures. The help example contains the following code:

  IEnumerator Start() { WWW www = new WWW(url); yield return www; renderer.material.mainTexture = www.texture; } 

The problem is that if you receive a texture through the field, then a new texture is created, each time, which also does not want to be unloaded from memory.
As a result, I applied such code that allows you to get rid of it:

 //    . public override void OnWWWFinish(WWW www) { Texture2D tex = new Texture2D(4, 4, TextureFormat.RGB24, false, false); www.LoadImageIntoTexture(tex); tex.Compress(false); www.Dispose(); } 

Farewell words

In one sitting, we didn’t remember much, but describe even less on the go. But I hope I described really interesting things, mostly, of course, by the editor. Did you do the right thing with the little things? I dont know. Like it, I will write more, I will not like it, I will still write.