Moteur de terrain 3D

Je sais mais ça rend super bien quand même ^^

Merci
J'ai commencé à bosser sur le moteur d'eau mais rien de bien bluffant pour l'instant vu qu'il n'y a que deux fonctions de prêtes, et j'ai réussi à optimiser un peu le temps de calcul des terrains, je passe d'environ 3,6 secondes à 3,3 secondes (pour générer deux terrains : un en haute qualité et l'autre en basse qulité)

nicoulas a écrit:

Bon je viens de faire un petit test ludique avec une heightmap et une texture trouvées sur le net (http://www.vis.uni-stuttgart.de/javatevi/Gallery.html) :

Ça donne ça (c'est l'île de Hawaii) :



Je vais essayer de corriger rapidement les bordures noires (qui viennent d'une légère faille du code de calcul des normales).
J'ai fait pas mal de tests de performances durant la génération des terrains mais j'arrive pas à descendre en dessous d'environ 3.6 secondes pour un terrain en 64*64 (cad avec 8192 polygones) sur mon processeur 2.66 GHz.

Un dernier truc, pour la compatibilité avec GM6, je me suis aperçu que contrairement à GM7, la fenêtre d'un exe généré avec GM6 n'apparait qu'au moment du premier event draw, alors qu'avec GM7, la fenêtre apparaît dès que le jeu commence. Justement, ça me cause un soucis puisque j'ai besoin de dessiner sur la fenetre avant le premier event draw. Si quelqu'un a une idée, je suis preneur

whaow tu vas faire un battlestation pacific avec ce moteur graphique ??

c'est marrant, j'utilise la même height map pour mes tests :gniah:

Mais pourquoi vous utilisez tous l'ile de Hawaï ? Et j'avais pas remarqué qu'on voyait la voiture de magnum sur l'ile ^^. Je vous conseille de faire la même chose sur Toulon ^^ Vous me verrez moi et Topaze ^^. Mais moi c'est une boule verte qu'il faudra chercher XD.

[Mode déconne off]

[TheDarkTiger] a écrit:

c'est marrant, j'utilise la même height map pour mes tests :gniah:

lol, c'est surtout motivant d'avoir un bon rendu assez rapidement (sans faire l'heightmap + la texture)

@ Playboy : on voit quoi sur l'île ?

@ Al_tanner : connais pas, c'est un jeu d'aviation ?

nicoulas a écrit:

@ Al_tanner : connais pas, c'est un jeu d'aviation ?

on peut dire ca
clique pour voir, c'est toutes les infos : http://www.jeuxvideo.com/jeux/xbox-360/00021416-battlestations-pacific.htm

Oui ok je vois, mais bon faire ça sous GM est assez long, puis bon le rendu serait légèrement différent

Hum bien Nicoulas vu le rendu de ton engin je pense dire que tu en serais capable !! D'ailleurs ça pourrait être bien de faire ma bataille navale en 3D ? Avec ton moteur Qu'est ce que vous en pensez ? Vous pensez que cela rendrait bien et qu'il est approprié ?

Sinon je faisait référence à ceci : https://www.youtube.com/watch?v=o3mfIywd9gA à la 10-12 em seconde tu comprendras pourquoi ^^".

[quote="Playboy"]Hum bien Nicoulas vu le rendu de ton engin je pense dire que tu en serais capable !! D'ailleurs ça pourrait être bien de faire ma bataille navale en 3D ? Avec ton moteur Qu'est ce que vous en pensez ? Vous pensez que cela rendrait bien et qu'il est approprié ?
quote]

bien sur, ce serait super si tu faisait avec cette Engine.


Est-ce-qu'il y aura des reflet dans l'eau ???

Oui et même des explosions et des bateaux qui coulent
Imagine toi tu voit le missile partir depuis le bateau et il atterit soit dans l'eau dans une grande gerbe, soit sur un bateau et avec une vue jumelle tu vois de la fumée qui commence à partir

Mais je sais pas si mes idées sont au delà des capacités du module de nicoulas ^^"

Mais en tout cas si j'ai de bons écho je pense que je m'y mettrais Man que donc que Nicoulas le finisse ^^*

whaow j'en bave d'avance

vivement que le moteur de nicoulas sorte

Ça pourrait être sympa comme vous le dite mais moi ce qui me gène dans un moteur 3D de cette qualité, c'est le temps de génération des terrains, à mon humble avis, on peut peut-être l'améliorer car 2 secondes pour une image minuscule ça fait un peu beaucoup...

EDIT :

Code:

col = draw_getpixel(i,j);

C'est mal mon fils... Avec le ScanLine de Delphi je te fais tous tes pixels en une demi-milliseconde. (mais ne rêve pas, transformer une sprite en TImage est quasiment impossible). Mais en l'enregistrant sur le disque, c'est faisable et tu transformerais ton temps de rendu de 2 secondes en quelques dixièmes de secondes. :fier:

@ Playboy : yay ça serait cool ça ! Dès que j'ai fini l'eau je poste la MAJ du moteur, comme ça tu pourra commencer si tu veux :lng:

@ Al_tanner : Arf, ça serait faisable en théorie (les reflets), mais le rendu serait soit mauvais, soit les performances mauvaises, bref ça vaut pas trop le coup. Et tu sais, mon moteur est déjà exploitable, y'a juste à prendre les scripts, après en mettant à jour les scripts, tu profiteras des futures MAJ ^^

@ Bibi : T'inquiète pas c'est pas ça qui prend le plus de temps ^^
D'ailleurs j'ai une idée pour optimiser encore un peu, je testerais ça un de ces jours.

Hum à mon avis si, draw_getpixel() bouffe vraiment beaucoup de perfs... Je vais regarder de mon côté en attendant ton optimisation.

Non en fait le plus long est le calcul des normales (+ le lissage) parce que au tout début, lorsque j'avais juste la boucle de draw_getpixel(), le calcul était bouclé en moins d'une demi-seconde.

Tant que j'y suis, je vais implémenter une option de texture splatting en fonction de la hauteur (en gros on spécifie plusieurs textures qui seront appliquées au terrain en fonction de sa hauteur), mais ça ne pompera pas plus de perfs à l'affichage (à la limite temps de calcul un peu plus long).

Petit double post powaaa.

Bibi tu vas être content, j'ai réussi à gagner (sur mon ordi) 0,5 secondes de temps de chargement lors de la création des terrains
Je suis donc passé de ~3.3 secondes à ~2.8 secondes.
En plus ces 2.8 secondes correspondent au temps de création du terrain haute qualité + du terrain basse qualité utilisé lorsque la caméra est loin du terrain.
J'ai testé avec juste le terrain haute qualité et le temps de chargement est de seulement 1.8 secondes :-D

perso je lit les données octet par octet sur le disque et 2 secondes, c'est le temps qu'il me faut pour une image en 128*128 (en mode minimal : pas d'ombrage, de normale ou de texture spéciale)
je met 8 secondes pour une image de 252*252 (mode minimal toujours)

et je suis d'accord avec toi, le calcul des normal multiplie facile par deux le temps de création des matrices.

Oui forcément avec une dll ça va beaucoup plus vite ^^ mais justement là je viens de supprimer des calculs redondants pour les normales et ça accélère vachement la génération.
Pour le moment je vois pas d'autre moyen d'optimiser, donc pas en dessous de 2.8 secondes pour l'instant.

non je n'utilise pas de DLL pour le moment ...

que des fonctions de GM.

Autant pour moi, il me semblait que t'avais créé une dll pour accélérer les calculs ^^

Ça veut dire que j'ai encore de quoi optimiser au moins :nezrouge:

nicoulas a écrit:

Petit double post powaaa.

Bibi tu vas être content, j'ai réussi à gagner (sur mon ordi) 0,5 secondes de temps de chargement lors de la création des terrains
Je suis donc passé de ~3.3 secondes à ~2.8 secondes.
En plus ces 2.8 secondes correspondent au temps de création du terrain haute qualité + du terrain basse qualité utilisé lorsque la caméra est loin du terrain.
J'ai testé avec juste le terrain haute qualité et le temps de chargement est de seulement 1.8 secondes :-D

Bien joué !

De mon côté, je me suis rendu compte que ce n'est pas le draw_getpixel() qui pompe le plus (il doit prendre 10 % du temps de calcul global), ce qui prend le plus de temps c'est le gros bazar juste en dessous de la boucle du draw_getpixel() dans la fonction d3d_create_terrain_from_sprite().

C'est ça le calcul des normales ? (désolé je suis un vrai n00b en 3D)


EDIT : sinon je vois aussi qu'il y a beaucoup de calcul avec des nombres entiers, il serait intéressant de faire une DLL en assembleur (assez simple), donc quand tu auras tout bien optimisé en GML, appelle-moi.

bibi675 a écrit:

C'est ça le calcul des normales ? (désolé je suis un vrai n00b en 3D)

Effectivement, c'est une partie du calcul des normales, après y'en a un autre bout dans la boucle suivante (c'est surtout là que j'ai otpimisé, y'avait des calculs qui étaient faits plusieurs fois pour le même résultat ^^)

bibi675 a écrit:

EDIT : sinon je vois aussi qu'il y a beaucoup de calcul avec des nombres entiers, il serait intéressant de faire une DLL en assembleur (assez simple), donc quand tu auras tout bien optimisé en GML, appelle-moi.

Oui, mais faut faire attention, y'a aussi beaucoup de nombres à virgule (normales, coordonnées UVs du terrain, hauteurs du terrain), mais par contre je suis pas contre l'idée de la dll.
Ce que j'avais pensé à un moment, c'est faire une dll, mais qui ne serait pas obligatoire : en gros si la dll est présente dans la dossier du jeu, les scripts l'utilisent, et sinon les calculs se font avec GM.
Mais vu que je galère un peu en C/C++ je retiens ta proposition ^^

Code:

        nx = (y2-y1)*(z3-z1)-(y3-y1)*(z2-z1);
        ny = (z2-z1)*(x3-x1)-(z3-z1)*(x2-x1);
        nz = (x2-x1)*(y3-y1)-(x3-x1)*(y2-y1);

Si ça ce sont des nombres entiers, on peut économiser le temps de "parsage" par GM, reste à voir si ses appels d'API sont performants...

Et je suis daccord pour utiliser la DLL si elle est présente (c'était même ce que j'allais te proposer mais je te précise quand même qu'elle ne ferra que quelques Ko car il n'y a que de l'assembleur et les fonctions en Delphi).

En fait x1,x2,x3 et y1,y2,y3 sont forcément des nombres entiers, mais pas z1,z2,z3, alors ça va peut être poser soucis =/

Pour la dll, c'est pas tant le poids, mais c'est toujours mieux d'avoir un truc le plus portable possible, puis certaines personnes n'aiment pas les dll
Non, en fait c'est plus pour laisser le choix à l'utilisateur, sans avoir rien de plus à paramétrer dans les scripts

J'en profite pour dire que j'ai quasiment fini le système de texture splatting, je vais pouvoir l'intégrer au moteur sans tarder, juste quelques trucs à régler.
Et aussi, j'ai trouvé plein de trucs à optimiser dans le code de génération de terrains colorés, je vais sans doute gagner au moins 0.1 ou 0.2 secondes sur celui-là (~3.2 sec actuellement).

Ok bah dès que tu as fini d'optimiser le tout, je verrais pour te faire toutes tes fonctions en Delphi + Assembleur. :fier:

Bon courage ! ^^

moi je voulais tout faire sous GM puis voir ce que je pouvait faire en C dans une DLL.

Au final, je pense que je vais surement faire le calcul des normales par une DLL.

Si tu veut, je peut implanter ton système dans une DLL pour toi (mon système de calcul est différent et utilise des Cos et des Sin :gniah: )

Ah ben je veux bien, enfin faudra voir avec bibi, autrement je vais me retrouver avec deux dll sur les bras ^^
D'ailleurs en parlant de dll j'avais fait un test pour accélérer le calcul d'une moyenne mais au final c'était plus lent avec la dll qu'avec GM ... :hehe:
Faut dire, je crois que je déclarais pas le bon type de variable (je les déclarais en 'double' autrement les résultats étaient disons ... improbables avec 'float').

Je viens d'intégrer le texture splatting, mais j'ai de gros soucis, déjà le terrain devient partiellement transparent puis les textures ne s'affichent pas tout à fait correctement, va falloir que je bosse pas.

Petit récapitulatif de ce qu'il me reste à faire :
- débogguer le texture splatting selon la hauteur (cad appliquer certaines textures en fonction de la hauteur du terrain)
- programmer une deuxième fonction de texture splatting mais en spécifiant des couches alpha pour chaque texture
- programmer la gestion des fluides (mais ça reste à voir finalement)

ok.

t'as juste ça à metre dans ta DLL ?

nx = (y2-y1)*(z3-z1)-(y3-y1)*(z2-z1);
ny = (z2-z1)*(x3-x1)-(z3-z1)*(x2-x1);
nz = (x2-x1)*(y3-y1)-(x3-x1)*(y2-y1);

TDT est beaucoup plus expérimenté que moi au niveau de la 3D donc je le laisse te coder ta DLL avec plaisir. :fier: