Discussion :

[Nanos]

Salut à tous !

Je suis en train de me développer un moteur 3D. Donc un moment il a fallu que je l'optimise. Alors pour sa j'ai l'intention d'utiliser les VBOs et après les IBOs. Mais voilà j'ai un problème. C'est pour les materials. Étant donné que je peux dessiner tous mes triangles en une seule commande avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

glDrawArrays()

Je suis bloqué car il faut que pour chaque ou plusieurs triangle, j'attribue un material. Mais pas pour tous. Donc du coup je me retrouve dans l'obligation de trier mes triangles par material ou plutôt par couleur diffuse, ambiante, spéculaire, etc...

Mais voilà, je n'arrive pas à trouver l'algorithme.

Par ailleurs, je viens de trouver une alternative mais je suis réticent : Est-ce que c'est conseillé de mettre dans la mémoire du VBO, un vertex (contenant 3 coordonnées, 3 coordonnées de normales, 2 coordonnées de texture, 3*3 données de couleurs (RGB -> Ambiante; Diffuse; Spéculaire)) ? Sa ne fais pas un peu lourd pour chaque vertex ?

Si sa vous intéresse mon code source est disponible sur mon git.

Pouvez-vous m'aider S.V.P ?

Merci d'avance...

[LittleWhite]

Bonjour,

Pour faire votre tri de matériaux, si vous donner un identifiant pour chaque matériau, alors vous pouvez trier les identifiants (car ce sont des nombres).

Pour la deuxième question, j'imagine que l'on s'organisera pour passer une texture au shader, afin de passer les couleurs des matériaux et donc, pour chaque vertex, on ajoutera un attribut pour le matériau. Dans un cas, où nous voulons encore plus de compression (soyons fous), on peut passer cette identifiant en 'w' d'une normale.

[Nanos]

Salut et déjà merci pour ta réponse.

Pour faire votre tri de matériaux, si vous donner un identifiant pour chaque matériau, alors vous pouvez trier les identifiants (car ce sont des nombres).

Donc j'ai un problème d'architecture: Je n'ai pas de MaterialManager. J'ai juste un membre Material dans chaque Triangle. Il serait plus judicieux de faire un MaterialManager qui contiendra la liste des materials et comme sa il n'y aura pas de duplication ?

Mais du coup, pour afficher mes triangles, je vais devoir rassembler mes triangles par couleur ambiante pour faire un glMaterial() et un glDrawArrays(), puis par couleur diffuse pour faire la même chose et après pareil mais pour la couleur spéculaire ?

Enfin c'est l'algorithme en lui-même que j'ai un peu de mal à concevoir...
Je peux toujours le faire avec un tri à bulle mais c'est vachement lent et pas du tout optimisé et je suis sûr qu'il doit y avoir un moyen de faire autrement.

Si sa peux aider à résoudre mon problème, voici mon git.

Pour la deuxième question, j'imagine que l'on s'organisera pour passer une texture au shader, afin de passer les couleurs des matériaux et donc, pour chaque vertex, on ajoutera un attribut pour le matériau. Dans un cas, où nous voulons encore plus de compression (soyons fous), on peut passer cette identifiant en 'w' d'une normale.

J'ai pas encore travaillé sur les Shaders, je sais simplement ce que c'est. Donc je vais laisser sa un peu de côté pour le moment. Sa a une importance dans mon problème ?

PS : Détail qui peut avoir son importance : Je suis sur OpenGL 2.1.

[LittleWhite]

Il vous faut un "Manager" (certains diront que les Manager sont le mal) pour pouvoir faire du tri et une gestion d'unicité de vos Material.

Après, oui, vous aurez un Material pour chaque association différente de Diffuse / Ambient / Spécular. Mais en théorie, il n'y en a pas mille non plus.

Pour les tris, autant utilisé le qsort() en C ou en std::sort() en C++

Bon, courage, sans les shaders ...
Les shaders sont obligatoires, pour la solution que j'ai expliqué, qui transfert les matériaux par la texture.

[Nanos]

Ah d'accord... Je viens de comprendre.

Au départ pour gérer les couleurs, j'avais l'intention d'utiliser glMaterial(). C'est pour sa que vous disiez que c'est très difficile de faire sans les Shaders ? Car moi je voulais utiliser glMaterial() et après glDrawArrays() avec un certain nombre de vertex à dessiner pour chaque appel poue respecter la couleur.

Donc le fait d'utiliser les Shaders, sa me simplifie bien la vie.

[LittleWhite]

Le fait d'utiliser les shaders peut simplifier la vie. Mais il n'est pas impossible de le faire sans (juste avec les glMaterial).
D'après moi, il n'était que de trier l'ordre d'affichage des objets afin de faire en sorte de faire le moins de changement de matériau possible.
Une classe de base pour les matériaux pouvait être :

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Material
{ 
private: 
    Color ambiant; 
    Color diffuse; 
    Color specular; 
 
public: 
    void apply(); 
}

Et dans la méthode apply() on retrouve les différent appel à OpenGL (glMaterial).

Ainsi, chaque triangle / objet possède un Material (ou une référence vers celui ci) et utilise apply, lorsqu'il le doit.

[Nanos]

En fait, question d'optimisation, je pensais faire encore mieux que sa. Parce que là, par exemple chaque Material possède 3 appel à glMaterial(). Mais si deux Materials possèdent par exemple une même couleur ambiante, il y a deux appels tandis qu'on peut en faire qu'un seul. C'est là mon problème. C'est de rassembler les triangles par couleur en commun. Mais sa oblige après chaque glDrawArrays() de refaire un tri. C'est aussi pour sa que dans ma classe Material, je n'ai pas de fonction apply().

[screetch]

une idée qui marche souvent, c'est de grouper tous tes mateiaux dans un manager

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class MaterialManager
{
    int16 addMaterial(....) { } //retourne un index dans un tableau
    void apply() { } //applique tous les materiaux, le plus efficace pour moi serait de les mettre dans un gros tableau de 
};

et ensuite lors du chargement, générer un VBO avec tous les triangles, et tous les materiaux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
for(int i = 0; i < vertexCound; ++i)
{
  vbo << vertex[i].x << vertex[i].y << vertex[i].z << manager->addMaterial(...);
}

enfin, au runtime, récuperer le materiau a partir de son index dans un shader.
Je pense pas que tu puisse ajouter beaucoup de materiaux; la limites inféreure est de 64 float (moins ceux que tu utiliserais, comme la matrice de projection); mettons 32 floats pour sur, et chaque materiau en prend 9 donc 3 materiaux max (sans doute 4)
sur le materiel récent c'est beaucoup moins un problème; il y a de la place pour 4000 floats sur les cartes récentes.
Si c'est pas assez tes materiaux peuvent être passés dans une texture.
Si c'est pas assez