or maybe you can use lot of flat terrain
Those pictures are of a normalized cube, that is one of the techniques I linked to in the beginning of this thread and you should definitely check that link out:
Four Ways to Create a Mesh for a Sphere
Notice that the spherified cube has much more even grid spacing than the normalized cube. This means that as the player walks or flies over the terrain, the detail level won’t so dramatically decrease as he gets closer to the center of one of the sides. It is a much smoother sphere. Here’s another article about moving from a normalized sphere to this improved technique (it is for C# and Unity but the math is the same):
Do you mean using a lot of instances of either ShaderTerrainMesh or GeoMipTerrain placed side by side around a spherical area to form the surface of the planet?
i think that best solution is with use lot of GeoMipTerrain.
But I do not know what this solution will give to the performance.
The bigger issue is that you will have horrible seams between the terrain instances.
Look closer at the images you posted above. The grid “squares” that cover the spheres are not square at all. They have four edges and four vertexes but the angles are not square 90º right angles. They are distorted into various weird diamond shapes in order to neatly cover a spherical surface.
But GeoMipTerrain and ShaderTerrainMesh produce square surfaces only by default. So you will have to modify them (in whatever language they are written in, GeoMipTerrain is mainly C++, IIRC) to a serious extent with some clever mathematics. Or else the terrains will not meet edge to edge but have horrific interpenetration or gaps of open space between them. There is just no physical way to cover a sphere with regular squares.
After that, you will need to further modify GeoMipTerrain to be able to share normals and possibly texel information between instances of itself (with totally different coordinate systems in some cases) or you will get terrible looking visible seams when you light the surface or do any procedural texture generation (which is required if you are doing a realistic earth sized planet or else the textures will be effectively solid colors when standing on the surface of the world because even the largest possible texture will be stretched over such an enormous area).
It will likely be less work to to build planets from scratch procedurally, vertex by vertex, face by face, normal by normal, UV by UV, than to try to hack GeoMipTerrain or ShaderTerrainMesh into spheres. And either way, you will need to understand the same math yourself well enough to implement it, so in addition to likely not being less work it will also likely not be any more simple.
If you are new to graphics programming you might want to scale back your ambitions for starters and try to make simpler types of environments before attacking something as advanced as full scale planets. Either do asteroids or unrealistically tiny planets or fantastical flatter environments like “flat earths” or “skylands”. And then come back to this when you are ready to dive into this type of graphics programming or someone has developed a library to do exactly this for you.
I gave an example here: Cube to sphere, but you need to use shaders as the correct variant. You can apply a height map to this cube, but you need to create a sweep and add edges.
Stuck at parent teacher conferences so I don’t have access to my code
One method I found that works well is creating a cube and then normalizing the geometry to create a sphere. There is a little bit of additional trickery to minimize the distortion at the edges. In theory you could use geomipterrain but getting the seams out would require additional work.
nullpointer.co.uk/content/pr … l-planets/ (has additional references)
serega-kkz thank for your answer, i have question :
For use geomipTerrain, i must be create cube with 4 geomip terrain and convert to sphere with your code or i use your planet.egg and i reparent my geomipterrain to your sphere and i convert vertex ?
I have a problem when i want to modify vertex, with geomip terrain your code make sqrt of negetiv number, i must be use abs function, Is this a normal behavior? am I on the right track?
# -*- coding: utf-8 -*-
from direct.showbase.ShowBase import ShowBase
from pandac.PandaModules import *
from math import sqrt
class MyApp(ShowBase):
def __init__(self):
ShowBase.__init__(self)
planet = loader.loadModel('planet')
planet.reparentTo(render)
geomNodeCollection = planet.findAllMatches('**/+GeomNode')
terrain = GeoMipTerrain("myDynamicTerrain")
terrain.setHeightfield("heightmap2.jpg")
terrain.setBlockSize(32)
terrain.setNear(40)
terrain.setFar(100)
terrain.setFocalPoint(base.camera)
root = terrain.getRoot()
root.reparentTo(planet)
root.setSz(100)
terrain.generate()
def updateTask(task):
terrain.update()
return task.cont
taskMgr.add(updateTask, "update")
geomNodeCollection = planet.findAllMatches('**/+GeomNode')
for nodePath in geomNodeCollection:
geomNode = nodePath.node()
for i in range(geomNode.getNumGeoms()):
geom = geomNode.modifyGeom(i)
vdata = geom.modifyVertexData()
vertex = GeomVertexRewriter(vdata, 'vertex')
while not vertex.isAtEnd():
v = vertex.getData3f()
x2 = v[0] * v[0]
y2 = v[1] * v[1]
z2 = v[2] * v[2]
x = v[0] * sqrt( abs(1.0 - ( y2 * 0.5 ) - ( z2 * 0.5 ) + ( (y2 * z2) / 3.0 ) ))
y = v[1] * sqrt( abs(1.0 - ( z2 * 0.5 ) - ( x2 * 0.5 ) + ( (z2 * x2) / 3.0 ) ))
z = v[2] * sqrt( abs(1.0 - ( x2 * 0.5 ) - ( y2 * 0.5 ) + ( (x2 * y2) / 3.0 ) ))
vertex.setData3f(x, y, z)
self.accept("f3", self.toggleWireframe)
app = MyApp()
app.run()The correct way is to use shaders. And your path will lead to nothing.
OK, thanks.
So If I understood i have to apply a shader to geomipterrain object ?
You must write your system with calculations of the terrain on the GPU. Geomipterrain is not suitable for this. Information on this subject here, my example was built on the basis of this information.