 |
||
| ||
| |||||
| Dernière réponse | |
|---|---|
| Sujet : Surfaces courbes : tesselation | |
| bjone | au fait pour quake3, re-télécharge la démo, tu peux changer le pas de tesselation sans faire de vid_restart |
| Aperçu |
|---|
| Vue Rapide de la discussion |
|---|
| bjone | au fait pour quake3, re-télécharge la démo, tu peux changer le pas de tesselation sans faire de vid_restart |
| chrisbk |
|
| youdontcare |
joli ! :)
|
| chrisbk |
|
| youdontcare |
tu bosses sur quoi au fait ? :) |
| chrisbk |
|
| LeGreg |
|
| chrisbk |
|
| youdontcare |
c'est pour ça que la méthode de LOD standard range les vertices dans l'ordre inverse de collapse. ton minIndex reste tj à 0, numVertices diminue. |
| LeGreg | quote:
"Software T&L pipelines do not look at you index list and see which vertices you are using. They T&L all vertices starting at MinIndex and goes for NumVertices vertices. Then it draws them. So if you are only drawing with vertices 15-20 of a 100-vertex VB, it's a good idea to set MinIndex to 15 and NumVertices to 6, so that only those 6 are processed by the software T&L engine." En clair, il n'est parfois pas tres bon d'avoir un vertex buffer et de sauter des vertex pour faire du LOD. Quelle est la solution? je ne sais pas trop. Peut-etre generer les donnees au niveau de detail desire et ne pas faire de LOD via par indices. Deja si tu sais que certains points n'apportent aucun detail, tu peux les virer de ton vb, en utilisant des methodes classiques comme les Quadtrees ou B-Triangletrees. Je pense que le probleme est un probleme assez ouvert, il y a deja eu de nombreux papiers sur le sujet.. A+ LEGREG |
| chrisbk |
|
| LeGreg |
|
| chrisbk | yop
bon ben g bricoler un peu hier.. X isle a pas l'air de se faire, y tesselent uniformemnt chaque secteur . Ensuite le choix du niveau de detail ne se fait pas uniquement de la distance ... a mon avis ca doit etre comme dans le papier "geomipmap" qu'on peut trouver sur flipcode, je crois que je vais la jouer comme ca vala... |
| bjone | oki, je suis d'accord.
mais, puisque t'y est regarde, si tu gagnes en perfs en faisant deux vertexs buffer, et tournant dessus histoire de voar si y'a moyen de remplir le second pendant que le moteut T&L bouffe l'autre :D |
| chrisbk | je charge mes points dans un tableau de 33x33
Ensuite je tessele ce tableau . Donc tu vois la taille de mon vb change pas Je prefere eviter de changer la taille du vb en run time, ca complique un peu tout mon bins, en plus d'ajouter les release / alloc en plein milieu du prog (je sais ps si c le mieux) Me semble que Q3 change les indices lors du tracage plutot que de recalc la surface (calcule une surface bien détaillé au load time, pis apres y taillade dedans) Bref, la j'ai trouve une chtite méthode . ca me vire pas les tri inutiles, ca me les transforme en triangle dégénérés . Ca doit tjs etre ca de pris, non ? (un tri degeneré, ca doit pas mettre trop lgtps a etre tracer, j'imagine) Vais voir si je peux pas améliorer ca ... |
| bjone | bin c'est qd même important, le moteur du monde :D
mais bon tu est carrément + avancé que moa, je suis dans mes débuts en directx. (genre affichage de canard :D) qd tu dis que les tesselles en runtime, c'est que tu as toujours tes altitudes en 9x9 en ram, puis juste dans un bloc temporaire tu les passes en 33x33 ??? passke pour moa l'idéal, c'est de faire une tesselation variable (po forcément 33x33), qui se recouvre dans le temps avec la géométrie+traçage coté carte 3d. genre pendant que la carte traçe, tu commençes à tesseller dans un deuxième tampon (genre double buffer mais pour les vertexs). |
| chrisbk | ouaip enfin; c un peu plus complique que ca
Mon terrain est sectorise pour la bonne raison qu'il entre pas en RAM (le terran actuel fait qqchose comme 386M de vtx en full quality, en fait la seule limite a la taille du terran c'est celle de ton DD) Je charge mes secteurs en 9x9 puis je tesselle ca en run time en 33x33 (bon, les secteurs en fait ils mordent sur les autres, un secteur chargé fait 11x11 vtx, mais son bout "propre a lui" c'est les 9x9 du centre, ceci pour assurer la continuite entre deux patches) Fo que je voye tout ca, mais le truc c que la g pas bpc de tps pour cette partie du moteur, qui n'est pas 100% vitale (g deja un frame rate assez correcte meme comme ca ..mais bon, le moins on en fait .....) |
| bjone | mais pour la "qualité" de la tesselation elle-même, je -pense- qu'il faut précalculer les coefficients, puis augmenter le pas....
mais pas générer le max de points, puis chercher à en sauter en fontion de la qualité voulue... mettons que tu ayes une table 100 étapes pour le t qui va évoluer de 0 à 1, pour la aute précision tu passeras par tous les entrées, ensuite tu vas aller de 2 en 2, puis .... pour faire décroitre la précision de tesselation. ensuite l'algo de création des trips est toujours le même (pas de prise de gueule avec des points à sauter).... |
| bjone | bin, pour le terrain je pense donc toutes tes altitudes sont dans un gros buffer de 30 megs, un truc du genre...
genre image 256 couleurs des moteurs voxels qui donne l'altitude + couleur... donc tu vas parcourir ton tableau, comme un moteur voxel (j'en ai jamais fait), mais en fait ton champ de vision te donne un triangle, et tu transforme chaque "ligne" du triangle ? donc je pense que le but serait que la tesselation serait paramétrée en fonction de la profondeur, mais de préférence pas par patch, mais de manière progressive dans le patch ? remarque, le moteur Crytek semble sectoriser la carte (y font sauter les secteurs par visibilité en fonction si t'est derièrre une coline), puis ils tessellent par patch (régulièrement dans le patch, mais po progressivement)... par contre j'ai essaye la démo d'aquanox, et tu vois des écart d'altitudes se réduirent avant qu'ils fassent sauter des points de contrôle.... |
| chrisbk |
|
| chrisbk | bjone : terran (c pour ca que ls pts sont dispose regulierement)
Youdontcare : bah c une facon comme une autre de poser une question non ? t'aurais prefere un classique "vous feriez comment" ? quand on y pense ca revient au meme :D vais voir l'article tiens.... |
| youdontcare | tu veux pas 100 balles et un mars aussi ? :lol:
y'avait un article de gamasutra y'a un an et quelque là-dessus, tesselation de surfaces bezier + lod en runtime ... cherche voir là-bas. après faut voir si l'algo de lod ne bouffe pas plus de temps que bourriner ta carte ... |
| bjone | t'achètes une geforce 3. :D
nan je déconne (et pas en fait), enfin un truc interressant.... c'est pourquoi, des objets ou un moteur de terrain ? |
| chrisbk | vous avez sur le plan XZ des points dispose regulierement ( 9x9 point)
Chacun de ces points a une hauteur Y quelconque Maintenant, vous tesselez cette surface de 9x9 a 33x33 (surface de catmull rom, mais bon, ca on s'en fout) comme y'a que la valeur Y a interpoler, et que le SIMD n'est pas une mauvaise chose, ca se fait plutot vite Bien vous avez donc un patch de 33x33 , que vous voulez afficher en strip . En utilisant des triangles degenere sur les coins, c faisable L'affichage se fait avec une liste d'index (je ferais bien un chtit dessin mais y semble qu'ici on ait pas le droit aux images) Allright Maintenant, parfois certains point son inutiles (apportant trop peu de detail), et il serait donc bon de diminuer le nombre de tri en virant ces points la . (donc sur votre dessin vous effacer un point) Question : comment calculer la liste servant a l'affichage des strips ? (contrainte supplementaire : l'algo doit faire ca en run time) Vous avez une heure :D (si vous avez rien compris je recommence :) ) |
