bonjour, g 13 ans ay jeux voeut fayre un final fantaisi 12. G besoin de programmateurs, etc... : p

hmhm ca sera tjrs aussi drole =) bref ! ct pour faire part d´un truc, ou plutot d´une interrogation =) Pourquoi donc mon octree ralentit ma scene ? ! j´en ai codé un parce que je pensais que ca allait reduire l´overdraw mais c´est completement faux, au contraire ca l´a augmenté. Quand les triangles sont partagés par plusieurs nodes, ils sont redessinés les uns sur les autres, ce qui augmente les données inutiles envoyées au pipeline. J´ai fait un test d´octree avec les vertex array ( sans wglAllocateMemoryNV(), juste DrawElements) + static meshes et ca s´averait plus lent que la scene en static meshes seulement... Les cartes 3D font le clipping toutes seules ( et tres vite), et meme en ayant un octree avec frustum, elles le font quand meme ( je m´en suis rendu compte avec la root node divisée par 1 =).

Donc question -> l´octree n´est utile que pour la detection de collision ? ! ou il faudrait chercher vers une data structure + intelligente ? ( kd tree ? !) bah vouala, aussi, quelle data structure vous utilisez ?

moi je préfere le BiTree parce ke l´octree c pas malin ca peut couper des maps en plein de parrallèlépipèdes tres fins si le niveaux est large.

et sinon en effet ca ralenti si tu fais un PVS et ke ton code est mal optimisé la meilleure des méthodes c´est le portal, tu affiches uniquement les poygones vus, pas plus pas moins ( pas besoin de Z-Buffer ! )

ahhhhhhhh
bhein voila enfin une question interessante
et ej suis heureux de voir que c est une personne de 13 ans .

Lightness a deja repondu en grande partie a la question mais il existe une autre solution un peux plsu complexe a mettre en oeuvre .

il faudrias que tu redecoupe les face partagée par les differnent node ( la tessellation) . masi ca demande des clacul mathematique pour chauqe triangle docn il faut que tu precompile ta map a l avance de plsu il faut que tu trouve un equilibre correcte pour la taille de tes nodes car un triangle coupe te donera

3 autre triangle si 2 point sont dans le nodes
1 traingle si il n y a que 1 seul points

couper un trianlge c ets pas encore trop dure mais al ou tu risque d avoir plsu dure c est au niveau des coordonée de texture . ..

Data
http://www.ploksoftware.org

Non Data, c´etait une blague, il a 16 ans.

Lightness, le Z-Buffer n´a rien a voir avec la PVS, tu as toujours besoin d´un Z-Buffer meme avec une PVS, la PVS sert a te donner une liste de poly a afficher, a toi de les afficher dans le bon ordre ou alors d´utiliser le Z-Buffer.

BiTree-> kesako ?
hm, j´ai pensé a utiliser les fragmenteurs mais ca me semble un peu compliqué, je pensais que le leger overdraw causé par le partage des nodes allait etre rattrapé par la determination + facile des triangles affichés, mais en fait, la scene juste en static meshes est + rapide.
Pour la determination sur l´axe des Z les cartes font ca toute seules ( pas le masquage via le Z buffer, mais la determination des donnees masquéss pour pas les calculer), via la LMA du gf3 et HyperZ les ati.
En fait je vois + trop l´interet de coder tout ces algos et data structures puisque les cartes le font en hard et tres vite... y´en a un ? =)

euh g 16 ans comme hs_dino l´a dit, les 13a ct pr la blague, paske je sais ke c´est l´age d´or =)

pour hs_dino: je ne parlais pas du PVS, en effet le PVS ne permet pas la non-utilisation du Z-Buffer, mais je parlais des Portals ! qui eut le permettent.

Ah bah désolé, j´ai encore perdu une occasion de me taire.

Ah! voila le genre de posts qui me plaisent : )

Alors une autre question:
Les BSP Trees, ca vaut quoi, comparé aux Binary ou aux Octrees?

J´en appelle à votre suprême expérience...

Kelios
---------

Je connais juste le BSP et le principe est très bon, je n´y vois aucun inconvenient.
Sinon, c´est quoi les Binary, les Octrees et les TwoBiTree?

Ca y´est, j´ai trouvé ce que c´est que les TwoBiTree et c´est vraiment nase et completement démodé.

Les octrees c la division en 8 d´une root node, puis encore en 8 des enfants, jusqu´a un certain nombre de polygones atteint dans les enfants ou jusqu´a ce que le seuil maximal de subdivision soit atteint. Ensuite faut assigner les triangles aux enfants et c en general la que ca se complique. Personnellement j´ai pas pu reduire l´overdraw au dela du triangle partagé par node, comme l´a di data, splitter des polys c un peu ardu avec les textures coordinates : )

Et je me suis rendu compte que sans octree, c aussi rapide, le seul ptit pb c pour les collisions mais g pensé a faire un octree qui gere pas les faces pour le dessin, mais qui retourne juste les triangles proches a la fonction de collision. C plus sage de laisser le dessin aux ingenieurs d´nVidia et ATI =)))

Tant ke je suis parti sur l´exotisme, est ce que qqn a deja entendu parler/connait/sait utiliser ou utilise la fonction wglAllocateMemoryNV() ? j´ai lu dans la doc de nVidia ke ct la methode la + rapide pour la geometry, couplée aux vertex arrays. personnellement j´utilise des static meshes seulement, mais si qqn utilise les VX arrays... qu´il fasse part des benefices =) parce ke je les ait pas trop vu, a part pr les sommets partagés

euh et pour finir, les BSP je trouve ca pas cool... les leafy BSP trees ( utiles pour pas utiliser GL_DEPTH_TEST ? ) sont trop lourd a parcourir avec une scene en high poly...

"euh et pour finir, les BSP je trouve ca pas cool... les leafy BSP trees ( utiles pour pas utiliser GL_DEPTH_TEST ? ) sont trop lourd a parcourir avec une scene en high poly..."

Faux, ca sera toujours plus rapide, meme avec avec beaucoup de poly, d´ailleurs, plus il y aura de poly par leaf, plus ca sera rapide a l´affichage.

Si ta map comporte 500 000 polys, amuses toi a les tester 1 par 1 pour savoir s´il est dans le fustrum et s´il est en collision avec un objet.
Avec le bsp, tu parcours juste les leafs ( qui sont moins nombreux que les polys), c´est très rapide a trouver le bon leaf avec une recursivité et un test de plan, ensuite tu n´affiches les polys uniquement visible que depuis le leaf et tu testes les collisions sur ton leaf, je ne connais pas plus rapide.

je ne connais pas plus rapide

T´inquiètes ca arrivera un jour : ) Petit dino deviendra grand.

toutes les fonction dont vous parlez moi connais pas : ( c du OGL ? moi yen a connaitre ke DX je peu pas vous aider sur ce coup.

"Si ta map comporte 500 000 polys, amuses toi a les tester 1 par 1 pour savoir s´il est dans le fustrum et s´il est en collision avec un objet."

C´est pas moi qui le fait, c´est cablé en hard =) et c´est tres rapide ! Avec l´immediate mode de GL, c sur que les BSP et Octree accelerent, mais avec le retained mode, tous les algos et autres routines ecrites par les ingenieurs d´ati et nvidia sont prises en compte, et la, c beaucoup + rapide que n´importe quelle methode programmée. Pour la determination de la visibilité, la carte teste chaque groupe de polygones ( donc objet, pas chaque poly) a travers le frustum. Si l´objet est dans le frustum, alors tous ses polys sont dessinés, et si il n´y est pas, ben ca ne l´est pas fait. Sur les GF3 et radeon en +, y´a des methodes qui determinent l´ordre des polys pour faire de l´excellent hidden surface removal, en hard toujours.

A tiens, je ne savais pas ça arf ; P

D,ailleurs, comment tu l´actives, ton retained mode, MASkwarE?

Kelios
---------

sur tous les sites ou g vu le retained mode en openGL, c´etait l´affichage avec display lists =)