Ca y est le Terrain Renderer compile.

Le commit est en ligne :

https://github.com/Overdrivr/NazaraEngine/commit/22e1d700c6908b7eb5c94aaebb3912f95b82b2b4

Il reste à le tester et corriger les bugs, peu je l'espère

Ensuite remettre dynaterrain sur pied !

EDIT : Le renderer fonctionne correctement :

https://github.com/Overdrivr/NazaraEngine/commit/390aaec114f572d8a61877ec1b66fd920cad3a12

Le dessin d'un seul chunk de test :

Allez plus qu'à remettre sur pied dynaterrain !

-
Edité par OveRdrivR 29 juillet 2013 à 22:29:18

DynaTerrain compile également, bonne nouvelle. Ce fut moins de boulot que prévu. Je n'ai encore rien à vous montrer car il reste toujours à tester et corriger l'ensemble, c'est à venir. 

https://github.com/Overdrivr/NazaraEngine/commit/f87cae3b9fe85c6d43af8cc09ac08be9a7c0e8e5

Dév un peu au ralenti ces derniers jours, box internet en rade.

Je me concentre sur le renderer de terrain pour le rendre plus robuste et plus léger. J'ai accessoirement trouvé un bug qui me coinçait depuis un moment sur les planètes pour gérer les jonctions entre les 6 quadtree (chose qui s'est avérée bien plus complexe que prévu), donc ce n'est pas du temps perdu.

Promis j'aurais des nouvelles plus intéressantes la prochaine fois !

DynaTerrain à nouveau fonctionnel ! 

L'intégration au système de scène n'est pas totalement terminée, même chose pour les matériaux. Une fois ça de fait, il y aura une correction des normales aux interfaces du LOD à faire. Directement après -> terrain infini

Nice, impatient de voir la suite!

Quel est la technique que tu utilises pour obtenir un maillage conforme ? Comment détectes-tu des changements de topologie induisant des changements sur la géométrie des mailles ? Peut-on spécifier la géométrie des mailles à utiliser pour mailler (et si oui, est-ce que cela détecte les impossibilités d'obtenir un maillage conforme, ie maille carrées pour un cercle ?).

D'ailleurs je t'invite à présenter ton projet sur PDP comme tu l'envisageais.

Bonnes questions Je vais essayer d'y répondre de manière claire. Pour commencer :

Comment détectes-tu des changements de topologie induisant des changements sur la géométrie des mailles ?

Le terrain est contrôlé par un quadtree. Les noeuds tout en bas de l'arbre provoquent l'affichage d'un maillage. Donc les changements de topologie sont fait dans le quadtree et répercutés sur le maillage. Maintenant pour répondre à ta question, à chaque fois qu'une subdivision a lieu, les nodes nouvellement créés vérifient simplement la profondeur de leur voisins, et soit ils ne font rien, soit ils adaptent.

Parce que récupérer un pointeur (ou une référence) d'un node voisin dans un quadtree n'est franchement pas aisé de base, chaque node possède un identifiant unique [profondeur ; position.x ; position.y]. Une std::map sert de table de correspondance entre cet identifiant et le pointeur vers le node associé.

Donc pour récupérer le pointeur vers un voisin, il suffit de prendre l'identifiant du node de départ, d'ajouter/soustraire 1 en x ou y (selon le voisin que l'on cherche à atteindre), et d'utiliser ce nouvel identifiant dans la table de correspondance pour obtenir le pointeur.

L'attribution des identifiants est faite selon ce modèle :

J'ai préféré cette méthode à celle de garder des pointeurs vers les voisins pour chaque node, car je trouvais que ça devenais un bazar immonde à la longue.

Quel est la technique que tu utilises pour obtenir un maillage conforme ? 

Par simplicité, j'ai imposé un niveau d'écart maximum entre deux nodes voisins. Donc au niveau du maillage, à une interface entre deux précisions différentes, je n'aurais au maximum qu'un niveau à rattraper. Du coup ça permet de déterminer l'ensemble des variations de mon maillage de base (une grille de 5*5 vertices) :

Ensuite c'est juste une question de déterminer la bonne configuration lors du check sur les voisins.

Chose importante, pour pouvoir respecter la règle du "1 d'écart max avec voisin", j'ai imposé deux règles :

• La subdivision d'un node a le droit de provoquer la subdivision d'un voisin si celui-ci est déjà un niveau de précision en dessous. 
• Le refinement d'un node (la fusion de ses 4 enfants) n'a pas le droit de demander le refinement d'un voisin

Peut-on spécifier la géométrie des mailles à utiliser pour mailler (et si oui, est-ce que cela détecte les impossibilités d'obtenir un maillage conforme, ie maille carrées pour un cercle ?

En fait, à part augmenter le nombre de vertices de côté pour la grille, c'est difficile de trouver un autre maillage qui puisse rattraper des niveaux. Par contre je saisis mal le sens de la question pour le cercle.

Il faut juste garder à l'esprit que la logique de dynaterrain repose uniquement sur le quadtree. Si jamais tu souhaite appliquer une transformation au maillage de base, tant que c'est appliqué de manière uniforme à tout les mesh le maillage complet sera continu (normalement !

Merci pour PDP, je fais ça asap

-
Edité par OveRdrivR 21 août 2013 à 17:36:08

Merci beaucoup pour ces réponses précises (avec les schémas, c'est la classe !).

Pour le choix de la maille, il est juste impossible d'avoir un maillage conforme en utilisant des mailles carrés sur un cercle, d'où ma question.
En fait, mes questions sont peut être un peu à côté de la plaque parce que mes études de maillages sortent du cadre du JV et repose plus sur les mathématiques appliquées, en ligne de mire la méthode des Eléments Finis.

Ah je viens de comprendre tu voudrais un terrain circulaire au lieu de carré c'est cela ?

A priori c'est possible, au même titre que pour les planètes les maillages sont déformés pour devenir une sphère, il suffit juste de trouver la bonne formule. Mais tant que la formule ne provoque pas de discontinuités et est appliquée à tout le maillage, ça doit fonctionner.

Bien évidemment il y aura un effet d'échantillonnage, les bords du cercle ne seront pas parfaitement circulaires. Je testerai ça à l'occasion je te tiens au courant