Space Graphics Toolkit & Planets

Thanks for the answer. I have seen oceans done as a post processing effect using a shader just like an atmosphere such that you could move around in it, but that example did not have waves (other than speckles seen from low orbit) or LoD processing. So I can start to appreciate the difficulty you face. Seeing as you plan to experiment with it again, do you think it might be possible to get permeable oceans so we can land at underwater bases? I can dream. Thanks again. This will be my Father's Day present to myself.

 

If I get oceans working then yes of course you will be able to dive through them, and I would have to implement some kind of effect when you go under. The planet terrain would be separate, so you could still easily place a base or whatever underwater. But first, I have to actually implement any of this

 

Hi,

I would like to ask what are the license on the planet textures included in the Solar System Pack download. Are those free to use in a app or game or require to give credit to a source ?

I am making a solar system emulator for Android and would like to use them for that purpose.

Thanks

EDIT:

I just saw the copyrights

NOTE: Most media used in SGT is public domain, but the Mercury, Mercury Normal, and Moon textures is subject to CC-BY 4.0. Please read the following link for more details:
http://www.solarsystemscope.com/textures/

Are the public domain images from some other sources, other than solarsystemscope? I would like to check it out before use them if possible.

 

Thanks for the suggestion, I'll give that a try. I was thinking of using this for shimmering stars of a constellation. Do you anticipate any performance issues if I have a couple dozen flares using this animation technique?

 

Thanks for the suggestion, I'll give that a try. I was thinking of using this for shimmering stars of a constellation. Do you anticipate any performance issues if I have a couple dozen flares using this animation technique?

 

The Earth textures are public domain from HERE. Most of the textures like Neptune, The Sun, Saturn, Uranus were extracted from NASA pictures that were marked as public domain. I don't have links to the originals though. In any case, the images I used or modified aren't the best. You can find many websites like solarsystemscope that have much better looking ones with more clear licensing, I recommend you use those instead.

 

It depends on the amount of vertices your flares have, and the CPU performance of your device. The code to generate the flares isn't very heavy though, so it should be fine.

 

Thanks for all clarifications.

 

Hello,
congratulations for this incredible asset

Different samples are displayed badly on my HDRP project. (or with an empty default HDRP project).

The materials are displayed incorrectly. (either dazzling white or black )

I must have missed a setting. Can you help me?

 

Hello, Thank you for such a great asset.
Couple issues...
1. Im seeing seams from a distant in webgl on planets...reading back in forum someone had similar issue and you sent them a shader fix....Can i get that fix as well.

2. what is best way to implement landing on orbiting planet. I keep getting thrown around when i reach surface

Also I would love to try that new procedural terrain feature you have teased if possible.
thanks

 

The atmosphere issues will be fixed in the next version. This required a rewrite of the SgtDynamicPlanet component, so it took some time, almost done!

As for the brightness, it's my understanding that you must add an HDRP post processing volume to the scene and configure it to handle the brightness correctly. Once this next update is out I'll look into the possibility of automatically adding one.

1 - This will be fixed in the next version which is nearing completion. The shader update was just a temporary solution that wasn't too good, the new version will include the proper fix.

2 - The best way is to not make your planet move or rotate while landing, because the physics system wasn't really designed with full scale planets in mind. If they must move, then the best solution is to not use the physics system, and instead directly get the surface height/distance, and handle the landing part yourself.

Regarding the new asset testing, I think I have enough testers for the first version. If don't get enough responses or something then I'll consider adding more.

 

You have a testable version? I'd love to try it.

 

You're on the list of testers, just a few more things to do before it's ready

 

Hey everyone,



Here's a new sneak peak of the new terrain asset!

This is on an Earth-sized planet, with a camera at an altitude of 29km.

As you can see, I've been working on the terrain height generation code. This whole planet is just this one mountainous biome to test this system out, but it can easily be expanded to work with any kind of biome. I still need to work on the terrain colors/materials as right now these are just hardcoded based on height. Next time they will be based on terrain features, and I'll send out test builds

 

Nice! That looks a lot better than the last mountains.

 

Looks really nice, great work so far.

 

Hi all. I experimented a bit again.
Kitbash3D Utopia on procedural planet.

 

Wow, looks amazing. Can't wait to see what you can achieve with the new components

 

Add a bit of clouds and it'll look god-tier

 

I have plans to experiment with the cloud rendering. SgtCloudsphere looks good at far to medium distances, but up close it looks bad which is why I added the proximity fade out. I have an idea to combine it with how the starfield nebula rendering works, and how the terrain LOD works, we'll see. The new terrain system has a higher priority though

 

not fixes for what is out now ?
that's unfortunate

 

The current terrain system will be replaced in the next version of SGT with a simplified version of the new terrain system. The features will remain the same, but it will now render properly in HDRP with an atmosphere, and you will see a substantial boost to performance. This new terrain system took a lot of work to develop and introduces many new features, so I think this approach benefits everyone

 

That looks awesome.
How many triangles has the planet?

 

Hello again, I'm trying to use the starfield infinite stretch component in my scene with a star (light/billboard version) i start scene with starfield off and when i enable the gameobject with the starfield...it activates but i lose lighting on my ship (that was provided by the star), and get errors in the console during warp. and the errors in console stop when i disable the gameobject and lighting returns to normal... any ideas?

thanks

console error:
Expanding invalid MinMaxAABB
UnityEngine.Camera:Render()
SpaceGraphicsToolkit.SgtDepthCameraoCalculate(Vector3, Vector3) (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepthCamera.cs:100)
SpaceGraphicsToolkit.SgtDepth:Calculate(Vector3, Vector3) (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepth.cs:35)
SpaceGraphicsToolkit.SgtDepthScale:LateUpdate() (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepthScale.cs:49)

 

In that picture the planet surface is 3 million triangles, 1.5 million vertices. With SgtAtmosphere it's double. In the future I will experiment with a screen space atmosphere effect to avoid this, but that also introduces other issues like incompatibility with AA.

Are you using URP or HDRP? If so, this will be fixed in the next version. The SgtDepthCamera component only seems to work well on the standard pipeline.

 

ok thanks..im using URP... so this next version has the visible planet seams fix for webgl and this SgtDepthCamera fix....that's awesome! any idea on the eta for next version? btw Thanks again for all your hard work on this asset...

 

This looks really cool...is this for a project or just messing around?

 

Maybe next week™, we'll see.

 

Let's say it was a test for a project.

 

Hello again, quick question... Do you know what could be causing this issue? When approaching a dynamic planet to land on... on the sun facing side of the planet, First, i cast a huge circular shadow as i land that is much bigger then my ship. Then as I am approaching the area from within the atmosphere it was fully lit and once i get lower it appears to be dark on the ground. any ideas? Thanks

 

This sounds like the way Unity's dynamic shadows work. They will only appear when your camera is within range (based on your quality settings), so if the area you approach is in shadow then they will suddenly become shadowed as you approach.

 

thanks for your reply...
and I can deal with that... but the main issue is when i get to the ground it is still dark around me and i can see light in the distance...but if i fly there its always dark on the ground for some reason.

 

Can you post a video or screenshots so I can get a better idea of what you're seeing?

 

It does that even if i try to go to that lit area in the distance.

 

Have you tried adjusting the camera near and far clipping?

 

I actually figured it out...I had used unity to compress all the textures down for webgl and somehow it made my all my albeido textures greyscale...i did them individually and now they work correctly.

 

Quoting above as it has been mentioned before.

@Darkcoder

On the topic of DOTS and Entities would you consider adding a simple DOTS example for two use cases:
- World Spawning - Cubes
- Stars and Asteroids - I am omitting planets as that is where a lot of the advanced features are. But simple stars and asteroid billboards at least might make a good example. Anything that isn't too complex.

Here I found example code for a DOTS floating point. Just not sure how to have it work smoothly alongside SGT already existing floating point.

https://forum.unity.com/threads/dots-for-floating-origin.807117/page-2
and

 

Great, I never would have guessed this would have been the issue!

I have no experience with Unity's ECS, so you probably know more than me about what's required to do these Once these features leave the experimental stage I will look into them more, but for now they still seem like very foreign concepts in terms of how Unity is currently used, and few people seem to be using it, and I'd rather not have to worry about writing two versions of my code (two versions of the shaders is tedious enough with SRP!).

 

Yes it was a really weird, I'm glad i figured that out... I am literally salivating, over this next release...and that other new asset too, speaking of that, can I pay for early access?.

 

I understand him not wanting to implement DOTS just yet.

I tried it several times and the code was outdated in just a few weeks each time. Best to wait... Dont know why they even release some of that sometimes ... should just release it to alpha/beta build testers than can product all the errors and problems for them fast enough (and give feedback).

This with DOTS when it is ready though should be amazing

What new features?!?!

 

Nope, but I can add you to the next test

I've been working on a new dynamic planet LOD system that will be released as a new asset, and I've back-ported a simplified version of it that will replace the existing SgtDynamicLOD with better performance and some other improvements.

 

Yes please!!! I would be honored good sir.

 

Is this system the one that is compatable with converting cubemaps into planets? I have a couple folders with 1tb of tiled cubemap data that would love you... or hate you because they would no longer exist...

 

This system could be modified to allow for cube face textures (one for each side only) easily enough. Multiple images per side would not be possible at all.

 

Equirectangular images would work though? I don't mean textures, I am more interested in heightmaps. I guess a second one could be splatmaps.

 

Hi, we purchased Space Graphics Toolkit for making a WebGL and mobile solar system app.

When we make a WebGL build that uses SgtCloudsphere, it makes the planets look like they have some black jitter on their surface. When we play the game in the Unity Editor, it looks fine. There’s no black jitter.

If I remove the SgtCloudsphere component from my planet and then build to WebGL it also looks fine so I think SgtCloudsphere the cause.

I recorded a video of the black jitter issue:
https://drive.google.com/file/d/1bEFsFFUCvsfDN3BN5G4DIhqDModor5kK/view?usp=sharing

Environment Notes:
Unity 2020.1.0f
The latest Space Graphics Toolkit 3.7.3
Have tried both Firefox and Google Chrome browsers

Is this an SGT bug or do we just need to change some setting when building to WebGL?
Or is WebGL unsupported?

 

The visual result from the shader could be easily configured to:

a) Render one equirectangular texture around the whole planet.
b) Render 6 cube face textures, one for each of the sides.
c) Render 6 equirectangular textures that have been split up into cube textures, one for each side.

Right now it only supports A though.

The heightmap component currently and in the next version will only support option A. Supporting something else would require custom code.

This is a depth buffer precision issue (z fighting). It looks like there's no way to control the precision of this in WebGL, so to fix this you must increase the cloudsphere's Radius setting until the issue disappears. The exact distance you must increase it to depends on the distance between the planet surface and cloudsphere surface, the camera's distance to the surface, and probably the camera's near & far clipping plane distance values.

 

Hey everyone,

Version 3.7.4 of Space Graphics Toolkit is now out!

• Moved main build to Unity 2018.4.13f1.
  
• Added Terrain feature.
• Added SgtFloatingParticleSystem component to Universe feature.
• Renamed SgtStaticPlanet to SgtPlanet.
• Renamed SgtDepthScale to SgtOcclusionScaler.
• Renamed SgtDepth to SgtOcclusion.
• Removed SgtDepthCamera component.
• Removed SgtDepthRaycast component.
• Removed Mie scattering from atmosphere inner shader.
• Replaced SgtDynamicPlanet with SgtTerrainPlanet.
• Implemented custom occlusion calculations for main components.
• Removed automatically created child components for all components.
• Improved multi-camera rendering code.
• Refactored all code.

NOTE: This is a massive update. Please back up your project, delete the old SGT folder, then install the new version.


This update changes thousands of lines of code, so proceed with caution. The main change is that the SgtDynamicPlanet component (dynamic LOD) has been replaced with SgtTerrainPlanet - This should give better visual quality, better performance, and improve rendering in HDRP (still work left to do on other features). This update also replaces the SgtDepthCamera, because it previously only worked well in the standard pipeline - It now properly calculates the optical depth for each volumetric object separately.

Let me know if you encounter any issues.

Enjoy

 

I cant wait to try this tomorrow... Thanks for your hard work!

 

Definitely seems like I'm getting some increased performance with the new Terrain vs the old Dynamic Planet.

The HDRP rendering is still the "most" broken for me with the Atmosphere rendering..if I set InnerFog to 1 (which seems to basically disable it) then it mostly works, otherwise I get a weird "flickering shadow" effect on the whole planet. I assume that's what you're still working on but just making a note of it, if not. Thanks! Really enjoying this tool.