Space Graphics Toolkit & Planets

Success, it's looking very nice, I have also updated cloudsphere shader by adding Offset -1, -1 on line 37, thank's a lot's!

 

Hi, I'm comming back!
From this morning (it's 20:49), I'm trying to render correctly your shaders, but I thinks they didn't like multiples camera (layered) and multiples sunLight (layered), atmosphere is blinking, and a bit bright.
And, did it's possible to update the displaced terrain script to have each submesh with custom pivot center, and not the planet center?

Thank's!

 

Did you attach the SgtObserver component to each of your cameras?

To change the terrain patch pivot point you need to modify the code in SpaceGraphicsToolkit/Scripts/Library/SgtPatchBuilder.cs line 14-17. By default the patches all have a transform.localPosition of 0,0,0, and the patch.PointBL/BR/TL/TR are used to specify the local coordinates for each corner. So if you want a custom coordinate then set the transform.localPosition to whatever you like, and subtract this value from the pach.pointBL/etc values.

 

Hi Darkcoder,

I am very interested my your SGT and have been meaning to get for quite some time, but I need to get a few questions out of the way before:
1. Is there a way to get the mesh data of SGT planets? From what I have read the SGT planets support cubemaps which are made out of 6 meshes? To be exact, I want to somehow be able to integrate some existing pathfinding solutions. All I need is to get the mesh data to generate the pathfinding grid.
2. Does SGT's cloud layer support volumetric clouds in any way? If not, is it hard to implement this myself?

Thank you!

 

1 - there are two types of planet meshes in SGT. One where you specify the mesh(es), so basically a static planet. And the other is runtime generated based on camera distance.

The generated meshes are stored in the SgtPatch component, and you can easily access the meshes using the .Mesh field. You could also insert some code into the SgtPatchBuilder so you can set up your path finding as soon as the patches are made.

Though I imagine setting up path finding on a constantly updating mesh set like this would be expensive, so you might be better off using a lower resolution static mesh for that. Alternatively you could limit the path finding to a certain LOD level, similar to how the SGT patch collider code works.

2 - the cloud layer isn't volumetric, but if you want to make a shader based volumetric effect then it should be fairly simple (e.g using a ray-marching like effect).

 

Ok, I successfully solve the shader bug, thank's a lot, but for the submesh position I think's you didn't exactly understamd what I need. Here a picture for helping.
Can you help me? I need it to solve totally the floating point position issue, because when my camera is on the surface with the center of the engine (Vector3.zero) near to the camera (for accurate position), the center of each subdivision is too far on a big planet (example: 6371000 for the earth). I will need what you explained before, but for now I need the same think's you explain me before, but with negativeZ and all others!
Thank's!

sorry again for my bad english!


EDIT: I think I found where is it!
EDIT2: did it on line 276 at "patch.MeshCenter = patch.Mesh.bounds.center;"? You killed me with your script..

 

Ok I did it successfully! (awesome)
Thank's a lot!
If somebody need the same modification here the solution:

Adding a function to SGTPatchBuilder:

Code (CSharp):

1.  
2.     private static Mesh UpdatePivot(Mesh mesh, Vector3 diff)
3.     {
4.         Vector3[] verts = mesh.vertices;
5.         for (int i = 0; i < verts.Length; i++)
6.         {
7.             verts[i] += diff;
8.         }
9.         mesh.vertices = verts;
10.         mesh.RecalculateBounds();
11.         return mesh;
12.     }

Then replace the line 276

Code (CSharp):

1. patch.MeshCenter = patch.Mesh.bounds.center;

by that:

Code (CSharp):

1.  
2. patch.Mesh = UpdatePivot(patch.Mesh, -patch.MeshCenter);
3. Vector3 parent = Vector3.zero;
4. if (patch.Parent != null)
5. {
6.     parent = patch.Parent.transform.position;
7. }
8. patch.transform.localPosition = patch.MeshCenter - parent;
9. patch.MeshCenter = patch.Mesh.bounds.center;
10.  

Warning: this need to keep scale of the planet to 1,1,1

 

Trying to update our game from Unity 3.x to Unity 4.x and the latest SGT. I'm getting these build errors.

"The name xx does not denote a valid type" where xx is:
SGT_Planet
SGT_SurfaceTessellatorCollider
SGT_GasGiant

I can't find an equivalent "SgtPlanet.cs" or "SgtGasGiant.cs" or "SgtSurfaceTessellatorCollider.cs". (Our code is written in UnityScript.)

Any tips or suggestion on how to proceed? (Our original developer is with a different project, so I'm getting a crash course with SGT.)

Thanks!

 

SGT 2.x and SGT 3.x aren't interchangeable, because it was completely rewritten and redesigned. However, the class names and such are different, so you can install both major versions at the same time without any conflicts. If your project was designed with SGT 2.x then you should keep that, and maybe use SGT 3.x for any new content you add, or stick with SGT 2.x until your next project if you're concerned about having loads of shaders and scripts in your project.

For example, the SGT_Planet (now SgtAtmosphere & SgtCloudsphere) component has completely changed, so to port an SGT 2.x planet to SGT 3.x would pretty much require you to set it all up from scratch.

 

Thanks for the quick reply! My main worry is that Unity 4.6 takes hours (like, more than 6 hours) to compile all the shaders in our game. On both multi-CPU/core OS X and Windows 7 boxes with PC and Mac target builds. (Previously, we used Unity 3.5.) I thought this shader compiler problem might have been due to the shaders of the older SGT, and that the new SGT might behave better.

The last build I attempted ran over 12 hours, and I ended up killing Unity. It was stuck at the shader compilation stage on both boxes.

 

12 hours for a build is ridiculous. I just tried building all the SGT 2.7.6 demo scenes using Unity 4.6, and it took less than a minute, so there must be some other issues with your project.

 

I agree. Unity is not helpful here since I can't tell what shader(s) it's choking on while compiling. Will have to do some more digging. I appreciate the datapoint.

 

Hi Darkoder,

I have a question about SgtSpacetime component. Is there a way to replace the plane meshes with lower poly ones?
80k tris make the scene a bit laggy on older generation mobiles(Galaxy S2).
What is the lowest level you recommend to use? And i know that the deformation effect will look more ugly but it should be a tradeoff.

Thanks

 

In the SgtSpacetime component you can see the 'Renderers' List, this allows you to set the plane meshes (make them in your scene and drag+drop them in).

You should set the meshes to be at least the minimum size of your spacetime warps, I made the mesh detailed in the demo so you can easily play around with the settings and still keep a good level of quality.

 

Hi,
Would it be possible to release the code you used to generate the geospheres? I'd really like one equivalent to a geosphere15 (the geosphere10 is too low, 20 is too high).

 

The geospheres were made using 3DS Max, so there's no code to look at. But I just made Geosphere15, and you can get it HERE.

I'm sure Blender or other software can also make these geospheres. The reason why I didn't provide the original mesh files with SGT is because importing fbx files has issues with rotation, scale, etc, and the shaders required very specific settings which are very easy to mess up. For example with the Geosphere15 I linked to above, you must set the mesh Import Scale to 1.0 for it to work correctly with more of the shaders.

 

I pre 3.0 you provided some surface sphere meshes 5,10,20,40 you should include them in the new version or in graphics add-on package, because not everyone are capable to use 3DSMX or Blender.

 

Darkcoder, I went through and replaced every shader in the game with the simplest possible one, and it turns out SGT was the problem. But we were using version 2 so that may explain it. Is there a way to get the last version 2.x (I think you mentioned you tested with SGT 2.7.6)?

 

You have really strange problems and i think you get some files corrupted. I'm working right now with a 2GB repository 10 scenes and compilation time on Android is max 5-7 min on MBPro i5 SSD+8Gb RAM, and i don't have any issue with SGT Library.
I can suggest you just to export everything from your current project as a package and reimport again in a new clean project.

P.S. Forgot to mention, i'm using Unity 4.6

 

Liviuss, we have not modified any of the shader files in our project. Since upgrading from Unity 3.5 to Unity 4.6, these are the only files I tested by replacing their contents with a bare-bones basic shader to isolate the ones that are causing builds to take a long time or hang. Therefore, it's very unlikely to be a file corruption issue since they're fresh installs from our Unity asset server.

Are you using SGT version 2 like we are? (We will eventually migrate to the latest SGT probably with Unity 5.x, but we need this intermediate solution now.) I suspect that the last SGT 2.x version has proper shaders as Darkcoder tested above with Unity 4.6.

 

Nope, but my prototype started with 2.x version and i didn't noticed any issues. For the sake of experiment, can you export/import the SGT version you use into a clean project and do a compile/deploy with a simple SGT object on scene? Also it would be good to investigate assembly log file maybe you will get there some clues.

 

I just sent you SGT 2.7.6.

The main issue with the shader system in SGT 2 is that I made a separate shader for each variation, and this caused a lot of extra processing (hence why I added the Shaders In Build wizard). I did this because SGT was released before Unity's multi_compile shader directive was added, so this was the only way to change a shader's capabilities at the time.

In my testing this shader replacement approach wasn't too much of an issue, and indeed as I test it now I still get good compile times (even faster than before if anything). So it sounds like the issue is when you combine all these SGT shaders with other shaders/code/assets that you see massive compile times.

The best way to test what's causing it is to make a test project and slowly add everything in one at a time.

 

Hi Darkcoder, about SsgtSpaceTime component, it would be nice if you in new versions will implement auto-collection of SgtSpacetimeWell components on startup and a method to register new ones in case of spawning.

 

I'm still experiencing a bug where 'SgtObjectPool<>' gameobjects travels across scenes.This is not fixed in the newest version of SGT.Any ideas how to fix it?

 

+1 have the same issue

 

Send me too

 

Is this during play mode? If so, that's intended. The whole point of the pooling system is to lower the amount of times an object or GameObject gets allocated, which makes your game faster, especially when switching between scenes that use SGT stuff.

If you hate pooling that much then open up SgtObjectPool.cs and after line 110, add: return null;

Alternately, you can call SgtObjectPool<ObjectnameHere>.Clear(); if you simply want to free up memory.

 

I get SgtObjectPool in every scene i open to edit, not in play mode.

 

Which version of Unity are you using, and which OS are you running it on?

 

MacOs 10.10.1 SGT 3.0.3 Unity 4.6.0f3

 

Yeah it looks like there's some difference between how the Windows and Mac editors work. I'll send you a build as soon as I update everything.

[edit] It seems like you have forum PMs disabled so I can't.

 

Just enabled PM-s so you can send now, thanks )

 

Just sent you a PM.

Oops, I missed this post.

This feature has now been added to SGT 3.0.4. So in the SgtSpacetime component you can just enable 'Use All Wells', so you no longer have to populate the list yourself.

 

While I think this asset is great and I like a lot of the new features, I just wanted to register a vote for putting the old geosphere sizes back into the package. I work on mobile and geosphere40 has an order of magnitude more polygons than I need or want.

I had a go at fixing the sun model by copying the some of the old geospheres from V2. I could replace the main sun mesh, but I can't replace the SGTOuterCorona mesh. It just rejects any other mesh I drop on it without any errors or messages. What do I need to do?

 

You're right, the Geosphere40 is too high detail and I'll include alternatives in the next next release.

There are two types of spheres in SGT 2: normal ones (Surface, Clouds), and inverted ones (Atmosphere, GasGiant, Skysphere). In SGT 3 I made it so the mesh inversion takes place in the shader, so you just need to set normal sphere meshes. So if you want to use the ones from SGT 2 then use the Surface meshes.

 

It is possible to add "softness" to the starfield shader? I try to make a volumetric fog in space, this works very well but a softness in the shader would be good.

 

To make the points softer you just need to increase the 'Star Radius Min' and maybe Max values. The reason why your stars look so sharp is because they're so small that they are likely only taking up one pixel on your device, thus the star color can only be black, or some shade of white/color.

If you increase the radius and still have issues then try adjusting the texture applied to the stars. If you look at the example star sprites that SGT comes with, you'll see they're pretty much blurred circles. So you can easily make your own ones that are smoother, or sharper.

 

Thanks for reply! I mean not the small stars (points), i mean the fog like in the 2 images below.
I use the "SGT Wrapped Starfield" with big textures for the fog between asteroids. But i think the starfield shader needs a smoothness to "blend" with the other geometry.

 

Ah. Doing soft particles like that requires the use of render targets, so I didn't think to add it in.

However, looking at the soft particles shader that comes with Unity makes this looks fairly easy to add, so I'll see if I can get something working tomorrow.

 

Ok, that would be really great. With this we can make beautiful volumetric fog/clouds. Thanks in advance.

 

Check your PMs. I sent you the latest build with this feature.

 

I have a question related to starfields generator, related to both Eliiptical and Wrapped. I'm trying to add some noise(dust) to the scene but i can't get rid of "enable/disable" effect of the stars. I think it's something related to the way the stars get culled.
You can check this https://drive.google.com/file/d/0BxVp4Kknjm_iMk1MVDN5R1ptc0U/view?usp=sharing to see the effect.
The scene use Eliiptical starfield with fade near/far disabled. Scene is XY with Z as depth. Radius 1000 and the player is almost in center. There are 1k stars with size 100-300.

 

The 'enable/disable' effect is caused by the 2d/3d wrapping of the starfield. Basically, when a star moves 1000 (or whatever distance, defined by the 'Size' setting) away from the camera, it will be teleported to the other side of the camera. This gives the illusion of an infinite starfield, but obviously if your starfield is small then it's very easy to notice when they teleport. In order to hide this teleporting effect, I implemented the 'Fade Far' feature, which allows you to make this teleportation less obvious.

For example, open the 'Infinite Starfield 2D' demo scene, hit play, and hold Up/Down/W/S. Here you can see the stars obviously teleporting from the front to the back, and vice versa. However, if you enable 'Fade Far', and set the 'Fade Far Radius' setting to 100, and set the 'Fade Far Thickness' setting to 20, then you can see the teleportation is no longer noticeable. You can improve the demo scene even more by increasing the 'Size' X and Y values, and also increasing the 'Fade Far Radius' setting accordingly.

 

Work like a charm, thanks!

 

Hi, I am having issues using the old Spaceship thrusters.
If I copy/paste the whole spaceship from the example, it works fine.
But when I try to copy individual thruster components in my own spaceship, then I add a ThrusterController and add in my thrusters, it does not work. I get the following error when I set the Throttle :
"Can't add component 'MeshFilter' to Flame because such a component is already added to the game object!"
"Can't add component 'MeshRenderer' to Flame because such a component is already added to the game object!"
"NullReferenceException: Object reference not set to an instance of an object"

It does that when manually setting the throttle in the Thruster Gameobject, in the editor.
There is no thruster effect visible.

The other ship copied from the example scene works fine, and seams to be configured in exactly the same way.
Thank you for your help.

 

If you copy and paste the individual components then the 'new' thruster component will still have links to the 'old' thruster, because it's copying all the data across. Making this copy/paste behavior work properly for complex scripts like SGT_Thruster is incredibly difficult, and I still don't have a decent solution for it that doesn't have tons of overhead.

Your best bet is to just duplicate the thruster GameObject itself, because that causes the copy/paste behaviour to be much more smart. If you really must use the copy/paste component method, then try putting the inspector into debug mode, and changing all the 'thrusterFlameMesh' and 'thrusterFlareMesh' Object references to null. This is an issue that I intend to improve in the future, especially when I get around to rewriting the thruster component.

 

Thank you very much, It solved my problem.
Quick Solution : Duplicate Thruster from example, move it to new spaceship, change rigidbody reference, add thruster in ThrusterController.

Very good customer support, especially considering the fact that today is christmas !
Thank you.

 

I'm having a weird issue with the atmosphere component. I'm using Unity 5, so that could be why I'm seeing it, but just thought I'd toss this here to see if there were any quick solutions. Basically, it looks like the outer atmosphere is showing through as pure white.

 

Does the atmosphere work correctly in the demo scenes? If so then can you post a picture of the SgtAtmosphere component's inspector settings?

 

Atmosphere seems to work all right in the earth demo. Here are my settings: