Comment Unity3D réduit-il le nombre de sommets .obj importés?


8

J'ai une question concernant la façon dont Unity3D gère l'importation de fichiers .obj. J'importe cette théière: http://groups.csail.mit.edu/graphics/classes/6.837/F03/models/teapot.obj

Le nombre de sommets de cette théière est de 3644. Je sais que la classe Mesh d'Unity doit répliquer ces sommets pour chaque face partagée par le même sommet. J'ai essayé cela avec un cube importé d'un .obj, et en utilisant Debug.Log () pour imprimer le nombre de sommets, j'ai découvert qu'il y avait 24 sommets dans le tableau de sommets du maillage.

Cependant, avec la théière, le fichier d'origine avait 3644 sommets, donc dans Unity le nombre de sommets devrait être 18960. Au lieu de cela, lorsque j'imprime la longueur du tableau de sommets du maillage, il imprime 3260 (encore moins que le fichier d'origine).

L'objectif final pour cela est que j'essaie de modifier un script d'importateur OBJ à partir du wiki d'Unity, afin que le nombre de sommets résultant de ce script soit le même que l'importateur natif d'Unity. Référence: http://wiki.unity3d.com/index.php?title=ObjImporter Remarque: J'ai imprimé le nombre de vertex à l'aide de cet importateur et le résultat était 18960.

Quelqu'un a-t-il une idée de la façon dont cette réduction du sommet pourrait être obtenue?


Algorithmes complexes, je ne sais pas ce que l'unité utilise mais vous pouvez les trouver en ligne.
MickLH

Réponses:


5

Plusieurs facteurs contribuent à la manière dont la géométrie est enregistrée et traitée sur différents supports (programmes, formats de fichiers, API). J'ai mis en œuvre plusieurs programmes d'analyse de géométrie commerciale, j'ai donc une certaine expérience avec cela.

Tout d'abord, je suis sûr que cela n'a rien à voir avec la simplification de Unity. Mais au cas où il le ferait, plusieurs algorithmes de décimation peuvent être mis en œuvre, mais je suis sûr que ce n'est pas le cas, car un moteur de jeu n'est pas censé changer la forme (propriétés géométriques d'un maillage) mais peut généralement modifier sa connectivité pour correspondre à sa structure optimale.

Certains de ces facteurs sont:

Qu'est-ce qui rend un sommet unique?

Cela peut varier considérablement en fonction de la façon dont le programme, l'api ou le format de fichier traite un sommet. Un sommet peut être unique s'il a une position unique, mais dans d'autres cas, il est unique s'il a un attribut unique. Par exemple, si deux sommets partagent la même position, mais ont des normales différentes, ils doivent être "dupliqués" dans le cas d'OpenGL, cela est particulièrement évident dans le cas du cube que vous avez mentionné.

entrez la description de l'image ici Bords durs et lisses.

Les normales peuvent dicter si un bord est considéré comme dur ou lisse, si un sommet contribue au bord dur, alors il doit être dupliqué pour que les API de rendu actuelles puissent comprendre comment rendre (ombrer) cette face correctement.

entrez la description de l'image ici

Indices

De nombreux formats de fichiers permettent à un sommet de face d'avoir plusieurs indices pour la position du sommet / texCoords / normals, ce n'est pas le cas des API de rendu actuelles. Un bon exemple de ceci est le fichier Obj, cela forcera Unity à reconstruire les index et dupliquera souvent de nombreux attributs pour correspondre aux index de vertex.

Connectivité

Un grand nombre des sommets qui sont réellement connectés et uniques sont enregistrés plusieurs fois, cela a à voir avec la façon dont le rédacteur de fichier d'origine a traité et enregistré le maillage. Unity réduira le nombre de sommets en double (rappelez-vous que s'il a un attribut différent, il n'est pas unique) afin de le rendre plus efficace pour le stockage et le traitement sans sacrifier la qualité.

Cela a également à voir avec le nombre de côtés de polygone autorisés par le fichier d'origine, Obj par exemple, autorise les polygones à côté N, ce que tout moteur de jeu sensé ne veut pas, il finit par trianguler le maillage et recalculer bon nombre de ses attributs qui, souvent, changer le nombre de sommets.


Oh je comprends maintenant! Dans l'importateur .obj que j'ai utilisé, les sommets sont toujours dupliqués pour chaque face dans laquelle ils sont utilisés, et c'est pourquoi j'ai toujours des bords durs sur ma théière (je ne l'ai pas mentionné auparavant parce que je pensais que c'était un problème différent). Très bonne réponse!
VitorOliveira

2

Les formats d'obj sont étranges en particulier parce que les positions, les normales et les coordonnées de texture sont séparées et chaque face peut choisir n'importe quel index dans chaque flux. Lorsque vous faites référence au nombre de sommets, vous pensez que les positions des sommets et le nombre de normales ne sont pas les mêmes et vous ne pouvez pas vraiment faire référence au nombre entier.

Pendant le chargement, ces trois attributs doivent être fusionnés afin qu'une position de sommet puisse se terminer en double car la face associée à cette position de sommet est associée à deux normales . Cela peut également se produire en sens inverse, de sorte que la plupart des chargeurs ont une étape pour optimiser l'obj, mais dans le cas de votre cube, l'optimisation ne fonctionnera pas car le cube a des bords durs et chaque sommet a une normale (ou coordonnée de texture) différente. C'est pourquoi vous avez compté 6 positions de sommet, mais l'unité a dupliqué ces positions, ce qui a donné 24 sommets.

Pour charger un maillage, vous pouvez dupliquer des positions / normales ou des coordonnées de texture, l'optimisation n'est donc pas simple. Cela revient à choisir le nombre minimum de doublons parmi ces trois flux.


Cette réponse était un excellent complément de ce que concept3d a dit, et elle m'a aidé à comprendre ce problème. Donc, je suppose que pour l'instant mon importateur .obj aura toujours des bords durs, mais si je veux l'améliorer, je devrais rechercher des algorithmes pour m'aider à savoir quels sommets doivent être dupliqués ou non, afin d'avoir un modèle à bords lisses avec un minimum ( ou au moins optimisé) nombre de sommets.
VitorOliveira
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.