Discussion :

[N_I_C_S]

@Kannagi
Merci ^^ ! Je crois que mon obsession c'est de m'éloigner d'un jeu java bien connu . (qui est super mais y a tellement de clones...)

@Dabou_Master
Ha ha, touché ^^ ! En fait le but c'est de reporter l'entière responsabilité des niveaux sur les joueurs . Pour ça, j'essaye d'implémenter le max de possibilités pour les futurs level designers (ce jeu c'est le consensus mou ). Pour ma part, bien vu^^, je continuerai à faire du bourrin pour mes niveaux, je sais rien faire d'autre !
Mais mine de rien tu poses indirectement un sérieux problème de gamedesign : comment concilier action/shoot'em-up et très grandes maps, autrement qu'en faisant du couloir ?

[Dabou Master]

Hum, regarde les principaux FPS bourrins (je vois principalement de l'arène sinon il y a les styles avec d'énormes masses de monstres) donc les Unreal Tournament et Q3, le dynamisme était souvent au rendez-vous grâce aux étages et à des propulseurs, donc sauter un peu partout ça rajoute sans doute beaucoup. Sinon ben tu fais de grandes landes tranquilles avec montagnes et autres et d'un coup tu entends un cri au loin suivi d'un nombre incalculable de bestioles (inspiration : Serious Sam, KISS psycho circus) et cette foutue montagne qui en fait n'en était pas une et te fonce dessus :'(.

Je ne demande qu'à pouvoir t'aider à bonifier ton style ^^ mais je t'avouerai que je ne saurais pas trop t'aiguiller dans la réponse à ta question. Je pense que dans le design il faut éviter trop d'arrondis qui apaisent l'esprit (c'est mon ressenti et peut-être que tu peux trouver des études sur les formes agressives ou apaisantes), et sans doute aussi éviter les endroits tranchants avec que de l'angulaire qui fatiguerait sans doute le joueur ...
Je te laisse méditer sur ces quelques ... méditations ^^.

[Kannagi]

@Kannagi
Merci ^^ ! Je crois que mon obsession c'est de m'éloigner d'un jeu java bien connu . (qui est super mais y a tellement de clones...)

mmh Flesh Snatcher ?
Sinon quand elle vient cette prochaine démo ? (même si le jeu est bien finalisé).

Je te laisse méditer sur ces quelques ... méditations ^^.

Quelle phrase profonde , c'est le seul truc que j'ai retenu

Sinon j'avais jamais entendu ces formes apaisante et agressive , c'est bon a savoir.

[N_I_C_S]

@Dabou_Master
hmm, surement, le shoot non-stop c'est pour des environnements limités, je vais pas commencer à vouloir faire trop de trucs à la fois comme pour flesh snatcher !

Pour le design, oui, en théorie toute la palette est possible du plus doux au plus abrupt, le tout étant de bien choisir en fonction du type de niveau... (c'est là que je dois méditer sérieux )

@Kannagi

mmh Flesh Snatcher ?

!

Sinon quand elle vient cette prochaine démo ?

Ha ha, dans quelques jours (1 semaine max) ! j'ai perdu du temps sur ces histoires de mémoire, déjà que je galère sur mon niveau supplémentaire .

[N_I_C_S]

Salut, quelques nouvelles .

Désolé, toujours pas de nouvelle démo car cette semaine j'ai encore perdu du temps à trituré le code mais c'est pour la bonne cause : j'ai enfin réussi à récupérer les normales lissées par vertex sur les terrains (sans shader ni aucune manipulation GPU, ni volume mémoire supplémentaire, d'où la difficulté...).
Esthétiquement ça ne convient pas forcément à toutes les formes (comme le dit Dabou_Master) mais allié à des terrains accidentés ça peut donner un aspect "liquide" sympa :



D'autre part j'ai laissé tomber les textures 3D très gourmandes en mémoire pour revenir aux textures classiques car j'ai trouvé une technique de mapping uv simplissime mais efficace. (bon, pour un résultat parfait il faut à la texture certaines caractéristiques : tileable + symétrique par rapport à la diagonale, mais procéduralement ce n'est pas difficile à générer ).

Voilà, je retourne à mon niveau pour vite mettre en ligne une nouvelle démo ^^ .

[Othana]

Si je puis me permettre, j'aimerais discuter avec toi de ta technique de voxel.
Je cherche un truc, pour mon projet, qui me permettra de générer des maps aléatoires destructibles.
Pour un RPG/bac à sable.

[c.aug]

Si je puis me permettre, j'aimerais discuter avec toi de ta technique de voxel.
Je cherche un truc, pour mon projet, qui me permettra de générer des maps aléatoires destructibles.
Pour un RPG/bac à sable.

Pour afficher les maps structurées comme du voxel on utilise un vieil algorithme très connu qui s'appelle "marching cube". C'est avec ça qu'ils font les terrain du cryengine par exemple, c'est infiniment plus performant que les heightmap d'unreal ou les quadpatch d'id tech, ça donne un terrain entièrement creusable.

http://www.exaflop.org/docs/marchcubes/

[N_I_C_S]

@Torq le nain
Bien sûr, avec plaisir ^^ .
Oui, la base est l'algo des marching cubes.
On peut en parler où tu le souhaites (en privé ou ici ).

@c.aug
Oui, enfin l'algo strict sert à polygoniser une formule mathématique (il servait au départ pour l'imagerie médicale), il faut un peu plus de boulot pour les terrains modifiables...
Et, même si le principe est bien connu, une implémentation performante et optimisée est loin d'être évidente, je l'ai appris à mes dépends . La gestion mémoire, par exemple, devient vite un problème (surtout quand, comme moi, on vise les petites machines) car on est vite confronté à des millions de voxels. Ca engendre aussi des difficultés annexes, comme la gestion des collisions (si on programme sa physique) loin d'être triviale sur ce type de géométrie (déjà que c'est pas évident sur des modèles classiques ), etc...
Bref, même si le principe est vieux (enfin, 1982 ) y a de quoi s'amuser autour !
Qu'entends-tu par "plus performant que les heightmaps" ? Ca n'a pas le même usage... (d'ailleurs j'utilise les 2, et en vitesse de traitement c'est plutôt l'inverse )

[Othana]

Pour afficher les maps structurées comme du voxel on utilise un vieil algorithme très connu qui s'appelle "marching cube". C'est avec ça qu'ils font les terrain du cryengine par exemple, c'est infiniment plus performant que les heightmap d'unreal ou les quadpatch d'id tech, ça donne un terrain entièrement creusable.

http://www.exaflop.org/docs/marchcubes/

@Torq le nain
Bien sûr, avec plaisir ^^ .
Oui, la base est l'algo des marching cubes.
On peut en parler où tu le souhaites (en privé ou ici ).

Merci à vous deux. Effectivement, j'ai beaucoup entendu parler des marching cubes, durant mes recherches. Ça reste pour moi encore bien obscur, pour le moment, mais ces infos vont m'aider à m'orienter.
Alors en ce moment, et c'est ce qui me freine le plus, c'est justement la génération de terrain et pourtant je me contenterais que de la topographie (du relief), le reste sera du placement d'objets tout fait et de textures.
N_I_C_S, je voudrais bien en parler oui, plus en privé, pour pas polluer ton sujet. De toutes façons, je sauvegarde tout ce qui a trait à mon projet et ce sera publié, quand ce sera bien lancé. Pour l'heure, l'ami Dabou Master m'a fait un joli modèle de test de perso et se rend dispo pour m'aider en faisant la modélisation 3D des créatures, et je n'ai que des études de techno, un cahier des charges, ainsi qu'un prévisionnel et quelques cas analysés (un RPG/sandbox c'est autrement plus complexe qu'un plateforme ).

[c.aug]

une implémentation performante et optimisée est loin d'être évidente, je l'ai appris à mes dépends . La gestion mémoire, par exemple, devient vite un problème (surtout quand, comme moi, on vise les petites machines) car on est vite confronté à des millions de voxels.

Normalement la ram du voxel ça s'optimise avec un octree. Si ça suffit toujours pas c'est qu'il faut baisser la résolution.

Ca engendre aussi des difficultés annexes, comme la gestion des collisions (si on programme sa physique) loin d'être triviale sur ce type de géométrie (déjà que c'est pas évident sur des modèles classiques ), etc...

Si tu sais programmer les collisions contre un triangle ou un polygone convexe, tu sais les programmer sur un marching cube puisque cet algo ne fait que générer des polygones.

(d'ailleurs j'utilise les 2, et en vitesse de traitement c'est plutôt l'inverse )

Oui en vitesse de traitement la heightmap est plus simple parce qu'aucun calcul vertex gaspillé dans les chunks. Avec le marching cube les trois quarts du vertexbuffer du chunk est calculé pour rien vu que le nombre de triangles affiché est généralement très en deçà du maximum.

Je parlais de performance en terme de modeling, dans le marching cube on peut creuser dans tous les sens.

[LittleWhite]

N_I_C_S, je voudrais bien en parler oui, plus en privé, pour pas polluer ton sujet.

Et pourquoi pas dans un autre sujet du forum, pour en faire profiter tout le monde, simplement.

[Othana]

parce que :

De toutes façons, je sauvegarde tout ce qui a trait à mon projet et ce sera publié, quand ce sera bien lancé.

?
Je me suis déjà fait plomber un sujet sur mon projet, qui est d'ailleurs bloqué et que je vais devoir réécrire.

[N_I_C_S]

@Torq le nain
Ok, je t'envoie un MP .

l'ami Dabou Master m'a fait un joli modèle de test de perso

Ha ha, je suis curieux de voir Dabou Master à l'oeuvre !

@c.aug

Normalement la ram du voxel ça s'optimise avec un octree.

Oui, par exemple . Mais attention, un partitionnement de l'espace n'a jamais diminué la taille mémoire d'un modèle donné, dans ce cas il sert à générer un modèle plus léger (mais au prix de voxels de taille variable, ce qui dans mon cas est embêtant).

Si tu sais programmer les collisions contre un triangle ou un polygone convexe, tu sais les programmer sur un marching cube puisque cet algo ne fait que générer des polygones.

Non, je fais de la collision continue .

Je parlais de performance en terme de modeling, dans le marching cube on peut creuser dans tous les sens.

Oh, ok .

[N_I_C_S]

Hello,

je ressors de mon cercueil (hin hin) pour donner quelques nouvelles de ce projets abandonné depuis de (trop) nombreux mois.

Ces jours-ci, pour m'y remettre doucement, j'ai essayé de profiter des fonctionnalités du code pour faire un petit système de cubes (c'est pas l'idée de l'année, mais ce sera un type de décor parmi d'autres, qu'on pourra mixer avec les autres, et puis ça va bien avec le design vectoriel du jeu ).

Quelques screens ?






Voici donc le résultat de mes efforts (un petit générateur de maps), après une petite semaine (oui, les petits cubes ça simplifie extraordinairement les choses !), que je soumet à votre jugement impitoyable :

http://tesseract-fps.sourceforge.net...troma_exp.jnlp
(Touches : E, S, D, F, Space | Souris : Direction | Click gauche : Détruire | Click droit : Construire)

Prérequis :
- Avoir Java installé (1.5 minimum) !
- Supporter 1 Go de RAM pour l'appli
- Supporter les shaders (GLSL)

ATTENTION : Choisir une grande taille de map + beaucoup d'octaves = temps de génération affreusement long !

N'hésitez pas à me faire part du moindre bug que vous remarqueriez !

[Vetea]

Salut NCIS !!!

Ravi de voir que tu as repris ce projet en main !
En occultant Minecraft et d'après les captures, c'est super travail et le rendu est superbe !
Bravo !

Dès que je rentre de mes petites vacances je DL et resterai ces travaux.
Bon courage pour la suite et a bientôt !

[LittleWhite]

Cela affiche combien de cubes ?
C'est super, quelles sont les techniques ? Frustrum culling ? Face culling ?
Quelles techniques OpenGL ? VBO ? VAO ? autre objets ?

[N_I_C_S]

@Vetea
Merci Vetea !
Ha ha, je voulais surtout pas faire comme Minecraft et j'ai craqué !
J'attend de pied ferme tes commentaires !

@LittleWhite
Merci !
En fait tous les cubes sont décrits par un grand tableau de bytes (par ex. un décor de 1024x256x1024 pèse 256 Mo),
Ensuite il y a un tableau de chunks verticaux (mis à 16x256x16 cubes dans la démo mais paramétrables), dont le rôle est de lire le tableau des cubes à chaque modification pour en extraire la géométrie et l'envoyer au chipset comme VBO (ou display list).
Et en effet il y a du frustum sur les chunks, qui possédent chacun (hormis leur VBO id) 6 floats à cet effet (vertexes min et max).
Enfin, l'objet décor dessine les chunks de près à loin selon une distance de clipping paramétrable (16 chunks autour du joueur pour la démo, ce qui correspond potentiellement à =~ 17 millions de cubes autour du joueur).
Pour le face culling j'utilise un simple glEnable(GL_CULL_FACE); !
L'inconvénient de ce système, par rapport à ceux de type Minecraft, est que, pour être compatible avec les autres types de décor dans la même map, il ne peut pas supporter une génération à la volée, il doit être généré entièrement avant de jouer la map, d'où un temps de chargement qui peut être long .

[Vetea]

Mon cher NICS, comme promis j'ai téléchargé pour tester ce nouveau moteur !

Mais hélas j'ai une erreur d'application :




Ben j'aimerai bien tester moi !! !!
Tu pourrai le réaliser en QB64 sinon ...

Allez bon courage et à bientôt !

[Dabou Master]

Salut NICS, content de voir que t'es encore en vie (enfin d'après tes dires ce n'était plus le cas mais ça l'est à nouveau ^^).

Ton décor là me fait terriblement penser à Cube World. Je suis quand même salement admiratif de ton travail ! Je ne saurai jamais si la génération est complexe ou abordable ou ... je sais pas quoi mais ça reste le genre de truc que, quand tu sais le faire, tu peux à peu près réaliser ce que tu veux à partir de là.

J'ai néanmoins une question un peu stupide que j'aimerais te poser pour mon savoir personnel.
A partir de tes compétences actuelles en terme de génération, peux-tu faire évoluer cette technique vers un rendu plus réaliste ? Par exemple la génération de terrains en voxel (cf. StarForge) ou des formes plus abouties ? Je ne saurais m'expliquer mais en quelque sorte changer de "brosse" (désolé j'essaie de l'expliquer avec quelque chose qui me parle un peu plus), au lieu de mettre un cube, se retrouver avec une figure plus complexe comme élément de base (pour obtenir un sol plus élaboré par exemple).

Ta génération est-elle infinie ou as-tu un espace limité ? Si l'espace est limité est-il possible de prévoir des éléments plus complexes dans la grille (x,y,z) ? Peuvent-ils être placés aléatoirement ?
Si la génération est infinie, est-il possible de placer des éléments plus complexes à des emplacements aléatoires ?

T'es-tu renseigné sur le calcul de voxels par les cartes graphiques ? Me semble que le CUDA est un début de solution mais je ne sais pas trop si ça a évolué au cas où tu serais au courant.

Oui c'est bon j'ai fini de t'embêter avec mes questions de débile roooh ! ^^

[N_I_C_S]

Plop !

@Vetea
Argh !
Bon, déjà merci d'avoir tenté ^^ .
Et grâce à ton message je me suis penché sur le .jnlp (avec un petit soft épatant : janela) et il y avait des erreurs . C'est capricieux finalement ces petites bêtes ^^ , mais ce doit être corrigé .
S'il te plait, est-ce que tu pourrais éventuellement retenter ?
( http://tesseract-fps.sourceforge.net...troma_exp.jnlp )
Pour m'aider à débugger ce stupide fichier ^^ ...

@Dabou Master
Merci ^^ .

Ton décor là me fait terriblement penser à Cube World.

Tu m'étonne, quand j'ai rajouté les petites ombres dans les coins des cubes, mazette ! Et l'absence de texture y fait beaucoup...

Non non, tes questions sont pas du tout débiles, tu parles même d'une partie de mes problèmes actuels .

A partir de tes compétences actuelles en terme de génération, peux-tu faire évoluer cette technique vers un rendu plus réaliste ? Par exemple la génération de terrains en voxel (cf. StarForge) ou des formes plus abouties ? Je ne saurais m'expliquer mais en quelque sorte changer de "brosse" (désolé j'essaie de l'expliquer avec quelque chose qui me parle un peu plus), au lieu de mettre un cube, se retrouver avec une figure plus complexe comme élément de base (pour obtenir un sol plus élaboré par exemple).

Hmm, en fait non, toute la théorie des voxels est basée sur le fait que ce soit des petits cubes (y a un autre système avec des tétrahèdres mais c'est tout). Cela dit c'est justement le but du système de pouvoir polygoniser les formes les plus complexes, découpées par cette grille de cubes sous-jacente. Et les "cubes worlds" ne sont qu'un cas particulier de ce système, où un cube ne peut avoir que 2 états (vide ou plein).
Haha, Starforge ! Ils utilisent le système VoxelFarm de Miguel Cepero ! Oui, tendre vers cette qualité c'est possible mais il faut encore un boulot énorme. En fait pas tant sur les techniques de rendu pas si compliquées avec OpenGL + shaders, mais plutôt sur les structures de données et la représentation informatique du monde.
Par exemple, il a visiblement un système de LOD époustouflant, permettant une distance d'affichage titanesque et en même temps pouvoir sculpter la matière très finement de près.
De même ses algos de génération sont d'une vitesse folle vu la complexité des terrains générés.
Bon j'arrête là , je radote mais c'est ma plus grosse baffe technique venant d'un dev indépendant !

Ta génération est-elle infinie ou as-tu un espace limité ? Si l'espace est limité est-il possible de prévoir des éléments plus complexes dans la grille (x,y,z) ? Peuvent-ils être placés aléatoirement ?

Je me suis cantonné à un espace limité , sinon ça éloignerait le jeu de ses principes de base...
Placer des éléments (végétation, etc...), oui, je vais bosser dessus ^^ . On peut déjà placer des modèles classiques sur un terrain en voxels, mais j'aimerais faire un système qui prenne un modéle quelconque et le répartisse aléatoirement selon certains critères .

T'es-tu renseigné sur le calcul de voxels par les cartes graphiques ? Me semble que le CUDA est un début de solution mais je ne sais pas trop si ça a évolué au cas où tu serais au courant.

Oui, j'aimerais bien m'y mettre aussi (d'ailleurs VoxelFarm est largement basé sur le GPGPU ) . Il me semble que CUDA est propre au matos NVidia mais il y a son "concurrent" OpenCL qui semble beaucoup plus portable .