Space Graphics Toolkit & Planets

Is the 'Outer Mesh Radius' setting right? It should match the radius of your mesh before any scaling is applied, so it would normally be 1.0 or 0.5. But if the importer has a mesh scale of 0.01 then I suppose it might be right.

Otherwise the settings look fine, what happens if you use the same settings as the demo atmospheres?

 

Also if your camera is within the atmosphere it might cause it to look like that. As it renders differently of course based on perspective.

 

That could be what's happening. Since I have a game where you can go into the atmosphere of a planet, is there any way to prevent this artifact?

 

As long as your cameras have the SgtObserver component they will render fine. If you're talking about the Scene preview window then that will render atmospheres incorrectly because there's no (sensible) way to hook into the scene camera to switch shaders before it gets rendered.

 

I do have that enabled on my camera. Still get the artifact, though.

 

It's actually the scattering that was causing the issues. Disabling that 'fixed' the artifact.

 

Can you create a small package with your scene demonstrating this issue and e-mail or PM it to me?

 

Done and done.

 

Well I have a rather unique issue that is either an easy fix or incredibly complex.

With the gas giant shader (this is an issue with the SGT2 and SGT3 one) I'm having an issue with how it interacts with objects passing through it.



This is a case where the volume probe doesn't work. We have an orbit line object that passes through the gas giant but the line appears to render above the gas giant. Render queue doesn't seem to do the trick.

Now if the gas giant uses the regular planet mesh (the one with regular faces), this issue goes away but obviously the lighting and UV space on the gas giant are distorted. If using the gas giant or atmosphere mesh (with the inverted faces) the render order issue with orbits and other solid unity objects is there.

The volume probe script from SGT2 doesn't really do the trick here. I can't be the only person working with orbit lines and the gas giant script and shader so what's the magic trick?

 

This is a difficult issue to solve in general, but for certain circumstances you can fix it. The easiest way I can think of is to draw the gas giants to the depth buffer, and rely on the z read to cull the lines out. However, doing this requires you render the gas giants first, then the depth spheres, then the lines. I'm pretty sure I'll need to write an additional shader to do this though, so I'll have a little play around and send you a build if I find a good solution.

 

Found a issue in "SGT Custom Starfield", "SGT Starfield Group" is created always in Default layer and don't inherit the parent object layer. Can be changed manually but anyway it's better to fix it in next release

 

You're right, I think this is the case for all the components. It will be fixed in the next next version (because Unity's currently majorly backlogged and I'd rather not get sent to the back of the queue).

 

The only image he supplied was a scene view, so that was my guess is he was just no checking the in game view. A lot of people play around with making big planets without moving their camera at all and just assume that what they see in the scene view is what they get. Move your camera!

 

Is there any way to use multiple sgt observers and link them to separate objects?

I have one sgt observer to ensure starfield stretching, it teleports around and attached the the solar system as children and then moves itself along with the solar system, which works great for starfield stretching and appearance of long range movement without displacing the player out into floating point instability territory.

However the sun have also latched onto this observer, so whenever the observer teleports close to the sun for its warp business the sun suddenly loses its entire atmosphere like so: http://goo.gl/GEpJk8 (10mb+ gif)

Is there any solution for this or do I simply have to either toss starfield stretch or live with a erratic sun appearance?

 

It's hard to tell what's going wrong from the gif. Can you give me more details about the scene? For example, what exactly happens when you hit the warp button? Do you add a warp camera or something?

 

When hitting the warp button an empty object(SystemHost) is moved to (0,0,0) world coordinates, adds all celestial objects as children and move according to the warp target, when the destination is reached, the celestial objects are deparented and it's all ready to repeat.

The SystemHost object have an unused camera attached and the (only) SgtObserver script, which means when it moves(along with the solar system) the starfield stretch. The player ship doesn't actually move itself during these warps which is why it have no sgtobserver of its own.

What I didn't know until some recent testing is that the sun also keeps track of the SgtObserver and fades or brightens accordingly depending on distance to it. So if the sun is at (0,0,0) world coordinates or nearby when the SystemHost teleports there, it will snap fade the sun(this http://goo.gl/APM0kI but even more instantly ), otherwise it will pass mostly unnoticed.

So is there any way to manually assign different sgt observers to different scripts?
Or can I somehow override the sun listener with a script of my own, or even just stop the sun from caring about the Observer location and leaving it in a static state.

 

So prior to warping you have no active SgtObservers? If so, that's not how it's designed to work. When you render a starfield or corona, if you don't have an SgtObserver on the cameras you use to render the SGT objects then the shaders won't have the correct values passed to them. In your second gif you can see this happening, because the distance from the camera to the horizon value isn't being updated, thus it renders incorrectly when you change the camera's position. In your first gif it looks like the corona has completely wrong shader values before you hit warp, because no SgtObservers have sent data to the shaders.

I suggest you add an SgtObserver to every camera, and use layers and masks to make the warp effect only render in your other camera. If you need more control over the stretching of the starfield then in the latest version of SGT I added some 'override' settings that allow you to set the velocity manually.

 

The systemHost object is always active and always have an sgtobserver.
In the first .gif the object is teleported and in the other I just move the sun relative to the sgtobserver(that is stationary, but in a much different position than the camera I record the .gif from).

I don't actually use the second camera at all for anything at all, it's just an unfortunate requirement for the observer script.
If I add a Observer to the camera I actually use, then starfield stretching immediately ceases.

I see that the new override takes a velocity vector, that should solve this whole situation.

Thanks for the help!

 

BTW,for example why it's not possible to change lighting gradient via code?So i have a method:

Code (CSharp):

1. public void ConfigureGradient(ref Gradient gradient, params GradientColorKey[] colors)
2.     {
3.         for (int i = 0; i < gradient.colorKeys.Length; i++)
4.         {
5.             gradient.colorKeys[i] = colors[i];
6.         }
7.     }

And when i call it:

Code (CSharp):

1. ConfigureGradient(ref Atmosphere.LightingBrightness, new GradientColorKey(Color.green, 0.2f), new GradientColorKey(Color.white, 1.0f));

There is no result =/

 

After modifying the gradients you have to call: Atmosphere.MarkLutAsDirty(), otherwise the look up texture won't be rebuilt from the new gradient values.

 

As i understand it should be:

Code (CSharp):

1.     public void ConfigureGradient(ref Gradient gradient, params GradientColorKey[] colors)
2.     {
3.         for (int i = 0; i < gradient.colorKeys.Length; i++)
4.         {
5.             gradient.colorKeys[i] = colors[i];
6.         }
7.  
8.         Atmosphere.MarkLutAsDirty();
9.     }

But it doesn't work
Also i tried to call it in the loop, but it doesn't work too.

 

It should work, if you look at the code:

MarkLutAsDirty() sets lutDirty to true

Then in SgtCorona.Update(), SgtCorona.UpdateState() gets called, which calls SgtAtmosphere.UpdateDirty(), which calls SgtAtmosphere.RegenerateLightingLut(), which should apply the new gradients to the 'lightingLut'.

Maybe try adding a breakpoint or debug statement in the RegenerateLightingLut method to make sure it's working.

 

The problem is that the gradient does not change.I mean in the loop i'm trying to change it:

Code (CSharp):

1. for (int i = 0; i < gradient.colorKeys.Length; i++)
2.         {
3.             gradient.colorKeys[i] = colors[i];
4.         }

It does not work, the gradient will not be overwritten.
Any advices?

 

Oh right, I believe accessing 'colorKeys' will return a copy of the internal array, so modifying it won't actually change anything. You need to copy the array out, modify it, then set it back. Or just set the colors directly from your params.

 

Thanks!It works

 

I have your earth in a scene on another camera in its own layer using a render materal to render it onto the gui and i cant get the cloud layer to show in that camera. Everything shows but the outer. Everything is in the right layer : / Any Ideas?

 

I just tested it and it appears to work fine. Do you have an SgtObserver attached to each camera?

Maybe you can send me a really small demo scene showing the issue.

 

I did want to thank you about getting back quickly on the gas giant rendering order thing.

I did have a feature request for sgt_spiral_starfield.

One of the things we're doing is wanting to use it for our background stars in our galaxies which would be a flat 2d pane. Unfortunately there's no way to flatten the Y axis dimensions of the galaxies (unlike the SGT2 nebulaes). Using Unity scaling distorts the individual sprites and the thickness curve affects both Y axis thickness and arm thickness.

 

You can easily modify the code to do this:

Open SgtSpiralStarfield.cs, and after line 66, add: position.y *= Squash;
Open SgtSpiralStarfield.cs, and after line 17, add: public float Squash = 1.0f;
Open SgtSpiralStarfield_Editor.cs, after after line 26, add: DrawDefault("Squash");

You can now modify the 'Squash' value from the inspector.

 

Awesome! Is the procedure about the same to add that to the elliptical script as well?

Edit- Just added those same lines to elliptical and it worked like a charm.

 

Not quite, SgtEllipticalStarfield already multiplies the position.y using the Symmetry value, but resets the distance after this. So to do the same thing as the earlier modification you need to add this after line 73: star.Position.y *= Squash;

The rest of the modifications are the same though.

 

Hmm... I uploaded a picture of the camera inspector. Im using Unity 5 Still cant get the clouds been trying for 2 days arg.

The clouds work for the other cameras just not in the Rendered texture of the camera im showing you below

 

Strange, maybe try hiding all the planet's GameObjects one by one until you can see what's going wrong. It's too hard to tell from a few screenshots alone.

 

I just downgraded SGT in my project to 2.7.6 and there is an issue with rings,they are not rendered both in the editor and build.
No exceptions,errors.

 

You can't 'downgrade' from SGT3 to SGT2. They use completely different script names, so you have to set up SGT2 rings again, or install SGT3 again.

 

I mean that i simply deleted the SGT3 folder ,imported SGT 2.7.6 and rewrote some scripts (thanks god my project is not big).
P.S. It seems to be i have already reported this issue - Space Graphics Toolkit [RELEASED]

 

I am

It appears I am having the same problem with the Venus planet too so it must be just the cloud layer. I did find out that the camera is seeing the planet clouds its only when you click on the render texture its self that you realize that the clouds are not showing. As you can see from the picture I have the camera as a child of Venus and a Unity GUI Canvas for the billboard script that I have on the canvas. Nothing special on the camera Then I am assigning the render texture to a raw image in my gui. But you can see that the render texture is not even seeing the clouds before it gets too the raw image gui element. Thanks for any assistiance.
Edit: Looking more into this I think it might be do to the cloud layers being a cubemap... because Jupiter and Saturn dont show at all...
Edit Again: Yes it its finally! I made a new texture took the clouds out of the cube map and made them just a plain texture assigned them to a materal and replaced the hidden/SgtAtmosphereInner material with the new one and Tada! Is there a way to get this to work using your method?

 

As I said, SGT 2 and SGT 3 aren't interchangeable, so you can't make a scene with SGT 3 and expect it to work after you delete SGT 3 and install SGT 2 again.

The Mali 400 GPU issue is something I can't find a fix for. It looks like it's an issue with how the GPU handles floating point numbers, either it's automatically changing the float precision from what I've set, or some of the maths functions (e.g. exp, pow) aren't as accurate as they need to be for those shaders. I believe you can 'fix' this issue by disabling scattering, and in my testing I found the effect is less apparently in SGT 3, but ultimately this issue only exists on this GPU, and it's not an issue with my code.

I still can't replicate this issue in 4.6.1f1. The only issue I notice is that the atmosphere and cloud layer's alpha channel seems to overwrite the alpha value of the background pixels (planet), but otherwise it appears to render fine in the Camera Preview, the Raw Image on the canvas, and the Render Texture inspector. Maybe it's just an issue with Unity 5.

 

Hello Darkcoder,

This is really impressive package! A couple of quick questions for you: which kind of detail can I expect when going down all the way to the surface of the Earth? Is it going to be more than what's available in the online demo?

Cheers,

 

The Earth scene in the WebPlayer demo is just a textured sphere with an atmosphere applied. In the actual SGT package there is a more detailed Earth scene that makes use of dynamic LOD and a heightmap to give increased surface detail as you approach. If you want the surface to look more impressive then you would need to use some type of detail texture, as well as spawn stuff (e.g. trees, rocks) as you get closer, but none of the demo scenes do that right now. I do plan to enhance the dynamic LOD to include these kinds of features, but there are a few other features I'd like to focus on more. Feel free to ask any more questions you may have

 

HI there,

Thanks for this awesome package. I am learning the ropes at the moment and going through this tutorial:

However after purchasing the latest version I cannot find the 'SGT>Examples>Free Camera Orbit' or 'SGT>Star Component. Are these downloaded elsewhere?

Many Thanks.

 

These components were part of SGT 2, and no longer exist. In SGT 3 you have SgtMouseLook (SGT Mouse Look) and SgtKeyboardMove (SGT Keyboard Move), and the other components are in the same place, they work more or less the same. The same goes for the rest of the video content, it's a bit outdated, but many of the parameters are similar. I will update these videos when I have more free time.

 

I would like to know how did you make the displace on the previews example of snap to surface.

There is a star using a cloned and displaced cube mesh, I would just like to know how to do that

Could you tell me how to do that ?

 

You can use the 'SgtDisplacedTerrain' component to create bumpy planets. You can then call the GetHeight method from that component to find the terrain height underneath a given location. This isn't so easy to do right now though, so I'm currently working on a new SgtSnapToTerrain component, and example demo. I'll send it to you once I'm finished.

 

Why i'm getting this error, i added light source to planet.

Code (CSharp):

1. Shader error in 'Hidden/SgtJovian': failed to open source file: 'SgtLight.cginc' at line 41

And after this my planets go pink.

 

What version of Unity are you using? And what OS?

 

Unity Pro: 4.6.1f1 [-Android <DX11 on DX9 GPU>]
Graphics Card: Nvidia GTX570 [Latest Drivers Installed]
SGT: Latest and version before latest one i tried both same problem
OS: Android

Well it's okay when i export/build application, everything is fine. I only can't see stuff in editor as you can see on screenshot, which make's hard and slow to do changes. I have to build it to just see small change i made to planet.

 

I can't replicate this issue using 4.6.1f1 <DX11/9> set to Android.

Can you open Space Graphics Toolkit/Shaders/Resources and confirm that SgtJovian.cg is alongside SgtLight.cginc?

If so, did you move the main Space Graphics Toolkit directory anywhere? For example a Plugins directory or similar?

If not, can you right click the Shaders directory and click Reimport?

If none of this works, then can you open SgtJovian.cs in monodevelop or similar, and replace lines 41 & 42 with:

Code (csharp):

1.                 #include "Assets/Space Graphics Toolkit/Shaders/Resources/SgtLight.cginc"
2.                 #include "Assets/Space Graphics Toolkit/Shaders/Resources/SgtShadow.cginc"

 

Both file exist's in project.
I did moved it to folder name "Art" , now i moved it back to "root" project folder and clicked on reimport. It all works , thank you on your support. Ok so probably the problem was because i moved it to that folder. It's important that work's now, i have close deadline so, thanks again for your support.

 

Hi Darkcoder,

I know you said you are trying to reproduce the features of SGT2 in SGT3 but I was wondering if SGT3 will include something similar as in SGT2 that allowed to place the stars "on a cube" or "on a sphere" ?

My game area is actually a rectangle but I don't need the stars inside the area, just on the outer edges similar to the "on cube" option in SGT2.

Thanks,
Alf