I am new to Unity and I'd like to know what's the best way to add a script to a Prefab.
I currently see two ways of doing so:
1) Use the Unity interface to add it to an existing prefab
2) Use the AddComponent following the code which instantiates the prefab
I try using the 2) everywhere as I am using git to source control my code and I think conflicts may be easier to resolve inside code (compare to inside .prefab files by instance). But I may be wrong.
Is there any unity good practice regarding this ?
That's indeed the only two ways to add a component to a GameObject.
The primary way you are expected to add components to GameObjects is the Unity interface. Being able to setup logic and data through the interface rather than code is one of the big benefits of using such a game engine. It gives you flexibility and it smooths the process for quite a number of operations.
AddComponent use leans more toward adding a component to change the behavior of an existing GameObject or to create a GameObject from scratch, both at runtime. Most people usually don't make an use of it.
Git handles .prefab merging just fine. These are basically just text files with tags and structure so that it can be interpreted by the engine and be readable for an user (think of XML files).
Related
I've just started my first Unity experience by moving a match-3 based game to Unity, and I want to be able to attach data to each available tile type specifying how likely that tile is to be dropped onto the board (and be able to override that value for each level). There are a few match-3 tutorials floating around, but besides a tendency to not explain how to make things happen in Unity, I haven't found any leveraging the Tilemap, which seems a shame since it looks like it provides a fair bit of necessary functionality. The only problem is, I don't see anywhere to attach data or a script to a base Tile, so I've been looking into whether going the Scriptable Tile / custom editor route would get me what I need; but then I run into the lack of instructions on how to get basic functionality on the custom editor (the ability to specify the underlying sprite seems rather fundamental, but I'm not finding anything).
Anyway, is the Scriptable Tile interface my best bet to get level-specific data attached to individual tiles, or should I be looking for a different way to get this data on there? Or should I just ditch the Tilemap and the functionality it does include out of the box altogether like all the tutorials seem to be doing?
I am messing with Unity's cameras for a school project, my plan was to change the way that coordinates are projected onto the projection plane to a projection onto a sphere using sphere coordinates. But, getting to the actual math behind the cameras has been a bit of a pain.
My first method involved messing with render textures but, theoretically, that won't work because the camera has already rendered a texture which I am modifying.
Next I tried to get into the code for the base camera, maybe make a copy of the camera to modify without messing the original, but then I ran into this, the code that sets all of the camera's parameters for the editor, I saw the reference to a few .h files.
Where can I access these files? I found files with the same names but not related to Unity. They were also different from each-other, making me think that the file above isn't referring to some sort of industry standard, but it might be.
Unity is generally considered to be made up of two parts; the managed front end, and the unmanaged back end. The front end code (written in C#) can be studied on GitHub here. The unmanaged code (written in C++) is proprietary and isn't freely available.
Unity is fairly modifiable, but there are a number of rules you have to follow.
A camera workaround might be to work with the Scriptable Render Pipeline (e.g. URP). But I'm not sure this actually addresses what you're trying to achieve.
I found a pack of unity assets (these 3D characters with built-in animations) that serves my purposes very well, but I want make slight feature changes to some of them. For example, I would want to change the color of some, maybe add a horn or other utensil, make the tail longer etc. I would like these changes to impact the animations minimally. I am wondering about what is the best workflow for this.
I looked into importing the .fbx files into Blender to make such featural changes, but the animations are not retained in Blender (this seems to inevitable according to some?). In general, most information is about workflows going from Blender to Unity, rather than the other way. I am thinking of importing the .fbx files into Blender regardless, without the animations, changing some features, and then importing back into Unity, hoping that the Unity animations can snap back onto the modified creature.
Since I am a beginner with both Unity and Blender, I wanted to check whether this is has a chance to work or whether there are better alternatives. Many thanks.
Unity animation if done using the main tool is probably just animating properties of the model/objects that are exposed to Unity's serialized interface, e.g. color, position, etc. So, either they animated the model hierarchy inside Unity (sounds unlikely), in which case the animation is part of an animation clip, or they did it in Blender, in which case the animation should be part of the fbx.
You can try an application like Fbx Review to view the fbx file and see if it includes the animation.
Unity Animation
Unity binds its animation streams with Transform/GameObject names. As long as you don't modify the hierarchy of the model, you should be able to modify it in blender like you want and later import into Unity.
Fbx Animation
Simply import into Blender, and make any changes that don't break the animations.
Alternative
If you really must, you can modify the imported mesh inside the Unity Editor. There's a few tools available for this in the assetstore.
Last Bet
Simply email the asset seller and ask them what the best way to proceed would be. For a 150$, they will probably be willing to provide this amount of support.
Unity's new "Prefab Variant" feature, introduced in 2018.3, is pretty sweet; you can learn more about it here.
I made some changes to an imported 3D model, preparing it for usage in my game, and then dragged the changed GameObject into the file area to save the prefab, when I was asked whether to save it as an original prefab or a prefab variant.
The first (original prefab) option basically removes ties to the source prefab (the 3D model), applying all overrides and setting it in stone. The latter (prefab variant) option still uses the 3D model prefab as it's imported, and applies all of the changes I've made as overrides atop that, meaning if I re-import the model, its new changes will propagate and the changes I'd made on the prefab variant would also still exist.
That sounds great! In fact, I can't think of any circumstance where I wouldn't want that. If I was changing the source prefab so much that the overrides became invalidated, then I'd need to redo work whether or not I used the prefab variant feature - no difference there.
Thus I can only think of benefits to using the prefab variant... Perhaps it's an overhead thing, but I don't know anything about that. I even get the feeling that there could be some performance benefits to using variants (deduplication of prefabs or something like that), but that's me just speculating.
Hence my question: when and why shouldn't I use the new prefab variant feature, and opt for original prefabs instead?
Variants are great if you want several versions of the same base object. if you have more than one type of the same object you should always use them. the overhead is practically the same, but its a great orginizational feature! since its mainly to improve ease of use, for multiple objects as well as workflow, there is a major caveat to using it.
Dont use this feature if your disorganized. but wait, your going to use it, its just to great, having all those different prefabs ready at a moments notice! so heres the thing...
if your making a new version of your base object, replace the base object... you dont want some to be a variant of the bas, and others the variant of a variant, keep it organized, and you will reap the rewards in the time-management are of your project!
What are the use-cases for using ExecuteInEditMode and what are for Editor scripts? When to use one instead of another?
ExecuteInEditMode - This is an attribute for scripts, denoted as [ExecuteInEditMode]. By default, MonoBehaviours are only executed in play mode. By adding this attribute, any instance of the MonoBehaviour will have its callback functions executed while the Editor is not in playmode. Use-Cases for this include, but are not limited to:
Position constraining – your script may help you position your game objects by constraint object positions using a custom algorithm.
Connecting objects – if the ComponentA of the ObjectA requires instance of the ComponentB that is somewhere on the scene, and you are able to find it using your code, then you can do it automatically instead of making the designer do it manually later.
In-Editor warnings and errors – Unity will generate a standard set of errors if something is wrong with your code or the initial Unity components setup. Still, you won’t receive any warning if you create a room without doors or windows by mistake. This can be done by a custom script, so the designer is warned when editing.
Management scripts – These are scripts that are keeping things in order. Let’s say that your scene has 5 cameras, but all these cameras should have the same FOV parameters. Instead of changing those manually (yes, you can select all of them, but there’s no guarantee that someone else will do the same) you can make your management script adjust all values using one master value. As a result all single camera parameters will be locked and can be changed only by using the management script.
The Knights of Unity have released a tutorial on some sample functionality for ExecuteInEditMode that expands on this.
Editor Scripts - This is a collection of scripts that extend the Editor class, a Base class to derive custom Editors from. This can be used to create your own custom inspector guis and editors for your objects. For more information, check out this video on Editor Scripting. Since Editor Scripts are programmed, you may also want to view the Scripting API.
With Editor you customize MonoBehaviour appearance.
For ExecuteInEditMode most use cases would be modification of Scene View, for example Mesh Renderer (I do not know if Mesh Renderer uses ExecuteInEditMode but it could), it will render Mesh in game but it does also render this mesh in scene view.
Some other use cases: validation, communication with other components, modification other components, modification gameobjects, basically you can do most of things that you could do in-game and in-editor.