Salut je travaille présentement sur un rpg 3D (c++) et (quand le projet n´était encore qu´une idée) je pensais prendre un moteur 3d préconcu, mais plus j´avance dans le concept (plus communément game desing) plus je réalise qu´il serait plus simple de programmé mon propre moteur 3D, car mon projet a un concept particulier de pour les graphismes. Je m´explique. Pour les personnages et pour certains objets (pierre, plante, buisson, arbres, etc...) les annimations se feront par sprites 2D contenant en tout 10 points de vue contennant chacun un nombre d´animations variables (ex : un personnage d´une race jouable compertera plus d´animations qu´un requin). Pour ce qui est de la modélisation, cela ce ferait avec des tiles de 4 pouces par 4 pouces (traduit en pixel cela équivaut à 406x433 pixels) (non officiel) pouvants etres placées en diagonales ainsi qu´etre affichés a moitié et avoirs en effet de transparence (ex: dire au logiciel que quand il voit une teinete particuliere de rose, de ne pas l´affichée et de simplement la rendre transparente).

Donc voila ma question. Pour mon projet me conseillez vous de prendre un moteur 3D déja fait ou d´en fabriquer un de toutes pieces ?

Si vous n´avez pas compris quelque chose, n´hésitez pas a me le dire.

Merci d´avance.

J´ai oublié de préciser, puisque la modélisation se ferait avec des tiles, tout serait modeliser avec le logiciel de Level Desing.

Aussi, si vous voulez d´autre exemple, n´hésitez pas a me le demandez (en passant, désolé pour le triple post).

Fait le toi meme, c´est plus rigolo
Tu te fais un heighmap, et tu te promenes dessus

A propos de heighmaps, une question que je me pose depuis longtemps maintenant. Je profite donc de ce topic pour la poser (désolé yophil7, je squate le temps de la question )

Est-il préférable de générer une carte par heighmap ou en chargeant un mesh 3D afin d´utiliser le moins de ressources possible?
Est-ce que ce genre de choix se pose en fonction de la taille de la carte, ou bien la réponse est tellement triviale que la question ne se pose pas?

Moi je serais partisant de répondre qu´il est préférable de le générer a partir d´un BMP, et non d´importer un Mesh de Heigmap.
Je m´explique :

Si tu le generes toi meme, tu assures une régularité parfaite entre les points : ce qui n´est pas le cas avec un Mesh importé : tu peux tres bien avoir une anarchie de triangles.
Les avantages quand le mesh est bien généré :
- Calcul immédiat du quad de triangle ou tu es (2 divisions suffisent)
- De la, calcul immédiat du sol (calcul de barycentre)
Autrement, en rien de temps, pour un x/y donné, tu connais ta position Z. Alors qu´avec un mesh importé : ouch !
- optimisations tres tres rapides : comme le mesh est tres régulier, pas besoin de faire de BSP ou d´octree pour classer les triangles : ils sont déja classés, donc un frustrum culling se fait plus simplement.

Merci pour ces précisions

Je me posais la question parce que, autant dans des types de jeux genre, sport, course ou action, une map enièrement "meshé" me semble logique ... autant dans un environnement plus grand du genre, MMORPG, RPG ouvert (Neverwinter Nights, Oblivion), gunfights et simulations d´avions, le choix entre un grand mesh ou une heightmap me semblait plus discutable (vu que la topologie des cartes est alors beaucoup plus basique).

Les programmeurs utilisent plein d´astuces pour éviter le Mesh quelconque.

Quelques exemples :
TombRaider : QUE des cubes. Une sorte de bitmap 3D. En 3 divisions, on sait sur quel cube est lara Croft.
Certains cubes sont coupés pour faire des pentes, mais c´est en 2 passes : y´a d´abord un cube tres cubique, et associé, un type "pente"
Quand Lara détecte ce type de cube, elle glisse... Mais pour la machine, ça reste un cube tres normal qui a la particularité de glisser, et d´etre rendu différemment

Pour TrackMania, ou beaucoup d´autres jeux de voiture, c´est des segments de routes placés, pareil, dans un monde dait de gros cubes régulierement placés.
Pour savoir ou est la route, c´est simple : on calcule d´abord dans quel cube elle est. Ensuite, on regarde quel type de route est contenu dans ce cube, ou alors aucun segment de route
Ensuite, selon le segment, on travail en local...

Mais dans ces cas la, en AUCUN cas c´est un gros mesh anarchique. Car on ne peut pas faire grand chose d´un mesh anarchique...
(sauf dans les FPS récents, ou on crée un BSP tree a l´initialisation)
Et je ne te parle pas de doom qui n´est pas autre chose qu´une "illusion", un jeu 2D dans lequel on a dessiné que des trapezes droits... Toute une histoire...

Donc si je comprend bien, plus une map est "découpée", hiérarchisée, mieux c´est.

Maintenant une autre question dans la continuité. J´ai mon plan 3D avec des relief, généré par heighmap, et je veut lui mettre une texture. D´après ce que j´ai pu voir, on a généralement la heighmap en niveaux de gris et une autre map en couleur pour la texture qui est donc projetée verticalement selon l´axe Z. Ca explique pourquoi sur des pentes abruptes, on voit souvent une texture étirée.

Ma question est donc, hormis trafiquer la texture de base (tasser sur la map2D afin que lors de l´étirement ça ne se voit plus), est-il possible sur un mesh généré par heighmap de projeter la texture selon la normale de chaque face?
On vois très souvent ce genre d´étirement dans les jeux, donc ça doit être assez compliqué ou impossible j´imagine, de faire une texture régulière malgré les variations de hauteur de terrain.

Je suis assez curieux de ce genre de chose, qui doit être propre à la programmation je suppose, étant donné qu´en infographie3D le problème ne se pose pas trop finallement.

Je t´avoue que je n´ai jamais pensé a palier ce probleme.
Mais ça me parait trreeeeeeees compliqué.
En effet, si pour un meme X, tu as une partie droite, puis, plus loin (mais toujours sur le meme Y, tu as une forte pente, et que tu veux donc ne pas trop étirer, ça veut dire que dans le bitmap de texture, il faut jouer la dessus : et surtout qu´il est irrégulier !

Un peu comme si tu as un carré de baudruche, que tu mets a plat, et que tu décide d´appuyer avec ton doigts a un endroit précis (pour faire une montagne).
La distance verticale sera différente a une abscisse donnée et une autre...

Fort fort complexe...

Je dirais que c´est pour ça que sur les planisphere, le Groenland est toujours représenté plus grand qu´il l´est en réalité...

Dur dur probleme... A mon avis, il faut traiter le bitmap avant (en faisant des distortions diverses dans le bitmap),
un peu comme cette image
http://www.tokai.be/images/Products/160asfin/16042asfin%20distortion.jpg

Autre solution a essayer :

tu as donc ton heightmap nu, et ta texture.
Tu calcules les points u,v sur la texture qui vont coincider aux vertex du heihtmap.
Au départ, ces points sont régulierement placés.

L´idée est donc, pour chaque point du vertex, calculer sa distance verticale et horizontale par rapport au bord, en tenant compte du relief : un perimetre de polyline si tu veux.
En fonction de la distance divisée par la longueur totale de la polyline sur laquelle tu travailles, tu décales horizontalement, puis verticalement, ton point u,v
Ainsi, tu remap tous tes points u,v, de façon a ce que le résultat soit régulier une fois posé.

A tenter...

Merci pour vos conseils, mais j´ai une question, sa signifi quoi "mesh" (je m´y connais plus en game desing qu´en graphisme).

Merci d´avance.

un mesh c´est un ensemble de polygones : un "dessin 3D" sans textures

Pour ce probleme de texturing de heightmaps tu peux utiliser des petits bmp puis utiliser la technique de texture splatting.

mais bon comme m´a dit un jour un bon informaticien, t´agace pas a faire des superbes effets sur tes terrains car tu vas y coller des batiments, de l´herbe, etc... personne ne fera attention aux défauts de texture ! :p

Ca m´arrive de jouer a GW et si on regarde de pret, tres pret le terrain, on découvre qu´en fait il est composé d´un grand nombre de petits bmps collés les uns aux autres. ca permet en plus de ne pas charger sauvagement la mémoire de texture des cartes graphiques !

++
Nico.

"Ca m´arrive de jouer a GW et si on regarde de pret, tres pret le terrain, on découvre qu´en fait il est composé d´un grand nombre de petits bmps collés les uns aux autres. ca permet en plus de ne pas charger sauvagement la mémoire de texture des cartes graphiques !"

C´est éxactement pour ca que j´utilise la technique explqiqué plus haut, pour faire en sorte que mon projet fonctionne sur la pluspart des machines. D´ailleurs, pour revenir au sujet du moteur, je vais essayer de le programmer (bon, c´est sur que je serai pas le seul programmeur dans mon projet, car je m´y connais pas trop en programmation, et aussi que je suis le seul game designer de mon équipe en plus d´etre chef d´équipe et scénariste principal) de facon a faire en sorte que le jeu soit considerer par la carte graphique comme un jeu 2D.

parles tu de billboarding ?

c´est une technique qui consiste a afficher une image 2D dans un espace 3d en l´ajustant suivant la caméra...

Ou bien l´autre technique qui melange la 3d et la 2d, le shader script. Genre plutot que de gerer une explosion d´un objet 3d via un effet de particules tres couteux en mémoire, on le gere via une animation d´images 2d pour créer l´illusion...

re, dsl

par contre je vois un truc louche.... exemple tu as un perso a un instant t du jeu avec des fringues, armes, etc. Donc ce perso est généré via une image 2d animée... tu auras autant d´animations et images 2d que de possibilités de combinaisons d´armes et vêtements ?? ?
je pense délirer la et ne pas comprendre ton systeme (enfin j´espère !

Enfait, pour ce qui est de l´annimation au lieu de tout combiner les possibilités, on prendra (ex: un vetement) et on fera tous les annimation qu´il peut y avoir avec, ensuite durant le jeu tout es combiné, mais pour le fait que le jeu soit considéré comme 2D par la carte graphique, ce que je voulais dire c´est que puisque le jeu n´utilise des ressources 2D, le moteur se cargera de créer une "illusion", mais du coté technique ca peut toujours changer (pour l´instant, je travaille sur le concept) et pour ce qui est de la camera, ce sera a la premiere personne.

Merci Fvirtman pour toutes ces précisions

"il est préférable de le générer a partir d´un BMP, et non d´importer un Mesh de Heigmap"

tearing sur les zones de fortes pentes, avec une grille reguliere

pour une heightmap basique, ca fait l´affaire, et on n´est pas trop regardant sur la qualite..

pour des choses un peu plus fines:
- re-parametrisation des splines de coupe du terrain (arc-length param, niveau + gradient, etc.)
- import de mesh (si si)
- voxel & marching cubes (> extraction d´iso surfaces)
- "volume material"
- etc.

faire un terrain de bonne qualite est qqch de COMPLIQUE ; mais on peut s´en tirer a peu de frais si on se satisfait de solutions simples