Minecraft!
-
D’après les screenshots de bug d’affichage de la version alpha je peux affirmer que c’est la même méthode + ou -.
Mais maintenant eux ils peuvent utiliser les VBO, où les vertexes sont envoyés une seule fois vers la mémoire GPU. Moi je reste sur plusieurs glDrawArrays: cette méthode envoie les vertexes à chaque frame, limitant la vitesse.
Je ne peux dépasser les 400k faces par secondes, soit plus beaucoup si on veux du 30 images seconde…
Voilà de quoi je parle par les glitches de MC:
Sinon en relisant les posts, je me suis rendu compte d’une amélioration possible donnée par quelqu’un. Sur le coup j’ai pas percuté, mais l’astuce est possible et peut déjà diviser le nombre de poly envoyés vers le GPU.
Je test ça et je reviens
Donc voilà j’ai tenté… mais bof bof…
Voilà l’idée de base: je sais plus qui avait dit « de toute façon on ne voit que 3 faces d’un cubes en même temps ».
C’est juste, de plus j’avais vu sur le blog de l’auteur de MC qu’il a (toujours?) réduis de 40% environs la quantité de poly envoyés au GPU en utilisant 6 listes, une pour chaque face, et en affichant que les listes des faces visibles.
L’idée semble bonne, mais en faite elle est complétement incorrecte!
Voilà une image que j’ai fait sous blender pour illustrer mes propos:
J’ai dupliqué un même cube, avec une couleur différente par face.
Question: Combiens de couleurs dénombrez vous?
Réponse: oui, c’est bien 5! Et pas 3 comme l’idée de base le suggère.
Effectivement c’est bien 3 faces visible… mais pour 1 cube!
Dans un ensemble de cubes positionnés aléatoirements c’est 4 ou 5… et encore, seulement si votre angle de vision de caméra est limité (moi c’est 90°)!
Avec un champ plus large, vous pouvez voir toutes les faces!
Donc le gain ne sera malheureusement que de 1/6, voir 2/6 dans des cas particuliers, soit entre 15-30% environs et pas 40% comme annoncé.
Dommage (mais c’est toujours cela de pris).
Prochaine idée: grouper les poly adjacents de même texture (dans un axe donné) pour n’en faire qu’un et utiliser un altas de texture de 1×256 + un mapping en répétition. Cela devrait aussi enlever qq polygones. Mais c’est fonction de la structure d’un cluster.
juste une info comme ça:
Le moteur 3D opensource Cube2 (sauerbraten)
a des maps également basé sur des voxels cubique (d’ou leurs logo): il fait ensuite intervenir une notion de lissage, donc les cubes ne se voient pas sur les map,( mais dans le mode édition c’est très clair), mais en fait c’est pareil que minecraft. J’en cause parce que cube2 est connu pour avoir une gestion de son octree et de dessin de polygone et de clipping très tiptop. (sudo apt-get source sauerbraten pour les debianiste)
Bah parlons en de Cube2: je viens d’en faire le portage ce matin (c’est au moins un très bon code C++, c’est tellement rare que cela mérite d’être dit!), bon sauf qu’il n’y a pas un seul commentaire… donc pas simple pour piger vite ce qu’il fait.
Par contre même avec tout au minimum dans une petite fenêtre, rien à faire pour les FPS… c’est hyper lent (sauf si map hyper basic avec rien dedans).
Le mode edition est très rigolos…
bon aller parce que je suis sûr que vous aller me le demander:
voilà les binaires (RPG et FPS)
http://www.yomgui.fr/prv/rpg_client
http://www.yomgui.fr/prv/sauer_server
http://www.yomgui.fr/prv/sauer_client
A lancer dans le répertoire avec les données officielles (les récupérer depuis leur site…)
Je lance la commande dans un shell ainsi:
rpg_client -w640 -h480 -t
Enlevez le -t pour le mode fullscreen
[edit]le fps (sauer_*) plante, je regarde pourquoi….
[edit2]alors en faite des fois ça plante pas… ca sent la variable non initialisée. pi dépend du mode choisi
@Yomgui :
Je prends un peu le sujet en cours …
Je me rappelle t’avoir vu à l’Alchimie avec le projet qui était déjà commencé si je ne me trompe pas … non ?
J’ai juste une petite question … je suis peut-être à l’ouest sur le sujet car j’ai pas lu les 9 pages du sujet complet … Mais une question me vient à l’esprit …
As-tu instancié tes objets 3D ?
Je suis quasiment sûr que tu vas me dire « oui depuis longtemps » … Mais je sais pas pkoi … Fallait que je le mette …
@ +
AmiDARK
Looool
Ce que l’on appelle une « instance » d’un objet 3D :
La structure « fil de fer » de l’objet 3D et les textures ne sont chargées qu’1 fois pour l’objet
après lorsque tu traces le rendu, tu utilises toujours la même structure « fil de fer » et la même texture pour les objets 3D identiques du décor…
Je te posais la question car je sais pas si dans Python tu peux faire des instances d’objets 3D …
…
@ +
AmiDARK
C’est bien se que je pensé par instance… alors oui… et non!
mes les vertexes sont créés à partir de copie de ceux d’un objet de base, donc oui il y a bien instanciation. Par contre j’envoi les vertexes à toutes les frames car il n’y a pas de VBO encore (dans tgl).
Yomgui a écrit :
Le mode edition est très rigolos…
bon aller parce que je suis sûr que vous aller me le demander:
voilà les binaires (RPG et FPS)
http://www.yomgui.fr/prv/rpg_client
http://www.yomgui.fr/prv/sauer_server
http://www.yomgui.fr/prv/sauer_client
A lancer dans le répertoire avec les données officielles (les récupérer depuis leur site…)
Je lance la commande dans un shell ainsi:
rpg_client -w640 -h480 -t
Enlevez le -t pour le mode fullscreen
[edit]le fps (sauer_*) plante, je regarde pourquoi….
[edit2]alors en faite des fois ça plante pas… ca sent la variable non initialisée. pi dépend du mode choisi
Un grand merci pour ce portage
Faut vite que je me remonte une machine MorphOS moi !!
Je vais avoir du temps bientôt
Abonnez-vous à ma nouvelle chronique "En Route vers le Futur" sur Youtube !
Mouarf… j’avais même pas fait attention que le créateur de cube engine et aussi celui du langage Amiga-E
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Minecraft!