Les fichiers .meta

Comme précisé dans l’article intitulé Utiliser Git avec Unity :

il est indispensable d’utiliser un Version Control System lorsque l’on travaille sur un projet en Unity.

On remarque cependant que certains fichiers générés doivent tout de même être versionnés, en particulier les fichier .meta¹. Ceci est contre intuitif et semble aller à l’encontre de la philosophie de Git.

Les fichiers .meta servent en fait à stocker des metadonnées concernant les Assets importés dans les projets. En particulier, si on sélectionne un Asset dans la fenêtre Project, on obtient une fenêtre Inspector qui ressemble à ça :

Commencer avec URP

Dépréciée depuis Unity 2021
Depuis Unity 2021, il existe un template vide pour URP. Il n’est dont plus nécessaire d’effectuer les étapes détaillées dans cette page.

Le pipeline de rendu utilisé dans ce cours est le Universal Render Pipeline (ou URP)¹. Il faut donc créer un projet Unity avec une configuration particulière pour pouvoir l’utiliser. Bien que la documentation Unity suggère d’utiliser le template fourni² pour créer un projet basé sur URP, celui-ci contient beaucoup de choses dont nous n’aurons pas besoin. Ainsi, nous conseillons plutôt de commencer avec un projet vide (utilisant le Built-in Render Pipeline), puis de le configurer pour qu’il utilise URP³.

Utiliser Git avec Unity

Il est indispensable d’utiliser un Version Control System lorsque l’on travaille sur un projet. En particulier, un VCS :

• aide à travailler de manière collaborative;
• facilite la gestion des différentes versions du projet;
• permet de faire des tests en local, sans risquer de casser les versions existantes;
• autorise à revenir à une version précédente.

Unity propose déjà son propre système appelé Unity Collaborate¹. Il en existe beaucoup d’autres comme Perforce, Subversion, CVS, etc.

Erreur de résolution de template de projet

Lors de la création d’un nouveau projet, Unity affiche parfois l’erreur “Failed to resolve project template” comme indiqué sur la capture suivante :

Ceci est vraisemblablement causé par un bug ¹ lorsque le path est trop long, ou contient des espaces. Il suffit donc de changer le nom du projet, du répertoire parent, ou de déplacer le projet.

Références #

Null Reference Exception et Unassigned Reference Exception

Dans Unity, quand vous accédez à une variable mal initialisée (ou pas initialisée du tout), vous récupérez une NullReferenceException¹ ou une UnassignedReferenceException. Ces erreurs apparaissent dans la console de la façon suivante :

Les erreurs les plus fréquentes sont :

• utiliser une variable exposée dans l’Inspector mais non-assignée. Un simple drag and drop dans l’éditeur Unity suffit;
• utiliser une variable non-initialisée (contenant une référence nulle);
• mal épeler le nom d’un GameObject quand on utilise la fonction GameObject.Find()²;
• le Variable Shadowing³.

Le code suivant montre certaines de ces erreurs :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ExceptionsExample : MonoBehaviour
{
	public GameObject unassignedRef1;
	[SerializeField] private GameObject unassignedRef2;
	private GameObject nullRef1;
	private GameObject nullRef2;
	private GameObject nullRef3;

	// Start is called before the first frame update
	private void Start()
	{
		// #1: not assigned in inspector
		Debug.Log(unassignedRef1.name);
		// #2: not assigned in inspector
		Debug.Log(unassignedRef2.name);
		// #3: not initialized
		Debug.Log(nullRef1.name);
		// #4: typo so Find() returns null
		var nullRef2 = GameObject.Find("exceptionCubeWithTypo");
		Debug.Log(nullRef2.name);
		// #5: shadowing, so ok here, but not ok in Shadowing()
		nullRef3 = gameObject;
		Debug.Log(nullRef3.name);
		Shadowing();
	}

	private void Shadowing()
    {
		// #5: shadowing
		GameObject nullRef3 = gameObject;
		Debug.Log(nullRef3.name);
	}
}

Les Events dans Unity

Il existe plusieurs types d’Events utilisables dans Unity : les UnityEvents¹ et les Events C# natifs². Les Events offrent un moyen simple et efficace de construire un système de diffusion de messages. Ils suivent essentiellement le design pattern Observer³^.

Le seul avantage à utiliser les UnityEvents c’est qu’ils sont intégrés directement dans l’éditeur⁴. Cependant les UnityEvents sont beaucoup plus lents que les Events C# natifs⁵. En conclusion, utilisez les Events C# natifs de préférence.

Les pipelines de rendu dans Unity

Les étapes principales du pipeline de rendu pour OpenGL sont :

Unity propose 2 types de pipelines de rendu :

• Built-in Render Pipeline² : c’est le pipeline de rendu par défaut.
• Scriptable Render Pipeline (ou SRP)³ : c’est un pipeline de rendu configurable et pilotable grâce à des scripts C#.

La vidéo suivante résume les principales différences des pipelines de rendu dans Unity :