Planètes procédurales, cartes de hauteur et textures

Je travaille actuellement sur un générateur de planète procédurale OpenGL. J'espère l'utiliser pour un RPG spatial, qui ne permettra pas aux joueurs de descendre à la surface d'une planète, j'ai donc ignoré tout ce qui concerne la ROAM. En ce moment, je dessine un cube avec des VBO et mappe sur une sphère.

Je connais la plupart des techniques de génération de carte de hauteur fractale et j'ai déjà implémenté ma propre version de déplacement de point médian (pas très utile dans ce cas, je sais).

Ma question est la suivante: quelle est la meilleure façon de générer de façon procédurale la carte de hauteur. J'ai regardé libnoise qui me permet de créer des textures / textures de hauteur, mais pour autant que je puisse voir, je devrais générer un réseau comme celui-ci .

Laissant le carrelage évident.

Quelqu'un pourrait-il me conseiller sur la meilleure route à prendre?

Toute entrée serait très apprécié.

Tout d'abord, je ne sais pas pourquoi vous voulez implémenter une carte de hauteur (c'est-à-dire un déplacement de géométrie) si les gens ne peuvent pas atterrir, il semble juste plus efficace de la cartographier normalement ou quelque chose.

Cela dit, ce que vous voulez, c'est convertir d'un arbitraire (x, y, z)en une (u, v)coordonnée, ce qui est trivial. Aucun cubemap nécessaire.

1. Chaque (u, v)texel a une hauteur (heightmap RGB = height) et une position (x, y, z) = pos.
2. Trouvez et normaliser la position, NORMAL(x, y, z) = N.
3. Nouveau sommet = pos+N*height.

Cela fonctionnera mieux avec une tessellation plus élevée. Utilisez également le libnoisemapping sphérique approprié pour votre heightmap, qui ressemblera à ceci (mais en noir et blanc):

Je n'ai jamais essayé cela moi-même, mais cela ressemble à un moyen très intéressant de générer des paysages sphériques. http://freespace.virgin.net/hugo.elias/models/m_landsp.htm

La cartographie de la hauteur de déplacement à mi-chemin est un bon point de départ. OP, pourquoi pensez-vous que ce n'est pas le cas?

OP est bon pour modéliser la surface de la planète sous forme de cubemap, car toute carte plate (par exemple, projection Mercator) va avoir des distorsions qui sont laides et compliquées, mathématiquement.

Si j'étais OP, j'oublierais d'abord la géométrie de la planète à grande échelle. Je ferais un cubemap où chaque face fait 2 ** N + 1 pixels (2,3,5,9,17,33 ...) et chaque texel code une hauteur [0..N) où 0 est l'altitude de la tranchée la plus basse attendue et N est l'altitude de la plus haute montagne attendue de la planète.

Je calculerais ensuite des hauteurs aléatoires pour les huit sommets du cube et les propagerais dans les six carrés de la carte du cube, de sorte que chaque sommet apparaisse trois fois.

Comme je génère récursivement des hauteurs fractales pour les points médians des arêtes, je m'assurerais de propager les sommets des arêtes de face à l'autre face qui les partage.

Une fois que j'ai terminé, j'ai une carte de cube où tous les texels de bord sont doublés et tous les texels de coin sont triplés. Pas besoin de le convertir en une carte normale - j'utiliserais l'algorithme dans l'article de Morten Mikkelsen pour rendre les normales directement à partir de la carte de hauteur au moment de l'exécution.

Lors de l'exécution, je rendrais probablement un quad qui couvre la projection de la planète à l'écran, et ferais un test d'intersection rayon-sphère unique dans le pixel shader pour savoir si j'ai frappé la planète et où. Bien sûr, il bat la pixellisation d'un modèle de sphère hautement tessellé et obtient également un bord lisse agréable.

Le bruit de déplacement médian, avec le déplacement maximal mis à l'échelle par la longitude absolue du pixel, peut produire rapidement une carte de bruit sphérique. Des tableaux de couleurs prenant l'altitude, la pente, la lumière du soleil ou la longitude comme paramètres peuvent être utilisés pour ombrer la planète automatiquement.