Jump to content

Science of the Spheres - development


NovaSilisko

Recommended Posts

Did lots of stuff for the terrain generator recently. Works in chunks and is very fast to generate right now while allowing very high detail up close. It's very apparent when the level of detail changes though, mainly because the terrain shaders are based off of vertex colors to control distribution of textures. So when the resolution changes, those vertex colors are less and less fine, making it very quickly degrade.

The solution there, then, is to eventually make a texture map, low resolution, to map onto the planet, and use that to control the texture distribution instead. This means the textures will look the same no matter what resolution the mesh has. That will come later.

Generation can get a little bit stuttery right now if you move fast and especially so on large planets with lots of chunks, mainly due to the number of times the generator needs to sample the noise map (both to offset the mesh and to calculate the normals), but this will get much better (possibly removing the stutter entirely) when the mesh processing is made to be multithreaded.

For collisions, the current notion is to first run a check of the planet against available rigid bodies at a low rate (say once per second), then another check (at a slightly higher rate, say 10 per second, or even base the rate on how fast the object is going) among those for which bodies are close to which chunks. The ones that are close enough will have collision meshes produced near them at a fixed resolution, and then have it deleted when the object is gone. Ideally it's smart enough to know which chunks have generated their collision meshes, so it doesn't keep erasing and deleting it every time, which would slow things down a lot.

Edited by NovaSilisko
Link to comment
Share on other sites

Z0fLCQU.jpg

rfJpsXe.jpg

 

Just screwing around flying around the terrain generator test scene at this point. I am... pleased with the results. Still kinks to work out though, the transitions between different levels of detail on the terrain chunks are fairly obvious, mainly because the method to choose which is needed is fairly crude. A curve will do a better job.

Edited by NovaSilisko
Link to comment
Share on other sites

6 minutes ago, NovaSilisko said:

I should probably restart this thread sometime soon... and the blog. Most of the information in the first post here and on the blog is already out of date for the third time.

That would probably be for the best. Good luck with further development!

Link to comment
Share on other sites

Another random one. Just flying around the terrain generator scene seeing how it reacts. There's still the issue of moving so fast the collision system can't actually keep up, but there will be some working values somewhere, just have to find them...

TjG6PlX.jpg

 

Currently each chunk can have up to 64 subdivisions - this comes out to a total of around 8700 triangles for a chunk at full resolution. You can go up as far as 128 subdivisions (which is kind of crazy), which yields I think something like 32,000 triangles, which is fine for a relatively recent GPU. Beyond 128 and you smash facefirst into mesh vertex limits.

The problem is generating that much mesh data. 32 is about as high as you can go right now before you start getting stuttering, and 128 is basically unusable with how slow it can get. But that's with all of the generation on the same processor thread. The mesh generation will sooner or later be made multithreaded, which should make 64 subdivisions be quick enough as to be almost unnoticeable, and maybe even 128 will be smooth to generate as well. The maximum will be a game setting, going through Low (16 subdivisions), Normal (32), High (64), and Ludicrous (128).

The collision, meanwhile, happens only when you go near to a chunk, to keep the number of active meshes (which are expensive to process) down to a minimum. The same mesh generator is used for the visual and collision meshes, the collision is just generated at a fixed number of subdivisions, currently 32. That may be a game setting as well.

Link to comment
Share on other sites

Not really anything important for the end user, but I made a simple GUI to help build planets for testing (and for the pre-made demo solar system) which makes it far easier to do, and uses the same underlying system that will eventually be used to handle procedurally-added noise generators.

Random pictures, as the results have been rather photogenic so far (need a rock texture that looks less like tin foil though)

NaQlEzl.jpgiblZzAH.jpg

 

A wide shot. At some point need to make a cubemap generator to control texture blending, to allow more surface variation...

eJLjyCx.jpg

 

And another planet, the same setup again but with different settings:

tMSCxED.jpg

nC11vQO.jpg

lySQZMk.jpg

 

Note the brightness varies between images sometimes due to 1) me changing the material settings and 2) me changing the exposure settings on the lander's camera.

Edited by NovaSilisko
Link to comment
Share on other sites

Soo I'm not averse to questions being asked. In fact I think I do better at explaining how things work when I'm asked questions, so ask away. I think I'm going to start working on the terrain scatter system next. That will be split into two parts - small things which exist in the thousands and are spawned only when you get near (and deleted when you leave), up to meter-sized or so, and larger things like big boulders and spires and trees and monoliths, etc.

Link to comment
Share on other sites

Wow....those screenshots and gifs look amazing. Honestly some of them could be mistaken for a picture of pol! :D 

 

Also, about texture change being obvious...ever flown near minmus? It jumps from blurry texture and subtle height map to defined height map and high res textures in one single jolt. :sticktongue: 

Link to comment
Share on other sites

1 hour ago, Bill Phil said:

Here's a question:

Could you include a miniature version of our solar system, perhaps hard coded, but randomly placed?

I'd like to have a few premade solar systems scattered around, the tricky part is figuring out how and where. I think it might be a case where if you've got certain coordinates in the portal device, it will take you to a galaxy and pick the special system as where to place the portal. Something like that. Ideally it will be moddable. That extends to planets themselves - I want to make each "species" of procedural planet (iceball, rocky worlds, dusty worlds, ocean worlds, with hefty variation amongst those) be its own script extending a subclass, with a specific range of conditions in which it can be spawned. This would be expandable by mods, to be able to inject new planet types into the generator. The same goes for special systems that contain  ██████████ or ████████, or planets with ████████████████ and so on. Such things would be addable as well.

Edited by NovaSilisko
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...