Space Graphics Toolkit & Planets

What is the simplest way to invert the SgtTerrainPlanet Mesh layout so that it renders the interior of a sphere instead of the exterior?

I want to use it as a "shell", like a skybox with dynamic LOD.

I thought I could get away with simply swapping the .Inner and .Outer values of the indices job at lines 250-251 of SgtTerrainPlanet but this doesn't flip the quads, it messes up the whole mesh layout (and seems like a pretty hacky approach...)

 

Now that this is mentioned...
A Dyson Sphere (with doors / openings to space) would be one hell of a feature.
As well as broken Planets or with deep rifts...

(Not actually requesting this...)

 

@nighty2 to answer my own question: you can flip the orientation of the SgtQuads to face into the sphere by simply assigning .CubeH to .CubeV and vice versa when setting up the quadJob (it seems like the quads are oriented by a crossproduct of these properties from looking at SgtTerrainTopology).

Useful for making the inside of a Dyson sphere you want to traverse perhaps...

 

Open SgtTerrain.cs and find the IndicesJob struct. You want to swap the 2nd and 3rd parts of this: Indices[index++] = a; Indices[index++] = c; Indices[index++] = b; and the second line: Indices[index++] = d; Indices[index++] = b; Indices[index++] = c;, so instead of acb, dbc, it goes abc, dcb. Though the colliders will also be backwards, and probably many other things will not work properly.

 

Instead of changing the Indices layout in the IndicesJob, I just reversed the orientation of the quads per my response to @nighty2. This keeps the mesh topologies unaffected so colliders can generate, and you only have to change out the calls to GetSpherePoint() to some other function ("GetInteriorSpherePoint()").

@Darkcoder one thought about the inheritance schema of SgtTerrain -> SgtTerrainPlanet: It seems to me that the ScheduleJob function and the various Jobs in SgtTerrainPlanet could be moved up to the parent class, since they're called by the list of cubes in the SgtTerrain instance (unless I'm missing something and theres a reason they have to be in the child class). Similarly, perhaps the List<SgtTerrainCube> cubes could be moved from SgtTerrain to SgtTerrainPlanet? As it is the SgtTerrain class sort of locks you into a very narrow set of topologies homeomorphic to a cube.

This would make it easier to create novel child class topologies inheriting from SgtTerrain and use it as a general dynamic LOD terrain generator (e.g. as a parent class for flat planes, toruses, etc).

 

Is it possible to use custom water prefabs for planets? Or is the package only compatible with its own water?

 

Hello everyone and in particular to the author of this beautiful asset. I have some questions related to optimization for VR (Oculus Quest 2). First general question is there any links or articles on optimization in general?
If its about details then how to optimize the light (for example how to bake light from any objects in this asset), how to optimize galaxies for example (they drop frames to zero), clouds of stars and backdrops (backdrops from the example work fine and do not drop frames at all, but backdrops from other examples where the stars are more clumpy drop frames twice or more) and so on.
Some objects (eg the example storm where the dark planet visible lightning) works fine in the editor without directional light and after I do build on Quest 2 the planet is not visible without directional light (at the same time it is visible behind the canvas with text for some reason). I basically only need images of some objects (Milky Way for example) because they will be at a great distance and you can't get close to them. Is it possible to make object imposters from this asset (when I make planet imposters with amlify impostors the imposter itself is invisible and when I try to make a galaxy imposter Milky Way for example or Nebula unity completely shuts down). Sorry for so many questions.

 

Good ideas. When I originally wrote this component it was all one class, but I later split it up and missed a few things.

I don't plan to extend this feature too much because there are some fundamental limitations with this implementation for larger planets that I'm not too happy with. Later this year I plan to experiment with an entirely new system that may work better.

You can use any material you like, because the terrain/water surface is a standard mesh. However, for realistic scale planets you will need to implement (yourself) the UV system the provided shaders use, because it's not possible to use standard UV techniques across such a large scale without artefacting from floating point precision.

The example demo scenes were all configured for desktop performance. To optimize them the main thing you need to do is reduce the overdraw/fillrate. For example, the 'dust clouds' in galaxies and such are achieved using lots of large billboards/stars which looks nice, but this is incredibly performance intensive, so you will want to reduce the amount of them, or their size. You can see the Overdraw in the Scene View render settings, where brighter is bad.

Imposters are a good idea, but it's my understanding they don't work too well for transparent objects? They are also not so useful for volumetric objects that the camera is inside, like a galaxy.

The best way to optimize this is to basically hand-craft the imposters, which of course takes a lot of time, but it will give you the best results. For example, I'm currently experimenting with background galaxy rendering, but rendering enough clouds in realtime to look impressive is impossible even on a high end desktop. To optimize this I'm rendering this ahead of time to a skybox, which is very quick to render, so you would want to look into something like this. Obviously a skybox won't look good in VR, so you would want to then augment it with foreground particles etc.

 

Hello one more time, after building on Quest 2 objects appear to be not illuminated (for example Aurora or Moon) while being illuminated in editor and in play mode. Also they look good behind the canvas with text (it's FPS asset) for some reason.
So for example when I load Moon from Solar System everything is black but when I add 3D cube I can see it. After switching clear flags from solid color to skybox I'm able to see background stars and main star in scene but Moon is black anyway.
UPD: So I made a Canvas with text and got it all over the camera view and now I can see everything but just a bit less brighter which I can fix with ajusting the light. And it only works with component on the screenshot I've made. Gonna keep digging tomorrow!

And some more screenshots
Thinking about leaving it as it is if I won't be able to find a true fix and if it's not gonna ruin the performance (well no idea how can canvas with text ruin performance anyway). Just will need to fix brightness.
Also changing shader to standard as it is on 3D objects like cube and sphere makes moon not black but moon becomes just a white 3D sphere.
Plus posting about some fixes I found for anyone else in need of them.
Background stars (also some other objects) invisibility fixes with simple switch of clear flags on camera to skybox and adding a black skybox.
Black holes only visible with multi-pass rendering mode (By the way, do you have any idea how to make the black hole distortion of space does not show my hands when I move them in front of camera because I have a character with hands).

UPD2: It works without text and everything only works with the image component. I reduced it to the size of VR Example (Canvas) game object by copying image component from UpperCenter to it (basicly all components and material from UpperCenter are now in VR Example).

 

Sorry for the late reply.

Which exact version of Unity and rendering pipeline are you using? I've noticed something like this before in HDRP when using extreme camera ranges, not exactly sure what causes it.

 

So that I can improve the performance, I want to make the objects spawn after 1 second. But I can't do it. I did it with waitforseconds, it worked, but after the objects were destroyed and spawned again, they simply spawned directly without waiting 1 second. How do I do that?

 

@Darkcoder They really need to fix the light falloff for Android builds, point lights are not the same on Android for some strange reason with URP. You would have to manually add the latest URP to the package manager, edit the script "RealtimeLights.hlsl" I have URP 12.1.6, on line 73, change the code to...

Code (CSharp):

1.  float lightAtten = rcp(pow(distanceSqr, .15));

with that youll have synced lighting across all builds, adjust the value for your game requirements...
Its been more than a few years. I'll create a bug report soon

 

What objects? With which settings? Did you look into the profiler to see which aspects of it are taking time?

Interesting change. Indeed, the way lighting changes between each pipeline is quite annoying and makes supporting all the pipelines incredibly difficult. I think most of the SGT scenes work more or less the same with per-pipeline light intensity values.

 

sry my english is bad, i mean i want to improve the performance, so that means i want that the sgt floating spawner shoult spawn the objects in 1 second but i dont know how to do that, i am trying but its not work

 

I see. There's no built-in feature to spawn objects with a delay. You would have to modify the SgtFloatingSpawner___ component code to do this, but it might be quite difficult. An alternative is to make the spawner spawn an empty prefab with a custom script that implements a delayed spawn. This would be much easier to implement, though it would have slightly more overhead, but maybe it wouldn't be an issue.

 

i dont know if i understand it

 

The spawner components usually spawn an object like a planet. In your scenario, you want to make it spawn an invisible prefab with a custom script on it. Your custom script would then spawn the actual object like a planet after some delay.

 

No problem. Unity 2021.2.16f1 Built-in.

 

Hi @Darkcoder. First, thank you for the whole toolkit, it's the absolute best!
I have one question: I've setup the solar system, dividing 1 UA by 1000 for distances while keeping the stellar bodies scale at 1, to make it more playable in my space sim. However, there's a visual issue with the Atmosphere and Cloudsphere of the Earth. Only their top half seems to be rendered. Halving the distance scale seems to fix the issue, but that's too small a scale for what I'm going for.

How could I fix this glitch?

 

I made a new Unity 2021.2.16f1 project, installed SGT 4.0.6 + Solar System Pack, installed oculus XR, opened the Moon scene, deleted the SgtCameraMove/Look components, converted the MainCamera into an XR Rig, ran it on my Quest 2, and the moon renders as expected:



The only issue I notice with this scene is the Moon material has no normal map, and apparently this causes the lighting direction to be incorrect in the editor. If I set the Normal Strength to 0 then it renders correctly. On the device it appears correct either way though.

Can you attach or send me a minimal demo scene using only the SGT media so I can replicate this on my end?

 

Thanks for reply and checking out my problem. I fixed it! Turned on HDR, copied camera and lightining settings from Aurora.
Also fixed black holes. They only work in MultiPass. But still dont get how to make hands (I have full body riged model) not to show up in black hole warp when I move them between the camera and the black hole.
And another thing is that on Earth Sized Planet, Venus, Earth and some other demo scenes objects on there surface have a huge number of rapidly disappearing and appearing triangles and the surface itself is not visible at all. There were other problems, but they were all fixed by performing the actions described above.

 

Glad you found a solution!

The camera settings are probably the most important change. I don't think HDR would change any of the features you describe, and the only lighting change I make to the demo scenes is to remove ambient lighting to make the dark side of planets darker.

I'll add single pass VR to my list of things to check.

 

Hi @Darkcoder. Actually, increasing the scale somehow fixed the issue, which works perfectly for me!

 

Hi @Darkcoder I am developing for VR and would like to know if there is an easy way to disable the tracking of effects on the camera? I saw your answer for 2017 before. But I don't know much about shaders.

 

Can you explain what you mean by "tracking of effects on the camera"?

 

@Darkcoder I'm talking about billboarding in view space. When you move your head while wearing a helmet, the effects move with it I hope I explained correctly

 

Hi @Darkcoder I found that in 2017 you started explaining how to do it here: https://forum.unity.com/threads/space-graphics-toolkit-planets.147954/page-34#post-3115886

 

Ah I see. I'll add this to the next version.

 

I drag and drop the Belt Model to Shared Material, but its not working. How do i fix it?

 

Hello,
I'm using the latest SGT Version and I got into some issues. I have a planet in my scene with rings. The planet has the 'Jovian' material attached to it. The glitch is not visible in the Unity Editor GameView, it's only visible on build on my Android device. The planet rings and the skybox are visible through the planet. It's like if the rendering queue is changed or something. Same problem with the original 'Jovian' Scene. I tested it on my 'Motorola Moto Edge 20' and the 'Samsung Galaxy A71', on both is the glitch. When it's build on Windows it's not visible and how it should be. I even tested with multiple Unity Versions.

Does anyone knows a solution for that?

 

The belt material uses a special shader that moves the vertices in an orbit. The Shared Material feature only works with normal shaders that don't modify the vertex positions. Additionally, the Shared Material feature only works with opaque materials, and the belt is cutout so it wouldn't work either way.

I can't replicate this on my Pixel 6 or Galaxy S6. This looks similar to an issue on the Quest 2 that I can replicate though, so perhaps it's the same issue. I plan to look into this later in the week.

 

Trying to use the same planet on quest 2
Getting the same issue
Kindly provide a solution for this

 

Good, I have seen this asset, and I really liked how dynamic it is to create planets, and everything necessary for a space game. But my question is the following.
1.- The planets can be put collider as terrain? What do I mean? To be able to objects, like bases, "EBS" for example? Or walk on the surface of the planet.
I am interested in having few planets, I see that it has LODs, to optimize, but what interests me most is being able to give life to the planets, with vehicles, walking, creating bases, 3D objects such as "houses, buildings, roads, etc" really This is my only doubt to know if the asset complies with this... Taking into account that creating "usable" terrain in a spherical way like the planet is what I see as difficult.

 

I feel like the sales of this asset will increase with starfield coming up ...

 

Hey Carlos

Just wondering if there is any way to clamp the minimum height of the terrain in order to achieve something more like the second image.

Cheers
Matt

 

Darkcoder Hi! I looked at the plugin you sent me Unfortunately, it does not solve the problem. I recorded a video where you can see that the effect repeats the turns behind the camera and tilts. That is, when you turn the camera and move its effects should not move at all
https://drive.google.com/file/d/1Skd1ylQ-EvLEJdXrWnwKY_B2R6Lz3Xdt/view?usp=sharing

 

I believe I've fixed this issue. A new version will be coming out shortly!

Yes, you can add colliders to planets. Populating the surface with objects to make it look interesting is difficult and that's up to you

Hopefully! Unless it bombs... but then maybe that would be good for me too, hmm.

Looks great!

In the next version I will add the SgtTerrainClamp component, which should allow you to do this!

I'll look into it!

 

Oh awesome cheers for that.

One other thing sorry. Say I have a planet and the camera on the player is the primary observer that all the planets colliders are generated around. If I have an object on the other side of the planet and need to get the terrain height at that position is there any way to do this? Sorry if I haven't explained clearly. Let me know and I'll make a diagram of what I mean.

I guess is there any way to get the height of terrain near position without using the colliders?

Cheers

 

The SgtTerrainPlanet component has the GetWorldPoint method and which can give you the terrain height under the specified world space point. This is how the SgtTerrainObject component works.

 

Hey everyone,

Version 4.0.7 of Space Graphics Toolkit is now out!

• Fixed issue where terrain areas set to Everywhere wouldn't work.
• Fixed issue where the dark side of jovians could become transparent.
• Added Align To setting to Starfield shader.
• Added Align To setting to StarfieldInfinite shader.
• Added SgtTerrainClamp component to Terrain feature.
• Terrain height modifier components are now executed in component order.
• Jovians no longer cast shadows on themselves.

Enjoy

 

@Darkcoder
great, what I do see is a lack of tutorials, right? I would add gravity to the terrain of the planet, but making "flat" terrain to be able to put bases and things like cities, or things like that, is difficult if the terrain is all generated in a mountainous way... I was seeing that they are generated very high , sometimes having the option that the terrain is not mountainous would be more ideal to give life to said planet.
Do you have any option to generate planets with the "ground" or "floor" areas being flatter? in order to give it more life.

 

Now it's working on the planet with the new update

the rings are still transparent, but I guess in real life it's similar on those kind of planets with rings.

 

You can use the 'areas' feature of terrains so the procedural noise is only applied to specific areas where you don't want mountains.

The new SgtTerrainClamp component can also be used to make areas above/below a specific height flat.

Oh right. I'll apply the same fix to the rings in the next version!

 

Ah I'm an idiot haha. Thought I checked that component but I must have missed it.

Code (CSharp):

1. Vector3 sampledPoint = terrainPlanet.GetWorldPoint(transform.position);
2. float height = Vector3.Distance(transform.position, sampledPoint);

That is exactly what was needed.
Cheers

 

Hey Carlos

Sorry I have another unrelated issue. I can't seem to get a new 2021.3.4f1 build to work. If I create a new URP empty project and import SGT then add the Earth Sized Planet scene into the build settings I get this error when I try and build.

Scene runs fine in the editor but just seems to fail on build. Any idea on what I can do for that?

Cheers

 

Hey folks,

First of all, thank you so much for this asset! It rocks the proverbial casba!

I am having an issue with the WarpTo functionality. I have a planet ~1AU from my ship and in code am doing:

Code (CSharp):

1. float timeToWarp = (float)(SgtPosition.Distance(floatingCamera.Position, targetPos) / warpSpeed);
2. warper.WarpTime = timeToWarp;
3. warper.WarpTo(targetPos, targetDistance);

Where warper is an instance of SgtFloatingWarpSmoothstep, warpSpeed is a very large number, and targetDistance is a calculated offset so I don't just crash into things.

It takes off just fine and seems to be working but diverges from the target point and ends up about 2 million km away from it when it stops instead of actually going to it. If it matters, the target in this case is a planet with an SgtFloatingOrbit attached around a star.

What I'm trying to figure out is why the ship isn't warping to the actual location that I care about, and instead is warping off to its side? Has anyone had a similar issue, or is there some intricacy of the warping mechanics that I'm not seeing in the code/docs that would help explain requirements I might be missing?

 

Thanks for pointing this out. I've found the issue and I'll release an update very soon!

What is targetPos? Keep in mind the warp position and distance must be doubles, and at no point during their calculation can you dip into single precision floats or you will lose precision which will make any realistic scale warps impossible. For example, you cannot use Transform.position data at all in the calculation.

 

yeah, sorry. I simplified the code a bit so that I didn't have to copy-paste a ton of context. targetPos is warpTarget.GetComponent<SgtFloatingPoint>().Position), where warpTarget is a regular GameObject

 

Can you prepare a really simple script and demo scene that I can run to replicate the issue?

 

I'm working on that now. I created a really simple scene that doesn't have any of my extra stuff in it and the warping is working as intended. None of my other code even has references to the transform properties of any of the involved game objects, so It's very confusing. But I'll start adding in my other systems one by one until I find the culprit.