🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Save Procedural Mesh Data For Later Use?

Started by
3 comments, last by LorenzoGatti 3 years, 5 months ago

Hi,

I am Prototyping a Space Combat Game In Unity and I need to make land able planets, Now If We Make the whole Planet as a Mesh the Size will cause the engine to go wild and ofc the Floating Precision errors will cause troubles, Right now I am Using Camera Layers to give the illusion of Big Planets they are not land able yet.

What I end up with after searching for hours was to use procedurally generated Planes as terrain tiles Once the player ship gets close enough to the Planet Coordinates.

What I would want to know is, how to store all the Planets data without regenerating it every time? Or Better Is there any way I can generate the Planet Once in Editor and save it for the build version? (Probably got to do something with seed value? or serialization to a json file and load that?)

And Last since the tiles are more or less flat How will I spawn tiles that are closer to poles and are curved? i.e. as you move across the planet the tiles spawning in front of you should be spawning in a spherical Order.

Thanks All i need is advice and links to resources if you got them. Thank you.

Advertisement

It depends how accurate you want it to become and if you use a deterministic generator for it. Save the values you used to generate the terrain should be your first step then, followed by some kind of change tracking to what the player did while they're on the planet.

If you really want to save planet data, your best bet would be to use memory mapped files to a really large kind of database file. I worked on a database in my last job and which did exactly that but for other kind of mixed data, so you could write an even more simple solution. We used memory mapped files for up to 50 TB of data which were split into 64k chunks. Each chunk was reserved for some kind of table and/or data. We then created views for each chunk we needed to access so there have been only a few parts of our 50 TB data been loaded on the same time. Maintaining everything in a B-Tree helped for fast lookups.

WD98 said:
And Last since the tiles are more or less flat How will I spawn tiles that are closer to poles and are curved?

You simply use a shader to transform your tiles in order to have a planetary view. It'll then look like this

https://i0.wp.com/shadersmods.com/wp-content/uploads/2017/11/world-curvature-shaders-mod-2.jpg?resize=725%2C379

@WD98 There are a few questions you should consider before coming up with the methodology. First do you need the terrain to be player editable? What sized worlds are we talking about? Also are we talking about smooth terrain such as in a typical game or Minecraft style terrain? Do you want height-mapped terrain or more complex terrain with overhangs and caves?

In general a whole planet can be stored as a single 32 bit number, a key to your procedural algorithms. Now if you want to add more variation in your terrain, you will probably want some extra parameters. In any case you can store a planet in not more than a few hundred bytes. This all assumes you don't care if your terrain is hand tailored to exact polygons. You can always just generate a random key and set parameters until you get something you like.

As for regeneration time, in my experience it's pretty fast, and by that I mean it can be a second or two. keep in mind that you only have to generate what you can see. If you are zoomed way out, you see the whole planet (or half really) but it's in low resolution. A single tri can be kilometers across. As you zoom in, of course you need more detail, however the closer you get, the less of the planet you can see, so you can render far less terrain.

If you put the effort in you don't need to store much on disk. You just need a good LOD system to make it all work. I don't use Unity myself so this may put more constraints on what you can do. But I've managed to get things working OK so I know it's doable. Right now my working planet is 8000 km diameter at about a half meter resolution. It maxes out at around 2 gig memory when running. However I'm using voxels, if you want to do height mapped terrain it will take far less memory.

And Last since the tiles are more or less flat How will I spawn tiles that are closer to poles and are curved? i.e. as you move across the planet the tiles spawning in front of you should be spawning in a spherical Order.

That's a tricky question. Ignoring Unity for a second you can subdivide a cube to the level you want it at, and push vertexes out to form a sphere. That gives you very roughly squarish tiles, but you will get a lot of distortion in places. I use an icosphere or rather a voxelized version of one. This gives you triangular chunks which is a bit harder to deal with, but you do get more even geometry.

If you want quadrilateral tiles,

Gnollrunner said:

And Last since the tiles are more or less flat How will I spawn tiles that are closer to poles and are curved? i.e. as you move across the planet the tiles spawning in front of you should be spawning in a spherical Order.

That's a tricky question. Ignoring Unity for a second you can subdivide a cube to the level you want it at, and push vertexes out to form a sphere. That gives you very roughly squarish tiles, but you will get a lot of distortion in places. I use an icosphere or rather a voxelized version of one. This gives you triangular chunks which is a bit harder to deal with, but you do get more even geometry.

If there is a strong need for quadrilaterals, instead of the triangles of an icosahedron, it is possible to use a rhombic triacontahedron (the shape of fairly common 30 faced dice).

On the other hand if triangles are not a problem it might be a good idea to reduce distortion even further with the 120 scalene faces of a disdyakis rhombic triacontahedron (same with each face replaced by a pyramid, the shape of the less common 120 faced dice).

Omae Wa Mou Shindeiru

This topic is closed to new replies.

Advertisement