Changement dans la gestion du terrain

Afin d'avoir une gestion des niveaux infinis j'ai du refaire la gestion des niveaux (c'est pas nouveau, ca fait un moment que j'en parle).
Du coup nous n'utilisons plus de heightmap mais des morceaux de terrains qui sont des .mesh.
Chaque morceau est carre de la taille que l'on veut.
Pour des besoins de coherence et d'optimisation il faudra se fixer a une taille commune a tous ces morceaux. Pour le moment ce n'est pas tres important de toute facon.

Donc est-il possible pour un graphiste d'exporter la heightmap vers un modele .mesh ?
Je n'ai pas les outils sous la main pour le moment. En attendant je bidouille avec les autres modeles

bah la heightmap que je vous avait fourni, vient d'un mesh, donc pas de soucis pour fournir le mesh oué ^^ faut juste me dire les dimensions de chaque morceau.

Sinon pour les exports, je suis toujours bloqué car Ofusion n'a toujours pas été adapté pour Max2009. A prioris (je suis le site officiel) ça doit arriver avant la fin de l'année...

Pour le moment on peut dire que l'on utilisera des blocs de 256 x 256 sur X x Z (la hauteur etant donc Y).
Chaque bloc doit etre centre sur 0 pour ses axes X et Z.

Donc pour le moment pas de heightmap ?
Je vais essayer de contacter les gens de viracocha, ils aarrivaient a faire des trucs sympa avec blender. Voir si je peux y arriver.

non mais je peux te faire les 2, dis moi juste précisément ce qu'il te faut...

Pour les bloc de 256*256, on parle en quoi? cm? l'unité c'est plus des pixels si on parle en terme de mesh

je te les range comment ? niveau nomenclature ?

Je ne parle pas de pixels ni cm.
Je parle de l'unite des meshs.

Par ailleurs a-t-on defini une unite pour les meshs en general ? est-ce que 1 = 1m ou 1 = 1cm ou 1 = 1km ?

niveau nomenclature, je pense creer un dossier pages dans data/ contenant des pages nommes de facon:
pageXXXxYYY
ou XXX et YYY definissent les coordonnees globales de la page en question (pour rappel, les pages sont organisees en grille)

moi je bosse avec1unité=1cm mais vu l'état des imports sous Gnoll, apparement c'est pas le cas de tout le monde :p

je vais en parler avec chylder qu'on se cale. Sauf s'il râle, on se mettra sur 1unité=1cm donc :p (ou objection de ta part)

1page=1block en fait ?

Si tu peux me faire une petite explication plus précise

C'est justement mon idée dans le post:
https://arcancia.forumactif.com/programmation-f9/premiers-screenshots-t813.htm

Trouver une échelle commune.
Je suis en cm aussi

début de piste:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=19594&highlight=scale+robot

Vu l'echelle des scenes que l'on aura, ne serait-il pas mieux de prendre le metre comme unite ?

Oui, 1 page = 1 bloc
La scene sera decoupee en blocs de 256x256 sur les axes (X, Z), la hauteur etant Y.
Un peu comme un echiquer. Chaque case est un morceau de terrain et l'ensemble de ces cases forment le monde.
Si tu as un monde de 2560 x 2560 (unites, pas pixel) et qu'une case fait 256 x 256, tu auras donc un "echiquer" de 10 cases par 10 cases.

Si ce n'est que ça.
Psylo, avec le mètre en unité de taille dasn max, tu pourrais me faire un parallélépipède de {x=1,y=2,z=1} orienté avec y vers le haut exporté en .obj ou .3DS et en .mesh pour comparer et l'intégrer dans artifexterra3d.

merci

Paf quel est le lien entre un bloc et un échelle humaine? pour fixer les chemins, les dénivelés, la taille d'un objet dans un bloc, l'emplacement de la cité ect et ne me dit pas que c'est en furlong, je t'étripe .

La relation entre un bloc et l'echelle humaine est la meme que celle entre les meshs et l'echelle humaine.
Les contraintes sont plutot du genre :
* ne pas avoir des blocs trop petits de facon a ne pas constamment charger/decharger des blocs (on ne charge que les blocs visibles et alentours)
* ne pas avoir des blocs trop grands de facon a ne pas gaspiller de la memoire

La taille sera ajustee en fonction des retours que l'on a concernant les performances et la densite des objets.
Mais mes 256 se basaient sur une echelle de 256m et etaient pris au pif.