Créer son jeu avec Unity3D !

[Grhyll]

On sent le vécu

[Metalink]

3 ans que je bosse professionnellement sur un gros jeu avec Unity, malheureusement ça fait partie des trucs connus

[Sifr]

De mon côté j’ai aucun debug.log actif, j’ai un boolean pour les sortir ou non.
Et j’ai fait sauter aussi tous les samples du profiler dans mon code.
Ca reste pareil.

Je me demande si cela vient pas des TryGetComponent en fait.

J’en ai remplacé pas mal avec cette variante au lieu du GetComponent classique.

Je vais faire un test... ça laisse rêveur ce genre de truc quand même.

[Metalink]

Le GetComponent c'est effectivement à éviter de faire à toutes les frames, ça peut couter très très cher. Il me semble qu'aujourd'hui Unity fait un peu de cache en interne, mais le faire soi même c'est un gain de performance garanti.

[Sifr]

La plupart de mes components sont mis en cache dès le start.

Mais dans certains cas je ne vois pas comment les cacher.
Par exemple, pour déterminer si un gameobject est un batiment ou une unité.
Je fais un test sur le Trygetcomponent et après j’applique ce qu’il faut.
Donc parfois oui j’ai pas mal d’appels si le nombre d’unités augmentent.

Mais pourquoi générer autant en editor et pas en build.

[Grosnours]

Question conne (puisque je connais pas ton code), tu peux pas plutôt différencier les objets différemment genre par des tags, leur nom, leur layer, ou une autre méthode moins gourmande ? Comme les autres l'on dit il vaut mieux garder les Update() et FixedUpdate() aussi légers que possible.
Le code compilé passe sur tout un tas de choses qui peuvent provoquer un arrêt immédiat en mode éditeur (y compris les certaines NullException), il ne faut pas trop prendre le comportement/les perfs dans l'éditeur comme parole d'évangile quant au résultat final.

[Sifr]

Question conne (puisque je connais pas ton code), tu peux pas plutôt différencier les objets différemment genre par des tags, leur nom, leur layer, ou une autre méthode moins gourmande ? Comme les autres l'on dit il vaut mieux garder les Update() et FixedUpdate() aussi légers que possible.
Le code compilé passe sur tout un tas de choses qui peuvent provoquer un arrêt immédiat en mode éditeur (y compris les certaines NullException), il ne faut pas trop prendre le comportement/les perfs dans l'éditeur comme parole d'évangile quant au résultat final.

Je pourrais effectivement passer par les tags pour éviter l’appel au getcomponent dans le if ça limiterait déjà.

Il me restera alors le getcomponent pour accéder aux fonctions et variables du composant en lui-même.

Mais ce que je retiens surtout de toutes les remarques et tips c’est que je suis pas mal côté optim de code et qu’il faut pas trop que je me soucie de ce truc en mode editor, je prendrai moins d’unités pour faire de l’optim, ça évitera de saturer l’éditeur, tout en sachant qu’en build je serai beaucoup mieux et que j’ai de la marge.

[Grosnours]

Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
Je ne sais pas si je suis clair.

[Molina]

Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
Je ne sais pas si je suis clair.

Tu veux dire les mettre en fils dans une hiérarchie ou les mettre dans une liste que tu fous quelques part ou y accéder rapidement ?

[Sifr]

Autre méthode plutôt que de chercher activement des objets : les faire s'enregistrer à leur création auprès d'un objet référence, dont on peut se servir pour accéder à tous les objets enregistrés et à leurs composants.
Je ne sais pas si je suis clair.

C’est ce que je fais dans d’autres circonstances dans mon code, mais là il semble d’après ce que j’ai lu/vu que le GetComponent reste supérieur en terme de perfos par rapport au parcours d’un array qui peut du coup s’allonger pas mal en fonction des objets actifs.

Par objet j’ai maxi sept composants pour les unités les plus complexes ça limite l’impact de la recherche sur l’objet.

[Grosnours]

Tu veux dire les mettre en fils dans une hiérarchie ou les mettre dans une liste que tu fous quelques part ou y accéder rapidement ?

Plutôt b) mais a) fonctionne tout aussi bien (il faut parfois se méfier de certains effets de bord des arborescences dans Unity mais là cela devrait aller).
Tout dépend du code, des objets à spawn et du projet en général.
Dans un de mes projets j'avais plutôt utilisé des tags pour retrouver rapidement toutes les sources de SFX ambiants en runtime mais j'aurai pu procéder autrement aussi.

C’est ce que je fais dans d’autres circonstances dans mon code, mais là il semble d’après ce que j’ai lu/vu que le GetComponent reste supérieur en terme de perfos par rapport au parcours d’un array qui peut du coup s’allonger pas mal en fonction des objets actifs.

Par objet j’ai maxi sept composants pour les unités les plus complexes ça limite l’impact de la recherche sur l’objet.

Effectivement à toi de voir ce qui te convient le mieux.



Au fait, si des gens par ici on réussi sans trop de problèmes à bake les paramètres d'illumination dans un prefab cela m'intéresse monstrueusement. J'en ai besoin pour une version de nuit de tous les éléments d'une ville low poly sans utiliser de sources lumineuses qui seraient très couteuses vu le nombre d'instances. Et les matériaux émissifs ont leur limites, on ne peut pas les utiliser pour tous les cas.
Il y a des threads de ce genre : https://forum.unity.com/threads/prob....324514/page-9 mais après avoir testé à peu près tous les scripts donnés là dedans tout ce que je peux conclure c'est que cela fonctionne sans fonctionner et que bien entendu cela dépend totalement de la version d'Unity.
Il y a bien cela : https://unity.com/how-to/advanced/op...g-mobile-games mais d'une part je ne peux pas tout utiliser là dedans et d'autre part j'en pige bien la moitié pas plus, je dois être un peu simplet.

[schouffy]

Tiens, une question me taraude.

Je pensais que le poids de la build finale était majoritairement fonction des assets (textures, sons et meshs/anims principalement). Mais je constate, en rajoutant des scenes à ma build, qui ne font que réutiliser les mêmes assets que les autres scenes déjà présentes, le poids de la build augmente systématiquement de façon non négligeable.
En gros, avec une map j'avais un zip de 150Mo, avec deux maps 250Mo, et avec trois maps 350Mo.
Et je vois bien en effet dans le répertoire Data que levelX et levelX.resS pèsent chacun un bon poids, et j'imagine que mes assets sont dans les fichiers sharedassets.

C'est quoi du coup, tous ces Mo dans les level ? Les lightmaps ? Parce que mes niveaux sont assez simples et je suis pas sûr de ce qui pourrait nécessiter autant d'information pour être représenté (cross topic prototypes )

[Grosnours]

Cela dépend de comment tu as éclairé la scène bien sur. Question : est-ce que tu as regardé ce que te donne l'Editor Log après un build ? Une autre question est quel poids font tes assets seuls ?

[raaaahman]

Un e-book sur l'optimisation de jeux Unity, gratuit pour la journée: https://www.packtpub.com/free-learning

P.S.: Ca ressemble à de la pub de m**** mais je n'ai aucun intérêt chez Packt Publishing.

[Sifr]

Tiens un petit problème rigolo que je cherche à optimiser côté ergonomie.

J’ai un sous marin sous une surface d’eau, visualisation de la caméra en mode STR.
Un collider rectangulaire permet de détecter le clic souris sur le sous marin.
Un collider rectangulaire de faible épaisseur permet de détecter un clic sur la surface de l’eau.

L’idée c‘est que si le joueur clique sur l’eau, il faut déselectionner une action, une entité ou donner un ordre de mouvement etc...

Maintenant, pour pouvoir sélectionner le sous marin je suis obligé d’augmenter le collider pour qu’il dépasse la surface de l’eau afin qu’on puisse le sélectionner sans que le raycast touche l’eau avant.

Mais en tant que joueur, on a plus tendance a cliquer sur le sous marin que juste au dessus, voir sur le kiosque pour le selectionner.
Du coup c’est chiant on clique plus bas et le raycast avec l’inclinaison caméra touche le collider de l’eau et pas la base de celui du sous marin.
Ca sélectionne pas et on est forcé de bouger un peu le curseur pour tomber au bon endroit.

Ma question : y’a t il une autre technique connue/usuelle qui permette de faire une sélection au travers d’un collider pour voir s’il y en a un autre derrière pour optimiser ce type de test de sélection sans bidouiller du layer ?

[Louck]

Plusieurs idées à chaud:
- Souvent dans les RTS, les unités ont un "drapeau" (ou une icone) pour être visible et être identifiable de loin, et souvent ils se trouvent en hauteur. Le joueur peut cliquer sur l'icone pour sélectionner le sous-marin.
- Pour un jeu de sous-marin, je pense que l'eau fait partie de 90% du décor du jeu ? Si l'eau a un collider, est-ce que tu prévois une action spécifique à l'eau si le joueur clique dessus ? Sinon, autant virer le collider et considérer l'intégralité du jeu comme un terrain jouable (clique gauche dans le vide = déselection, clique droit dans le vide = action).
- Tu peux jouer avec les layers et prioritiser: Tu test d'abord si le joueur clique sur le sous-marin (en testant le layer utilisé par l'unité). Ensuite tu vérifies s'il clique sur l'eau (en faisant un autre raycast, mais cette-fois avec le layer utilisé par l'eau).

[Sifr]

La proposition 3 me va bien. Facile à mettre en oeuvre et robuste. Merci.

Je peux pas supprimer le collider de l’eau car je n’ai pas que des sous marins, mais aussi les navires, les hélicos et les avions même si ces derniers ne sont pas cliquables vu qu’ils sont lancés depuis une base aérienne, le ciblage se fait avec le collider surface d’eau.

[Grhyll]

Après tu as aussi Physics.RaycastNonAlloc qui va te renvoyer plus d'un hit, et du coup tu peux juste parcourir ta liste de hit pour voir celui qui a la plus grosse priorité.

[Sifr]

Après tu as aussi Physics.RaycastNonAlloc qui va te renvoyer plus d'un hit, et du coup tu peux juste parcourir ta liste de hit pour voir celui qui a la plus grosse priorité.

Ah oui et je cherche s’il y a un composant Unit dans la liste, ça va passer sans soucis.

En parlant de soucis, je suis fou, j’ai converti tout mon Projet avec le HDRP et je pleure.

Passé trois heures à comprendre leur système d’éclairage... et trifouiller pour avoir enfin un peu de lumière correcte.

Tous les shaders HS, j’ai dû refaire mon eau dans Shader Graph. Comme découverte de l’outil ça a été violent
Et les particles systems sont majoritairement HS aussi vu la gestion de la transparence.

Question pour ceux qui pratiquent le HDRP : c’est normal qu’on ait du mal d’avoir les effets bien visibles issus du particle system ?
Il faut passer par le VFX graph pour refaire l’équivalence sous ce render pipeline ?

[Sifr]

En fait j’ai trouvé, je sais pas si c’est idéal mais en changeant les shaders des particules avec leur version particule/additive ou autre ça remet les choses en ordre.
Bizarre d’ailleurs que les effets génériques fournis par Unity n’héritent pas direct de ceux-ci.

En tout cas le HDRP est génial, je pestais contre le rendu pourri de mes modèles issus de Magica Voxel quand c’est super beau dans le rendu de Magica et là je retrouve enfin la même chose

[schouffy]

Si tu ne vises pas le photo réalisme, en général il vaut mieux s'orienter vers l'Universal RP.
Sinon oui l'éditeur est encore bien buggé avec le SRP, tu verras souvent la couleur mauve
Pour ton problème de colliders, j'arrive après la bataille, mais pourquoi ne pas mettre tes colliders sous marins & navires, et l'eau sur 2 layers différents ? Comme ça dans ton clic, tu raycast uniquement le layer contenant les bateaux/sous marins et si tu hit rien, c'est que tu hit de l'eau ?

[Sifr]

Ils sont déjà sur deux layers différents.

Mais oui l’idée de tester par ce biais est pas mal aussi.

Je vais tester ce qui est le plus efficace. Faut juste que je vois les conséquences entre le clic unité / batiment / la déselection / le clic glissé pour la multi sélection / le clic des super armes et de ciblage des avions, ça fait un gros mix qui parfois part en sucette avec pourtant la bonne idée du moment

J’aime bien le HdRP, faire un shader avec fresnel et se rendre compte qu’il est invisible.. se gratter les neurones pendant une heure et comprendre qu’il faut forcer l’intensité des sources pour dépasser le seuil d’illumination global... c’est rigolo.

[Grosnours]

Tout le monde s'en tape, mais le baking de prefab, c'est dans la poche.
Grâce à Bakery, un de mes meilleurs investissements en tant qu'asset. On peut donc illuminer ses prefabs autant qu'on veut dans une certaine scène, calculer l'illumination, enregistrer les données dans le préfab et sortir l'asset dans une autre scène déjà pré-illuminé. Le tout même avec des lumières qui font partie du préfab et qu'on peut éteindre par la suite tout en disposant de leur lumière.
Résultat dans un monde instancié : vous pouvez disposer d'une illumination nocturne pour un cout faramineux de ....zéro. Il suffit de disposer de ses préfabs en version jour/nuit et de les créer/détruire dynamiquement à l'aube et au crépuscule pour avoir toute une ville illuminée sans la moindre lumière qui coute un bras. Pas mal de travail à faire en amont, mais le résultat en vaut laaaargement la peine.

[Sifr]

Tout le monde s'en tape, mais le baking de prefab, c'est dans la poche.
Grâce à Bakery, un de mes meilleurs investissements en tant qu'asset. On peut donc illuminer ses prefabs autant qu'on veut dans une certaine scène, calculer l'illumination, enregistrer les données dans le préfab et sortir l'asset dans une autre scène déjà pré-illuminé. Le tout même avec des lumières qui font partie du préfab et qu'on peut éteindre par la suite tout en disposant de leur lumière.
Résultat dans un monde instancié : vous pouvez disposer d'une illumination nocturne pour un cout faramineux de ....zéro. Il suffit de disposer de ses préfabs en version jour/nuit et de les créer/détruire dynamiquement à l'aube et au crépuscule pour avoir toute une ville illuminée sans la moindre lumière qui coute un bras. Pas mal de travail à faire en amont, mais le résultat en vaut laaaargement la peine.

Comment ça fonctionne exactement ?
On a toute l’illumination dans le prefab et ensuite on exclut celui ci de toute l’illumination de la scène ?
Ou faut quand même laisser un peu d’illumination globale ?

Dans mon environnement je crée les icones de mes unités par un chargement d’une mini scène qui snapshot tous les 3d des batiments et des unités donc les icones sont automatiquement remis à jour si je fais une modif.
Par contre j’ai toujours des problèmes d’éclairage et ça pourrait être une solution pour gérer la visu plus finement.

[Grosnours]

Tu prends ton préfab et le met dans une scène qui aura une illumination plus ou moins comparable à celle dans lequel il sera inséré (moi par exemple ce sera avec une skybox nocturne). Si ton préfab possède des sources internes d'illumination, tu leur rajoutes pour chacune d'elle un script Bakery d'illumination. Tu t'assures bien que le préfab est static. Ensuite tu rajoutes à la racine de ton objet préfab dans la scène un script Bakery particulier, tu l'appliques au préfab mère et tu lances le calcul de la lumière via Bakery.
Ensuite tu sauvegardes le préfab obtenu comme une nouvelle version dans ton projet. Puis tu va dans ce préfab et désactive la version Unity des lumières internes au préfab (juste le composant Unity de lumière, pas tout l'objet).
Tu testes le préfab résultat dans une nouvelle scène, et poum il a effectivement conservé tous les paramètres d'illumination internes et externes.

J'ai donc désormais des versions nocturnes de tous mes assets, avec une tonne d'illumination statique faite (plein de lumière de façades d'immeubles par exemple) mais qui me coûte pas un rond. Ce qui n'est bien entendu pas du tout le cas si tu rajoutes de véritables sources d'illumination. A chaque cycle jour/nuit, je crée/détruit dynamiquement tous les assets et les remplace par leur version jour/nuit. Tu peux faire cela de façon graduelle histoire de ne pas avoir de coût trop grand quand il y a beaucoup d'assets.

En théorie, le baking de l'illumination dans un baking est possible dans Unity de base, en pratique le thread à ce sujet dans les forums d'Unity dure depuis au moins 7 ans et tout le monde à des expériences radicalement différentes et qui dépendent totalement de ta version de l'éditeur. Avec Bakery, cela fonctionne out-of-the-box.

Les limitations de la chose est que ton préfab doit être statique et que l'illumination enregistrée ne projettera bien entendu aucune ombre à l’extérieur du préfab ou sur tout objet tierce.


Un exemple ici où on a le segment de route et la maison illuminés alors que la scène ne l'est pas et leurs illuminateurs internes sont désactivés.

[Sifr]

Merci c’est très intéressant. Je vais y trouver une utilité pour des scènes de nuit

J’ai encore une question simple mais qui me semble importante : y’a t il des paramètres capitaux à définir quand on fait un build ?

Jusqu’ici je cliquais et hop et puis je testais mais maintenant je voudrais en faire un vrai package possiblement testable.
Et je me demande ce que Unity capte dans son package de build.

J’ai déjà vu des users raler par exemple sur Jagged Alliance Rage que le build activait par défaut des trucs de tracking/module de pubs...
Je sais pas si c’est une légende mais par le passé j’aimais bien savoir ce que je lachais dans la nature.
Alors s’il y a un guide connu je veux bien la référence car cette partie me semble pas assez décrite.

[schouffy]

J'avoue que j'ai pas bien compris l'intérêt de tout ça. Le PBR, c'est pas justement pour avoir un seul asset qui pourra être utilisé dans toutes les conditions de luminosité ?
J'ai bien compris ton argument des performances, mais dans quel cas un asset peut-il désirer exactement le même éclairage dans deux contextes différents ?

[Grosnours]

J’ai encore une question simple mais qui me semble importante : y’a t il des paramètres capitaux à définir quand on fait un build ?

Jusqu’ici je cliquais et hop et puis je testais mais maintenant je voudrais en faire un vrai package possiblement testable.
Et je me demande ce que Unity capte dans son package de build.

Qu'est ce que tu veux dire par package de build ? Les packages que tu inclues dans tes builds via le gestionnaire ?
Si c'est le cas jepeux te faire un retour sur le package d'analytics et bien qu'on avait à l'époque vraiment fait une grosse personnalisation de ce qui était envoyé et comment (avec un téléphonage maison d'une tonne de données sur les machines utilisateurs dans le cadre d'un jeu 3D gourmand) tout cela était extrêmement peu utilisable, l'interface analytics du dashboard étant taillée uniquement pour l'aspect analyse consommateurs/ventes et supporte assez mal les data points personnalisés sur des tableaux à double/triple/plus entrées. Bref on a pas vraiment atteint notre but, qui était d'établir des guidelines générales sur quelles machines (RAM/CPU/CG) étaient nécessaires pour quelles usages.
Bon c'était il y a plus d'un an et l'interface à changé depuis mais je pense que le principe de base reste le même, un outil pointu à usage limité.

J'avoue que j'ai pas bien compris l'intérêt de tout ça. Le PBR, c'est pas justement pour avoir un seul asset qui pourra être utilisé dans toutes les conditions de luminosité ?
J'ai bien compris ton argument des performances, mais dans quel cas un asset peut-il désirer exactement le même éclairage dans deux contextes différents ?

Reprenons mon problème de base.
On est dans un cas où tu as un univers totalement instancié, avec une illumination totalement dynamique (cycle jour/nuit en particulier). Il y a cependant une énorme majorité d'objets statiques, très nombreux. La question est donc : comment les illuminer de nuit ?

Réponse 1 : leur filer des objets internes d'illumination, trop coûteux car le coût faible de base est démultiplié par le nombre d'objets.

Réponse 2 : créer dynamiquement des illuminateurs externes aux obets, mais vu le nombre élevé d'objets on arrive à un coût prohibitif bien que moins élevé que la réponse 1. Et c'est moins joli en rendu que la réponse 1. Je suppose que le PBR rentrerait en action dans ce cadre. Mais pour que le pBR fonctionne il faut des sources lumineuses, et ça c'est couteux.

Réponse 3 : créer une version nocturne de tous les préfabs avec l'illumination pré-calculée dans une autre scène et autant d'illuminateurs internes qu'on veut. Bakery permet aux préfabs de faire référence à la lightmap de cette scène dans laquelle ils ont été bake et de l'utiliser dans une autre scène. On a donc un résultat illuminé mais avec un coût nul (et aucun shader à ajouter, important ça). En fait après tests sur une carte avec des milliers de tronçons de route, on gratte une poignée de FPS de nuit (je ne sais pas trop pourquoi par contre).

Il y en a peut être d'autres réponses, mais je doute qu'elle aient un coût inférieur à la réponse 3.

Ce qu'on fait désormais c'est au lieu d'avoir un préfab avec la logique et les assets, on a un préfab père avec la logique de l'objet et un préfab fils qui possède l'objet physique. Ce dernier est crée et détruit à chaque transition du cycle jour/nuit, alternant entre le préfab version jour et le préfab version nuit. La création/destruction a un coût, mais il est subi uniquement deux fois par jour in game et peut-être intelligemment perlé pour en réduire l'impact.
Le véritable coût ici est en amont vu qu'il me faut maintenant générer des versions de nuit de centaines d'assets ce qui va me prendre un temps certain. Mais une fois que ce sera fait, on en parlera plus.

[schouffy]

Mais tes objets, en situation d'aube ou de crépuscule, ils n'ont pas un éclairage bizarre ? Soit tu affiches l'asset "jour" et tu obtiens un truc trop clair, soit tu affiches l'asset "nuit" et il est au contraire trop foncé.
Et ça veut dire quoi, que tous tes objets pop "LOD style" 2 fois par jour pour le joueur, aux heures que tu as choisi pour les transitions ?

Et ça veut aussi dire que tous tes objets ne pourront plus être impactés par un éclairage dynamique si tu voulais en rajouter ? Des explosions par exemple.

[Grosnours]

C'est un city builder low poly, la caméra utilisateur passe son temps loin des objets eux-même. Donc la transition brutale jour/nuit est peu gênante et peu ou prou fidèle au fait que l'éclairage public/entreprises/particuliers en général est un on/off par définition.
D'ailleurs si c’était vraiment pas un problème, je pourrais parfaitement créer un troisième préfab avec un éclairage intermédiaire (mais là je ne vois pas trop l'intérêt).
La meilleure solution est à mon avis de passer en prefab de base (non éclairé) à l'aube/crépuscule pour laisser l'éclairage solaire dynamique temps réel avec ombres faire son effet. La seule chose que je perds réellement est un poil de fidélité dans l'éclairage nocturne (lune/étoiles) mais il est par définition très faible est totalement inférieur à de l'éclairage nocturne de ville.

Pour ce qui est de l'éclairage, avoir l'éclairage statique pré-baked ne veut pas dire que les assets ne seront plus impactés par un éclairage dynamique. Pas d'une manière qui m'handicape en tout cas.

Pour illustrer voilà un exemple bateau (uniquement pour les routes) avec deux gros spot rouges et verts au dessus de la même ville en version jour et nuit (la nuit sera mieux faite niveau skybox, là c'est juste le jour sans le soleil pour vérifier que tout va bien).

Dans mon cas les performances sont infiniment plus importantes que la qualité du rendu et je ne vois pas trop comment obtenir des performances de ce type sans prefab baking ou sans devoir te taper des écritures de shaders à la pogne.