Minecraft!
-
Ah ouai 200.000 quad c’est beaucoup plus cohérent avec mes 400.000 tri.
Maintenant je te soumet un autre problème. Mettre toutes les textures en une seule grande est super intelligent car ça permet de faire un seul batch. En revanche ça pose un autre problème. Sauf erreur il n’est pas possible de faire du « tiling » en selectionnant une fraction de texture. Parceque pour réunir les faces partageant le même plan et la même texture dans une seule grande face, il faut forcément du tiling, et à ma connaissance, c’est forcément bord à bord de texture…
Je me demande aussi comment tu fais ton occlusion culling. A l’échelle d’un objet complexe et et ses bounding box, il est rapide d’éliminer beaucoup de polygons. En revanche à l’échelle de cube à 6 faces, ça doit faire énormement de tests pour checker chaque cube par rapport aux autres. Bon cela dit vu qu’ils ont tous la même dimension et qu’ils sont alignés, j’imagine qu’on doit pouvoir optimiser l’algo à mort. Projection de rayons? Ou un truc du style… D’où ma question
@crisot: vu que moi c’est des quads, 400 kt/s, c’est comme 200 kq/s, effectivement on à la même chose.
Pour les occlusions c’est très bête: quand je « fabrique » la carte, pour chaque cube rajouté je le lie à un « noeud » qui posséde 27 pointers correspondants à 27 noeuds répartis sur un cube 3×3: le noeud du centre qui reboucle sur le lui-même évidement, les autres sont remplis après que toutes la carte soit générée, par une fonction de recherche des voisins.
Voilà j’ai une carte des voisins pour chaque cubes.
Ensuite pour l’occlusion je regarde pour chaque noeud si une faces est occultée par un voisin, ou non.
Je sais qu’il n’y a que 6 voisins occultants à un cube, mais j’ai pris aussi les diagonales en cas de besoins… on sais jamais.
Si plus tard j’en ai vraiement pas besoin je reduirai la consommation mémoire.
Donc sinon pour revenir à l’optimisation: non, je gagnerais jamais plus de vitesse maintenant: le rendu d’un cluster est limité à 1 seul appel à glDrawArrays avec un tableau qui sera toujours remplis plus vite que l’affichage de son contenu….
J’attend d’avoir un TGL stable de MOS 3.0 pour tester le gain d’accéleration des derniers drivers. On verra si j’y gagne qq chose (normalement oui, d’après Henes
)Ah oui sinon, il n’y a pas de source lumineuse pour l’instant. Et si il y en aura je laisserai OpenGL s’en occuper.
Thellier: Yomgui bosse sous MorphOs avec TinyGL
Il serait jamais à 200.000 quad/sec avec MiniGL ahah
@thellier: merci de cette note, j’ai mis-à-jour ma page wiki sur le projet en mettant en bien visible 2 petites notions
Coucou, juste une question, pourquoi es-tu passé par des hexagone pour ta map, les carrés ou les triangles, c’est pas plus rapide ? (artblink qui rêve de fair zeewolf sur AOS
)C’est dommage de faire des portages
quand on connais la logithèque ludiques de l’amiga, y’a plein de jeux à refaire (et en mieux )
@crisot: fais toi plaise
c’est se qui compteMême si je trouve se jeu pas terrible
Je suis peut-être un codeur fénéant, mais étant donné que t’es dans un univers complètement cubique et dont tous les cubes sont d’égale dimension, j’vois vraiment pas l’interet d’écrire une routine de collision 3D…
Avec les coordonnées X Y Z du personnage dans le chunk on a largement ce qu’il faut et les collisions se gèrent avec une poignée de if();
- Vous devez être connecté pour répondre à ce sujet.
