Software OpenGL : Modeleur de terrain - Page 1

Je rends public le développement de mon premier programme OpenGL digne de ce nom (codé en C++).

Je recopie les infos que j'ai mis sur mon site :

Description générale :

Il s'agit d'un modeleur de terrain en 3D, rendu avec OpenGL. Le programme tourne pour l'instant uniquement sous Windows.
Le programme commence à devenir opérationnel mais de petits détails restent à terminer.
Il s'agir pour moi, entre autres d'apprendre a maitriser différents aspects d'OpenGL et de la programmation Win32, donc l'intérêt final du programme n'est pas primordial.

Caractéristiques :

L'utilisateur agit sur l'altitude des points d'une grille pour former des reliefs. Soulever ou abbaisser un point entraîne les autres (quand la pente entre les deux points devient supérieure a une pente paramètre) et forme un montagne ou un cratère sous-marin.
Pour pouvoir modeler le terrain plus rapidement, il est possible d'étendre la selection de sommets grace à un curseur rectangulaire, et ainsi de créer rapidement un plateau (en surélevant les sommets) ou un fond sous-marin (en abaissant les sommets).

Des couleurs sont générées automatiquement de manière à produire un rendu agréable. En dessous du niveau initial, les somets sont bleus avec deux nuances pour imiter les fonds marins, et au dessus existe une échelle de couleurs allant du vert foncé au blanc (neige).
Un polygone transparent recouvrant toute la map fait affice de surface de l'eau et rend les fonds marin plus crédibles.
La table des couleurs actuelle est du plus profond au plus élevé :

* bleu foncé (fond marin profond)
* bleu clair (fond marin peu profond)
* jaune (sable)
* vert foncé (forêt)
* vert clair (paturages)
* gris (rocaille)
* blanc (neige)

L'éditeur est en même temps un viewer : l'édition se fait directement dans le monde en 3 dimensions, et l'utilisateur peut se placer où il le désire.
Il déplace la caméra avec le clavier et change l'angle de vision avec la souris, comme dans les first person shooter.

Le rendu comprend l'éclairage : pour cela les normales aux faces et aux points sont calculées à chaque modification. Elles peuvent être affichées en option, pour la curiosité.

Le programme intègre un menu visuel proposant les options suivantes :

* Nouveau (Crée une map vide)
* Sauvegarder (Sauvegarde la map dans un fichier externe spécifié par l'utilisateur)
* Charger (Charge un fichier depuis n'importe quel emplacement de l'ordinateur)
* Quitter
* Activer/Désactiver l'affichage de la grille
* Passer en mode caméra libre (vue dirigée en permanence par la souris)

D'autres options sont accessibles par des raccourcis clavier (Activage/Désactivage de l'éclairage, Affichage des normales..).

Screenshots : (les images sont dispo en 1024*768 depuis mon site)



Evolution du projet :

Ce que je prévois de faire ensuite :

* Divers petits trucs pour rendre l'interface agréable
* Un skydome pour avoir un rendu de ciel
* La génération de map a partir d'un bitmap (height mapping)
* Et bien sûr une release

Heu... C'est tout, juste les infos même pas un d/l ?
Parceque bon les heightmap en OpenGL c'est pas ça qui manque, si ça interesse qqun il passe 5 minutes sur Google et il peut en trouver des dizaines de très complets, totalement terminés, et open-source

Et bien, en fait c'est un projet en cours de développement, j'aurais peut-être du remplacer software par Projet dans le titre.
Par contre le fait qu'il en existe plein, terminés et mieux sur le web c'est normal, après tout c'est mon premier programme OpenGL et il est sans prétention.

J'ai pensé à un d/l mais le problème c'est qu'il y a quelques trucs pas pratiques qui risquent de merder sur d'autres plateformes (résolution non modifiable, problème avec les zones de clic, taille de la map à modifier pour les petites configurations, utilisation de DirectInput...).
Bon je vais faire un ptit pack alpha rapidement

Non en fait c'est juste que je vois pas l'interet de poster les caractéristiques d'un truc comme ça sans le proposer un d/l, comme comparaison ça serait comme si quelqun postait un shot et qq infos sur son prochain nibble Ti alors qu'il en existe déjà des dizaines

ba, c normal qu'il soit content de lui

Vi mais de là à créer un topic juste pour le dire, c'est juste décevant quand on arrive ici c'est tout.

arf

tiens, pour info, vé devoir faire un truc comme ca pour la terre les les planetes proches de la terre dans le syst. solaire, ca va etre bien chiant a faire

nEUrOO :
tiens, pour info, vé devoir faire un truc comme ca pour la terre les les planetes proches de la terre dans le syst. solaire, ca va etre bien chiant a faire

???
Faire un modeleur pour chaque planète du système solaire ??

oué
enfin, je vais deja essayer de faire la terre bien correctement... c'est pas gagné

suffit de l'activer quand on est a une distance inferieur a x etc... c tout a fait faisable par contre pour trouver les données du relief des plannetes ...

Jackos: soit ca, soit avoir un degré de relief en fonction de la distance... (plus on s'approche, plus c'est précis sur la face visible)
De tte facon, cette derniere méthode permet d'éviter pas mal de calcul...

ca s'appelle du LOD (ou level of detail)
t'as des tas d'algos pour ca... du clod, roam, le geomipmapping, et du geomorphing pour blender les differents niveaux de LOD sans avoir de popping...

Je pourrais faire une release mais j'ai quelques problemes avec des boites de dialogue windows pour faire un ptit setup.

J'utilise VC++ et l'éditeur de ressources pour faire un dialog.
Ensuite j'ai créé une classe dérivée de CDialog avec le class Wizard.
Je veux appeller le dialog en modal :
D'après la doc, j'ai donc normalement uniquement a déclarer un objet (le constructeur est appellé) et après à appeller DoModal pour cet objet.

Ca compile bien mais après a l'éxecution a l'appel de DoModal :
- En mode DEBUG, ca provoque une assertion qui viendrait d'apres mon débugage d'un endroit ouil cherche le handle de la fenêtre
- En mode RELEASE, le dialog s'affiche mais tout de suite apres j'ai une erreur (le programme a rencontré une erreur et doit fermer).

J'arrive pas a savoir si le pobleme vient du code ou de la ressource. Des suggestions ?

A part ca j'ai rajouté effectivement le height mapping, mais je pensais utiliser un dialog windows pour régler des parametres (lissage, taille...)

Ah oui aussi, est ce que quelqu'un sait comment récupérer la taille des bordures d'une fentre windows ou meme directement les coordonnées écran du pixel en haut a gauche de la fentre (de rendu) ?? Ca m'aiderait pour définir de manière paramétrée mes zones de click (car je récupère la position de la souris en coordonnées écran et il me la faudrait en coordonnées fenetre de rendu (c'est a dire sans les bordures et la barre en haut).

ScreenToClient devrait faire l'affaire je pense

Ok, le ScreenToClient marche bien. Merci bcp.
Pour le reste je suis toujours planté. C'est lourd.

Si tu veux des liens qui servent pour l'élaboration d'un moteur de terrain, voici ma sélection perso (ça m'a aidé pour travailler sur le mien pour ma boite) :

http://ohad.visual-i.com/exper/exper.htm
http://www.devimg.net/?View=297

* Voxel

http://www.base-sixteen.com/terraVox/
http://sourceforge.net/projects/atomvox/
http://www.theteahouse.com.au/gba/terrain.html

* Roam

http://ddg.sourceforge.net/
http://home.planet.nl/~monstrous/terrain.html
http://sourceforge.net/projects/demeter/

* Raytracing temp-réel (avec height-field)

http://www.xl3d.com/xl3d/raytracing.htm
http://www.winosi.onlinehome.de/

Si ça peux t'aider

Kochise

http://www.winosi.onlinehome.de/

biensur, c'est un rt temps reel
temps reel, a quelques heures par frame pour certaines images
surtout que ca a trop a voir avec les terrains
#marmotte#


y a http://www.vterrain.org qui est pas mal dans le genre (sans doute une des meilleures ressources pour les terrains sur le net, d'ailleurs le format de heightfields .bt a ete cree dans le cadre de vterrain...

Faut pas être trop con non plus, et chercher un peu dans le site : http://www.winosi.onlinehome.de/RaVi/index.html

Le rapport avec le terrain ? Y'en à pas trop, si ce n'est que le moteur de WinOSI-RaVi peut être utiliser pour afficher les terrains en height-field façon POV !

Kochise

ah oui j'avais pas vu, dans downloads. enfin tjrs est il que je vois pas le rapport avec un terrain, et "si ce n'est que le moteur de WinOSI-RaVi peut être utiliser pour afficher les terrains en height-field façon POV !", visiblement il est plus interesse par le temps reel, et je doute qu'un terrain en heightfield "facon POV" de taille raisonnable fasse du 60 fps ou meme du 10 fps sur une resolution au dessus de 320*240 (et meme en 320*240 d'ailleurs)
pour l'instant les rasterizers sont bcp plus rapides que les rt a qualite graphique egale pour des environnement complexes (et pour des terrains un minimum pas immondes). quand les premiers hardware rt sortirontla tendance s'inversera peut etre ceci dit (j'espere )

Ah oui au fait, j'ai oublié de poster ici :
j'ai fait une release (enfin) de mon programme (j'avais des problèmes avec les boites de dialogue de windobe)
sur mon site : http://moitib.free.fr

merci pour les liens, je vais aller jeter un coup d'oeil.

Ça s'appelle "Windows".

S'il veut l'appeler "Windobe", c'est son droit (même si je suis plus pour "Window$", perso ).

Si je veux lui expliquer que le logiciel s'appelle "Windows" et pas autrement, c'est le mien.

Bah c'est insoluble votre problème, parce que si Kévin veut te reprendre il a aussi le droit

Bah c'est bien pour ça que j'expliquais juste à moitib quelle était l'orthographe correcte, y'avait pas besoin du commentaire à la con de Kevin

716c<
t1<7 734|V|
_|\|057u8_ r0xXx0rZ

sBibi (sauf ./28 hein )> T'es chiant à tout savoir, toi