[RESOLU] Quel impact a un modèle en plusieurs objets (UV atlas)

[Farstone]

Bonjour , pour plusieurs raisons (notamment le bake "by mesh name" de substance) je fait mes modèle en plusieurs parties sous Blender. Le problème c'est que sur Unity les parties sont bien séparé, mais chaque sous-partie utilise 1 instance de material, je me retrouve avec un boulon en 4k à lui tout seul . Bien sur je dramatise un peu le truc, le GPU instancing viens à la rescousse d'après la communauté anglophone.
Voici ce que dit la doc de Unity à ce sujet : GPU Instancing
Quand je voie ça je commence vraiment à me poser des questions sur l'optimisation de mon workflow, le GPU Instancing aide mais j'ai l'impression qu'il n'amortie pas le choc à 100% (surtout avec de la 4k). Par exemple je travaille actuellement sur une voiture (vue les besoins du projet, séparer la voiture en 3 UV set me semble une bonne idée) 1 en 4k pour l'intérieur, 1 en 4k pour l’extérieur, et 1 en 2k pour les roues qui seront dupliquer, sa donne un peu ça dans Unity :

Véhicule
---Intérieur(material 1)
------Volant(copie de material)
------Siège(copie de material)
---Extérieur(material 2)
------Capot(copie)
------Coffre(copie)

J'aimerais savoir si je perd des performances en utilisant ce workflow, et quel méthode vous utilisez de votre côté.
Il me semble d’ailleurs que la lumière coûteras plus chère aussi, étant donnée que chaque sous objet à un mesh renderer.
J'ai la possibilité de regrouper les objet en 1 après le baking, et d'animer la voiture en utilisant le mesh, plutôt que les objet si c'est nécessaire, c'est juste une question de préférence.
Mais malgré tout, ce workflow n'a pas que des désavantages, si je veux qu'une pièce puisse être séparé de la voiture sans utiliser d'animation, ou encore lui ajouter un rigidbody pour un effet de dégâts.
J'attend vos avis avec impatiente, sa serrait dommage de se rendre compte d'une telle perte d'optimisation sur la fin d'un projet, surtout que je ne pense pas être le seul à utiliser ce workflow

[Alesk]

Salut,

Tout d'abord pourrais-tu contextualiser un peu plus ton projet ? C'est un jeu de course ? Une présentation de voiture ?

Ensuite tu sembles confondre matériaux et textures... La taille de la texture n'aura qu'un impact très minime sur la vitesse d'affichage (ça consomme surtout de la mémoire vidéo)

Pour ce qui est du batching pour économiser des drawcalls, c'est géré automatiquement par unity, mais avec certaines restrictions, listées ici : https://docs.unity3d.com/Manual/DrawCallBatching.html

Sinon oui, le gpu intancing semble être une bonne aide, mais là je n'ai pas encore eu l'occasion de le tester.

Plus de détails sur ce que tu cherches à faire pourraient aider à clarifier la réponse.

[Farstone]

En faite je fait le prototype d'un système de véhicule pour en apprendre un peux plus sur Unity et les outils disponible, mais comme c'est un prototype, autant pousser un peu le truc et essayer d'avoir un résultat modulaire, ergonomique et optimisé, pour l'instant je ne compte pas ajouter de système de customisation pour le véhicule, mais je veux qu'il soit possible de l'inclure facilement si nécessaire. Je suis conscient de la différence entre une texture et un material, mais je ne comprend pas encore le fonctionnement approfondie des material dans Unity et comment sont gérer les performances à ce niveau (d'ou le sujet), je pense que je n'ai plus le choix et que je vais essayer d'en savoir plus sur leur fonctionnement pour être sur de ce qu'il se passe (si quelqu'un connait un sujet vulgarisant tout ça ).
J'ai d’ailleurs une autre question que je me pose depuis longtemps, à la place d'avoir 1 véhicule avec 2/3 UV set en 4k, pourquoi ne pas séparer plus de parties qui aurait chacune leur propre UV et réduire la taille des map ? Car 4k ce n'est que la taille de la texture pour les UV, mais si les UV prennent moins de place, en séparant par exemple 7/8 parties de la voiture je devrait arriver au même résultat que j'avais en 4k, en 2k au niveau de la texel density si j'ai bien compris ? De cette manière j'ai plus de flexibilité sur les différent modèles qui composent la voiture car ils sont tous indépendant au niveau des material. Mais est-ce que 8 material différent en 2k vont être plus lourd pour la CG que 3 material en 4k ?

La doc sur les drawcall parle un peu de mon problème comme j'utilise un atlas pour plusieurs mesh, mais il semble être plus approprié à des props commun contenant peux de tris qu'on ferrait drag & drop dans la scène sans les grouper, or, mon véhicule est déjà fait en sous parties

Batching dynamic GameObjects has certain overhead per vertex, so batching is applied only to Meshes containing fewer than 900 vertex attributes in total.
If your Shader is using Vertex Position, Normal and single UV, then you can batch up to 300 verts, while if your Shader is using Vertex Position, Normal, UV0, UV1 and Tangent, then only 180 verts.

En cherchant un peux plus, il me semble que Unity préfère avoir les objet "combiné" et partageant le même material (un peux comme dans mon cas), voici 2 point qui sont relié au sujet

CPU Optimization
Combine close objects together, either manually or using Unity’s draw call batching.
Use fewer materials in your objects by putting separate textures into a larger texture atlas.

Que veux dire combiner pour Unity exactement, que toute les parties aient le même parent ? Est-ce qu'il considère les child qui ne bougent pas d'un game objet en mouvement comme étant static ? En tout cas la vision d'Unity sur l'optimisation se rapproche beaucoup de mon workflow de base j'ai l'impression.

[Alesk]

Plus tu auras de meshes différents avec des matériaux différents et plus tu perdras en performances.
Encore une fois, la résolution de ta texture n'aura d'impact majeur que sur la conso de ram vidéo.

Ce qui "coûte" en performance, c'est d'avoir de nombreux matériaux différents sur beaucoup d'objets.

Moins tu auras de matériaux à utiliser et mieux ce sera.

Après, il faut voir aussi quelle config tu vises...

[Farstone]

C'est bon à savoir, j'ai déjà plus conscience de ce qui utilise quoi au niveau des matériaux, je ne savais pas que les textures n'affectait que la vram, donc normalement tout va bien et Unity va pouvoir gérer mes atlas pour optimiser tout ça (tant que j'utilise le même matériaux, qui, si j'ai bien compris a déjà les textures en cache dans la vram tant que 1 instance du material est toujours actif).

J'ai une autre question un peu HS mais qui reste dans le sujet des atlas, je comptait utiliser l’emissive map du matériaux pour faire les clignotants, les feu arrière, et une light pour les phares, j'avais vue qu'on pouvait activer/désactiver l'emissive map d'un matériaux en script mais je me pose des questions quand à sont efficacité maintenant, déjà car il m'est impossible à ma connaissance de désactiver seulement certaines partie de mon atlas pour l'emissive (ce qui m'oblige a séparer l'uv pour les clignotant, et par conséquent du matériau) mais aussi parce que Unity va devoir recharger le matériaux au complet car la map se désactive. Je voudrais utiliser l'emissive pensant que c'est peux être plus optimisé qu'une light, elle permet aussi de mieux jouer sur les variations de lumière pour arrivé à un rendu sympas du phare. Est-ce que c'est une bonne stratégie de modifier un material pendant le runtime ?
Sinon, il n'y a pas vraiment de config ciblé car Unity permet de diviser la taille des textures par 2 si le joueur le souhaite pour alléger la vram (à moins que ça soit un processus destructif des maps ? ), mais disons que ça se situe entre une GTX 660 stock minimum et une 1050 Ti en recommandé. Merci de ton aide et bonne journée

[Alesk]

Les textures bouffent aussi un peu de puissance hein... mais bon, ça reste négligeable.

Pour ce qui est de l'emissive, ça ne coûte rien de l'activer / désactiver, par contre c'est global... donc tu ne pourras pas le faire de manière sélective si tu as un atlas.

La méthode simple consisterait à créer des matériaux à part pour chaque élément qui doit s'allumer individuellement.
La méthode complexe implique de coder un shader spécifique...

[Farstone]

Je pensait utiliser la méthode simple depuis le début, je ne suis pas mauvais en programmation mais les shader m'ont toujours effrayé, je vais essayer de comprendre leur fonctionnement et je ferrait mon choix final en fonction de la complexité de la chose, peux être que le shader graph rendra tout ça plus simple Je pense avoir toute les réponses relatif au sujet, merci beaucoup pour ton aide et à la prochaine !

[Alesk]

Ok, si tu as des questions pas trop complexes sur le shader, je pourrai aussi de donner des infos.