Space Graphics Toolkit & Planets

Last I checked the basics were working again now. The problem I have is I need to generate dynamically thousands of planets and I don't see any way to do that, other than with procedural textures. There used to be some assets that did this but none of them (or at least none of the ones I have) work anymore, and SGT itself doesn't *appear* to offer this feature though maybe I'm missing something.

 

Interesting, Earth is so ridiculously big that just two textures won't cut it though, and using the same UV data for macro and micro details won't work. Perhaps there's some way I can cleverly pack this into the mesh data and have it seamlessly transition without using too many samples, I'll have to experiment more!

Hopefully this year.

I considered using render textures to generate the terrain data, as it does have some good advantages. It also has some big disadvantages though, like it's very expensive to transfer data back for collider generation (must be done on main thread). There may also be floating precision issues, as I believe double floats aren't supported on older shader models.

Indeed, SGT doesn't. This is because generating good looking planet textures requires tons of work (e.g. Grand Designer), and I don't think that time investment would increase sales enough to justify it.



Also, here are some new pictures of the terrain stuff:









This is travelling down to the surface of an Earth sized procedural planet, with a simple height & slope based texturing shader (this will be improved a lot soon). I've now implemented LOD seam stitching, optimized the mesh batching a bit, and implemented pooling. In the last picture near the surface there are around 6 million triangles in view.

It currently takes around 20 seconds to fully generate this geometry when spawning on the surface, but this is mostly held back by my slow quadtree traversal code. With some better code and a few more optimizations maybe I can get to below half this. We'll see

 

This has the same problem I've seen in a bunch of similar products: from far away, the terrain looks barren, but when you get up close you see vegetation. That... just isn't right.

When you're in an airplane looking down at an area with lots of plant life growing, you can easily tell from the color that it's not just a bunch of barren rock. You can't make out the details until you get closer, sure, but you can clearly see that vegetation exists. I'm not sure why so many LOD systems get this wrong.

 

This is just one layer of textures tiled a million times or something. This means from any kind of big distance each texture will appear to be a flat texture. As I said, I have plans to improve this shader a lot

 

I watch the unite talk about porting a zombie swarm to dots .... that was quite a technical punchline! Are you planning to take advantage of burst compiling? I don't remember if it was in this thread I see mention of using ecs.

 

Yes, this terrain generation uses burst and jobs, not ECS though.

 

Hello everyone,
I've done as much as I can to extend the sgt shader and terrain so I'm sharing them here. SGT terrain will now take four height maps (red, green, blue and alpha channels) and the shader uses four mask maps in the same way.
To make the main mask map and albedo I use either Wilbur or Planet Texture Generator (both free). You can create height maps in Wilbur or import them. You can then colour the height map by height/slope/relative elavation etc. (under Texture > shader setup). You'll want to use red, green, blue and black (for the alpha channel).
You can do the same with the biome height maps, so any height map you create or find online can have a mask map created easily.
To use the alpha channel for the fourth biome I used Gimp (free photoshop equivalent). It has a colour to alpha function where I transfered all non-black colours to the alpha channel. This makes the alpha channel white where the black is on your texture. This then becomes my featureless biome which breaks up the other biomes.
To avoid obvious tiling from high above the surface, you can use the fade out mip-maps slider on the texture import settings.
There are three detail maps that read the r,g,b channels of your biome masks, you'll want to fade their mip-maps too.

The normal maps are currently displaying as if the sun were at a right angle and from some angles the terrain looks metallic or washed out. I don't know how to fix these issues I'm afraid.

Let me know if you have any problems.

 

Thanks a lot, you are awesome.

While constantly looking for some tools to create the most painful thing in making planets, creating height maps, I found a new software for it. Most of you will know them and I already have them on my computer. It is one of the most beautiful space simulation ever, Space Engine. Space Engine has a planet editor and you can export all maps for the planets including height maps. There is one downside, you must pay for it and the standart edition only allows you to export maps up to 2K. If you buy the pro version for €49 you can export high resolution maps. I'll test a little more with it and if Space Engine does what I expect, I will pay for the pro version and share my experience with Space Engine.

Here are a few screenshots of my quick test with low resolution height maps (2048x1024) of mercury.

 

Can you show what that looks like from roughly GEO distance?

 

Hi jwvanderbeck. What do you mean by GEO distance? Do you mean geo synchronous orbit?

 

Yes, GEO means Geosynchronous Equatorial Orbit, sorry for the slang Just curious how good the 2k textures look when viewed from higher orbit like this:

 

That looks awesome!

 

@Darkcoder how can I make planetary surfaces like this?

 

The SgtFloatingCamera system is driving me up the wall.

I'm trying to build something that uses 3D models, but largely keeps the action in a 2D plane. The camera is positioned overhead, at a Y value of 3000, looking straight down. If I could, I'd set the camera to orthographic, but for whatever reason, that completely screws up SgtBackdrop. (Try it, you'll see.)

I want planets to orbit with SgtFloatingOrbit. This is intrinsically tied to the SgtFloatingCamera, and unfortunately SgtFloatingCamera also has the SnapDistance property and no way to turn it off.

No matter what I do, I can't get snapping to work correctly without also turning on Use Origin. Depending on what I try, it glitches out in all sorts of different ways. So I put SgtFloatingOrigin on the player, turn on Use Origin for the camera, and set up all the distances correctly. So far so good.

Except now I can't have the camera follow the player by parenting it. That no longer works. So I have to set up SgtFollow on the camera. SgtFollow lags, because of dampening. I don't want lag; I want the camera to behave as if it's parented to the player. Searching through the code reveals the completely undocumented fact that the lag can be disabled by setting the Dampening property to a negative number. So I can get that to work... right up until I hit the snap distance. Then everything completely falls apart.

The camera "snaps" to (0, 0, 0), which is not where it's supposed to be. The camera's Y position is supposed to always be 3000. And even worse, it doesn't take the player with it. A bit of checking shows that this is because the Player object doesn't have a SgtFloatingObject component. And here's where I get stuck.

No matter what I do, I can't find any way to put a SgtFloatingObject component on the Player object and maintain the scene's proper coordinates. Doing so immediately snaps the camera to (0, 0, 0), the same location as the Player object. That shouldn't be possible, as the settings on the SgtFollow specify that it's supposed to remain at (0, 3000, 0) relative to the Player component's position, but it happens. Any attempts to correct this are futile; changing the Y on one of the two causes the other one to change at the same time.

Snapping appears to be thoroughly broken, and there's no way to disable it and no way to customize its behavior.

What I need:

• Designating the Player object as the Origin with a SgtFloatingOrigin component means that it, not the camera, is the authoritative center of the coordinate system. The camera is slaved to its movements with a SgtFollow component. Therefore, it seems intuitively obvious that snapping should relocate the Origin object, not the camera, to (0, 0, 0), and the camera should maintain its assigned distance.
• Given that the Player only moves in the XZ plane and maintains a constant Y:0 position, the camera should therefore always remain at Y: 3000, no matter what.
• If the SgtFollow component says the camera's Local Position is (0, 3000, 0), it should not be possible to get into a state where the Position of the camera and the Position of the Player that it's following are the same.
• If the Snap Distance of the camera is set to 10000, it should not be possible for it to snap at a position of (0, 3000, 0). But it is. Attempting to trace how this is happening in the debugger has proven futile so far; there's some "spooky action at a distance" going on, moving the Transform around in some place I haven't managed to track down yet.

I'm incredibly frustrated by this system. What I'm describing really should be simple and straightforward, but instead it doesn't appear to even be possible at all!

 

Any chance on supporting URP? Right now this is completely breaking my project

 

Still trying to track this down. Ran into one issue that I ought to report as a bug here:

SgtFloatingOrbit.UpdateOrbit

calls

cachedPoint.PositionChanged()

unconditionally, even when no position change has occurred.

Fixed version:

Code (CSharp):

1.         public void UpdateOrbit()
2.         {
3.             var oldPos = cachedPoint.Position;
4.  
5.             cachedPoint.Position = CalculatePosition(ParentPoint, Radius, Angle, Tilt, Oblateness);
6.             if (!SgtPosition.Equal(ref cachedPoint.Position, ref oldPos))
7.             {
8.                 cachedPoint.PositionChanged();
9.             }
10.  
11.             if (SgtHelper.Enabled(Visual) == true)
12.             {
13.                 Visual.Draw(this);
14.             }
15.         }
16.  

 

Oops, missed the notifications again

This is in Space Engine?

Sorry for the issues!

You're right about SgtFollow, I completely forgot to document it.

If you want to use SgtFloatingOrbit without using SgtFloatingPoint/Origin, then you can use SgtSimpleOrbit instead,which is the non-origin shifting system version of the same code.

The reason why you can't just parent the SgtFloatingCamera + Origin to another object is because this component detects any Transform movements you perform on it, and adds them to the origin (allows for simple use with Rigidbody/SgtCameraMove/etc). This means when the parent object snaps, the camera has now 'moved', and this movement gets added to the origin, and so on forever. This could probably be fixed by checking if there is a parent SgtFloatingObject and calculating the relative change though. Another issue is that many people like to parent to create a simple orbit system with crazy Z offset values, which introduces incredible positional precision issues, almost defeating the purpose of using a origin shifting system.

I'll see if I can make these changes and get a test scenario working like you describe.

The next version includes better SRP support, there are still some features like SgtBillboard and the Planet shader that don't work though.

Thanks, I've added a new SetPosition method that performs this check, and included it in SgtFloatingOrbit.

 

Yes, this is in Space Engine.

 

I think a walkthough tutorial is needed for the best practise usage of the floating object system. I found it really difficult to author the scene with it. Besides I still haven't found the solution for rendering objects that are really far away from camera or for objects that are really big(which is very common in space games), both situation will have precision problem which lead to graphic error, like planet's texture is rendered incorrectly if the scale of it is really big and placed far away. I mean, I'm not making the observable universe, I found it already difficult enough to author a scene with the size of the solar system, even scaled down 1000 times

 

In this picture the terrain itself doesn't have any complex textures, it's just the terrain heights that are impressive. This means with the right blend of fractals it can already be done with the new terrain stuff. Right now I've only experimented with very simple simplex noise, but with some more experiments perhaps I could get something closer!

If you let me know the scenario you're trying to set up then I can try making it on my end and see if any changes need to be made. I made the origin shifting system quite a while ago and almost no one has provided feedback on it, so I don't really know which parts are difficult or need changes. The example scenes you see in the package are of some common scenarios needed in the example scenes and of things I think users would need, but beyond that I can only guess. Any feedback is appreciated!

 

That would be awesome. As far as I know Space Engine is using fractal noise for procedural planets.

 

Well, if you use LibNoise, you can check http://libnoise.sourceforge.net/examples/complexplanet/index.html
It gives you an example of what you can achieve in a single texture just mixing differents noises properly, from that you can get a niche heightmap output to get those results. The texture will be procedural, the only problem is to use modifiers and all that to get the output you want

EDIT: https://github.com/ricardojmendez/LibNoise.Unity also here you have imported into C#, so from that you have a good starting point into generating it, RigedMultifractal, Perlin, Billow, etc
Also, in the libnoise page you have the needed tutorials to mix it, or whatever you may need, from that you can just keep adding stuff and customize it your way

 

I was only using the graphic features of SGT and so far so good, everything works like expected and perfectly. I'm now planning to make the gameplay part(sandbox like), which requires relative realistic scaled universe, so I tried to use the floating object system, otherwise it's not possible.

The problem I'm currently having is how to author the scene manually, the demo scene provided by SGT is good for procedural generated galaxy, but not so good if I have to place the planets, moon, astroids manually. I'm having difficulty alone with navigating in the editor at all, and have no idea how to set the high precision transform component in editor correctly(I could calculate all the coordinates in code, but it's very difficult to add details, like some wrecks or debris fields floating around some moon or planet for exploration, if I want to control the play experience. It's really difficult to provide fine tuned experience with procedurally generated contents )

Another problem I'm having is graphic issue of large planets, if I set the scale of it above 10000, I'll have various problem with rendering(looks like heavy z fighting problem, the problem will also occure with the the planets in alien planet pack of SGT, the yellow colored one appears pure yellow, missing textures. If I scaled the planet down, everything get solved)
The main reason for this problem is still the floating number precision, snaping camera back doesn't solve the problem if the objects are really far away, and are so large as a celestrial object which can still be seen with such distance
​

 

SGT can give you a floating origin but that isn't going to magically solve all your problems especially not in the editor. You simply can't lay out a real scale solar system in the Unity editor as the precision isn't there. That's why the floating origin exists in the first place. Objects need to be moved closer to you. After about 10,000 units you start losing (IIRC) centimeter precision, and after 100,000 you start losing meter precision.

Floating origin systems work by essentially keeping the player at 0,0,0 and moving the objects in the world around at runtime. In editor mode though you just can't place things in the editor with precision out past a certain distance.

And even using a floating origin at runtime, you need to be clever with how to handle stuff really far away but still visible the player, either by using perspective tricks (move the object closer but shrink it down) or converting between rendered objects and skybox beyond a certain distance.

 

Without a doubt, this is the best asset of procedural planets. For now I have used the basic version, but I will certainly buy it, but first, I would like to know a few things, because that will depend on whether I can use the asset or I will have to think about another alternative

Sorry if there are many questions but I really want to be sure before buying this asset.

1. When I put, for example, a house on the surface of the planet, how does light behave inside? Light from both the sun and that caused by a lamp (point light)
2. Does GI work?
3. How do static objects interact on a planet orbiting the star? Or all objects must be dynamic regardless of whether they are houses?
4. What will be the correct way to make cities, trees and other objects that would be static? Should they be exclusively procedural? Will these features be implemented in the future?

5. Have you seen this project?

https://github.com/Shmaug/UnityPlanets

I find it interesting and maybe, just maybe ... Could you give yourself some ideas about the things I mention. Among the scripts there are some lighting oriented ones such as the Fake_GI.cs, or the creation of trees, grass and clouds. I haven't had the time to try it, but I really hope it's helpful for you.

My intention is to create some areas of the planet with "imposters", to improve performance and to have more control over the design of certain sections of the planet. Not only would I like to do something random, I want to make landscapes that are pleasant to see. Regardless I have to put each tree and stone one at time. Although maybe I can help me with some asset like gameobject brush or area spawner
For that reason, I am concerned that this incredible asset does not allow me to create my whim and although for now it is not possible, knowing that it may be possible in the future, that would help me not to have to use a simple and boring Unity terrain, or worse, another no mans sky, huge planets with nothing interesting.

I don't ask about clouds and water, because I see that it is something you are currently working on, so I can only wish you success.

And speaking of clouds, I found this:

https://cescg.org/cescg_submission/real-time-rendering-of-procedurally-generated-planets/

About the sea, this:

Read the description.

 

Yeah, I know it won't solve all problem, that's why I'm seeking for best practise suggestion rather than expecting solving the problem by magic, the I also thought of the perspective trick you suggested, didn't try it though, it just become very tricky if the object isn't static and is orbiting another object which is even further away.
I'm thinking if there's some method or workflow to make the authoring manually partial practical, like warping to a planet first and then place the object near that planet

 

Hi liiir1985, that is a problem with Unity and I think every other game engine out there. They are not made to edit extremly large scenes. To edit a solar system in Unity is a pain in the ass. The only thing you can do is to place everything in your code and edit separately. That is what I do.

 

Hey everyone,

Version 3.6.7 of SGT is out!

This version mainly focuses on SRP improvements. While full SRP support isn't there yet, many of the important features like SgtStarfield, SgtAtmosphere, SgtProminence, SgtBackdrop, SgtJovian should work. SgtSingularity, SgtBillboard, and specific settings of some other features may not be working yet though. I had to change the way cameras are handled internally, so before I change too much code I want to make sure this doesn't break anything for existing users. Let me know if you encounter any issues!

I'm using the new Unity.Mathematics noise, because it has very good performance when compiled with burst. I tried compiling some other noise code with burst but it wasn't even close in performance, not to mention I'd rather not use a non-Unity third party library.

To position objects with high precision you just need to add the SgtFloatingObject and SgtFloatingPoint components. You can then set the LocalX/Y/Z positions to where you want the object in your universe in meters. This can be tedious for large scenes, and doing it by code can simplify things a lot, but I'm not sure how else it can be done. You can still adjust positions in the Scene view, but obviously this window wasn't really designed for galactic scale positioning.

As for planets and other large objects, the mesh size is indeed an issue that can't be solved with objects like this. To render correctly the mesh origin must be within a reasonable distance of the visible vertices, so special meshes must be used. The new terrain stuff I'm working on shows that this is possible with some tweaking. If you look at the screenshots I posted earlier, this is a planet with the same radius as Earth, and using the current origin shifting system without modification it's possible to render the planet at ground level without visual issues. For large planets you will have to use a system like this.

1 - It behaves as you expect, as the terrain can use any standard material, and the sun uses a standard light.

2 - Baked GI won't work, because the terrain is procedurally generated and changes based on camera movement. If you use a static mesh instead of the dynamic LOD terrain then it should though.

3 - If your planet is moving then it obviously won't work with static objects. I don't recommend you move the planet though, as it will probably cause issues with the physics. SGT comes with 2 types of orbit systems (Newtonian and fixed orbits), in the examples these are used to show large scale orbits from a distance, they're not designed for moving planets and still having tiny objects on the surface.

4 - You must place these manually. I will improve the procedural spawning features, but I'm not going to implement any kind of procedural city generation system.

5 - Never seen either of those projects. In any case, I plan to make a system with much higher visual fidelity than these.

 

Thanks for the reply, and I think I'll live with placing objects with code, and I think I'm gonna to make some tools to make the life easier for me.

Oh, btw, is it possible to make the editor camera in scene view to snap? maybe It'll some how make it possible to place objects in editor. Currently the main camera object will snap in scene view, which actually doesn't make much sense.

 

Slightly silly question, especially considering the push was SRP changes, but did the Star shader get any substantive changes? I ask because I am using a modified version of it that lets me assign properties per render instance rather than having to spawn additional materials. I basically added [PerRenderData] to a bunch of the properties.

 

The origin shifting system can only snap around one camera (per render scale). Snapping to multiple cameras like the editor camera too would mean every object in the scene would have to constantly change position before rendering, which would result in terrible performance.

I didn't change this. As far as I know it should already work with SRP since it doesn't access any renderer specific data.

 

Yeah, but I think it doesn't make sense to snap main camera in edit mode, so it's possible to only snap the scene view camera. While in play mode, of course only main camera should be snaped

 

Alright, I could add this as a setting I guess. I've added it to the to-do list!

 

Hi Darkcoder,

can you tell me how to use specular maps in the planet shader. I can't find a way to do that. Seems there is some hidden stuff going on.

 

There is no specular map, but the PBR smoothness can be stored in the alpha channel of the albedo. I experimented with allowing full metallic and occlusion maps, but in my testing the visual result wasn't really worth the extra authoring difficulty and memory requirements. The smoothness map with adjustable fixed metallic seemed like the best compromise.

 

I want to extend the shader with spec maps but you are using the standart surface shader lighting which has no gloss and specular. I am searching for a way to use another lighting model with no success. Is it possible?

 

I am currently doing some extreme planet shader extensions to see what I can get out of it. Performance is not my focus but the game runs at 60 FPS when I fly around the planet. I could extend the shader with a color map to define which texture is visible using the rgb channels including texture strenth, texture tiling and normal maps for each texture. Normal maps and textures are fading in and out by camera distance from the surface. That gives me control over which textures are visible from space. I am using a mercury height map with only six LOD levels. If I use more LOD level everything will be rounded off and I loose the sharp edges of the craters and mountains.

Here are some screenshots of my results. I am still impressed what you can get out of this asset. Can't wait to get my hands on the new asset.

 

The lighting model is defined at the top of the shader code:

#pragma surface surf Standard2 fullforwardshadows vertex:vert

This is modified standard lighting, with night lights. It's defined later in the code in the LightingStandard2 and LightingStandard2_GI functions. You can read more about lighting models HERE.

While you could change to a classic specular setup, I think PBR does basically everything it can do, but looks much better. The PBR smoothness is basically the specular highlight size, as you can see HERE.

Incredible! Looking better every time!

I have a few other tasks to finish before getting back to the terrain. Right now the terrain heights are hard-coded, and there are some hard to track down scenarios where the terrain data appears to get messed up. Once I improve on these I'll send everyone builds

 

Thanks alot! That'll save me a lot of time

 

Arrrrrg, yeah I can use smoothness maps, thanks. Sometimes ....

Thanks, it it so much fun to improve the planet visuals that I forget to code the game!

New asset:
That is awesome. Take the time you need.

 

Hey @Darkcoder

I'm having a bit of trouble with SgtBackdrop, not sure if I have set up something wrong but the stars seem to be visible through the planet, I've been scratching my head all day with this , Would you have any idea's what's causing this?

 

Hi, try to increase the near clip plane of the camera. I had the same problem.

 

You can adjust the Transform.Scale of your backdrop, so it goes behind your planet. You could also adjust the SgtBackdrop.Radius, but then you will have to adjust your Star Radius settings to compensate. If you scale it up too much then you'll have to increase the Camera.ClippingPlanes.Far to compensate. For example, if this far value is say 10000, and your SgtBackdrop.Radius is 1000, then your Transform.Scale should be at most 10 on each axis to prevent the stars from clipping outside of the camera range.

 

Does anyone know where i can get high-res cloud cube maps.

 

I think this should have up to 16k cloud maps:
Super Earth
dont have it yet as Im hoping to get Fog Volume to work instead, but if you do get it before I can or can't get FV to do what I want, please do report back.

 

You can get good ones HERE.

 

Thanks for the quick replies big help! Scaling up the transform did the trick

 

Thanks, but the asset is a little bit expensive just for cloud maps.

 

Thanks. I have the problem that Unity crashes every time I want to define a cloud texture as a cube map. Do you have any idea what I can do?