For each face
.. create texture of size ( 100 x 100 ) as faceimg
.. for each pixel in faceimg
.. .. xx,yy,zz as ( 3D position of pixel if on perfect sphere )
.. .. faceimage[x][y] = generate ( planet seed, xx, yy, zz )
.. map faceimage to the face
generate ( seed, x, y, z )
.. return selected noise at x, y, z
eq2k wrote:Thanks for all your feed back so far has helped me think of some aspects in different ways. I do plan to planetery landing. So was thinking if I created algo to create planet and using technique like surface nets I would be able to chunk parts of the planet based on what can be seen. But not sure how to chunk something like a surface net. Maybe some way to chunk a window of data to be voxeled. I'm sort of thinking it maybe a bit like the zoom into Mandelbrot technique but in 3 dimensions.
As a developer I've become increasingly interested in creating my own procedural planets / universe. I have done a fair amount of research on the techniques involved and was wondering what techniques you use in LT to help point me in right direction.
Ive seen techniques using Surface Nets, Dual Contouring, warping cubes into spheres and so on. Because I'm not sure which is best to go with for procedural planets I have got myself in a confused state regarding implementing LOD (i assume using marching cubes / octree's).
Also not quite sure how to tell when imposters come into play. Also do you use compute shaders or are the meshes streamed to GPU.
I appreciate your time and hope you can give me some quick pointers. I really can't wait for LT to come to fruition.
Flatfingers wrote:A related practical question concerns the "procedural" part: how much of the semi-randomly generated terrain/heightmap data must be stored forever once the player has gotten close enough to a planet's surface for that data to be generated?
Storing everything once it's been generated insures that a place, once visited, always has the same apparent geometry on subsequent visits, but at an ever-increasing storage cost.
Alternately, randomly generating data on every new visit reduces storage costs, but the details of terrain will be different each time.
So how should developers decide which of these is best for their project?
To put it another way, how much terrain geometry/texture data must be stored to persuade most players that a place looks "the same" on each visit?
Users browsing this forum: Baidu [Spider] and 4 guests