Bien, comme convenu j'initie ce sujet pour essayer de mettre à plat les spécifications d'un nouveau moteur de terrain.

Quelques choix techniques vont devoir être décidés.

- geometrie: plutôt système genre ROAM, ou encore quadrender, ...

- rendu: rendu software traditionnel de base, oui shader intégrés, terrain splatting ou terrain mapping, etc...

- fonctionnalités: quelles fonctionnalités doit on proposer et intégrer (changement relief dynamique, etc...)

de ces propositions techniques dépendront en grande partie le codage final de la classe CTerrain...

-geometrie: perso je suis partie sur un quadrender, mais dans l'optique de l'alier a du lod, le probleme c'est que la geometrie se suive entre les quads, je me suis pas pencher d'avantage, mais je pensse que c'est le point le plus important, qar c'est ici que l'on va gagnier le plus en perf.

-rendue: software pour le moment, pour le texturing/splatting est ce qu'une class externe pourais être interessant ? histoire qu'elle puisse être utiliser pour les truc a venir, et pouvoir choisir esaiment entre shader et software ...

-fonctionnalités: uhm ... ben en relation avec la geometrie ....

après inutile de dire que tout les paramètre devraient pouvoir être changer, heightscale, nombre de quad, ... etc

Visiblement peu de membre on l’expérience nécessaire pour départager toutes ces techniques, ton avis serait le bienvenue tmyke
pour ma part je voterai pour les shader, même si je connait pas
Sinon quels sont les avantages/inconvenants de : ROAM et quadrender, terrain splatting et terrain mapping ?

nico :

Sinon quels sont les avantages/inconvenants de : ROAM et quadrender, terrain splatting et terrain mapping ?

géométrie
-ROM, avantage: bonne optimisation en terme de nombre de primitive lors du rendu, inconvénient: plutôt disgracieux sur le plan visuel, moins facile à gérer sur des terrain dynamiques.
-Quadrender, avantage: visuellement nickel, gestion dynamique bien plus à porté, inconvénient: un poil plus gourmand niveau perf (quoique...).

perso, j'opterais plutôt pour le quadrender, ceci dit je dois faire encore quelques tests. Un mixage des deux (comme le pense Magun) est possible, mais la mise en oeuvre
n'en sera que plus complexe...

texturation
-terrain mapping: simple, en gros une texture globale précalculé, et une seconde, sur un second layer pour une vision plus agréable de près.
inconvénient, moyennement adapté à de grande surface (on perd vite en détail à moins de passer par des textures énormes genre 4096x4096).
- terrain splatting, plus agréable sur de grande surface à mon sens, plus dynamique je pense aussi.
inconvénient: passage quasi obligé par les shaders, et une gestion des différentes textures pour le mettre en oeuvre un peu plus complexe.

L'avantage, c'est que les deux mode sont possible, par exemple dans le code que j'ai fournis dans le premier sujet, il est tout à fait possible d'utiliser au choix l'un
des deux mode de texturation....

Je cogite en ce moment.

A première vu Quadrender et terrain splatting semble se démarquer. c'est sure que ça marchera pas sur les vieilles cartes, mais bon; je doute qu'on puisse obtenir grand chose de ces vieilles cartes de toutes facon
Après tant mieu si on peut choisir entre different procédé, si c'est pas trop long à mettre en place, et pas trop lourd non plus, à nous de fixer les priorités, pour moi c'est perf/beauté

Aller quelques nouvelles quand même

nico :

A première vu Quadrender et terrain splatting semble se démarquer. c'est sure que ça marchera pas sur les vieilles cartes, mais bon; je doute qu'on puisse obtenir grand chose de ces vieilles cartes de toutes facon

Ben en fait, la plupart des vieilles carte acceptent aujourd'hui le shader 2.0, ceci dit il y aura toujours une possibilité de texturing standard sans passer par les shader, donc pour les très
vieilles cartes, il y aura une solution quand même...

nico :

...à nous de fixer les priorités, pour moi c'est perf/beauté

c'est aussi mon approche. Un juste milieu, mais qui garantie quand même un minimum de qualité visuelle, tout en ayant des performances fort acceptable.


Je vais donc travailler dessus ces deux prochaines semaines. Je dis cela car je pars en déplacement 15 jours à partir de lundi pour le boulot, et donc mon portable devrait chauffer

bon, je demande un peut de nouvelle, car franchement c'est un peut mort ?

bref, je ne pense pas qu'il y est que le terrain a faire, je suis a disposition si on cherche a prog des trucs.

tmyke :

je pars en déplacement 15 jours

Je pense que ça explique pourquoi le projet est un peu "mort" (en tout cas bien endormis )

Sinon, pour ma part, je compte toucher à la gui (je ferais un post quand j'aurais le temps pour dev : c'est-à-dire dans quelques jours).

Dernière modification par thesus (18-02-2011 19:27:00)

Magun :

je suis a disposition si on cherche a prog des trucs.

Je te propose d'implémenter addoceanscenenode()
ça va bien avec le terrain je trouve ou un lac plutôt.

je verais se que je peut faire

j'ai continué trankilou le développement de mon terrain, et je dois dire qu'il commence à être sympa, j'ai viré les points négatifs
il dispose d'un splatting shader et suport des 'unlimited light", le fog est à revoir (le rendu reste très correct sans)
il est toujours basé sur le quadtree mais intègre également un lod "clasique" je cherche actuellement des algorithme pour un lod plus poussé style c-bdam ou rtin (si quelqu'un a un sample)
je bosse en ce moment sur le raccord entre les quads et le mode d'édition
je compte revoir le shader pour qu'il supporte plusieurs textures en une, comme ça il y aura la texture référence, la colormap, la texture "pack" et le bumpmap "pack"

l'app pour générer mes terrains via la libnoise (sur le portable core i3, hd5165) avec compiz

edit: visualisez l'image dans un autre onglet, le forum semble redimentionner l'image, c'est pas terrible

ce n'est pas vraiment sinificatif mais j'ai 540fps pour +1.5M de poly sur le fix (hd5770, phenon II x4 10) avec compiz d'activé ...
les méthodes de calcul sont thread-safe (enfin dans mon engine sa passe nikel, toutes les fonction OnAnimated sont dans un thread séparé)
le rendu est "static" c'est a dire que le changement de position se fait directement au niveaux des vertex pour les quads ce qui a permis de supprimmer les changements de matrices pour chaque quad
c'est aussi valable pour les matériaux, et les rendus de debug

ps: pour information dans mon engine, il n'y aura pas de moteur de terrain, mais un heightfield général optimisé, qui sera utilisé aussi bien pour le terrain que pour l'eau, seul le shader changera
le "layer" du terrain peut être généré par texture ou algorithme ou par la libnoise, peut-être que ce serait bien pour aip ?
ps2: tmyke on voit tous le temps tous les topics comme "non lu" dans cette partie

"methode" de calcule du lod

Dernière modification par Magun (13-06-2011 23:05:00)

Jolie travail
D’emblée, j'aime beaucoup la gueule de ton éditeur... Tout cela semble très alléchant.

Je travaille moi aussi toujours sur un moteur de terrain 'convenable' pour N3xtD, et par contre coups poutr AIP.
Je bosse sur un gros projet de jeux, en extérieur (le jeux hein, je bosse pas dehors), donc ce sont
des fonctionnalités importantes pour moi en ce moment (comme par exemple aussi une classe Water, cloud, etc...)

Là, j'en suis à tester un terrain splatting avec shader, passage de 16 textures (uniquement pour DX pour le moment).
Si tu as l'occasion de nous faire un petit pack de test un jour, je suis preneur

Code sur le calcul du LOD propre et instructif, merci .

ps2: tmyke on voie tout le temps tous les topics comme "non lue" dans cette partie

faut que je vois cela... enfin surtout Nico vois cela

merci
je ferais une demo dans le weekend ou plus tard surment :]

ps; oui désoler je pensais a nico mais j'écris souvent tmyke a la place .... >< ... bref

Pas de soucis, et pour la demo, c'est quand tu pourras

désoler cela risque de prendre plus de temps que prévue pour sortir une demo windows, en effect je n'est pas compiler depuis des mois sous windows
en outre je doit reconfigurer tout la partie windows, les library et tout ce qu'il sans suit ... c'est pas vraiment passionant

ps: j'est tout de même l'executable unix x86_64 a disposition si tu le souhaite

Te bile pas, y-a pas d'urgence.
De toute façon, à l'heure actuelle, je suis sur une étude de projet de jeux, très très sérieux, et qui (si il se concrétise), non seulement me prendra tout mon temps (ou presque) ,
mais en plus m'éloignera quasi définitivement d'Irrlicht et de ce qui peut tourner autour