Salut !

Je compte m'attaqué a la gestion de grande maps :

Pour ce faire, je compte crée plusieurs image 0000.jpg, 0001.jpg, ... et un fichiers qui fait tableau :

Exemple :
0101 0201 0301 0401 0501 0601 0701 0801 0901
0102 0202 0302 0402 0502 0602 0702 0802 0902
0103 0203 0303 0403 0503 0603 0703 0803 0903
0104 0204 0304 0404 0504 0604 0704 0804 0904
0105 0205 0305 0405 0505 0605 0705 0805 0905
0106 0206 0306 0406 0506 0606 0706 0806 0906
0107 0207 0307 0407 0507 0607 0707 0807 0907
0108 0208 0308 0408 0508 0608 0708 0808 0908
0109 0209 0309 0409 0509 0609 0709 0809 0909

....
Et ensuite par rapport a la position de la camera, il affiche les 8 cases adjacente :
000
0x0
000

et charge les 16 cases adjacente a ces cases affichés.
uuuuu
u000u
u0x0u
u000u
uuuuu
et donc décharge tt le reste.

Cependant, me vient des questions :
-Puis je, en cours d'executions, chargé et déchargé des maps ?
-Qu'est ce que le frustum culling (j'ai vaguement vu mais sans plus) ?
-Comment l'integré a mon code (fonction existante dans irrlicht) ?
-Comment accelerer au maximum mon rendu ?

Bref mon idée est celle de tous cependant, je chercher a me rensigner sur les possibilités avant de me lancer dans des recherches.

Si vous avez des experiences, je suis interessé

a+
w

Pour la première question pas de doc sous la main mais oui ya pas de raisons
Le frustum culling c'est ne pas rendre les polys hors champ de vision. C'est un peu couteux en calculs (à moins d'utiliser de l'octree/quadtree) et pas forcément très avantageux. Il y en a déjà un dans irrlicht, mais je crois qu'il est pas activé par défaut. Pour accélerer le rendu il faut soit te créer un terrainSceneNode soit modifier celui d'irrlicht (dans la source) car tu dois toucher à la méthode de rendu de ton node. il y a plein de méthodes de cull qui existent mais tu peux commencer par ne pas rendre les polys au dos de la caméra, t'es sur que ce sera viable. Sinon, google pour backface et occlusion culling

Ne pas rendre ce qu'il y a au dos de la camera sera handicapant dans mon cas : c'est un FPS et un brusque retournement risque de bugué, ou de ralentir le programme.

Oki, pour le frustum culling, et je pense qu'avec les nouveau GPU, ces "petits" calculs passe tranquils...
Si tu sais comment activé/désactivé le frustum culling dans irrlicht, je suis preneur (je vais quand même aller voir la doc )

Merci

a+
w

Yop,

En fait, j'avais la même idée que toi pour afficher les maps (enfin presque). Mais tu auras peut être le même problème que moi pour les relier (essaye d'en relier deux, tu vas voir que ca pose des problèmes à moins que ca soit moi qui soit pas doué lol) donc va falloir refaire le generateur de heightmap (customscenenode) ou bien en utiliser un autre existant (fait par quelqu'un).

Willikus :

Ne pas rendre ce qu'il y a au dos de la camera sera handicapant dans mon cas : c'est un FPS et un brusque retournement risque de bugué, ou de ralentir le programme.

Vu le framerate moyen des programmes il y a aucun problème :) Tu check minimum 30x/seconde tes polys donc aucun problème. Ce sera justement moins handicapant qu'un culling plus avancé comme le frustum/backface/occlusion car le test sera beaucoup plus rapide.

Willikus :

Oki, pour le frustum culling, et je pense qu'avec les nouveau GPU, ces "petits" calculs passe tranquils...

Bin non justement :) le culling (mis à part pour le backface) est effectué AVANT la phase de rendu, donc c'est le CPU qui les calcule. Et c'est la que c'est dangereux d'avoir affaire à un bridage du rendu par le cpu, parce que le gpu se fait chier en attendant que le cpu lui envoie la scene a rendre :)

Willikus :

Si tu sais comment activé/désactivé le frustum culling dans irrlicht, je suis preneur (je vais quand même aller voir la doc ;) )

Je viens d'aller voir vite fait en fait ce que j'avais vu c'est l'automatic culling (irrlicht teste si la bounding box de l'objet est dans le champ) du terrain qui était mis à off :) Fausse alerte... Copland avait eu un problème avec ce culling donc si il passe par là...

Sornoz :

donc va falloir refaire le generateur de heightmap (customscenenode)

En tout cas c'est pas ça le plus dur, allez voir la source du terrainSceneNode d'irrlicht, la partie chargement est bidon.
Mais apparemment il y a eu pas mal de custom scene nodes pour les terrains sur le site off/wiki.
A voir...

Mais apparemment il y a eu pas mal de custom scene nodes pour les terrains sur le site off/wiki.

Oui, notamment celle de arras. J'ai pas regardé le code, mais le terrain dans la démo est quand même assez grand.
http://irrlicht.sourceforge.net/phpBB2/ … rrain+tile
Si tu veux pas tout écrire, je pense que ça devrait t'intéresser

Je sais qu'on s'éloigne du sujet

Les nouveau GPU n'était pas annoncé comme des bête de calcul et que de nombreuse chose (dans un avenir proche) lui serai attribué :
Physique, pré-rendue, ... ?

Sinon, pour la séparation des heightmap, si il y a un décalage, ont doit pouvoir ecrire une suite qui en tient compte, non ?

Dans la journée j'essairais bien de cree/supprimé des heigtmaps dans la boucle mais j'ai des doutes:/

a+
w

Coucou,
Il vous faut combien en taille de heightmap ?
256,512,1024,2048 ?

(tu as... tu as... ??)
J'ai try de refaire le systeme de heightmap, mais je me suis vite confronté à mon manque de connaissance sur Illicht et sur le vocabulaire anglais -_-.
Je voulais juste refaire le même sans les bugs. Donc retour à OpenGL, pour m'entrainer.
A moins que tu possède l'outil de mes rêves
La taille n'a pas d'importance, tant que l'editeur de heightmap marche correctement.

C'est quoi que t'appeles "les bugs" ? Heightmap retourné, c'est pas génant ça, il suffit d'inverser l'image sur paint et rulez........

Re,

Ce qui me gène, c'est http://forum.irrlicht.fr/viewtopic.php?id=331. Sur mon deuxième post. Regarde les images (après ca vient peut être de chez moi)

http://forum.irrlicht.fr/viewtopic.php?id=336
Si tu me dis qu'il est bugué je te frape à grand coup de massue sur la tronche ^_^(trêve de plaisanterie, y'a certainement des bugs mais je préfère mon systeme à celui d'irrlicht)