Space Graphics Toolkit & Planets

Great news! I am looking forward to try this version. With the atmosphere issue: I am using your atmosphere scripts in my game on a directional light with a SgtLight component, treat as point light option enbled. Planets are large, like 1M radius. And distances are large like 50M to the edge of the system. No flickering issues so far. Sgt version 3.7.3. HDRP pipeline. I haven't even changed one line of code. But, with a custom floating origin mechanism.The key may be that when you are on the planet, you should not move it or rotate it, instead, the whole universe should fake a geocentric motion. Keeping planets in heliocentric motion when walking on them even causes flickering on transparent surfaces, so windows of the buildings always flicker on the corners and sometimes even on the edges. It seems to be a general issue.

 

I forgot to enable it in this version, but you can uncomment line 46 of SgtAtmosphereInner.shader in Features/Atmosphere/Resources. This should fix all flickering issues in HDRP.

I still need to work on the brightness values, because having a light with Lux > 1 causes SgtAtmosphere to be too bright, but this is too low to light up the planet properly. You can fix this by making two lights, one with SgtLight, and one to light the scene. However, I will make it so SgtLight has some sort of setting to make this easier.

After I finish fixing the HDRP lighting brightness and RenderQueue issues I will look into this more. I plan to make more demo scenes showing the new terrain system, including placing some kind of objects on the planet surface. When I get to this I will see what issues occur with transparency and the origin shifting system.

 

@Darkcoder Your floating origin system works great. There is nothing wrong with it. I needed that geocentric system and therefore a custom floating origin system, that's all. HDRP lighting does not seem to be stable in nature. Lights behave different when you upgrade a project or create one from scratch. Point lights are the most problematic. I managed to reduce the brightness by volume settings->exposure but then you loose the space darkness 9the darkness of the dark part of the planets). It is strange that in my game I can get a satisfactory amount of space darkness with exposure, maybe because it is a project upgraded from built-in render pipeline.

And, with the atmosphere in 3.7.4... 3.7.3 version works out of the box with HDRP. 3.7.4 has clippings and they do not relate to the floating origin problem I mentioned previously, I think.

Terrain is now much more better. However, I am looking for a way to give detailed textures on close ground. Far ground details are great. I haven't looked at the shader, yet, but, if it is possible to arrange a near tiling and far tiling fields in the shader and lerp between those tiling values according to vertex position for the provided textures, can this be achieved?

 

Indeed, lighting in HDRP seems to be a huge mess. Sometimes my planets appear purely black, sometimes they appear to bright, etc. I'm not sure if there's a way to set it up in a way that it will work more or less without issue in all pipelines. I think the easiest solution is for me to add some kind of script that 'upgrades' the scene to use HDRP specific settings.

The flickering should go away if you follow the steps in my previous message to orrbain: "you can uncomment line 46 of SgtAtmosphereInner.shader in Features/Atmosphere/Resources. This should fix all flickering issues in HDRP.".

You can always modify the SGT Planet shader to do this kind of detail lerping you describe. However, the main issue is that tiling only works up to about 10,000 tiles, then the floating point precision of the UV data breaks down. 10,000 tiles is fine for smaller planets, but for realistic sized ones you need a completely different shader and vertex data setup, which is why I'm working on a new planet asset that will allow for this.

 

Cool, thanks, changing that line in the shader did fix it. I had noticed the issue with the atmosphere brightness as well, and since you mentioned it I found that changing line 104 of SgtLight.cs to:

color = SgtHelper.Brighten(cachedLight.color, Mathf.Min(1f, cachedLight.intensity));

Solved the problem for me. I'm not sure if it's totally correct or not and a setting would probably work better, but at least for now it's working fine for my purposes. Thanks!

 

Great!

In the next version I've added the Intensity setting to SgtLight, so you can control it separately.

 

Just one other thing to note in case, I am also seeing that SgtBackgdrop stuff seems incorrect in HDRP. For example if I have a SgtBackdrop of stars, then the shadows on Rings are filled with the backdrop instead of being black. I also noticed it doing something similar with the atmosphere fog transparency when on a planet. I assume it's some kind of ZTest issue in the shader or something?

I tried all the various RenderQueue and Blending Mode settings and it didn't make a difference.

 

Good afternoon. How can I enable "Single Pass Instanced" for materials? One eye does not work now ((( (URP, 2020.1.8)

 

To fix this I think you have to change the RenderQueue to Transparent, and increase the transform.scale so it renders behind the foreground objects. I'll update the demo scenes for the next version.

Does this issue occur for all features, or just some? I'll try and test it out later today.

 

For generated materials grid.

 

Is it possible to apply atmospheric fog to an object spawned by the SGT prefab spawner component?

 

I think I've fixed this. I'll send you a private message with a test build.

Good idea, I'll see if I can add this!

 

Hey everyone,

Version 3.7.5 of Space Graphics Toolkit is now out!

• Added SgtLight.Intensity setting.
• Added SgtTerrainPrefabSpawner.Threshold setting.
• Added SgtTerrainPrefabSpawner.SharedMaterial setting.
• Updated demo scene background RenderQueue and scale for SRP compatibility.
• Improved SRP compatibility documentation.
• Fixed single pass stereo VR rendering.
• Rewrote Spacetime to be easier to use.

HDRP support is almost complete. If you follow the new steps in the documentation then the lighting can be set up to work in most scenarios. I will look into making some sort of tool to automatically do these steps for you, perhaps I could make a prefab automatically configured with the lighting volume, and add that in, we'll see. Let me know if you encounter any issues.

Enjoy

 

Brand new project in 2020.1.7f1. Imported 3.7.5 into blank project. Got 162 errors, almost all of which seem to relate to namespace errors. A few random errors below:

Assets\Space Graphics Toolkit\Features\Shared\Scripts\SgtHelper.cs(6,13): error CS0234: The type or namespace name 'Mathematics' does not exist in the namespace 'Unity' (are you missing an assembly reference?)



Assets\Space Graphics Toolkit\Features\Terrain\Scripts\SgtTerrain.cs(124,40): error CS0246: The type or namespace name 'float3' could not be found (are you missing a using directive or an assembly reference?)



Assets\Space Graphics Toolkit\Features\Terrain\Scripts\SgtTerrain.cs(14,57): error CS0246: The type or namespace name 'double3' could not be found (are you missing a using directive or an assembly reference?)



Assets\Space Graphics Toolkit\Features\Terrain\Scripts\SgtTerrainSimplex.cs(88,4): error CS0246: The type or namespace name 'BurstCompile' could not be found (are you missing a using directive or an assembly reference?)

Any ideas? Like I said, brand new project with nothing in it but SGT.

 

You are missing the required packages (Math, Jobs, Burst, etc.). See here: http://carloswilkes.com/Documentation/SpaceGraphicsToolkit#PackageManager

 

Thanks! It's been a while, but I don't remember ever having to do that before.

 

Since version 3.7.0 the dynamic LOD features have been rewritten to use Unity's burst, jobs, and mathematics libraries. These improve the performance a lot, but they also mean you have to manually install the Burst and Mathematics packages (because Unity's auto package installer is garbage).

Installation steps are in the "Space Graphics Toolkit/READ ME.txt", as well as the documentation as @orrbain linked to, thanks!

 

Hi there,
Darkcoder I really love your floating point system it's ideal for my project and the entire SGT is fricken awesome dude what an asset.

I'm hoping this is the correct place to ask this type of question as I have a question in how to make changes around the 3rd person mouse using your Universe scene demo as a test bed.

My problem is that I want to scroll out and in with the mouse to make my 3rd person camera move away and towards the target ship. I can do this normally however I'm struggling to get this done with your 3rd person camera in that scene.

My question is I was wondering what your opinion would be in how I should apply a move in and away from the target with the camera given I'm using floating point system.
Cheers

 

I'm not sure I understand the question. The "Universe/15 Third Person" example shows you how to combine a 3rd person camera around a spaceship with the warp to pin feature of the origin shifting system. If you just want to know how to bind mouse wheel to the third person orbit distance then you can write a simple script that reads Input.mouseScrollDelta.y and uses it to modify the camera's Transform.localPosition, where the Z is the distance.

 

Thanks Darkcoder,
Your probably confused by my question because it's probably really stupid, but u pretty much answered what I was asking. The exact details of what I needed to do were escaping me as I was unsure which event to code the input and changes and whether what I was doing was causing strange results like flickering in stead of zooming out etc..
and also whether I was using the correct transform position i.e. using the floating origin system whether I then needed to apply transforms to localPosition on the origin control or still use the camera's default transform as well.

Rather than just keep trying different things I thought I'd come to the expert.

I haven't tried to read the Input.mouseScrollDelta.y and then modify the camera's transform.localPosition with the z being the distance exactly so that might be it.

I'm assuming it's okay to put that code into a separate script of my own in an Update() event and it should just work okay.

I'll give what you said a go.

Once again I love your asset and everyday when I look more into it I'm amazed by what it can do.

 

Hi Darkcoder,
BTW: your advice on the mouse scroll z worked a treat thanks for that.
I have an issue and I'm unsure of the cause, I'm hoping you can help.

Do you know how I can fix the planets pack images, I'm currently trying to create some custom planets but all of the surface looks like below from the shader. All the planets come out the same in the pack for me.


Thanks in advance.

 

Hey if you go to Space Graphics Toolkit folder in your assets folder, look for pipeline asset in root of the folder and click and look in inspector then click the switch to (whatever render pipeline you are using) button (standard, or urp or hdrp)... that should fix it.

 

Thanks amack2u,
Yeah that did the trick, I think I read something about that in the documentation but forgot that I was using Standard Pipeline.
Cheers again.

 

Hello ,

I bought this asset few weeks ago and currently trying to use it in a VR game. Everythings looks great but flares from stars and singularity are not working properly with my VR headset. I took a screenshot.

If someone have any idea, thanks
I tried to search on this topic, but no results (i think the search option is not great...) Sorry if the question has already been answered.


Best regards,

 

Which exact version of Unity and render pipeline are you using? Is this with the latest version 3.7.5? Which VR headset and which VR rendering mode are you using?

 

Hi and thanks for your reply.
I'm using Unity 2019.4.11f1, SGT 3.7.5 , built-in render pipeline.
My VR headset is a HTC VIVE (first gen), i use XR Plugin management (3.2.16), openVR XR plugin (1.0.1) and SteamVR unity plugin (2.6.1). Using the single pass instanced (i tried to modify it, but my unity keep crashing).


EDIT: Ok i just tried on a new project, without XR plugin management but with the old built in XR (in edit-> player). I was able to check multpass, and tried with a singularity: looks great. I switch to single pass and got the same rendered as my first post. I will look on my main project and see why i can't switch to multipass.

Thanks

 

That narrows it down. In the latest version I changed quite a bit of shader code to support single pass instanced rendering, and perhaps I forgot to update the singularity shader. I’m currently away from my PC for two days, once I get back I’ll check it out!

 

Hello! I just purchased this asset and I LOVE IT! I do have one question regarding the universe example.

When using the floating sphere spawner (or any floating spawner) ... is there a way to define exactly the prefabs I want to spawn. So far when I give it a list, it randomly spawns the prefabs (sometimes duplicates).

Basically I want to make hand crafted star system. But I want my named planets / moons to be dynamically placed by the space toolkit.

Also the "Distance Min" for the floating LODs don't seem to work.

 

I'll send you a private message with a new build adding this feature.

The SgtFloatingLod.DistanceMin code looks correct, you can see it on line 63 alongside DistanceMax.

 

Thank you so much!

Also I was able to get the Min Distance working after some fiddling around. It was user error on my end lol

 

Does the SGT floating origin system support VFX graph particles ?
And one more thing, I cant see clouds in a camera view, even though I added the SGT Depth Texture on the camera for soft particles. Do you know why ? Thanks.

 

No, since particles are not GameObjects. The particle emitter can be on an object that gets repositioned, but any particles will linger until they die. If you're using floating origin, your best bet is to keep your particles short-lived.

 

I asked this question of the VFX Graph team last year as I'm using my own floating origin system and wanted a "custom space" transform option to parent particles to, which would shift with the floating origin. This would give world-space like behavior for particles with a floating origin system. Here was the answer:

https://forum.unity.com/threads/feedback-wanted-visual-effect-graph.572110/page-11#post-4552234

From my limited testing, it works, but I just wish they included it as a built-in option.

 

I am actually using this technique and it works well. Was just wondering, if he has a better solution.

 

I haven't played with VFX graph much. If it's possible to read and write the position of every particle at any time then it should be possible to make it compatible like how the SgtFloatingParticleSystem component works.

 

Hello, I am trying to create a game with large scale planets, planets to which I could place models of things like buildings for example. The issue Im having is when I increase the scale, it does not increase detail. I am trying to achieve a result similar to what you have done in your video:

What settings should I use to achieve this result?

 

This video was made using the old SgtDynamicPlanet component, which no longer exists. I'll see if I can make the necessary changes to support this kind of scene with the new SgtTerrainPlanet.

 

The old component, which no longer exists??
Include it again, please, unless in the current version there is a better solution. If not, I have to confess that I don't understand anything.

 

Hey everyone,

Version 3.7.6 of SGT is now out!

• Added Obsidian Planet demo scene.
• Added SgtTerrainSimplex.Ridged setting.
• Added SgtTerrainSimplex.Seed setting.
• Added SgtPlanet.Channel setting.
• Added SgtTerrainPlanetMaterial.WaterLevel setting.
• Added SgtTerrainPlanetMaterial.HeightmapBias setting.
• Added SgtFloatingSpawner.RandomizeIndex setting.
• Fixed SgtStarfieldInfinite stretch feature.
• Fixed some Basic Pack demo scene materials.
• Moved SgtOcclusion code to Shared folder.

SgtDynamicPlanet was replaced with SgtTerrainPlanet a few versions ago, this new component has much better performance and visual quality, I just forgot to port over a few things. This new version should bring everything back.

 

Ok, thanks

 

That would be great, I need to create large scale planets.

 

Hello, nice asset!

Question: how many Shadow Spheres are supported in URP?

I can only ever get 2 or 3 to work, then they disappear. If I toggle an object off and on again, is shadow sphere usually works (and some others fail)

However, it's not just one, I usually have 2 or 3 working at the same time. (Trying to build Jupiter with 4 galilean moons and a ring)

I also struggle with Auroras and their Z test/zwrite, they are either always on top of a jovian, or below. It gets worse when I place them on a child or sibling object. I'd assume a Jovian should write a z value based on its depth tex or alpha fade values (and I'd greatly suggest this). I can't get the mesh offset to work but I'm almost at the point where I render an invisible sphere to properly occlude the Auroras.

I wonder where the transparency z ordering is defined in URP, this may or may not be a unity issue

Some constructive feedback: instead of using so many generated materials, it would greatly improve usability if the asset would use predefined or persistent materials instead, especially allowing me to replace them with my own shaders (example - lightning, auroras, jovians) without changing SGT's source code. These changes are perpetually at risk of being overwritten with each update. The way the shader names are hard coded also makes it difficult to just derive from the class. The abundance of generated textures for something as simple as a 1d easing function also tends to muddy the Prefab Overrides menu and often marks my scenes dirty without an apparent reason.

Realism feedback: Jovians should fade to black rather quickly when the camera penetrates them (pretty much with the alpha fade distance). Setting these distances directly rather than through guessing some numbers would also help a lot (what even is alpha fade and density? they seem to counteract each other).

Performance feedback: The generated textures greatly improve the flexibility of the shading, but do add additional texture lookups. Possibly a better solution than shader keywords, at least

Some matter-of-taste feedback: Why wrap every serialized property into a C# property? It looks super clunky and impedes extensibility because if I want to just add another float, I need to copy and modify an entire line with annotations (or deviate from your code style).

Aaaaand some less than constructive feedback, I saw the dynamic planet demo and bought the asset and... Turns out it's not available anymore? Terrain Planet looks like quite a downgrade and has a lot of intense popping at all distances. It looks so unsatisfactory that I'm not even considering adding my own terrain synthesis, but going for another solution all together. Not sure what I can say, and there were probably issues with dynamic planet, but... sgtTerrainPlanet isn't the answer (does it really use Unity terrains as the underlying final splat mapping structure? That would explain things...) Initially I thought it was some type of clip map implementation but it has no discernible morphing, only intense popping for me. The lighting looks entirely unreal and the colors are so strange and garish, i wonder if an RG Map accidentally made it into the albedo slot somewhere.

 

Just in case, I took a video of one of the sample scenes as they come out of the box, URP 10.2.0 (but same on 10.1.0) on an RTX 2080 super, Unity 2020.2.0b11 (but I also tried 2019.4)

I wouldn't consider this an error if the popping was close to the horizon, but this is within "an arm's length" of the camera. From my gut feeling, each of these terrain sections should be resolved 2-3 LODs higher at that stage; possibly that's prohibitive with a non-tree datastructure. There could be smooth interpolation along the error margins with a triangle bintree / quadtree, or with a projection of a single resolution grid perhaps as shown in this paper. (that would have a lot of morphing though, I'm building this myself at this time, can share some results later perhaps - the demo video cheats by only zooming out and having a very hazy atmosphere )

I tried to work around SgtTerrainPlanet's popping with an offset observer transform, but that didn't make it better, because there's also popping "an arm's length" behind the camera.

The popping becomes slightly better at 512 or higher resolutions, but I would consider these prohibitive in terms of performance for most uses. 256 still has intense popping just 10 units in front of the camera.

The shadows look rather broken as well. I would expect the shading to be at least similar in behaviour and quality to the Lit or Simple Lit shaders that come with URP.

 

The shadow system supports up to 2 shadows per shader/material. This is mostly due to shader instruction limits, and the inability to write arrays of sampler2Ds. I may change this to one ring shadow and an arbitrary number of sphere shadows, since sphere shadows could be calculated without textures. In most scenes 2 is sufficient, as shadows that don't intersect with objects can be skipped. In your scenario you may want to arrange the moons so that no more than 2 can cast on the planet at the same time, and disable shadows from the smaller ones since they would be too small to be scene in most scenarios.

I don't remember if I ever tested the aurora and jovian features together, but indeed the recommended solution is to use an invisible sphere that writes depth. SGT comes with the "Space Graphics Toolkit/Depth" shader for this purpose, but it currently isn't used in any of the example scenes. I'll see if I can add some examples of this. Getting the draw order correct is also much easier if I add a CameraOffset setting to SgtJovian, which I've now done.

The materials being hidden is a design decision to make this asset easier to use. The vast majority of users have no ability or desire to replace the shader, and I'd rather not have to write lots more documentation for this, so it's a win win.

The generated textures are something I'm also not too happy with, and in the past these were hidden and directly integrated into the base component. The reason why I separated them is because most users have the ability to modify textures, and there are many interesting modifications you can do that aren't possible or easy to allow with the a few simple settings (unless you make the inspector as complex as the aurora). If you let me know which components can mark the scene as dirty then I can look into it, as that shouldn't happen.

The opacity isn't calculated based on a set distance like with the atmosphere, which is why the numbers are a bit vague. This is also why the names are a bit vague, because they're usually not based on anything real. When making these settings I have a variety of reference materials I want to be able to replicate, and I experiment with a bunch of different settings that can produce these results with minimal overhead, and these often result in many settings that do similar but different things and I have to somehow come up with different names. AlphaDensity and AlphaFade indeed counteract each other, where AlphaDensity basically controls where the jovian edge fading begins from the inside, and the AlphaFade controls the sharpness or end point of this transition. There are many examples like this that can't be succinctly explained, so I recommend users experiment with them to develop their own understanding and tweak them until they get the result they want.

There may be ways to optimize the shaders for specific scenarios, but unlike shaders the textures can easily be modified by most users. In my testing all the shaders perform really well though, and 1-2 texture lookups per fragment is basically nothing.

I went back and forth with this many times, and decided to make everything use properties because it works better with Unity's built in event and animation systems, and it makes the code more consistent. Basically Unity's event system can only call methods(including setters), not fields. Previously I had SetXYZ() methods to keep fields and to accommodate this, but then it makes it more confusing and difficult to use. Therefore making everything properties keeps everything named the same no matter how you access the values.

SgtTerrainPlanet implements geometry clipmapping. It does not use Unity's built-in terrain system, not sure where you got that idea.

Based on your video it looks like you have burst compilation disabled. Go to Jobs/Burst/Enable Compilation from the menu bar. I guarantee you that this new terrain system is superior to the previous ones in every possible metric by like 10x.

 

Sounds good, except... burst is on. I also turned off Leak Detection and Safety Checks - to no avail. (my project is a DOTS project so I usually have burst on)

For a test, I created a 2019.4.14f1 URP project from scratch, with Burst 1.3.9 and no other code. The demo behaves about the same.

The performance is sometimes good and sometimes pretty abysmal (on the same planet!), so there may be something going on based on the direction you move in etc. I'll try to get a precise repro.

Thank you for the explanation. All moons of Jupiter cause reasonably large shadows / eclipses. I wonder if the resonance of the orbits could be faked in a way so they never eclipse more than two at the same time. (I am fine with having no seasons / my simplification is that Jupiter is the center of my system anyway, and the sun is static)

Knowing that it's a limitation of the current system helps. I'm still prototyping but wanted to work on the visual language of the game.

I think the spherical shadows should indeed be entirely distance based in fragment code, though I do like how it can create colored shadow volumes.

 

I am new (to both the forums and this asset) and i'm curious as to how to use it.

 

Very concrete feature request:
Please make anything that renders custom geometry (including gizmos) to a camera not render anything to any scene view cameras if this hide icon is selected in the hierarchy...


... and (only if) this hide icon is selected on the top tool bar of respective scene view:


I would be so very grateful.

And a small issue report:
Unity 2020.2 struggles with how (several) asset store assets rewrite their assets, giving inconsistency warnings. Yours is one of them, I don't know what the code does but it's not conformant with the Asset Pipeline.

 

Strange, what kind of CPU are you using? Since this uses burst it's CPU heavy, but for a planet of the detail level seen in your video there should be no issue on most systems. Also, is vsync disabled? The mesh generation jobs are set to run for 3 frames, so if you enable vsync it can take time to update the whole planet. I should add some kind of way to adjust this depending on load.

Also, to adjust the range at which LODs appear I recommend you increase the Detail setting rather than the Resolution. This is an easier value to work with for adjusting the detail based on the desired performance, and if you increase it then it will make the LOD less obvious.

If your planet is high enough detail then you will have to have LODs generating within view of the camera. Making them only generate near the horizon would require either very low detail planets, or extreme triangle counts.

Which aspect of the asset do you need help with?

I'll see what I can do, it looks easy enough to support this.

This is probably because I copy+pasted the pipeline tool from my other asset, and maybe the GUID is messed up. I'll see if I can regenerate it or something.

 

Intel(R) Core(TM) i7-8086K CPU @ 4.00GHz, boost till 4.7GHz, 6 Cores, 12 Logical Processors. Not the fastest machine but should not struggle with these workloads (and it doesn't with others). I have 32 GB of RAM.

Interestingly, the performance fluctuates, some areas of the planet always look poor, though, and always pop intensely. Others are a bit better, or get better over time (minutes, not seconds later, though). Synchronous Compilation doesn't help significantly. The frame rate is over 500 fps, and some areas are doing a lot worse than others, so I suspect there's a directional component to the algorithm that has some problem.


In the planet demo, this is a bad area with intense popping and sudden extreme changes in the terrain shadows and altitudes, with whole swaths of details appearing out of thin air (don't mind the shoddy video capture rate, the game runs at 500-1000 fps, see the stats overlay):

This is a not-so-bad area, still has a good amount of popping but it's more acceptable:

The planet (should be close to the same as out of the box in 05 - Collider.unity scene)

 

And another bug report for Unity 2020.1 and later:

1. When editing a prefab "In Context", in other contexts than "Normal", (i.e. Gray or Hidden), most custom geometry also keeps rendering. That means that if you have a Jovian at 0/0/0, you must edit your prefabs in very dense fog. See mouse cursor near context buttons.


2. Furthermore, these objects render even into the pure prefab stage (the blue one that you get by double-clicking a prefab). See mouse cursor near bottom of screen. That's especially bad because in that case, most prefabs are at 0/0/0 and anything from the normal editor scene isn't even supposed to be rendered.