Minecraft!
-
Petite progression du jour: je lis les fichiers regions (.mcr) et j’ai pu tester une vrai carte… enfin un tout petit morceaux.
Pour se rendre compte:
– une carte c’est un groupe de régions.
– une région c’est un groupe de 32×32 « clusters ».
– un cluster c’est un groupe de 16x16x128 « blocks » (ou cubes si vous préférez).
Soit 1 région = 33 554 432 blocks… potentiellement, car en faite tout n’est pas remplis évidement.
Mais j’évalue à 50% d’utilisation des clusters en moyenne, représentant tout de même 16,7 millions de blocks par régions.
Cela dépasse largement la capacité de mémoire sur nos machines, même sur un PC avec 4Gio c’est limite!
D’ailleurs j’ai pu lire sur le wiki dev officiel que le serveur n’envoie qu’une grille de rayons 10 clusters vers les clients, soit 21*21 clusters.
Cela diminue le nombre potentiel de blocks (toujours avec 50% d’occupation) à plus de 7 millions…
Enfin bref, en limitant la hauteur et en ne prennant que 10×10 clusters, j’ai 370 872 cubes dans ma carte en mémoire.
En interne je regroupe mes cubes (ou noeuds) dans des clusters (rien à avoir avec ceux du .mcr) dans une grille de 9x9x9, soit 729 pointeurs (=2 916 octets par cluster).
Donc mes 370 872 noeuds sont répartis dans 1080 clusters.
Premier constat: inéfficacité de la gestion mémoire.
1080 clusters = 787 320 pointeurs soit 3 Mio!
Or j’ai 370 872 noeuds… donc prés de 53% de la mémoire ne sert à rien!
=> 1er point: revoir comment je sauve mes donnée en RAM!
Deuxième constat: trop de noeuds/clusters visités pour le nombre rendu.
Comme je dois faire 2 passes pour le rendu entre les noeuds plein et ceux qui ont de l’alpha (genre les arbre), je boucle donc sur 2 160 clusters, mais heureusement dans la passe alpha, je vire immédiatement ceux qui n’ont aucuns noeud avec.
Je tombe donc à 1 564 clusters visités, donnant à leur tour 11 655 noeuds (cela peut monter à 12 000!).
Après avoir virer clusters totalement non visibles, puis les noeuds non visibles, on obtient plus que 215 clusters, donnant 6 800 noeuds.
Vu que les 6 faces d’un cube ne sont pas toutes visibles suivant leur entourage, il me reste 19 605 faces (QUADS) rendus.
Alors déjà je prend pas toute la hauteur d’un cluster .mcr (à peine plus que la moitier)… alors avec toute la hauteur les nombres de clusters/noeuds visités doubles, pour toujours le même nombre rendu.
Donc un système totalement inéfficace pour chercher les noeuds « à rendre »…
Ceci expliqant maintenant mes 4-7 fps dans cette carte!
Et hop qq améliorations sur le point 2, j’ai gagnée qq fps:
j ai envie de me lancer dans ce truc aussi mais sous warp3d sous os3/4
yomgui tu peut me passer une carte et son format/structure? MERCI
Je voudrais tester l algo auxquel je pense depuis qques jours…
Le jeu complet je m en fous mais afficher une ‘cubes map’ le plus vite possible je trouve ca un challenge marrant
Alain Thellier
Alors le format des cartes bêta 1.3 c’est ici:
http://www.minecraftwiki.net/wiki/Beta_Level_Format
Lire aussi les liens a la fin sur le fomat alpha des chunks.
Pour des samples, plus complique a trouver, mais j’ai fini par tomber sur les sauvegardes des joueurs.
Taper dans Google « .minecraft/world/region »
On trouve des .mcr comme ici:
http://julesmoreau.free.fr/serveur%20minecraft%20lundi%202%202h30/world/region/
Effectivement c’est un super challenge!
Pour info j’ai amélioré ma conso mémoire, mon moteur peut afficher une région de 96 x 96 (tout n’est pas remplis jusqu’en haut, les 128 positions, donc j’ai environs 680 000 blocks au final en mémoire). avec de fps variables (à 4-8 à plus de 30 suivant les quantitées…) Cela prend tout de même plus de 400Mo en mémoire!
C’est encore améliorable côté vitesse, côté conso mémoire, je peux pas mieux (et cela sera pire car faut que je rajoute encore qq bytes à mes structures pour le vrai ‘game play’).
Alors que le meilleur gagne
@zeGouky: il existe plusieurs version « openSources » en faite, mais je n’est pas trouvé une écrite C/C++ et OpenGL, sans autres dépendances.
Voilà pourquoi j’ai faite la mienne.
Et puis pour le challenge…
Sinon qq info pour les intéressés: le moteurs gratuis et O.S. le plus connus est celui fait par « Celeron-55 », dit C-55, en C++ et la lib irrlicht.
Par contre on oublis comment il rend lse blocs: il scan des dictionnaires à la recherche des blocs affichable et ensuite il fait 9 lancés de rayons par blocs pour savoir si ces derniers sont ou non occultés.
Certe beaucoup moins de blocs à la fin, mais 9 lancés sur chaques blocs, avec en plus des accès type dictionnaires dans la boucle du scan du rayon!
J’ai tenté… plus de 3 à 10 secondes par frames!
Comprend pas pourquoi il annonce fonctionnant avec les les configs plus anciennes (enfin on a pas le même sens de ‘ancien’).
Je doit trouver une autre solution car j’ai encore trop de blocs qui passe vers la phase de rendu OpenGL.
Ah je suis content!
content, content, content, même.
J’ai passé 15 jours à chercher le meilleur moteur de rendu qui demande par 4 Go de mémoire pour afficher une distance utilisable en un nombre de FPS potâble.
Et j’ai enfin fini par le coder!
J’ai tout testé… 15 versions différentes y sont passés, mais j’ai trouvé!
Il me donne donc pour une carte chargée de 618 350 blocs (soit une taille potentielle de 96x96x128) et avec une distance de visualisation max de 40 blocs, dans les 15 à 30 fps… et avec la transparence!
voui, voui, voui!
Bon j’ai implémenté le fog, mais là ça tue les perfs (par 2 voir 3), en plus j’en suis pas satisfait visuellement parlant… alors je le met en optionnel pour l’instant.
Sinon pour le fun, j’ai testé avec une distance de visu égale à celle de l’original sur PC (soit 300 blocs): 5fps!
Mais si on y regarde bien, c’est très très bon!
Faite le calcul: 87 544 faces en 187.33ms, cela donne plus de 465 659 quads/s, soit près de 1 862 638 triangles/s !!! c’est monstrueux!
Et encore c’est même plus car j’ai oublié de compter les faces transparentes…
- Vous devez être connecté pour répondre à ce sujet.
