Minecraft!
-
Ce n’est pas ce qu’on appelle opensource …
Ce n’était pas la question posée me semble-t-il.
oui leo moi non plus j’avais pas envie d’y toucher je trouvais ca moche .
j’ai quand meme essayé et ce jeux est addictif !!ca plaira pas a tout le monde c’est sur mais moi je suis rester bloqué dessus un bon moment a c’est tres rare quand j’accroche a un jeux .
éssais tu me diras
Je vais paraître à la traine mais… c’est quoi Minecraft ? Biensûr, j’en a entendu parlé, mais les écrans que j’ai vu ne m’ont franchement pas donné envie d’y toucher… Et quand j’entends « Java », ça me donne encore moins envie
J’avais pas percuté, alors c’était ça la sphere verte sur fond noir en 3D fil de fer que je voyais sur ton écran !??
Don't lose it... and don't lose your head
Yomgui qui nous prépare un clone de Minecraft ?
Heureusement qu’on a ce gas là tout de même ! On a des programmeurs de génie dans notre univers
Et j’ai même pas vu à l’Alchimie… Yomgui, tu as une petite vidéo pour voir comment ça tourne ?
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
Yomgui: T’es bien courageux, et tu me coupes même l’herbe sous le pied
Le boulot que tu es en train de faire je rêve de le faire aussi. (j’y pense presque tous les jours en fait, sauf que toi tu concrétises ^^)Faut être honnête, au dela de ses apparences simplistes, en raison de sa profondeur de champ, de la quantitée de cube, un Minecraft n’est pas simple à réaliser sur nos « petites » machines (mais pas impossible non plus).
Au niveau optimisation du bousin, je pense que le premier gain de vitesse s’obtiendra surtout en réunissant tous les polygons partageants le même plan et la même textures en un minimum de polygons.
L’avantage c’est qu’un tel algo est très simple d’écriture, et n’a besoin d’être réexecuté que partiellement à chaque modification de terrain. Ca réduit également drastiquement la quantité de vertex à T&L. Le désavantage c’est que ça réduit lourdement les possibilités d’occlusion culling. De toute façon je doute qu’un occlusion culling à l’échelle d’objet aussi petits et nombreux que des cubes de terrain soit réaliste (Mais j’admet être une bille à ce jeu là
)Au niveau des performances, tu dis que tu es à 29.000 faces (quad ou tri?) par seconde. C’est quand même un peu léger à ce niveau de texturage et de filtrage, maintenant je sais pas ou passe le temps machine. J’veux pas dire de connerie mais la scene que j’ai modélisé à l’alchimie me donne dans les 400.000 tri/sec (CPU limited sur Aone [email protected], mais énorme marge d’optimisation), et je trouve que c’est encore loin d’être suffisant pour afficher un Minecraft digne de ce nom. Enfin bon t’as déjà fait des prouesses en opti
Keep on! J’applaudi
@Crisot: merci de ton soutiens!
Je sais pas trop ce que cela va donner ni où je m’embarque en faite.
Sinon pour le moteur de rendu, j’utilise des quads que je rend en remplissant un tableaux de vertex/tex/color que je donne ensuite à manger à TGL par glDrawArrays(). donc difficile de faire mieux mise-à-part en mettre le plus possible.
Donc là plusieurs choix pour répondre à la question: comment remplir un max de vertex dans un minimum de temps?
Pour l’instant j’ai construit la carte en interne de façon très simple mais très versatile: 1 appel à glDrawArray c’est 24 vertex max (6 quads).
Alors l’idée de grouper les cubes entre-eux pour former des surfaces oui, je vais le faire.
Mon idée pour la suite c’est de faire un gros tableau pour glDrawArrays() avec tous les cubes « statiques », tableau créé pendant la lecture de la carte. Avec une gestion de l’occlusion (j’ai déjà, marche à merveille!) on entre que les faces visibles, cela limite en taille.
Evidement tu vas me demander comment cela ce passe quand on retire ou ajoute un cube: en faite plutôt qu’un gros tableau pour toute la carte, qui pourrait évidement être trop gros pour la mémoire (et puis carte infinie on oublie) je découpe la carte en « clusters », chaqu’un de taille fixe (genre 25x25x25 cubes). La boucle principale de rendu cherche premièrement dans les clusters en mémoire ceux qui sont visibles dans le champ de la caméra.
Pour chaque cluster je rend avec 1 seul appel à glDrawArrays() tout son contenus. Si rajout d’un cube j’ajoute dans mon tableau une entrée à la fin. Si on retire un cube, je vire l’entrée pour ce dernier et si ce n’est pas le dernier de la liste je le remplace par le dernier, pour pas avoir de « trous » dans le tableau.
Les clusters seront eux mêmes gérés dynamiquement pendant le rendu: si le joureur comment à aller dans un secteur où il est proche d’un cluster de bordure, des nouveaux sont générés qui remplaceront les plus lointains de la camera… histoire de garder de la mêmoire.
Avec tout cela je pense que je devrais avoir de bonne perfs.
De plus les textures pour les cubes « monde » sont tous dans la même texture OpenGL, donc 1 seul appel à glBindTexture avant le rendu de toute la carte, avec de passer au « sprites ». Mais là c’est une autre histoire
Note:
Après réflexions (et calculs…) je vais pas faire 1 tableau fixe par cluster, car 1 face c’est 32 octets (12 pour les vertexes, 12 pour les couleurs, 8 pour les textures), donc 1 cluster de 11 cubes de côté donne 255552 octets, avec une distance raisonnable de 10 clusters de côté stockable en mêmoire on obtient 243.7 Mo! :'(
Cela serait dommage de prendre autant si en plus un cluster n’est pas remplis à fond (avec que des blocks transarents en plus pour être sûr de devoir tout afficher).
Je vais voir pour un truc plus dynamique.
- Vous devez être connecté pour répondre à ce sujet.
