Space Graphics Toolkit & Planets

WOW 0_0 QL

 

Hey everyone, SGT 3.3.4 has just been submitted for review! Here's a picture of the the kind of planets that can be created right now with the basic terrain shader and noise components.



3.3.4 also comes with the new SgtDebrisGrid component, which allows you to make infinite asteroid fields that can be bound to shapes like the SgtSphere or the new SgtBox, unlike the SgtDebrisSpawner, which simply spawns more or less debris based on your location within these shapes.

NOTE: If you're using Unity 5.6.0 or 5.6.1, then selecting SGT components that have the 'Camera Offset' setting (e.g. SgtStarfield, SgtAtmosphere) will spam the console with the following error: "In order to call GetTransformInfoExpectUpToDate, RendererUpdateManager.UpdateAll must be called first.". As far as I know this is a Unity bug that I can't do anything about, and you can safely ignore it. I find this error incredibly annoying though, so I won't be updating SGT to any version of Unity that still has this issue.

 

Hi Darkcoder,

I am wondering if the new version breaks anything because I updated before reading this and am using Unity 5.6.1. It seemed like the starfield and other scripts have moved or something like this because my sun and starfields can't seem to find the scripts anymore. I can revert to my previous version though so no real damage, but would like to know when you have a chance if I did something wrong when I updated.

Also could you please elaborate on what changed in this version and if I should wait on Unity's fix or can I use this as it is with Unity 5.6.1?

Thanks so much!
Django

 

3.3.4 hasn't been released yet (still waiting for Unity to verify it), here's the changelog for it though:

The moving starfields issue you mention has been fixed in 3.3.4, but it looks like I forgot to mention it in the log, thanks for reminding me! I've tested SGT 3.3.4 in Unity 5.6.0 & 5.6.1, and as far as I can see everything works identically to 5.5.0. The only major change that might require updating scenes is the SgtTerrain rewrite, but in terms of settings it's now quite simple so I don't think it's such a big issue.

If you'd like an early copy of 3.3.4 then I can send it to you though?[/quote]

 

Hi Darkcoder,

Thank you for your quick reply and the log changes! I don't mind waiting for the asset store, but if it is not much trouble for you to send me an early copy that would be much appreciated.

Best,
Django

 

Sorry if this is a stupid question or has been asked before. I'm new to unity and tried searching the thread and 34 pages is just a lot to go through. I'm looking to make a 2D 4X game. Everything I've seen is centered around 3D with SGT. Is it possible though to use the planet creation and such in a 2D environment? I know Unity 2D is basically 2.5D so I have my hopes, but want to make sure before I spend 100 dollars. Thanks.

 

Yes, SGT can work in a '2D' setting and I'm pretty sure some users have made 2D games with it. However, some of the shaders only do calculations in 3D and may not look correct with default 2D settings. For example, if you have a planet with an atmosphere that has a radius of 5 units, and your 2D camera is located on top of the planet with an orthographic size of 10, you would expect to see a planet that fills half the screen and looks great. However, in 3D this likely means that the camera position is inside the planet, so it will switch to the inside-atmosphere shader, and render incorrectly. To fix this you need to move your 2D camera back on the Z axis by at least 5 units so it's outside, and adjust your near/far clipping planes accordingly. If you have scattering or other settings enabled then 5 units won't be enough to get correct rendering though, so I recommend you move the camera back many multiples of your planet's radius (e.g. 1000 units), and adjust the near/far clipping planes accordingly. If you do this simple workaround then your scenes should render great though.

tl;dr position your 2D camera as far back on the Z axis as you can, and adjust the near/far clipping planes so the scene is still rendering, and it will work fine.

 

I understood about 10% of that. Suffice it to say it will work. Good enough for me. I'll figure the rest out on the fly.

 

This might be a beginner question or what not, but if its simple enough or difficult, how would I go about using (Q) and (E) to use as the pitch/turn the default fly camera? Or has this been discussed already?

 

I don't think it's been discussed. If you open SgtMouseLookFree.cs and go to line 60-61, you should see:

Code (csharp):

1. Remaining.x -= Input.GetAxisRaw("Mouse Y") * sensitivity;
2. Remaining.y += Input.GetAxisRaw("Mouse X") * sensitivity;

To change the controls you can either map Q/E to Mouse X/Y, change Mouse X/Y to a different axis, or add your own code to inc/dec the Remaining.xyz values based on Input.GetKey(KeyCode.Q), etc.

 

Ok thanks for the controls. I will try that. Also one last thing, as for the terrain mesh. How would I go about changing the mesh- for instance, to make the planet terrain LOD system look a bit like the image provided? Would I change/edit the patch (mesh filter), model? or is there another way of doing this. Not exact but something like this image for poly art...

 

Keep in mind your example image is very likely produced using poly reduction, as the triangles appear to be differently sized. You can modify SgtTerrain to be faceted/poly art, but it will never be able to produce that kind of topology.

The easiest way to achieve this effect using SgtTerrain is to just use a shader that modifies the mesh data like THIS. Another approach is to just make the planet in another program, poly reduce it, and use it as a static mesh. If these approaches isn't suitable, then you'd need to modify the mesh generation code.

The modifications required must be done in SgtTerrainLevel.cs line 174+, which is where the vertex and index data for each face's LOD level is calculated. Right now this mesh data is laid out in quads, where the vertex data for all the quads inside the ring.Outer rect are written, and the indices for the quads inside that and outside ring.Inner are written. The vertex data is laid out such that every quad shares vertices with its neighbours to save memory, but for a low poly effect you must remove this optimization, and write unique vertex data for each triangle. You'd also need to modify the index calculation code to account for this.

Keep in mind the code is a little complex due to optimizations. For example, to avoid writing the same vertex data all the time, the quads are checked against the previously written quads (lines 202-206), the vertex data is written to a kind of rolling buffer (line 208), the normals are calculated from the positions and written after position generation (line 228), then the edges are overwritten by parent data to avoid seams (lines 233-236), normal calculation requires knowledge of positions outside the quad bounds (line 185).

 

Hmm ok noted. Thanks for the help. I will try another solution.

 

Hello,

first of all congrats on this plugin it is just incredible! I like it a lot!


My question is if I'm using lod terrain on planets and enable the collision generation the framerate gets rather slow and choppy everytime it loads more collision tiles.

Am I doing something wrong or is this WIP?


Thanks for your awesome work!

 

This feature is indeed WIP, and I have some great ideas to optimize it more. There are limits to the optimization though, so if possible try to work around the use of colliders. For example, from an SgtTerrain instance you can find the height under a specific point, which is great for player movement or similar, and if you need an actual mesh collider under a specific point you can use the SgtTerrainPlane component.

 

Hi!

Is there any way to point the billboarding of the SGT assets towards a specificed location? I'm working on a mobile VR app and it can get especially weird if there are large particles all around you since they end up looking like they're rotating(which they are) to always face you.

 

If you know how to tweak shader code, sure.

For example, in SgtPointStarfield.shader, the billboards face the camera because all 4 corners are given the same position and transformed into view space (line 133):

Code (csharp):

1. float4 vertexMV = mul(UNITY_MATRIX_MV, i.vertex);

They're then pushed apart based on the input normal, and transformed into projection space and output (lines 147, 152, 154):

Code (csharp):

1. float4 cornerMV = vertexMV;
2. ...
3. cornerMV.xy += i.normal.xy * radius;
4. ...
5. o.vertex    = mul(UNITY_MATRIX_P, cornerMV);

You'll notice they're pushed apart on the xy axis only, this is because view space is rotated to the camera, so +x is always right, and +y is always up.

So if you want to rotate the billboards toward a specific point then you must pass that point to the shader as a float3, get the float3 vector between the vertexMV and your point, construct the rotation matrix from this, and multiply that matrix somewhere before it's output.

 

Hey everyone, here's a sneak peak of a feature I'm adding to the next version of SGT:



If you didn't guess, it's a star surface shader that is not only procedural, but animated! This means you can easily fill your games with lots of different looking stars that look great up close, use little memory, and have no texture seams.

 

I'm going to assume you updated the Solar System pack to only work with Unity 5.5 since it crashes Unity 5.4 and all the prefabs are blank. Once again I'm disappointed in this asset.

 

Indeed, I always update SGT and the packages to use the latest Unity features and new design ideas, which will make backwards compatibility difficult/impossible.

If you're using an older version of SGT then you can still get old versions of the packages from the repository linked on the first post or my website though, I thought it was marked quite clearly?

 

By far still my favourite asset I brought this like over a year ago and it is still being updated! Would it be possible to have like animated storms? Like the swirl on Jupiter? or even earthly weather or planet deformations.

 

The problem with animated gas giants is that they require a lot of difficult to create media to look good. Take a look at Space Engine for example, that Jupiter looks great, but it uses 10 layers of clouds, and even then the Great Red Spot doesn't animate. Getting it to animate would require interpolation between many frames, which is possible, but who is actually going to create all this media just for one planet?

One alternative is to create a flow map and interpolate around the base texture, which I may experiment with, but still, making that texture is quite difficult, especially for a cubemap.

Another alternative is to make a fully procedural gas giant shader that does this kind of swirling for you, but to date I haven't seen any such shaders that I think look good, which leads me to believe it's incredibly difficult to make such a shader. If you do a quick google search for prcoedural gas giant you'll see basically all of them look like marble or otherwise nothing like a convincing gas giant. So even if I were to make one, there's a very high probability that it would require SM3.0+, and thus be incompatible with many devices.

You can already deform planets using SgtDisplacedMesh or SgtTerrain, and add basic weather using SgtLightningSpawner and SgtCloudsphere. I hope to extend SgtCloudsphere in the future to spawn actual clouds when you get close, but there are a few more important things I'd like to do first.

 

For Gas Giants , you will need real Fluid Dynamics to look god , one way is to do simulation in Maya or Houdini for example , export animated textures with flow maps , perhaps . Have seen those kind of technique , but not used in games . And maybe based on those maps add procedural details ?

 

Having an issue with the new update. Not sure why.



Using Unity 5.6.1f1 Personal 64-bit


EDIT: Think I figured it out. Needed to delete the old SGT import, then re-import. Now down to one error, and it's in my code. Probably some reference to a file in the old SGT that doesn't exist anymore. (And yes, I was using a really old version of SGT there)

 

Yeah, I imagine fluid dynamics would be required. I don't have Maya or Houdini though, and writing or modifying my own sounds like way too much work. If anyone can find or generate such flow maps I could try writing such a shader though.

Scared me for a second there Yeah SgtCorona was removed a while back. Some of the older change logs warn you about having to back up, delete the old files, then update.

 

Would like to make a suggestion for your spherical terrain, not sure if anyones thought about it. A terrain blocker for creating caves and things like it. Was thinking something like a capsule collider that would hide that part of the terrain mesh (replacement shader?) and terrain collision. Then you can toss your cave entrance on top of it. I would love to implement something similar but only have vague idea where to start and I am not that great of a programmer yet.
Thank you and Awesome pack!!
~Ark

Also I had an idea about the storms on gas giants, you can make a hemisphere mesh, put your "Storm" on it and have a SGT compatible shader that uses something like this but not for ui obviously. Then add a noise to the transition for a "flow" and rotate the storm around the planet. If done right it might look fairly decent, though this is where my programming lacks the most.

So I had some time when I got home to play with Substance designer and Shader forge and this is what I came up with for animated storms.

 

Apparently the forums wont let me edit my original anymore so I had to attach it as a second post. This one looks much better.

 

First of all, thank you for these assets! There are so useful and well designed.

I encounter a rendering problem with planets that use the Jovian component. Indeed, my LineRenderer components or simple GameObject components that cross these planets are not hidden. So we see them inside.



I tried to play quickly with shaders (tags, zwrite etc.) and with render queue variable in Sgt Jovian script, but without success. Do you have any idea how to solve this?

Thank you,

Kadaj

 

Step 1 - Change the Render Queue on your orbit ring material to 3002 or higher.
Step 2 - Select your jovian GameObject's child called 'Model', and find the MeshRenderer/Materials array.
Step 3 - Find the Space Graphics Toolkit/Examples/Basic Pack/Materials/DrawDepth material, and drag and drop it into the array in step 2.

I'll add a demo scene or tutorial to the next version to help future users.

P.S. Great looking project!

 

Perfect, this works great! Thank you very much for your quick reply.

 

Hello, how could I add collider to the terrain LOD? When playing around with the default terrain procedural and regular planet terrain, the camera collides with it. Is there a way to do this with a custom camera? or say I have a ship with a camera parented, how can the ship collide with the terrain?

 

The 'MaxColliderDepth' setting can be used to generate colliders.

The SgtKeyboardMove component collides with planets by checking the distance between the camera and the terrain, then repelling the position if it gets too close. You can look at the SgtKeyboardMove.RepelPositions method to see how this can be implemented.

 

I discovered a few days ago your work on the Milky Way, it's awesome! The rendering is so beautiful.

I would like to use these assets in my smartphone app. But, they seem very resource intensive. The maximum I can show on the screen, it's more or less 2000 clouds (on Sgt Nebula Starfield component) and 2000 stars (on Sgt Spiral Starfield), at about 40 fps. Unfortunately, the rendering below 5000 clouds is not great.

Do you have an idea for optimize the performances? Because the rendering is so beautiful, that it would it's a pity be not to take advantage of it.

Thank you again!

 

The performance of nebulas is almost entirely based on the fillrate of your device. For example, if there is one nebula cloud in front of the camera at full size on an iPhone 6 then that's 750x1334 or 1000500 pixels being rendered. If your nebula has 10 similar clouds also in full view, then it's 750x1334x10, so the performance can very quickly go down.

To reduce the amount of pixels drawn you must reduce the cloud count and increase the cloud size to compensate, but this will trade off quality for performance. If the quality or performance is still unacceptable then you can re-design your camera movement system so it doesn't get as close, or replace the nebula clouds with a flat plane that has your galaxy texture.

 

Hey Darkcoder,

Just updated to 2017.1 and found a bug. If you click on SGT object (or its child gameobjects) both in hierarchy or scene view, you instantly get a lot of error messages. In my case it happens in demo scenes with flares or singularity.

 

Thanks for pointing this out. As far as I know this is a bug with Unity that was supposed to have been fixed in Unity 2017. I noticed the error in 5.6+ and made a note in the upgrade notes. Luckily, this bug doesn't seem to have any adverse affect on the way SGT works, so you can just ignore it until it gets fixed or a workaround is found. I'll do some searches and see what's up.

 

BTW, also wanted to ask. I get a little bit different error message when click on gas giant in the scene view, though it doesn't affect anything (or at least i didnt notice). Is it a unity bug too? Here's how it looks, took from demo scene:

 

Hey Darkcoder.

I'm enjoying your product since I bought it one year ago. As you are still developing and adding to it (and I hope you wont stop that^^) I want to add a (non-important) feature-request: an (artistic) neutron-star

 

As far as I can tell this is indeed a Unity bug, since the _MainTex in question is marked as a cubemap, and the texture it's assigned is also a cubemap.

If I knew what one looked like I would, but every artists' rendition looks drastically different. Isn't it basically some combination of the accretion disc, corona, and some star texture?

 

Well, here is how it could look like
P.S. Neutron star at 0:35

 

Basically yes. However, like Infernno has added, a popular artistic conception is to add one (glowing, shining, slightly moving) axis which goes through the star (iirc: rays leaving that star).

 

I see, so you're talking about the beams coming off pulsar neutron stars. The effect in Elite is certainly very cool, but it doesn't really look realistic at all based on my understanding of how they work. Here's a video that's closer to what I'd like to implement:

The main difference between this and what I envision though is I'd want the beam to actually spiral out, and not be some perfectly straight beam. In Elite it looks more like the star is emitting high velocity smoke in an atmosphere.

 

That sounds really nice! I will be happy to see it in a future update

 

I am trying to figure out how I would mousedrag a planet in real time so I can adjust the orbit radius in real time by clicking and dragging it on the z axis? I know how to do this with buttons example below..any pointers?

Code (CSharp):

1.        
2.  
3.     public GameObject Target;
4.  
5.     // Use this for initialization
6.     void Start () {
7.        
8.     }
9.    
10.     // Update is called once per frame
11.     void Update () {
12.        
13.         if (Input.GetKey(KeyCode.KeypadMinus))
14.  
15.          Target.GetComponent<SgtSimpleOrbit> ().Radius -= 5.0f;
16.  
17.         else if (Input.GetKey(KeyCode.KeypadPlus))
18.  
19.         Target.GetComponent<SgtSimpleOrbit> ().Radius += 5.0f;
20.  
21.         }
22. }
23.  

 

What do you mean by Z axis? To check X or Y screen axis you can add a sphere collider to your planet, then listen for Input.GetKeyDown(KeyCode.Mouse0), and cast a ray into the scene from Input.mousePosition, if it hits then toggle some value like 'isDragging', then adjust the .Radius value based on mouse position changes, and when Input.GetKeyUp(KeyCode.Mouse0) is detected, toggle 'isDragging' to false.

 

Maybe try something like this (pseudocode):

Code (CSharp):

1. public SgtSimpleOrbit Target;
2. private float relativeY;
3.  
4. void Update() {
5.  
6.     if (Input.GetMouseButtonDown(0)) {
7.         relativeY = Input.mousePosition.y;
8.     }
9.  
10.     if (Input.GetMouseButton(0)) {
11.         Target.Radius += Input.mousePosition.y - relativeY;
12.     }
13.  
14. }

However, this is more like a general scaling problem - you should get better answers in the Unity Answers section

 

Thank you. I have just used raycast to set a target on another script then used some buttons to move the orbit radius pretty cool. Now just wondering do you how would I draw the orbit gizmo ideally when the orbit radius is being changed only and in game view.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class OrbitRadiusControl : MonoBehaviour {
6.  
7.     public GameObject Target;
8.  
9.     // Use this for initialization
10.     void Start () {
11.  
12.     }
13.  
14.     // Update is called once per frame
15.     void Update () {
16.  
17.         if (ControlFreak2.CF2Input.GetKey(KeyCode.KeypadDivide))
18.  
19.             Target.GetComponent<SgtSimpleOrbit> ().Radius -= 0.2f;
20.  
21.         else if (ControlFreak2.CF2Input.GetKey(KeyCode.KeypadMultiply))
22.  
23.             Target.GetComponent<SgtSimpleOrbit> ().Radius += 0.2f;
24.  
25.     }
26. }
27.  

@Drakons. Thank you for the pointers.

 

Per https://forum.unity3d.com/threads/space-graphics-toolkit-released.147954/page-33#post-2969682 SgtDepthTextureMode is still in the Examples sub-directory (so produces a compilation error if you don't import Examples).
Thx & HTH

 

Question about the SGT Thruster- so after bringing them into the scene- say I have a ship with rigid body, same as the demo scene - I can't activate them as the demo scene. The thrusters stay on. Also how would I map them to the controls or better yet map them to my controls since my ship is using the analog stick for mobile controls on the screen for instance?

Thanks

 

The way the thrusters work is they maintain their current throttle value, and therefore the on/off mechanism must be controlled by another component. In the Thruster demo scene, this is controlled by the 'SgtKeyboardThruster' script.

This script uses Unity's built-in control axis system, so you should be able to map it to your gamepads like any other control. I recommend you examine the Thruster demo scene to see how these features are linked up, since it can be a bit confusing to explain.