ThunderZ :
Alors les reponses en paties 
en gros selon ta description d'au dessus, c'est similaire a une grille de voxels?
Non le voxel engine est très particulier tu as pour te simplifier un mega tableau de donner (le plus simple, x,y,z,coleur) qui correspond a CHAQUE points.
heu non
deja je te parle d'une grille de voxels, pas d'un "voxel engine"
et tel que tu l'as decrit: "il passe donc par un systeme de cellule, une grille quoi pour calculer sont univers.
Cela ne veux pas dire que l'on affiche que des cubes, non, non mais que l'on utilise les cellules de cube pour le cacul."
passke ca ou je me trompe ou ca veut dire que t'as une grille de cubes, et que tu te sers de cette grille de cubes "pour le calcul"..
mmh quel calcul?
et tes "cubes" tu les stock comment? dans un arbre? un ABTree? un arbre binaire? un KD-tree? un AABB tree? un octree? un asasjdfajds tree?
ou juste dans une liste?
La c'est un landscape, tu definie une serie de vertex de base et tu definies tes polygones depuis les points.
Le cube engine lui definie des secteurs depuis des vertexs donc.
"La c'est un landscape" > un terrain? les levels sont stockes dans une heightmap?
mais ptetre que tu dis ca passke sur le site dont t'as file le lien y a "Landscape-style engine"?
"tu definie une serie de vertex de base et tu definies tes polygones depuis les points" -> si c'est ca, y a aucune difference avec une mesh normale
"Le cube engine lui definie des secteurs depuis des vertexs donc" -> cpas l'inverse plutot? remarque on a ptetre pas la meme definition de "secteurs"
pour toi c'est quoi un "secteur"?
absolument pas. un bsp ca veut dire ce que ca veut dire, les deux premiers dooms utilisent des BSP 2D, c'est toujours un bsp... meme principe qu'un BSP 3D... et tu dis? doom3 utilise pas de bsp? roooh
Voui les dooms utilises un bps 2D c'est vrai mais je pensais a un bsp 3D plutot moi j'en utilise pas
Doom 3D je crois kil melange BSP et autre technique, faudra que je me renseigne a titre personnel (en tout cas la gestion des lumières est un miracles )
un miracle? le systeme de lumieres de doom3 etait impressionnant il y a 1 an. plus maitenant... j'irais pas a dire que c'est une merde compare avec ce qui peut se faire avec le hardware actuel, mais presque. les shadow volumes sont immondes, ils abusent de la composante speculaire dans l'eclairage de leurs surfaces, tout ou quasiment a une gueule de plastique...
tu veux savoir comment faire ca ou mieux?
google shadow volumes, google per pixel lighting, google programmable hardware, google hardware/vertex shader shadow volume extrusion, DOT3 bump mapping, blinn/phong/diffuse bump mapping, etc, etc...
et puis:
http://developer.nvidia.com http://www.ati.com/developer/
un Z-buffer c'est pas utile pour "la resolution", au contraire... plus ta resol est elevee, plus t'as besoin d'avoir un bon fillrate... la dans ton cas justement, un Z-buffer serait pas si couteux que ca, vu que la resolution est faible. mais ca depend aussi de la quantite d'overdraw sur une frame. et si tu dessine les faces d'avant en arriere avec un bsp relaxe + pvs pour reduire l'overdraw sur les grandes maps, tu peux gagner beaucoup en utilisant un Z-buffer...
Par contre la suis pas du tout d'accord avec toi.
Je tourrais donner entièrement raison sur PC pour deux choses -> resolution basse et ecran geant + proc puissant et memoire enorme.
La on est certe en 320*240 mais sur un PETIT ecran donc les erreurs visuel sont très très faible (idem pour la correction de perspective sur les textures), actuellement le rendue des textures est plus fin et crois moi ca rend terrible.
De plus un ZBuffer meme en 320*240 ca bouffe un peu plus de memoire (faut l'econimiser a tout niveau) et du temps de calcul suplementaire donc a eviter en priorité.
tu t'es demande les changement que tu pourrais faire a "ton" code, et tout ce que tu pourrais virer si tu utilisais un z-buffer?
tu t'es pas demande si l'overdraw que t'as sans z-buffer etait pas plus couteux que si t'utilisais un z-buffer?
et si tu utilise un bsp (
), tu peux faire comme faisait Q1, c'est a dire dessiner d'arriere en avant, avec uniquement des ecritures dans le z-buffer, et n'y lire+ecrire dedans que pour afficher les objets dynamiques... mais bon si tu laisse ton truc comme ca, juste avec une map, cette methode la n'a aucun interet... par contre afficher la map avec le z-buffer, ca en a un
et je t'ai pas parle d'erreurs... et de toute facons meme si t'as des erreurs de tri et que l'ecran est petit, c'est pas une excuse, c'est _tres_ ennervant d'avoir les yeux distraits par du flickering quand tu te deplace...
du geometric mipmapping? 
?
)
ils ont surement mis ce nom pour designer l'effet de popping qui se produit quand des chunks de geometrie sautent d'un niveau de LOD a un autre (ils ont pas de geomorphing? haaaannn... 
), tu peux faire comme faisait Q1, c'est a dire dessiner d'arriere en avant, avec uniquement des ecritures dans le z-buffer, et n'y lire+ecrire dedans que pour afficher les objets dynamiques... mais bon si tu laisse ton truc comme ca, juste avec une map, cette methode la n'a aucun interet... par contre afficher la map avec le z-buffer, ca en a un 
!!!!!!!
![[/img]](https://www.yaronet.com/pmag/pubf.gif){kind=link}