cette apres midi et ce soir je me suis amusé a regarder les effets d'environnement mapping et les possibilités d'implémentation dans mon moteur des différentes techinques avec les shaders GLSL
J'ai commencé à m'amuser avec du simple Spherical Environment Mapping sur le galactique colossus du jeu supreme commander(dans le jeu son armure est plutôt polie et lisse alors que dans ma démo elle est très terne)
Le résultat étant plutôt sympa après seulement quelques minutes (presque juste copier coller l'exemple de Ozone3D) je me suis amusé à intégrer quelque effets supplémentaire pour avoir un résultat plus proche du jeu.
voici une démo de test avant l'intégration dans mon projet principal:
====================
http://dl.free.fr/bmuJB7Oxy
====================
les commandes sont les mêmes que d'habitude. j'ai rajouté la monté et la décente du point de vue de la camera avec les touche + et -
dans le zip de la démo j'ai mis le code sources de celle-ci.
voir l'image:
Franchement c'est du beau boulot. Mon petit paysage opengl a l'air bien fade tout a coup apres avoir vu ton projet
(Les "ça ne marche pas", même écrits sans faute(s), vous porteront discrédit ad vitam æternam et malheur pendant 7 ans)
N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java
Deux images pour illustrer les travaux en cours.
Mise en place d'un système de LOD pour le terrain: plus la camera est éloigné du terrain et moins il y de triangles dessinés.
Ainsi que d'un peu de physique avec la lib Newton Game Dynamic. AU départ j'étais parti sur PhysX mais celle ci est limité au niveau de la gestion des terrains
Pour Newton j'ai repris l'exemple du HeightField du SDK de la version 1.53
N'oublie pas de télécharger la version 2 du SDK, Newton a bien changé, autant en terme de fonctionnalités qu'en terme de performances .
Je sais je l'ai récupéré en version 2.1 il y a quelques mois.
Le problème c'est que beaucoup de choses ont changés depuis la version 1.53 avec laquelle j'avais fait plein de truc comme la gestion des véhicules qui est entièrement à reprendre. J'ai même remarqué que quelques fonctionnalités n'étaient pas finies. Surtout pour les véhicules
Pour l'instant j'ai fais la méthode de facilité consistant à reprendre mon ancien code 1.53 et à ajouter une classe HeightField reprenant celle du SDK 1.53
C'est sur que pour la suite passé à la dernière version serait mieux. Mon but pour l'instant est de voir quel moteur physique peu gérer un terrain 4096x4096.
PhysX ne peut pas (en tout cas sa classe pour le faire plante chez moi à cette taille)
Newton 1.53 en faisant à la main peu.
Regarde Havok c'est gratos depuis un petit moment et je pense que c'est assez performant
~40 de FPS pour moi avec une GTX 280 :p
Par contre pour les perfs tu devrais eviter d'ecrire dans la console une fois le rendu lance. La console windows est particulierement lente !
Sinon le rendu est clairement sympa
Je viens apporter quelques nouvelles:
J'ai fait un module pour intégrer SPARK comme source de particules et j'ai mis le GC relooké dans la démo:
Whats up ?
Souhaites tu continuer le développement de ton moteur vers un Earth Mapping ?
Je suis en train de faire un système d'éclairage dynamique par rendu différé avec picking color.
Il manque encore le spéculaire. Il y a déjà le bump mapping et les textures
voici les première images:
le rendu final avec une lumière omnidirectionnelle + 4 lumières ponctuelles
les buffers de données avec en haut à gauche les normales dans l'espace absolue, en bas à gauche la couleur, en bas à droite la positions des pixels dans l'espace absolue et le dernier qui contient quelques trucs sans grand importance
Pas mal du tout, j'aime bien l'image avec la vue sur les robots dans ton monde.
C'est du bon boulot, bon courage :-)
Jc
Salut,
Très beau travail, bien qu'il faut le hardware nécessaire pour faire tourner tout ça.
J'ai un peu regardé vite fait comment tu avais agencé tout ça. La curiosité est un vilain défaut il parait, et toute idée est bonne à prendre.
Néanmoins, juste quelques précisions, histoire de voir si j'ai tout bien compris.
Pour ton terrain tu te sers d'une méthode de Vertex Displacement Mapping. Si j'ai bien compris la façon dont tu l'utilises en quelque ligne :
- tu envoies un maillage plan / plat (tous tes vertex sont aux même niveau) de taille de ta heightmap.
- à l'aide d'un texture (ta heigthmap) tu va changer la hauteur vertical de tes vertex constituant ton maillage dans ton vertex shader histoire d'avoir une accélération GPU.
Donc jusque là aucun souci c'est le principe du Vertex Displacement Mapping.
Néanmoins je ne vois pas l'intérêt de calculer la hauteur de ton maillage à chaque frame pour un maillage qui est sensé être statique je trouve cela un peu couteux de recalculer à chaque frame la hauteur du terrain qui n'a pas bougée.
Je vois dans le Vertex Displacement Mapping un réel intérêt dans le cas de maillage déformable au cours du temps (un tremblement de terrain par exemple .)
Cependant autant je comprends son utilité pour des phénomènes dynamiques d'ailleurs comme tu sembles l'employer dans ton application pour la formation de cratère ou autre, autant pour la génération complète de ton terrain je trouve que ca fait énormément de calculs identiques refaits à chaque frame pour un même résultat même si cela est fait au niveau GPU c'est du temps de calcul perdu pour d'autre effet ou tous simplement améliorer le fps pour une config moins performante.
Après j'ai peut être mal compris et certaines choses ont dû m'échapper.
Quoi qu'il en soit très beau boulot.
Rien ne sert de courir, mieux vaut partir à point. Programmer aussi d'ailleurs.
Surtout, mais surtout pas d’astuces !
Pas de bras, pas de chocolat. Les deux mains sur le clavier.
La curiosité n'est pas un vilain défaut
Tu as bien compris la première partie de l'algorithme basé sur le Vertex Displacement Mapping.
Mais tu n'as pas compris la deuxième partie, là ou réside toute l'asstuce.
Mon terrain fait 4096*4096, avec un maillage statique j'aurai 4096*4096*2 = 33 554 432 triangles autant dire que je mets la carte graphique à genou.
L'astuce consiste a découper mon terrain en 2 patch réutilisable : une zone centrale et un anneau, donc 2 maillages de créés. qui font 64*64 et 128*128 avedc un trou de 64 sois 8192 et 24576 triangles (c'est mieux que 33.5 millions, l'économise beaucoup de mémoire)
ensuite pour afficher je fais:
-affichage de la zone centrale à l'échelle 1 ou ce trouve la caméra
-affichage de l'anneau ou ce trouve la caméra
=> une zone avec 100% de précision de 128 * 128 est dessiné
-affichage de l'anneau avec échelle 2 (50% de précision)
-affichage de l'anneau avec échelle 4 (25% de précision)
... ainsi de suite jusqu'à ce que la totalité du terrain sois dessiné. les hauteurs des vertex de mes appel au maillage anneau sont calculés dynamiquement. Grace au Vertex Displacement Mapping je peu recycler je recycle çà l'infinie (ou presque) mes 2 patch
au finale j'ai 200000 triangles de dessiné au lieu de 33,5 millions
soit une division du nombre de triangles par plus de 167.
Et bien merci pour cette précision c'est d'autant plus clair.
Rien ne sert de courir, mieux vaut partir à point. Programmer aussi d'ailleurs.
Surtout, mais surtout pas d’astuces !
Pas de bras, pas de chocolat. Les deux mains sur le clavier.
une image de l'éditeur en cours de développement.
Il est fait avec Qt et j'y ai intégrer mon moteur.
Salut ^^ pas trop dur d'intégrer son moteur dans un framework comme Qt ?
Woa cool je savais pas qu'on pouvait intégrer la SFML dans Qt comme ça :o moi aussi j'utilise la SFML (<3) et il faut avouer que cette librairie déchire ^^
En effet très pratique si on peut l'intégrer dans un environnement Qt sans effort :p
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager