Moteur de terrain 3D

Super que tu sois d'accord, mais en fait pour l'instant les scripts n'exportent rien du tout, ils créent juste un modèle in-game à partir d'une heightmap (je sais pas si je vais faire en sorte de pouvoir exporter ou pas).

Par contre j'aurais besoin d'aide pour lisser les normales, parce que je planche dessus depuis le début et j'arrive à rien de concluant ^^

EDIT : en fait ton exportation se fait comment, par une heightmap (vu que tu parles de .bmp) ? Le plus simple ça serait peut être qu'on voie ça sur msn non ? Je t'ajouterais tout à l'heure vu que j'ai vu que ton msn est sur ton profil

je sais que tes script n'exportent rien :gniah:

ce que je voulais dire c'est : tes scripts, ils importent que du BMP ou aussi un type de fichier à toi ?

sinon, pour la heightmap, bha tu clique sur enregistrer et là, tu peut choisir " heightmap(*.BMP) "

sinon, t'as essayé d3d_set_shading(true); ?

pour MSN, je préfère éviter, je suis littéralement envahi de gens et quand je le lance, j'ai rarement moins de 5 personne dans les 30 premières secondes...

par contre, par mail ou MP, ça sera Impec !

Okok pas de problème.

En fait mon script génère un terrain à partir de n'importe quelle image en niveaux de gris, donc du BMP sera parfait

Pour d3d_set_shading(), il est sur true par défaut, c'est juste que j'arrive pas à calculer les normales de manières à ce que le terrain soit plus lisse, comme dans anim8or en réglant le smooth angle en gros

Si vous fusionnez vos systèmes, c'est vrais que ce serait le pied.

Les Matrices du Tigre centuplées par la puissance de Nicoulas.

EDIT

Topaze22 a écrit:

la puissance de Nicoulas.

lol


Ajout de la possibilité de répéter une texture sur le terrain.

Bon, voilà quelques news :

- Le calcul de hauteur (Height Finding) est maintenant parfaitement opérationnel (j'ai eu un peu de mal mais bon, ma mère m'a aidé [racontavie](elle est prof de maths )[/racontavie]).

- On peut aussi calculer l'angle entre deux points du terrain (en donnant seulement les valeurs x1,y1,x2,y2 (le script se charge de trouver les valeurs de Z grâce au script de Height Finding).

Je poste donc la source (qui va encore changer, mais bon histoire que vous ayez accès au code quoi ) en .gm6 et .gmk avec un .exe pour ceux qui n'ont pas la version enregistrée.
L'exe montre le même terrain que le dernière fois mais avec 4 balles rouges qui bougent sur le terrain et avec un exemple de LoD du terrain inclus (Level of Detail). Vous pourrez aussi changer la texture par une qui se répète en changeant deux lignes de code :p
Un dernier détail, y'a quelques soucis avec la version .gm6 au niveau des commentaires (vu que LGM supporte pas les accents, ils sont remplacés par des '?').

Voici le lien : http://www.mediafire.com/?ojyk0dmjmin

Vu que ton moteur utilise de nombreux scripts est ce possible d'en retirer un gex ? Histoire de tout combiner et augmenter le palette 3D de GM ^^" moi je dirais que si c'était le cas cela me pousserait à me pencher sur la 3D car j'ai pas commencer et je suis une quiche faut dire aussi. Mais ton système étant excellent et je trouve intuitif ça passerais mieux

Enfin voila quoi ^^

Eventuellement quand il sera fini (et si j'ai le courage ^^), je le passerais en .gex, c'est vrai que c'est toujours plus pratique d'avoir la fonction et ses arguments qui s'affichent directement dans le code editor

Et merci du compliment

Je profite de ce post pour dire que j'ai fait un essai de terrain dynamique (avec des primitives mais sans utiliser de modèles), et le résultat n'est pas fameux niveau performances : avec 512 triangles (donc 1536 vertex) le système sans le calcul des normales prend 65% de mon CPU, donc j'ai décidé d'enlever cette possibilité de terrains dynamiques (dynamiques dans le sens ou chaque point était facilement modifiable).

Et je ferais peut-être quelques tutos sur comment commencer en 3D, quelles sont les choses essentielles à savoir, les astuces (rendu, performances), si ça en intéresse certains ^^

On peut donner l'impression de mouvement en affichant différent matrice/model avec un compteur, non ?

Comme ça, ça pompe rien à part de la RAM ou de la VRAM (je ne sais pas).

Tu parles de faire plusieurs 'bouts' de terrains et les assembler ?
Si oui ça pompera rien de plus au CPU pendant l'affichage, sauf que le chargement au début sera un poil plus long, et sinon les modèles sont stockés dans la RAM mais la quantité qu'ils utilisent est vraiment négligeable : même en chargeant un modèle à chaque step, on arrive très difficilement à une saturation de mémoire (j'ai seulement 512 mo donc ça me connait la saturation de RAM )

edit : seulement 4 downloads =(

C'est bien ce que je pensais.
Donc on pourrait se servir de plusieurs models pour faire une animation qui ne consommerait pas plus de performance que si il n'y avait pas d'animation.

Oui ça serait faisable, mais des terrains dynamiques auraient été plus pratique. Je vais voir si je ne peux pas enregistrer l'HeightMap dans une grille, créer le modèle du terrain, puis si on modifie une valeur de la grille, recréer le modèle du terrain. Ça contournerait les limitations et les problèmes dus au primitives.

Comme ça au moins si on ne modifie rien, les performances seront bonnes (après reste à voir les perfs si on modifie sans arrêt des points =S)

Vraiment beau boulot, c'est intuitif, compréhensible, je pense surtout que ça peut servir d'exemple pour aider ceux qui ont du mal en 3D (les autres aussi bien sûr, mais les premiers sont plus dans le besoin)

Le tout ne pompe pas beaucoup niveau processeur..
Perso je préfère le terrain sans les ombres car il paraît plus lisse =p

C'est franchement impressionnant, encore beau travail

Merci beaucoup, et je suis content que ça paraisse intuitif, car c'était mon objectif principal avec celui de bonnes performances et de bon rendu

En fait pour ce qui est du terrain ombré pas très lisse, je travaille dessus depuis le début, j'espère que bientôt j'arriverais à rendre les normales (ce qui sert pour l'éclairage) de façon à ce que l'ombrage soit plus joli.

Topaze22 a écrit:

Si vous fusionnez vos systèmes, c'est vrais que ce serait le pied.

Les Matrices du Tigre centuplées par la puissance de Nicoulas.

centuplées ?! (ça fait une semaine que j'ai lu ça, et je n'ai eu le temps de répondre que maintenant)

Ce dimanche (cad en 6heures) j'ai fait ça :

Spoiler:

donc, participer avec lui, je veut bien, mais dites pas que son systeme centuple le mien.

pour info, DLL en C pour le pré-calcul des ombres et l'accélération de la lecture (un map de 96*96 en un peu moins d'une seconde)
et GM pour l'affichage avec son moteur par défaut.

Ho my god, d'habitude, tu étais plutôt limité par le nombre de poly sur tes matrices, je ne pensais vraiment pas que tu avais l'intention d'améliorer ce point !?




Au lieu de faire deux systèmes séparés, ce serait mieux si vous faisiez du travaille d'équipe, m'enfin, si ça ne vous dit pas, tant pis.

Le système classique du Tigre (avec peu de poly), ça me convenait déjà bien, si il veut l'améliorer, je ne vais pas cracher dans la soupe


M'enfin, si il reste comme il est mais qu'il le finis, ça m'ira vraiment bien.

Moi j'ai rien contre faire un projet commun, au contraire ^^

Mais après niveau organisation ça risque peut être d'être chaud non ? Je crois que TDT n'a pas beaucoup de temps libre et de mon côté je suis pas toujours libre non plus donc pour trouver des plages horaires ça risque d'être assez ... dur

bha oui, le problème c'est que je peut travailler 6-8 heures de suite sur un projet le dimanche, et pas du tout pendant la semaine ...

bref, pour travailler à plusieurs , c'est pas top .

mais on peu travailler en collaboration :
les fichiers et programmes sont interchangeables .

au fait, avec le nouveau système, on peut faire des maps de 192*192, ça passe. je sais pas jusqu'où on peut aller (mais je sais que 256*256 plante)

donc, à voir...
mais je pense que travailler en collaboration sera plus judicieux pour nous deux.

Oui ça c'est sûr.

Ce soir je vais plancher un peu sur la possibilité de charger/enregistrer un terrain (ça ça va être très rapide) puis sur le lissage des normales (plus long à faire).

Moi mon système n'a comme limite que la puissance du CPU du pc vu que j'utilise des grilles, donc en 256*256 ça doit passer mais en faisant du 10-20 fps, bref c'est pas très intéressant.

Faudrait au moins qu'on voie pour la compatibilité entre nos systèmes, puis après aussi au niveau de l'optimisation et des trucs comme ça.

ma limite actuelle est de 252*252
elle est due au fait que, par flemme, je n'ai lu les données que sur un octet (soit <=255) et que , toujours par flemme, mon système ne peut ouvrir que les images dont la taille est multiple de 4.

donc, le multiple de 4 le plus proche et inférieur à 256 est 252.

bref, après les tests, une matrice non optimisé de 252*252 commence à ramer un peu ... je vais voir en virant les 'double sided polygones' :gniah:

pfou jme suis pris des maux de tête horribles avec povray à faire les heightmap avec des cartes de montagne ^^, alors j'ai vraiment pas envie d'essayer ton truc, mais vraiment superchapeau de faire ça

@ TDT : Je comprend pas trop d'ou vient ta limite mais bon, ça me parait un peu complexe pour moi

@ Chulien : Bah c'est pas très compliqué : plus un point est clair, plus le point sur le terrain sera haut et inversement, en fait tu dessine une image en noir et blanc, tu rajoute par dessus un flou gaussien puis le tour est joué

oui mais non arrête jvais m'énerver!
est-ce qu'on peut faire sortir du script d3d avec ça?

C'est à dire ?

Tu veux dire un modèle 3D à partir de l'heightmap ?

yep! si c'est oui, ça m'intéressera quand jme remettrai à la 3d

[quote=\"[TheDarkTiger]\"]ma limite actuelle est de 252*252
elle est due au fait que, par flemme, je n\'ai lu les données que sur un octet (soit <=255) et que , toujours par flemme, mon système ne peut ouvrir que les images dont la taille est multiple de 4.

donc, le multiple de 4 le plus proche et inférieur à 256 est 252.

bref, après les tests, une matrice non optimisé de 252*252 commence à ramer un peu ... je vais voir en virant les \'double sided polygones\' :gniah:[/quote]

En gros, ses variables sont du type \"octet\" donc 8 bit, donc 256 possibilité donc il peut y mettre des nombres allant de 0 à 255, sauf qu\'il a fait très simple et que, véritablement, seul des nombres multiples de 4 passes. Donc 255 passe pas, ni 254 ni 253, mais 252 oui et tout les multiples de 4 inférieurs passent aussi.


L\'intérêt d\'utiliser un octet au lieu de 2, c\'est que ton processeur va (en gros), faire certaines petites choses deux fois plus vite (genre, additionner deux octets, c\'est deux fois plus rapide que d\'additionner 2 variables de 2 octets chacunes) [en gros, parce que j\'ai la flem de faire un cour pour décomposer une instruction de GameMaker en Assembleur pour calculer les nanosecondes théorique nécessaire pour leur éxécution].


Après réflection, je ne suis plus sûr d\'avoir été plus simple que [TheDarkTiger]

Bah oui en fait c'est le but de ce moteur : créer un terrain en 3D dans GM (donc un modèle 3D), puis après tu peux faire des bricoles du genre trouver la hauteur Z en n'importe quel point du terrain à partir des coordonées X,Y (heightfinding), trouver la valeur de l'angle d'une pente entre deux points, enregistrer/charger/dupliquer un terrain.
Pour l'instant ce sont les principales fonctions, mais j'en ajouterais sans doute quelques unes encore

(et je dois toujours lisser les normales, c'est en cours, mais le résultat n'est pas celui attendu, je caypapourquoi )

EDIT : Ah mais il parlait donc des limites de la DLL ? Je comprend mieux ^^

En gros plus tes variables sont d 'un "petit" type, et moins grand tu pourras mettre des nombres dedans, mais plus vite ils seront manipuler par ton processeur.

Par défault, GameMaker met toutes tes variables en type "long float" (je crois, il faudrait que je retrouve le passage ou MarkOvermars en parle).
Donc les variables de GameMaker sont gigantesques et tu peux y mettre des nombres gigantesques dedans...

Mais lorsque tu commences à faire des boucles et que tu cherches à optimiser les instructions, tu dois forcément finir par te poser la question "quelle taille [type] suffirait pour mes variables"...
J'avais vu un gard qui mesurait le temps d'incrémenter 10 millions de fois une variable dans une boucle genre :

for(i=0;i<10 000 000;i++)
{
//rien
}
afficher le temps.

Et ba d'un coté il lui fallait 3 seconde, de l'autre il lui fallait genre 0.03 seconde.


Je peux me tromper un brin dans l'exemple et le résultat, mais ça devait être à peu près ça. (différence entre un int et un double int il me semble, ou je ne sais plus quoi, mes derniers cours en langage C, ça remonte à loin...).

tu as compris en gros Nicoulas ?
Je te fais la remarque parceque si tu veux améliorer tes matrices, il va falloir que tu ais consciences de ça. [je suppose fortement]

Oui ça je sais (j'ai un bouquin sur le C++), mais au début j'avais pas pigé qu'il parlais de variables et dans sa DLL alors je comprenais pas trop ^^

En tout cas merci pour l'explication, même si je le savais déjà à peu près :lng:

Mais j'hésite à faire une dll pour trois raisons :

- j'ai jamais fait de dll pour l'instant alors je préfère commencer par des trucs simples
- mon système est quasiment fini alors j'ai pas trop envie de devoir en réécrire toute une partie ^^
- à la base je voulais faire un truc simple et juste en GML :nezrouge:

Mais c'est vrai qu'avec une dll le gain de temps doit être énorme

C'est vrais que je n'ai jamais vu un tel résultat juste avec le moteur de GM, un grand bravo pour ta découverte !