Minecraft!

15 sujets de 151 à 165 (sur un total de 201)

BatteMan
8 décembre 2011 à 8h38 #142280
Ce soir, ou demain…, je teste ça sur le Mac Mini.

J’ai déjà réinstallé Gribouillis 3 (via Grunch, qu’est-ce que c’est pratique ce truc), et c’est de la bombe de balle avec la Wacom ! Me reste à réinstaller Helios, et tester ce Minetest.

Yomgui est magique !

—

/me verrait bien Yomgui dans une équipe de basket US ! Avec la foule qui scande son nom quand il rentre sur le terrain !! YOM-GUI !! YOM-GUI !! YOM-GUI !! YOM-GUI !!

Only Amiga makes it possible !
Yomgui
8 décembre 2011 à 11h59 #142281
@bat: tu veux qu’on me prenne pour le ballon? Du haut de mon 1.70m j’imagine pas le truc

Bon vous m’en direz plus alors… quand vos becannes sont prêtes
BatteMan
8 décembre 2011 à 21h42 #142282
30 FPS avec le réglage de base qui donne déjà une bonne vision du terrain, perso, je trouve ça épatant !

Toujours 30 FPS avec 6 en x et z (consomme 50% des 1 Go de mémoire). Avec 8, je suis à 97% de conso et 25 FPS de moyenne ^^ (bon OWB est ouvert derrière et j’ai déjà 15% de mémoire utilisée).

Bon, c’est sur le Mac Mini (à 1,75 GHz ^^) et ça dépote méchant ^^

Par contre, pas moyen de lancer Gribouillis ici. J’ai récupéré la dernière version de Python sur ton site (pas réussi à faire l’install’ depuis Grunch, il échoue au moment de l’installation de Python) et toutes les dépendances sont installées… mais j’ai quand même droit à un « Python is not executable » quand j’essaye de lancer Gribouillis. Une idée ?

—

/me abuse un peu en étant limite HS, mais bon ^^

Only Amiga makes it possible !
henes
8 décembre 2011 à 21h57 #142283
Yomgui a pété son Python aujourd’hui. Il va falloir attendre qu’il corrige (ou trouver une ancienne version).
serge
8 décembre 2011 à 22h01 #142284
vous allez me prendre pour une bille mais je n’arrive pas a mettre la main sur Python? 😮

Yomgui, suivant les liens de DL de meta-morphos vers ton site j’ai des pages 404

est ce que c’est bon si on a la version 3.x?

EDIT : j’ai trouvé

RyZen Rulez 😉
BatteMan
8 décembre 2011 à 22h02 #142285
Rah, méchant Yomgui ! Bon, reprenons le « vieux » Python que j’ai qui traîne sur un HD !

Merci sieur henes de l’info !

En matant rapidos, c’est juste qu’au lieu d’avoir le fichier-lien « python » qui renvoye sur le fichier « python2.5 », on a un fichier vide nommé « python ». J’ai donc effacé le fichier « python » et j’ai recréé le lien via makelink ^^

Serge : Pour récupérer tous les fichiers qui vont bien, passe par les liens pour les dépendances nécessaires à Gribouillis : http://yellowblue.free.fr/yiki/doku.php/en:dev:gb3:start ^^

—

/me avait un backup, ouf ! ^^

Only Amiga makes it possible !
Yomgui
8 décembre 2011 à 23h26 #142286
Contrairement à ce que dit Hene, j’ai rien pété dans Python, c’est Grunch et ses régles d’install avec lesquelles j’ai du mal.

Essayez maintenant, j’ai corriger plein de truc dans la .db

@serge: malheureusement MM ne peux pas suivre les mise-à-jours, donc les liens sont régulièrement cassés, cela vaut mieux, car sinon après les gens ont jamais les versions adéquates.
Yomgui
13 décembre 2011 à 19h25 #142287
Ce fils n’est plus dans la liste en première page?!

Pour la peine, je vais écrire quelques lignes, histoire de faire mon blog ici. Je sais, j’en ai un, mais c’est tellement mieux d’aller pourrir les serveurs des autres! (de toute façon personne n’ira lire le miens).

Malgrès les « bonnes » performances données par le moteur actuel, et même si « battleman » (il adore) trouve cela pas mal sur sont G4 à la nitro, moi je trouve cela médiogre au final.

Surtout quand je vois les perfs que de pauvres adaptations obtiennent sur des tablettes pas franchement plus véloces.

Donc je revois ma copie:

1) je garde l’idée d’utiliser glDrawArray(), voir même mieux glDrawElements() si possible, cel ame permettra de passer aux VBO quand disponible sur TGL.

2) il faut mettre un max de points par appels à ces fonctions: donc le moteur c’est un remplissage de tableaux en gros.

3) Mais faut tout mettre! Et c’est là que mon moteur actuel souffre d’un grand mot: certe j’utilise une passe d’occlusion permettant de savoir si un bloc était totalement caché ou non. Mais je tracé tous les blocs potentiellement visibles qui restés dans tous les clusters visible du fustrum. En gros une caverne sous les pieds du joueur était rendue, même si elle n’était à priori pas visible.

Dommage… Il me faut donc un algo de occlusion culling adapté.

Pour régler le problème du point 3), je décide au passage de changer la façon dont le fustrum culling était fait (actuellement en regardant si la bbox d’un cluster de blocs était visibles ou non).

Note: en parlant de bbox (bounding box, ou boite englobante en plus français), j’utilise ici des AABB (Axis Oriented Bounding Box), facile à manipuler.

Revenons à nos moutons (cubiques évidement): un fustrum culling sympas pour ce type de config de terrain c’est le octree, voir un kd-tree (je me tate…)

Pour les crétins, ah non.. pardons, je me crois sur le site du zero (cf les vociférations d’une certaine personne), ce sont des concepts mathématiques pour découper votre espace 3D en sous-espaces, dont les propriétés vous permet d’accélérer les recherches des éléments ci trouvant.

Une fois cela fait (test de perfs s’impose) correctement, mon idée est de stocker dans les noeuds que les blocks ayant au moins une face visible (de la même façon que mon « occlusion tree » actuel, mais en moins consommateur de mémoire). Je ne vais pas créer une structure pour définir tous les blocs, juste ceux potentiellement visibles (ou BPV).

Bon tout ceci ne résoud pas mon problème d’occlusion global, mais cela m’aide à réduire le nombre de tests. En particulier le cas de la caverne sous le joueur (enfin un peu plus loin mais dans le fustrum).

Quelque soit l’algo trouvé, le grand problème est que je dois le relancer complétement à la moindre modification des propriétés de la caméra.

Il faut donc que l’algo soit très simple et très rapide évidement.

Là encore j’ai un début de piste: les blocks d’un cluster MC sont tous réunis dans un tableau de 32768 entiers d’un octet par blocs (16x16x128).

Pour les connaisseurs en mémoire cache de CPU, c’est une taille très sympatique n’est-ce pas! Si l’octet vaut 0, c’est de l’air, sinon c’est un blocs, solide ou non.

Si maintenant j’utilise une technique de lancer de rayon à travers ce tableau en testant juste si l’octet est différent de 0 ou tout autres valeurs de blocs solides, on arrête le rayon: si on a pas rejoint le bloc tester, c’est qu’il est pas visible.

Maintenant est-ce améliorable? Si je lance un rayon par BPV, est-ce que je peux mettre à contribution plsuieur tests dans 1 seul lancé? car j’ai peut-être d’autres BPV? Mais là cela casse mon idée d’accés cachés… humm à réfléchire, j’y gagne peut-être plus.

bon voilà je m’arrête là pour aujourd’hui. :sweat:
Mod
Tcheko
13 décembre 2011 à 23h02 #142288
Tiens biloute :

http://code.google.com/p/efficient-sparse-voxel-octrees/
Yomgui
13 décembre 2011 à 23h05 #142289
@Tcheko: tu ->[] et surtout tu ne <-[] ! (au passage j’adore le mec qui fait la grosse pub CUDA avec son « efficient » et qui ne fait qu’utiliser des API haut niveaux toute prête… press-button-power!)
Mod
Tcheko
13 décembre 2011 à 23h50 #142290
Baaa… C’est juste une piste… Octree + voxel, c’est généralement une solution qui marche.

Après CUDA… peu importe. C’est l’essence de l’algo qui compte.

En tout cas, bon courage.

++

(Et oublie pas de packager helios )
Yomgui
14 décembre 2011 à 12h08 #142291
Episode 2: L’arbre qui cache la forêt

J’était parti sur mes partitionnement d’espace avec octree et kd-tree: je viens de rapidement m’apercevoir que le problème de l’un comme de l’autre c’est qu’ils sont dédiés à des scène statiques.

Or MC c’est très dynamique: tout est destructible, tout est constructible!

Un petit coup de « dynamique kd-tree » dans google me confirme mes craintes, mais me donne aussi des pistes: le BVH voir aussi le BIH (non c’est pas les noms de nouveaux virus).

En gros c’est des kd-tree avec des AABB … (là j’en ai perdu 6)
krabob
14 décembre 2011 à 12h34 #142292
… puis quand tout est en cube, ya pas besoin de kdtree: on sait ou est quoi, les kdtree c’est pour des world ou les polys sont « n’importe ou » , avec des échelles de détails qui varient. Dans une scene 3D habituelle avec des poly décrit dans n’importe quel sens, on ne sait pas dire quels poly sont présent dans un espace donné, c’est pour ça qu’il faut un kdtree, qui va permettre de dire « là, il y a ça »… (en général le plus lourd avec les kdtree c’est qu’il faut gérer la subdivision des grands polygones par les sections du kdtree, en plus petits polygone, et garder 2 bdd 3D: l’originale avec les polys de base, et la version subdivisé, et les objets des 2 bdd sont synchronisés si les objets doivent être dynamiques. Pas de mystère, même des moteurs de dessin 2d ont ce design pattern (cf batik et SVG/GVT ) )

Dans un monde de cube, la matière est déjà indexé ! tout ce qu’il y a a faire c’est parcourir les cubes qui intersectent la pyramide( ou cône) de projection. Dans ce cas on peut aussi parcourir ces cubes de la base de la projection (position camera) vers le fond, et arréter de dessiner quand on sait que l’écran est plein.
krabob
14 décembre 2011 à 12h51 #142293
autre suggestion à creuser:

La technique de raytracing de « cube illimité » par marchéage:

Utilisé par exemple dans une demo amiga très rapide sur 68k:

« Any One Of These Suckers by Ephidrena »

(edit: pour « any one… » je subodore que loady a utilisé une technique mixe de « voxel de sol » la plupart du temps (traçage de ligne verticales qui permet de suivre les cubes et refaire le marchéage que quand on « tombe » d’un cube))

.. ou encore l’intro 256b hell de exceed, qui fait aussi du marchéage de cube rapide:

hell by Exceed

… pour un rendu GL de ces choses, lier ça à un algorithme genre « tile accélerator » de la dreamcast ou rendu « superscalaire » de raytracing (même chose)
Yomgui
14 décembre 2011 à 13h24 #142294
@krabob: oui j’ai regardé le cube marching, mais c’est pas adapté non plus ici. Cette technique pond des polygones non orientés.

De plus j’ai appris a me méfier des demos, implementant des algo de façon trop ad-hoc: résultat inexploitable dans un cadre plus générique.

Sinon le kd-tree tu peux l’employer avec une grille très homogène, mais le BIH est bien mieux dans ce cas..

Attention ne pas dire qu’une scène avec des objets sur une grille homogène n’a pas besoin de partitionnage. C’est complètement faux, et cela ce voit quant tu dépasses le millions de cubes! Impossible d’aller s’amuser à le parcourir linéairement, car c’est de complexité O(n)! Il faut des algo en O(log n).