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
 
(si vous avez rien compris je recommence )

t'achètes une geforce 3.
 
nan je déconne (et pas en fait), enfin un truc interressant....
 
c'est pourquoi, des objets ou un moteur de terrain ?

tu veux pas 100 balles et un mars aussi ?
 
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 : 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
vais voir l'article tiens....

 
Oh attends, j'en ai encore tout plein : montagne castant des ombres portes sur le paysage quand .... tu n'a pas tout le paysage en memoire, + contrainte de modification en tps reel dudit paysage
 
Des heures de jeux mon gars

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....

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)....

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 .....)

bin c'est qd même important, le moteur du monde
mais bon tu est carrément + avancé que moa, je suis dans mes débuts en directx. (genre affichage de canard )
 
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).

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 ...

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

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...

 
juste une question: si tu les vires tes triangles
apres pourquoi tu les generes en premier lieu?
 
J'ai peut-etre pas tout a fait saisi: quoi est dynamique, statique, genere a chaque frame?
 
LEGREG

 
le but ce serait de ne pas les virer definitivement, mais plus creer un tas de liste d'index pour faire du lod.
 
Nope je m'amuse pas a tesseler a chaque frame, je genere une version complete du secteur une fois pour toute ( ou presque, enfin passons) . De meme la liste d'index, je pense pas non plus m'amuser a la calculer a chaque frame...

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

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.

 
Vouif, j'avais deja vu ca pour le software TnL
(la solution con c de se dire que au prix des geforce2mx.....bon)
 
Ben tu vois l'autre soucis c que tout ca doit se faire en run time : le type se deplace, il approche d'une zone qui n'est pas en memoire . Donc a ce moment la fo que je charge le secteur, genere sa texture + un peu plus tard le tesselle (j'etale ca sur +eur frame)
Bon, les proc qu'on a c plus des 286, mais quand meme, autant le menager un peu en evitant eds algo ptet lourd (surtout que le paysage n'est qu'un bout du moteur)
 
le soucis en reoarganisant les vtx pour le LOD c que tu ne les accede plus de facon contigue en memoire (pour les niveau de LOD tres detaille), et ca a aussi un coup (maintenant a savoir lequel coute le plus...peut pas dire, mais autant optimiser pour les niveau de lod bien fourni, non ?)
 
Enfin voila quoi

 
Oui euh.. bon moi j'ai encore une G200
Alors mollo !
(et elle ne fait pas de multitexturing,
eheh, ca vous empoisonne la vie, non ?)
 

 
Pourquoi ne pas tester ca sur des scenarios simples ?
 
Si tu obtiens des resultats ca m'interesse aussi ..
 
LEGREG

 
 
Houla
(arrete, deja deux stage de texture c chiant, alors pas de multitex, heuh ben...voila quoi )
 
 
chaipatrop si je vais avoir le pts de faire des tests, mais si je fais, je post ce que j'obtiens, OK ?

chrisbk a écrit a écrit : Houla (arrete, deja deux stage de texture c chiant, alors pas de multitex, heuh ben...voila quoi )     chaipatrop si je vais avoir le pts de faire des tests, mais si je fais, je post ce que j'obtiens, OK ?

tu bosses sur quoi au fait ?

youdontcare a écrit a écrit :  tu bosses sur quoi au fait ?

 
sur quoi ... matos ?  
bah une gf2MX des familles
 
Sinon sur le projet en lui meme c un moteur de paysage, dont tu as un (ancien, entre tps y'a eu des changements) screen shot ici : http://site.voila.fr/godbout/1.jpg

joli !
 
c'est pour une démo ? un jeu ? un projet militaire top secret ?

youdontcare a écrit a écrit : joli !   c'est pour une démo ? un jeu ? un projet militaire top secret ?

 
thks
 
pour le moment, c'est du 100% pour le fun, mais ....... top secret

au fait pour quake3, re-télécharge la démo, tu peux changer le pas de tesselation sans faire de vid_restart