Content directories: Beyond the AssetBundle

Sep 22, 2026|6 Min

George Ing - Unity Technologies

Senior Engineering Manager

Cette page a été traduite automatiquement pour faciliter votre expérience. Nous ne pouvons pas garantir l'exactitude ou la fiabilité du contenu traduit. Si vous avez des doutes quant à la qualité de cette traduction, reportez-vous à la version anglaise de la page web.

Cliquez ici.

Un peu sur le contenu dans Unity aujourd'hui

Depuis Unity 2.1, le modeste AssetBundle a soutenu le contenu Unity distribué en dehors du binaire Player. Ces vingt dernières années, un nombre extraordinaire de jeux ont utilisé les AssetBundles comme représentation de leurs données, y compris certains des titres les plus importants au monde.

À un niveau de base, chaque AssetBundle est une unité indivisible pour la distribution, le stockage et le chargement. Les AssetBundles suivent leurs dépendances au niveau du paquet, formant une unité monolithique plus grande qui, pour des raisons d'efficacité, doit être téléchargée, chargée et déchargée ensemble.

En raison de cette spécification, la manière dont un titre définit sa disposition d'AssetBundle est un facteur principal dans tout, de ses performances en temps réel à sa taille de téléchargement. Ceci est vrai que l'on utilise directement les AssetBundles, ou via le package Addressables.

Aujourd'hui, nous allons parler de quelque chose de différent pour l'exécution Unity.

Présentation des répertoires de contenu

Les répertoires de contenu sont un remplacement fondamental, plus performant et plus granulaire des AssetBundles. Ils sont disponibles aujourd'hui dans Unity 6.6 comme alternative aux AssetBundles envoyés avec le Player. Pendant la génération Unity 7, la pile technologique s'étendra pour gérer une livraison complète et granulaire par voie hertzienne (plus de détails plus tard - c'est très cool).

Plutôt que de compiler les ressources dans de grandes unités chargeables, les répertoires de contenu fournissent au runtime Unity la capacité d'identifier, de charger et de décharger indépendamment des artefacts individuels(maillages, textures, etc.) avec une saturation complète des ressources matérielles et une déduplication de contenu implicite.

Diagramme montrant comment les ressources Unity sont chargées depuis le stockage local vers la mémoire de travail. À gauche, un panneau « Stockage local » contient neuf icônes d'assets Unity (maillages 3D, atlas de sprites, clips audio et préfabriqués). Une flèche étiquetée « Charger individuellement » pointe vers la droite vers un panneau « Mémoire de travail » contenant seulement trois de ces éléments, avec un espace vide en dessous étiqueté « Disponible pour d'autres travaux. » Sous la flèche, un sous-titre indique « Charger → utiliser → libérer. »

La gestion du contenu dans les projets Unity est maintenant plus facile que jamais, avec des compilations plus rapides et moins de préoccupations concernant la colocalisation des actifs et les mises en page des AssetBundle.

Les jeux que vous construisez sont plus petits, plus rapides, dédupliquant implicitement et ont accès à une gestion de mémoire dynamique complète via un nouveau type de référence chargeable. Pour les personnes utilisant Addressables pour le contenu regroupé avec le Player, vous pouvez passer aux répertoires de contenu aveczéro modification de code.

Comment avons-nous fait que cela arrive ? Regardons sous le capot de chaque étape du pipeline.

Une base familière : Construire

En 2019, nous avions une discussion sur ce que nous voulions d'une base de construction sérieuse dans Unity : parallèle sur chaque cœur, déterministe, entièrement mise en cache et capable de partager ses données de construction entre les machines. Il s'avère que certains de nos collègues expédiaient une API avec exactement ces propriétés depuis des années, le cadre d'importation d'actifs.

Donc, le processus de construction du répertoire de contenu s'exécute dans le cadre de l'importateur d'actifs standard. Chaque actif est construit individuellement par un importateur d'actifs, isolé et hors processus. Les constructions sont déterministes, avec mise en cache de la base de données d'actifs, saturation complète de tous les cœurs matériels et prise en charge native des accélérateurs pour des constructions partagées rapides.

Ce n'est peut-être pas la première fois que vous entendez parler de ce système de construction. Certains d'entre vous se souviendront du pipeline de construction multi-processus que nous avons évoqué dans Unity 2023.1. C'est la même fondation.

Diagramme montrant comment les fichiers sources sont convertis en assets Unity via le Build Importer. Deux fichiers FBX produisent chacun deux objets AssetBundle (affichés sous forme d'icônes de paquet bleues et grises), tandis que deux fichiers PNG produisent chacun un seul asset de sprite/texture (affiché sous forme d'icônes carrées à damier). Les flèches de branchement des fichiers FBX illustrent qu'un seul fichier source 3D peut générer de multiples ressources d'exécution.

Le résultat est un groupe lâche d'artefacts très granulaires, un petit manifeste suivant les dépendances entre eux, et un nouvel ensemble de fichiers de diagnostic pour rendre votre construction plus facile que jamais à comprendre.

C'est incroyablement simple.

Une base familière : Adresser

Si vous ouvrez un répertoire de contenu construit et que vous regardez les artefacts, vous remarquerez que chaque artefact a un nom haché assez étrange :

c0152db4dd710be51b2decb997325f34.cf
f0a44ad4a4babd121543fd44032928e7.resS
4226b5c16a50dab6eff0f08dd1253d4b.resource

Voici ce qui est cool - ce n'est pas un hachage aléatoire. Au lieu de cela, le système de répertoire de contenu utilise le même modèle de stockage adressé par contenu utilisé par des technologies comme Git. Chaque fichier de contenu est nommé et référencé par un hachage de son contenu. Ce modèle est incroyablement utile au runtime Unity car il lui permet de dédupliquer implicitement le contenu comme une fonctionnalité native.

Ceci étant dit, le stockage adressé par contenu avec un véritable graphe de dépendances présente un risque de forte volatilité. Considérez la relation la plus simple possible entre deux artefacts :

A → B

Mettre à jour B et les changements de hachage de B. Malheureusement, parce que A référence B, le hachage de A change aussi. Mieux encore, cela se propage tout en haut de la chaîne.

Au lieu de cela, les artefacts ne se référencent pas par hachage de contenu, ils se référencent via un identifiant stable. Le manifeste de construction conserve une petite table de consultation mappant les identifiants stables aux hachages de contenu.

Avec ceci, l'exécution a tout ce dont elle a besoin pour charger !

Une base familière : Load

Dans les répertoires de contenu, nous introduisons un système de chargement dynamique incroyablement performant.

Lorsqu'un répertoire de contenu est monté, le système de chargement lit le manifeste et résout les dépendances d'identifiant stable entre les artefacts. Il permet à chaque artefact d'être chargé et déchargé entièrement indépendamment, sans aucune pollution des artefacts co-localisés (rappelez-vous le problème avec les AssetBundles - une unité monolithique et indivisible ? Parti.)

Aux utilisateurs de DOTS, le format de fichier sous-jacent des artefacts peut également vous paraître assez familier. Les répertoires de contenu produisent et chargent la prochaine génération du format de fichier de contenu que nous avons introduit dans DOTS en 2022, apportant la technologie qui a alimenté le chargement d'Entities multi-threadé pendant quatre ans à tous les assets.

C'est un système de chargement entièrement asynchrone pour les opérations de lecture et de désérialisation. Cela signifie une bande passante de chargement plus élevée et une utilisation des API de lecture asynchrone spécifiques à la plateforme.

Diagramme comparant deux pipelines de chargement d'assets Unity. La section supérieure, intitulée « AssetBundles », montre un fichier sérialisé traité séquentiellement : chaque asset passe par Read puis Deserialize un par un avant une étape finale Awake, les téléchargements GPU n'ayant lieu qu'à la fin. Ceci est étiqueté « Séquentiel ». La section inférieure, intitulée « Répertoires de contenu », montre un fichier de contenu utilisant un pipeline jobifié : tous les actifs sont lus en parallèle d'abord, puis les étapes Deserialize et Awake de chaque actif sont échelonnées et chevauchées, avec des téléchargements GPU distribués tout au long du processus. Ceci est étiqueté « Jobified », illustrant l'avantage de performance du chargement parallélisé par rapport à l'approche séquentielle AssetBundle.

Plus excitant encore, le répertoire de contenu foundation nous permet d'apporter un type de référence moderne et chargeable à Unity pour la première fois, appelé Loadable.

Mesh bodyMesh;
bodyMesh.Load();

Ceci est une référence réelle et chargeable, intégrée directement dans le moteur pour les projets basés sur le répertoire de contenu. Les objets référencés par les Loadables seront tirés dans la construction, mais ne seront pas chargés avant que vous n'appeliez le Loadable. Le couplage des Loadables avec l'interface ScriptableObject (très) familière vous permet d'organiser rapidement le contenu chargé dynamiquement incroyablement.

C'est un principe dont nous sommes très enthousiastes. Avec les répertoires de contenu et les Loadables comme fondation, n'importe quel asset dans Unity peut devenir une unité chargée et déchargée indépendamment - une capacité intégrée directement dans le moteur - des éléments d'un créateur de personnage aux morceaux d'un terrain diffusé, sans nécessiter de dispositions d'AssetBundle ou de définitions de groupe à concevoir.

Construire des jeux à grande échelle dans Unity n'a jamais été aussi facile !

Mettre les répertoires de contenu à l'épreuve : Slime Rancher 2

Au cours des derniers mois, quelques-uns de nos partenaires ont eu la gentillesse de nous permettre de tester des répertoires de contenu avec leurs jeux.

Par exemple, examinons le excellent jeu Slime Rancher 2 de Monomi Park et certains des avantages qu'il tire du passage aux répertoires de contenu. (Slime Rancher est disponible sur Steam !) Slime Rancher, Slime Rancher 2)

Temps de construction incrémentale