Space Graphics Toolkit & Planets

Rendering a planet from the surface requires a lot of GPU fill rate, because the terrain + ground atmosphere + sky atmosphere + camera background (+ stars?) take up the whole screen, not to mention updating the mesh of a whole planet takes up some CPU. For maximum performance it's best to use a normal terrain when on the planet surface, then you can use normal fog and replace the background with a sky material and cut the fill rate requirement in half.

 

This occurs in the Editor as well as the Quest. I'm on Unity 2021.3.3f1, built-in render pipeline.
My lights actually didn't have any CwLightIntensity components. They're point lights so no SgtLightPointer either, and TreatAsPoint was disabled as well.

But, as I haven't noticed any real performance drop with a far clipping plane set to 300000, I've kept it that way.
So, problem not "solved", but worked around I guess.

It just seems weird to me that the far clipping plane could have an impact on lights that are actually close by, but I have no idea how SGT works under the hood, that's way above my current skills.

Anyway, thanks for everything!
I'm sure I'll be back with another weird issue before long

 

I've noticed something like this in HDRP before, but never built-in. I don't see how the camera clipping range would make lights flicker though, hmm. I'll keep an eye out for it.

 

Hello! I have problems with TerrainPlanet beeing clipped at high distances and radius.
I checked the game camera, the range is set to very high.
It seems to cull only in game mode, not scene viewer.
More details sent via PM.



EDIT: found out it was due to a small NEAR clipping plane value (0.3) from the camera.... paradox.
it's still a bit weird... I have to put the NEAR Clipping plane distance to over 14 to make the terrain visible at great distances. This doesn't feel right, since I cannot zoom closer to my ship now anymore without them getting clipped.
Camera FOV horiz is at 90 degrees.

 

It appears clipping only applies to Planet and Planet Terrain. Ocean and atmosphere will be rendered in farer distances. Could it be in the (Terrain)Planet shader material?

Changing the near clipping value of the camera is definately a no go for our project. It will clip very small spaceships totally.

 

Another topic:
the TerrainOcean material shader is missing FadeBound parameters as on the Terrain material.
It won't let me define when the ocean detailing fades out on zoom out, you can only fade them on zoom in.

 

Back to the near clipping Problem. I tried Star shader today and here the problem is much worse.
I have to set near clipping to a huge value to be able to see the star at great distances....

 

After some browsing on this thread I found out the problem only occurs when using skyboxes.
My used shader is Mobile/Skybox. Other Skybox shader have same effect.
Changing render queue has absolutely no effect.
Is there another way than having a second camera rendering the skybox?

 

I sent you an updated build of the shaders that adds this.

I can't replicate this issue with these settings and shader, at least in 2020.3.0f1 BIRP. This is the Star demo scene with it 2.444e+07 units from the camera.

 

Hey everyone,

I made a fun little spaceship battle demo scene using Spaceships and Space Graphics Toolkit.

You can get a package of it HERE.

NOTE: This requires Spaceships and Space Graphics Toolkit to run, and I recommend you enable the Deferred Rendering path due to all the bullets and explosions using lights.

Enjoy

 

Your camera near clipping is set to 100. Try set it to 0.1 or 1. Then you will notice, if you have a skybox on that camera. Without skybox, it renders fine.

Thank you for the updated shader!

 

Would anyone have any idea on how to get the collider component to actually work? Tried everything I can think of and my test object just passes through the planet :-/

 

Also, is there a way to visualise the collider? Can't seem to get it to show up.

 

Hey @Darkcoder,

I've made over 350 objects with SGT's Starfields (Elliptical, Dome, Box, etc) in my app Galaxy Map (https://linktr.ee/galaxymap2). Objects such as nebulae, supernova remnants, clusters and galaxies. I've also included Starfield Multiply to help with the dark regions and it looks great.

Here are a few examples:


And here is a video of the Helix Nebula:
https://upload.wikimedia.org/wikipedia/commons/5/58/Helix_nebula.ogg

Not everything can be modelled to look exactly like in real life (and considering we only have images of these objects from one perspective) but the outcome is pretty close.

Thanks for making such a great tool,
Raydekk

 

Still renders fine for me, in Unity 2022.1.20f1 this time. This is in DX11 though, if you're running in OpenGL you may have different limits.

SgtPlanet or SgtTerrainPlanet? In either case, the colliders are MeshColliders, which show up in the Scene view, as long as you haven't disabled the MeshCollider gizmos.

Wow, incredible work! Must have taken so long. When I made this feature I had a go at making a few nebulae, but it was still quite difficult and time consuming so I only made a few.

Are you making some kind of galaxy viewer?

 

It's just an educational app that lets you rotate and zoom galactic objects. You can also fly a ship through them.

 

I believe I have the same issue @Darkcoder - and it still happens on the latest SGT.
This is with a 100000 radius planet on my mobile phone (on PC there is no issue):


Now, if I disable the gameobject with the SGT_TerrainOcean, the circles disappear. The circles change size if I move around the planet, like in Space-Frontier's post. So I guess it's an issue between SGT_Atmosphere, SGT_AtmosphereDepthTex and SGT_TerrainOcean maybe with this(?):


I can provide a test scene/project if you want in a private message.

 

The standard asset vehicles assume the Y axis is up/down, but on a planet this depends where you are. So you must first disable gravity, and use the SgtGravityReceiver instead, then probably rewrite the camera code. The "Terrestrial Planet" demo scene is already configured with colliders and gravity.

Which render pipeline? Do you get this issue with planets, or just planet terrains? Planets are much simpler so it's easier for me to test.

 

Standard pipeline
It's on the terrain system but as I said in the previous post, it has something to do with SGT_TerrainOcean because when I disable the TerrainOcean gameobject there is no issue anymore

 

hi, maybe daft question but is there any way to get access to any kind of renderer components from the sgt components? I am updating my prototype game which used all my own assets to use sgt ones, i have replaced my planets with SgtPlanets that get randomly generated in code. My targetting system caches the bounds from Renderer components and uses it to draw UI targetting recticules on selected objects etc, but GetComponentInChildren<Renderer>() on the SgtPlanet object always returns nothing - how should I approach this?

 

and i hate to double post but whilst im asking some questions im wondering if there is anything i can do to clip an infinite starfield or set a inside radius so if im generating space dust for moving around but i have a camera inside a cockpit of a ship i stop seeing star dust INSIDE the ship and only outside?

 

Darkcoder NOT only is this asset is incredible ! YOU are the best helpful dev EVER ,thank you so much !!!!!!!!!!!

 

Hi @Darkcoder ,
Is there a way to invert the direction of the gradient on SgtFloatingOrbitVisual ?
As of now it works best for clockwise revolutions, but the planets of the Solar System have a counter-clockwise revolution.
It would be great to be able to either choose to "flip" the gradient, or to have it based on the Degrees Per Second value of SgtFloatingOrbit (if it's a positive or negative value).
Not sure how much work that would involve though (or if it is already possible and I just didn't figure it out)

Cheers

 

I got strange planet atmosphere artifacts on mobile only, with huge planets.

It has to do with the camera near clipping plane. Variing the value changes the results.
Sadly a solution comes with other problems:
if I set the value too high, it might cull spaceships, that come too close to the camera.
my near clipping plane is at 1, my far is at 1e11

 

I fear it's a zBuffer precision issue. (Camera is using a DepthTexture.)
https://www.unity3dtips.com/zh/unity-z-fighting-solutions/
I tried setting near clipping plane to 10 which fixed the ring artifacts for mobile, but a value of 10 is bringing up gamedesign problems, as I won't be able to render small objects closer to the camera anymore.


@Darkcoder is there anything you can do to bring zBuffer values of Terrain and Atmosphere further away from each other?

 

Hi. I get a massive performance spikes in my build and by using the deep profiler, I have found an issue. It is this method "SGTcameraState.Find()"
I am using a lot of particle effects from your pack, but they dont contain many particles. I am using a high-end PC.

 

The shores seem way too big and can't be made smaller than 1, which result in hard edges instead of fade out.
@Darkcoder, is there a way to reduce the shore range for bigger planets?

 

Does your planet have any TerrainOcean? I noticed in one of my tests that the artifacts do not appear anymore if I don't use any TerrainOcean. But that's really a no-go for me, because I have water worlds, earthlike planets and lava worlds that need it.

 

Hi,

Just purchased this package and testing things out with the demos - I am running the Earth sized planet demo and noticed this strange artifacts when approaching the planet - I am using URP render pipeline and have not tweaked any settings yet- just running the demos to view what can be done etc. Any ideas why this is happening ? This is running on a Linux machine using the latest LTS 2021.3.21 version of unity.


excited to start playing around with these tools - feel like I just bought a new lego set


thanks in advacned,

Ren

 

@Darkcoder have a bug with using the black hole from the Singularity/Examples/06 Black Hole scene with the Universe feature.
If the object is really far away from the camera (1.1e+13 or more) the black hole isn't rendered anymore. At 1.1e+12 it works

 

@Darkcoder (hope you are well mate) - I managed to fix my targetting system myself with a custom implementation that uses the mesh.bounds and recalculates "real bounds" based on planet position and radius rather than using a renderer component with preset values

I have yet to come up with a way to get things drawing in the right order though. To recap:
- I have a phsyical player ship moving around my world with a camera inside the cockpit looking out (and player can free rotate to look out different windows etc)

- I have an SGT Backdrop component which i've replaced my old janky skybox with. Its great, but the ship moving about seemed to leave it behind. I wrote some code to position the SGT Backdrop at where my player ship is at all times but ignore ship rotation and it now looks correct EXCEPT these stars draw infront of SGT planets etc, i'm sure i'm doing this all wrong.

- I have an infinite starfield to provide the space-dust style effect when flying around and give the player a sense of how fast they are moving. I dont mind so much that it draws in front of planets also I guess it makes sense (and ultimately i should find a way to "fade" it out when the player slows) but also it doesnt seem to have a inner radius component so these space dust specks fly into my ship and are visible inside the cockpit. I am uncertain how to prevent this.

Any tips on the final two when you have time would be great! Thanks for all your hard work

 

Hi @Darkcoder,

I had the very same issue after importing SGT 4.1.3 and then SGP 4.1.1 on top of it. I expected that existing files are not overwritten, but obviously some were considered newer from SGP and hence were updated with the older version.

(Unity 2021.3.27 URP)

Thanks

 

How can I fix the transparent of the Ring:

 

Hey Carlos

Just noticed an issue in 2022.3.1f1 and up. If you open an SGT scene, lets just say one of the terrain examples and then open the standalone profiler it seems to break all SGT materials for some reason. Regular profiler seems ok but the standalone one seems to break it. I can reproduce it with a blank URP 2022.3.1f1 project and only SGT installed.

Cheers

 

I have a weird bug with terrain spawns. It used to work fine so no idea what has changed. I have a ship that can take off and land on planet surfaces, but when I lift back off the planet, all the rocks I have spawned on the surface start moving across the surface! They are terrain objects, no physics or rigid bodies or anything. Just a simple mesh with SGT Terrain Object.

Any way to fix these from moving around on their own?

The slide along fairly quickly, sticking to the terrain mesh as they go.

 

Forget about this, I just realised that I just had to modify the gradient itself to make it work !

 

Why does my Radius Max Property of Aurora doesn´t change anythink in game. I change the slider in my game and the value changes, but nothing happens:



When the Planet gets despawned, the value will be saved (it stays at 10), and when the planet spawns again, the Radius Max will be updated. Radius Max is at 1.8, but it is actually at 10. Why does it not updating:

 

Pulling my hair out here. Is there ANY way to effect the radius of an ocean at runtime? I don't seem to be able to access the property at all. Is there a custom script out there anywhere that will allow me to alter the float value at run time?

 

Never mind, I got chatGPT to write me a script to interface with it. All working now!

 

Hi again, has anyone got lens flares working with large planets? I can see flares through them. I've even tried adding a giant sphere collider on its own layer but that doesn't block them.

 

Hi Mulbin, in my Space Exploration Game the sizes of my Planets are in Metre (like the earth is 12742000 metre instead of 12643 km) and the lens flares working are working with terrain planets without using any collider. I also have the same probleme with the giants, i tried using collider but it didn´t work. I am also on URP if you are asking.

 

In Unity 2023.1.6f1, I am getting an error message for " 'OUTPUT_SH': Too few arguments to a macro call" in a number of SGT shaders (noticed in Additive, Atmosphere, Aurora, Backdrop, and Planet so far). Is there a workaround that makes SGT compatible with Unity 2023?

 

Hi @Darkcoder,

is there an easy way to match planet terrain colliders with the visible mesh? I tried with the latest SGT version and the included "Obsidian Planet" scene. I added SgtTerrainCollider to the terrain gameobject and played around with the settings. A too high resolution creates spikes much outside of the visuals. A too low resolution behaves as expected, but I failed to find the right setting. The "details" slider has no effect at all it seems.

Thanks in advance!

 

Hi @JamesTCookie You could use a layered camera as a workaround. One for the near and one for the far away objects.

 

I did so already but I hoped for a more performant solution.
Thank you

 

What is best practice for getting a decent frame rate when near a large planet? I'm using an earth size and it chugs down to 30-fps as I get close on an RTX 3090. It seems to be specifically the terrain mesh causing this. Are there best settings to use? There are so many different variables its hard to tell what to adjust for good performance.

 

No. Frankly the current system is insane. Just a lot of trial and error. I'd recommend running a build in the editor then gradually adjusting the size of the colliders during runtime to see what random scale closely matches the terrain... it will never be perfect though, you'll always have places objects sink into the ground and places they float above its currently just not really fit for purpose with any accuracy.

To give an example of how random it seems, I have a near earth size planet...

SGT Terrain set to:
Smallest Triangle Size 10
Resolution 32

SGT Terrain Collider set to:
Resolution 4096
Detail 64

That fairly closely matches the vertices of the terrain. Never has a "match colliders to terrain" button been so badly needed

 

Sorry for the late replies everyone.

Almost all features of SGT use normal MeshRenderers. The notable exceptions are SgtPlanet and SgtTerrainPlanet and SgtTerrainOcean. This is because SgtTerrainPlanet creates/destroys a lot of meshes as you move, and managing a hierarchy of GameObjects is far more tedious than just rendering them directly as needed, and the planet code shares parts of that so it renders the same way. Therefore, you would have to change your implementation. I recommend making a custom component you add to all your objects that uses the Renderer by default, and in cases like planets you can use a custom value, then your code can remain very similar and have additional flexibility for cases like this.

The starfield infinite shader/material has a NEAR FADE setting which can be used to hide stars that get within a certain range of the camera.

You can just modify the gradient so the left side is transparent instead of the right?

According to THIS article, OpenGL ES doesn't support a reversed z-buffer, so it's not possible to render scenes with such massive scale without z fighting. However, it should be possible with Vulkan and Metal, but I'm not sure if Unity uses it?

It's possible to offset the atmosphere from the planet surface, but it may cause rendering issues with mountains or rings. There is the shader setting you can set in the .cg file called 'offset', which does this to some degree depending on the GPU. So you could open Atmosphere.shader and add "Offset -1, -1" to line 65 (FORWARD pass), and possibly other passes and see if it changes anything.

Interesting results, but I don't see how checking UnityEngine.Object equality 417 times would take over 800ms. There must be some kind of race condition somewhere. You'd have to isolate the lag spikes more specifically in a very simple demo scene to identify what's causing it.

In the latest version I can set Range to any value, including less than 1?

This is probably the z buffer issue I mentioned above. Does the issue go away if you compile with the Vulkan graphics API?

Does the black hole appear if you swap its material to something else, like the Sprites-Default? If so, this could also be a different depth precision issue. You could try swapping the actual black hole with a flat sprite or similar based on distance.

SgtBackdrop should follow the current camera around by default. If it clips inside or renders in front of planets you probably just need to increase its scale.

Unity's package importer just overwrites all updated files (even if they have moved) and keeps any that have since been deleted. This can easily cause the project structure to break depending on the package update, so if something strange happens it's generally best to delete the asset folder before updating. Of course you should always back up your files before updating anything in case it breaks.

Are you sure the shadowed section isn't just dark, and against the blackness of space it gives the illusion of it being transparent? You can swap the ring texture to something more opaque to check.

I've never tried the standalone profiler. I tried it now but the PC I'm currently on doesn't have enough memory apparently, so I'll have to test it next week. If you select one of the shader bundles, like "Plugins\CW\SpaceGraphicsToolkit\Features\Planet\Required\Shaders\SGT_Planet_Bundle" and click Switch All Shaders To ____, does it work again?

Does this issue occur in the Terrain feature's "06 Spawner" demo scene? If not, try modifying this scene until the issue occurs and send me a copy of it to try out.

No idea, you can add some code inside the SgtAurora's RadiusMax property to see what and when it's being set by. This property is very simple and just gets passed to the shader every frame, so it should work fine as long as you're setting it.

For super massive scenes the physics system doesn't work properly, and the lens flare works using a raycast so that's probably why. SGT comes with theSgtOcclusionScaler component, which works similarly for the lens glare effect that hides behind planets like in the "Terrestrial Planet" demo scene. This component has code that scales the raycast back to the MaxRaycastDistance value to overcome this. This doesn't help with lens flares though, which I think and entirely Unity's own code that you can't touch.

There is an update to the shader files that will fix this, I'll try and get it out in a few days.

I believe the difference on large planets is down to floating point precision limitations. In the "Terrestrial Planet" demo scene, a Resolution of 256 seems to match up to the visual. For the Obsidian Planet scene, a Resolution of 65536 seems to match the visual mesh, but there is some offset. Making them align would probably require heavily modifying SgtTerrainCollider code to not using parenting and not having the mesh origin at the center.

What is the performance like on the example "Earth Sized Planet" demo scene? It runs great on my 3060ti, so your should be even better. You can check the profiler to see what exactly is causing the lag.

 

Hi, been using this asset for a game I'm working on.

I'm hoping to use DOTS/ECS now that it has hit 1.0, and whilst the assets (stars etc) all render find in standard URP. If I try to use them with DOTS (IE in a subscene as entities) I suddenly get errors.

The first error is easy to fix, just a case of editing the Shader files (despite them saying do not edit xD ) to change '#pragma target 3.0' to '#pragma target 4.5' to allow them to work with DOTS (DOTS enabled or something?)

However, I've got a second error also, and as my shader programming knowledge isn't the greatest I could use some help/advice.

"A BatchDrawCommand is using a pass from the shader "Space Graphics Toolkit/Prominence" that is not SRP Batcher compatible. Reason: "UnityPerMaterial var is not declared in shader property section" (_SGT_Color)
This is not supported when rendering with a BatchRendererGroup (or Entities Graphics). MaterialID: 5 ("Prominence (Generated)"), MeshID: 2 ("Plane"), BatchID: 2."

The above is the main error I get and I'm unsure how to resovle that. Something to do with the property which I've found in the code, but no clue how to fix it.


Alternatively, will regenerating the shaders with BetterShader help (either the free or paid version)? I tried to get support on the discord but its totally locked down unless you buy it and I don't want to spend £100 in case it won't actually help me.

 

[URL='https://forum.unity.com/goto/post?id=9094570#post-9094570']↑[/URL]

The shores seem way too big and can't be made smaller than 1, which result in hard edges instead of fade out.

[USER=41960]@Darkcoder[/USER], is there a way to reduce the shore range for bigger planets?



[URL='https://forum.unity.com/attachments/1260169/']View attachment 1260169[/URL]

In the latest version I can set Range to any value, including less than 1?

setting the range less that 1 won't change the appearance sadly. The shore looks still weirdly oversized and looses it's fading (ugly sharp)

EDIT: it looks like when closing in on the terrain it looks fine, but only from higher distances, values below 1.0 won't have any effect