J'ai enfin trouvé un peu de temps pour refaire de zéro mon exemple de "Minecraft-Like". Tout le source et les ressources sont dans le zip ci-dessous. Désolé, je ne peux pas mettre le code directement ici, ça ne tient pas...
http://keleb.free.fr/codecorner/downloa ... clone2.zip
[UPDATE 11/07/2014]
Support préliminaire d'OpenGL => si quelqu'un peut tester sur Mac / Linux et me dire si ça marche, ça m'intéresse!
[/UPDATE]
[UPDATE 10/07/2014]
Un peu plus de matériaux pour construire, correction du bug sur la lave.
Et surtout ajout des matériaux type "billboard" pour l'herbe et les fleurs!
(par contre, les mondes modifiés avec les versions précédentes ne sont plus compatibles; désolé)
- Clic gauche pour creuser / clic droit pour construire;
- E/R pour sélectionner le matériau de construction;
- G pour passer en "ghost mode"
- Ctrl + flêches pour se déplacer.
[/UPDATE]
La version 5.30 de PB m'a bien aidé, en ceci qu'on peut désormais afficher le nombre de batches de rendu utilisés pour afficher la scene 3D.
Pour mémoire, Ogre doit "ordonner" la scène en paquets de choses à afficher avant d'envoyer les infos vers le GPU. Cette opération est faite par le CPU, ce qui constitue un goulet d'étranglement important: quelque soit le nombre de polygones affichés, au-delà d'un certain nombre de batches (100, 200, 400 selon les machines), ça ramera.
Grâce à la v5.30, j'ai pu voir que:
- Chaque material compte pour 1 batch;
- Chaque groupe de géométrie statique compte pour 1 batch;
- Les deux se multiplient: 10 groupes contenant 10 materials chacun correspondent à 100 batches (je crois).
Par ailleurs, pour créer un paysage en cubes, on sait qu'on va avoir beaucoup de polygones avec pleins de textures différentes, donc:
- On voudrait créer plusieurs groupes statiques (beaucoup?), afin que les polygones non-présents à l'écran soient automatiquement exclus du rendu;
- De plus, un groupe statique prend du temps à construire: après avoir ajouté les entités voulues dans le groupe, il faut faire un "BuildStaticGeometry" qui est d'autant plus long qu'il y a beaucoup de polygones dedans. Donc, si on veut les créer au fur et à mesure qu'on se balade dans le paysage, il vaut mieux qu'ils soient petits (donc nombreux);
- Qui dit textures différentes dit materials différents, donc beaucoup aussi.
Vous voyez le problème...
Voici le compromis que j'ai choisi:
- Le paysage est découpé en "chunks" de 16x16x16 cubes, qui sont créés à la volée quand on bouge la caméra. Ils sont initialisés dans un thread (grâce à l'include "Perlin" fourni par G-Rom), puis on les mets dans des groupe de géométrie statique (1 par chunk);
- Un seul material est utilisé pour toutes les textures, selon la technique du "Texture Atlas": on une grosse image contenant toutes les textures (comme une feuille de sprites), et on pointe sur la bonne à l'aide d'un shader. Pour passer le n° de texture à afficher au shader, j'ai codé ça dans le rouge de la couleur du vertex (256 textures maxi, donc);
- Le Texture Atlas est construit automatiquement à partir de datas et d'images présentes dans le répertoire "TextureLib", ça facilite la maintenance et la customisation;
- Pour les materials semi-transparents (l'eau) et les materials animés (magma), j'ai été obligé de créer des materials à part => ça fait 3 en tout.
Dernière précision, j'ai stocké les infos des chunks dans des octrees (cf mon post précédent), mais je ne suis pas certains que ce soit très avantageux...
)
. Si tu veux éprouver un peu ton système, il y a une constante "#VIEWDIST" au début du code qui détermine à quelle distance sont affichés le morceaux de paysage; j'ai l'impression que tu peux la mettre à 5 ou 6 sans trop de problème...
,