Space Graphics Toolkit & Planets

I sent you an early copy of the SgtBoxStarfield component which brings this functionality back. It will be included in SGT 3.0.7.

 

Thank you so much again for the hard work and the support !!!

 

I was going to try building something with the Displaced Earth component, but when I loaded up the example I got a massive and sustained FPS drop (down to 3) upon zooming in.

 

Did you upgrade to SGT 3.0.6, which has a much faster SgtDisplacedTerrain component?

 

Does it require Unity Pro? I'm running Unity free.

 

No, SGT will always support Unity free for the majority of its features.

 

It seems to be related to SgtComponentPool<SgtPatch>; when I delete this the framerate returns to normal.

 

I can't replicate this, what version of Unity and OS are you using? The patch pool just stores a list of disabled patches and otherwise does nothing at runtime, so I'm not sure why it would cause any slowdown.

 

Unity 4.6.1f1 on Windows 8.1 x64. I'll try again to verify, but it definitely seemed like deleting that restored the framerate.

 

Darkcoder, does the new version of SGT support building Windows Store apps? (I apologize if this was already asked)

Thanks!

 

1) Sometimes during work I get this error:

It occurs in demo scenes too.
2) Skysphere component is now deprecated? Can't find it in 3.0.6
3) Also if you increase planet's scale (with 'Displaced terrain' component on it) some *artefacts* appear

 

Sorry, I thought I had followed up on this. I found the cause of the problem: apparently, having the ICanScript visual scripting library in your project results in massive slowdown in this scene.

... I cannot fathom why.

 

A minor issue I haven't seen before changing to Unity 5.

With HDR enabled the stars(sgt starfields) behind rings and jovians(when smoothing is disabled) turn up as black spots. You can also see other planets through them. Render queue offsets doesn't amend this.

 

Does the toolkit allows applying different color schemes within a volume? For example, if I wanted to show the earth crust in one color, and as I navigate inside towards the mantle, I wanted to show a different color scheme. Wondering if this is possible.

Thanks,
Vijay.

 

Hmmmm... I'm having serious problems with fairly simple scenes now that I have upgraded to Unity5. I have the personal license, and previously I had the free license.

My issue is that my frame rate has dropped from totally smooth to maybe 5 FPS. All I have done is upgrade my project to 5, and re-downloaded SGT to update it.

NB: This frame rate drop is not happening on the demo scenes.

I have a basic solar system created with only 3 planets (Mercury -> Earth), and of course the Sun. In 4.6.x, this ran completely smoothly, as did much more complex scenes (as do very modern games on maximum graphics). Now I can't seem to get it above 5 FPS no matter what I change.

I have tried:
Disabling shadows
Reducing aniso levels
Looking at scenes with JUST a central sun
Reducing geosphere from 40 to 20
Reducing my galaxy background stars to 1/10th

Please note, my central sun is a point light and uses corona, atmosphere, and prominence. My planets have virtually the same stuff the examples do, except for my own code which is (at the moment) doing little more than telling the planets where to be.

One thing I have noticed is a new message on the Mesh Renderer that wasn't present on 4.6:
This renderer has more materials than the Mesh has submeshes. Multiple materials will be applied to the same submesh, which costs performance. Consider using multiple shader passes.

This message is present on every SGT object in my scene. It seems to be because of the SgtAtmosphereInner material element on the Mesh Renderer. However, as I said, this isn't happening in 4.6.

 

Use the profiler(ctrl+7 shortcut) and you'll be able to track down what causes it.

 

It's apparently physics processing of several sorts. The thing is, I'm not using Unity's physics at all. I need the colliders for ray tracing purposes and to block lens flare, but other than that, I don't use them. I have no rigidbodies, or any other physics related controls. Is there something in SGT that is using physics?

EDIT: Clarification, I am also not using SGT physics for anything. At least, not intentionally. I manually calculate the orbits of my planets using an elliptical formula. I am not using SGT's gravity.

Items that I use from SGT:
Atmosphere, cloudsphere, corona, prominence, elliptical starfield, nebula, Earth shader, several textures and cube/bump/etc maps, and the geosphere meshes

Additional things I have tried:
Shutting off colliders of objects in solar systems that aren't being displayed (should have done this anyway)
Adjusting physics settings to minimize calls

Final note: thank you for pointing me at the profiler. Since I have only had free versions, I was never able to use it until now. However, the profiler is reporting that the physics calls are coming from object "N/A". Each of the various calls has a huge list of these "N/A"s that are making each kind of physics call. Obviously, if the object is marked as N/A, I can't tell which object it is coming from. Could it be the starfield's sprites are somehow generating physics calls now? I literally have 100,000+ of them for the Milky Way in the distance. Though, as I said above, I tried cutting this back to 1/10th to no effect... Any suggestions? Anything in SGT that might be using physics that I am not aware of?


Final edit:
Found a work around. I have edited my fixed timestep to be 10. This apparently slows down physics calculations. Since I am only using colliders for ray tracing and the like, I do not need physics calculations at all. Now my physics calculations happen every 10 seconds! It's smooth as glass again! Yay!

 

If you're just applying mesh colliders to the geospheres try replacing them with simple sphere colliders and scale the radius to match the planets, it worked for me.

 

That's what I am already doing.

 

Glad to see that this package was not abandoned and received a lots of love
BTW did you completed the surface LOD , to simulate atmospheric re-entry? I was checking the demo page and among them I don't see any example of LOD.

 

Hey guys,

Attempting to purchase through the asset store (within Unity 5 itself not on the website) it pops open a warning that this asset was built using Unity 4 and may have incompatibility issues.... before I throw money at the screen to buy the space pretties, how incompatible is it actually with U5?

 

As for me, the latest version of SGT is working well with Unity 5.
P.S. It pops because the asset should be *republished* with the latest version of Unity.

 

Here is a feature request: I want to be able to set cloud depth with a texture. That way I could make some clouds that actually have some definition instead of just being flat.

 

I'm using Unity 5 (HDR enabled, Deferred rendering) and I am seeing the gas giants exhibit odd behavior. They seem to be transparent!

The orange objects in this screenshot are opaque objects behind the gas giant.


Any tips on how to fix?


EDIT: This seems to be due to the ambient light level being below 1.

 

Also, I get much better looking Jovians when I change this line in SgtJovian.shader:

Code (csharp):

1. lighting += scattering * i.texcoord2.w * (1.0f - i.texcoord2.w); // Only scatter at the edges

to this:

Code (csharp):

1. lighting += scattering * i.texcoord2.w; // Only scatter at the edges

That change eliminates the blackness that eats away at the edge of the jovians when scattering is turned on and the camera is at a low angle between the light and planet and inside the planet, which seems to only be present in Unity 5.

 

Have the thruster examples been added to the new versions?
I can't find my old pack and wanted to check them out.

 

No, there is no thrusters example in SGT3 yet.

I am looking forward to seeing volumetric probes again!

 

Sorry for not replying guys, this forum's notification system is really bad. In the future, please e-mail or PM me, or scream at me to look at this thread if I ever don't reply!

No idea, but I often test on Windows and on Windows Phone without any apparent issues.

1) Does this occur in the latest version too? I made some changes to how things work in Unity 5 (assuming you're using that)

2) It's been added back in from version 3.0.7 upwards.

3) This is due to floating point inaccuracy. It's possible (I believe another user has done this) to overcome this issue by changing the code responsible for placing and generating the mesh data for each terrain patch. However, these kinds of modifications are very game specific, and there's no way to write a single generic implementation would would 'just work' with people's projects, so I haven't implemented any facility for this. But it should be fairly easy, as the code behind the patches is quite simple.

This is due to HDR breaking when a transparent object's alpha channel is set above 1.0 (which easily happens with gas giants). I believe I fixed a few of these in version 3.0.9, but I still need to go through all the shaders to make sure this doesn't happen, as well as make sure no shader instructions limits get breached.

I'm not sure I follow. SGT doesn't have any subterranean features that would allow you to view the crust, mantle, or other layers of a planet's interior. If you have code that allows you to dig into a planet, then you could change the atmosphere color to reflect these different stages though, but this sort of color changing isn't built-in.

Assuming you're not using SgtTerrain (which can generate collision meshes at runtime), then I'm not sure what could be causing such a drain of the physics system. Perhaps you could e-mail or PM me a package or project that demonstrates this?

Yes, the new version of the surface tessellator was implemented quite a while ago, and it's now called SgtTerrain. It's much faster and better implemented than the previous version, but I'm still not too happy with its implementation, so I will likely rewrite it sometime. This is the main reason why I haven't added it to the showcase demo scene, and after watching the Unite talk by the Kerbal Space Program guys I might do an implementation similar to theirs.

SGT has been fairly compatible with unity 5 for quite a long time, but recently I moved the main build over to Unity 5 and ironed out all (or at least most) of the issues, and since version 3.0.8 it's been updated from Unity 5, so you should no longer see this warning.

Indeed, my plan was to make the SgtCloudsphere component really basic (as it is now), and either expand it, or add a sibling component that gradually adds in volumetric clouds as you approach them. But before that, the SgtTerrain component needs some love, and maybe some type of ocean or SgtHydrosphere component needs to be added.

Very strange, well the gas giant is transparent, so I'm guessing this is some transparency quirk. Could you e-mail or PM me package/project/scene that demonstrates this?

I'll check it out, but that line was designed so you can only see the scattering at the edge of a gas giant. Without it, you'd be able to see it while deep inside it, or even on the other side. Getting these calculations looking right in all situations is really tricky!

Yes, version 3.0.9 added the 'Simple Thruster' demo scene. Also, version 3.0.6 added the 'Flying On Terrain' demo scene, which also demonstrates the new thrusters.

Me too, though rewriting the shader code in C# isn't too fun, especially when it still needs some work.

 

In other news:

​

That's right, SGT is finally on sale again!

If you've enjoyed SGT so far then please spread the word, it really helps me out!

If you've already bought it and don't care about sales, then stay tuned for new updates soon. In addition to some more fixes, I've been working on a cool new warp effect that doesn't require starfields.

 

Hey Darkcoder,

First of all, I think your tool is the best sci-fi one in the asset store. You can do so many things with it, it's amazing!

I made an app about half a year ago - a model of the Milky Way Galaxy with SGT version 2. Link is below:
https://play.google.com/store/apps/details?id=com.galaxymap.galaxy

I modified some of your scripts, even made a couple of galaxy types for my own use (SBa, SBc type for example). I'm thinking of upgrading the project to use version 3 (latest). I just glanced over the new version and IMO - seems radically different (regarding scripts), so I would probably have to rebuild it from scratch.

Is there any increase in performance from version 2 to 3 regarding starfields and/or nebula clouds?

In version 2, I tried updating the jitter of a nebula cloud to slowly increase from 0.3 to 0.7 and back from 0.7 to 0.3, thus creating an impression that the nebula clouds were moving. It looked perfect in the Unity editor, but on mobile the FPS dropped to 3 from 50-60 on a Note 3, so I had to remove this feature. I've seen that there is a similar feature in version 3, that makes the cloud "pulsate", thus creating the same impression if the parameters are tweaked accordingly.

Anyway, thanks again for designing such a great tool.

Raydekk

 

Hey,

Congrats on releasing the app, it looks great!

The starfields in SGT 3 are similar to the ones in SGT 2, so there shouldn't be much performance difference (the basic starfield rendering code is pretty simple, so there's not much to speed up).

The reason why adjusting the Jitter value is slow is because it modifies all the stars in the starfield, which requires rebuilding the mesh data. If you need this jitter setting to run very fast then you need to create a custom starfield shader that performs these calculations in the vertex shader. But yes, the pulse setting which is available in SGT 3 nebulas can be used to make them look more alive.

If you're thinking of upgrading to SGT 3 then I highly suggest you test it out on its own first to see what the differences are like, because I changed many things. Also, make sure you back up your old project, and try replacing the features one at a time, because SGT 2 and SGT 3 can be installed at the same time.

 

Hi, I purchased your asset yesterday DarkCoder and it's incredibly amazing, a must have.

Nevertheless when I am on the surface of a planet in night time I only see a black sky, I cannot see the stars. I don't know if it's normal or not, I don't have unity pro, perhaps it is required to that.

 

The sky on the dark side of a planet is black by default, but if you want to make it transparent then you can edit the 'Lighting Brightness' to your liking.

For example, if you open the 'Earth' demo scene and fly to the dark side of the planet, the sky is black. But you can make it transparent by:

1 - Select the 'Earth' GameObject, and find the SgtAtmosphere component.
2 - Click on the 'Lighting Brightness' gradient to open the gradient editor
3 - Click the gradient key at the very top left (the first alpha key)
4 - Drag the alpha slider down to 0

The dark side of Earth should now be transparent.

 

Thanks you're great!

 

Yeah, I'm taking it slow, everything is backed up. After checking SGT3 out I realized that I could remake the project so that I wouldn't have to modify any of your scripts, and only build custom scripts based on yours. And each time you released a new version, I wouldn't have to recheck each modified file before importing the new version.

 

1) I'm using 3.0.8 now and it still appears, but i haven't tried 3.0.9 yet
2) Thanks I've already noticed that
3) Well, i managed to avoid this by using multiple cameras

 

Hey guys,

The 'Solar System Pack' and 'Galaxy Pack' have been updated to use the new GUI system, as seen in SGT 3.0.8+

Also, SGT 3.1.0 is on the way, which fixes a few things, including a texturing bug in some of the demo scenes.

 

Awesome work! How about some detailed Moons in a future version of the Solar System Pack? Specifically a detailed Moon to go with the Earth ;-)

 

The only reason why I didn't include a moon texture in the existing packs is because I couldn't find a public domain one at the time (it's basically a requirement for publishing these kinds of media to the Asset Store). I can probably find one of the front easily enough, but from what I recall the satellites that took pictures of the 'dark' side always seemed to have special licenses. Though it would be possible to include these in the 'Solar System Pack' and include the extra license requirements, as I did with the 'Galaxy/Nebula Pack'.

 

Heads up: the 'Tomorrow Sale' ends in about 24 hours. So if you or your friends want to get SGT at a discounted rate then this will probably the last chance in quite a long while (it was over a year since the last sale). Spread the word

 

What would be the best way or the best 3rd party asset to build a nice terrain system on your displaced terrain planet ?
I want to have nice ground textures (rocky, grass, snow, etc), trees and grass prefab procedural placement (lots of it), and a nice heightmap resolution on closeup terrain.
My planets will be around 10,000m of radius and maybe even bigger if possible.
I have a floating origin system.
I tried using some voxel terrain systems as it would be nice to have actual huge voxel terrain planets in a space sim ! but I am also open to non-voxel.

Thank you.

 

I'm not familiar with any Unity voxel systems, so I can't say. But I imagine there are many challenges when applying them to planet like terrains, so it may be hard to find ones that work well at the scale you describe. The SgtDisplacedTerrain component is more of a mesh LOD system than a high detail procedural generation system, so there's no built in way to spawn trees and stuff on the surface. However, if you're fairly skilled at C# then I imagine you could write a component (or extend the existing functionality) to do this to a basic level. But how you implement this would highly depend on the kind of game you're trying to make.

 

I am basically making a multiplayer space sim with multiple planets.
However, I want to emphasize on the gameplay on the terrains, not just some basic tiny planets that you can almost walk on, but a real terrain system with lots of details, vegetation and great textures.

The space exploration side of the game is complete as well as the multiplayer part and scaling system (relative positioning, floating origin, etc).
Now I have to build a terrain system on top of that, and be able to seamlessly descend from space to the planet's surface, and land with the spaceship.. The players will then spend more time on the planets themselves than in space (for mining, fighting aliens, exploring the terrain, crafting, etc).

I guess I could use the LOD system to make the terrains extremely precise when we go down but the problem is performance because the whole planet is still there.

1. Is there a way to do some kind of Angle culling so that when we are really close to the surface the invisible part of the planet is completely destroyed until we takeoff again ?

2. Also, I just noticed a problem, not sure how it happenned.. After changing the main textures of the planet within the prefab, I saved it, built the executable, then when I reopened Unity it was back to the Old textures !
And I am pretty sure I saved it since I save every single action it`s like a reflex for me, and I did it within an hour so yeah I saved it at least 37 times.. , plus I built the executable which is actually working with the new textures, but they are not there anymore in the editor.. Any idea on how this would happen ?

3. Is there a way to add multiple textures to individual terrain mesh when on the ground ?
I tried adding textures on the mesh but they disappear the moment the game starts, looks like your terrain system is removing them to keep only one ??

Thank you.

 

Hey! I'm having some problems concerning the SGTObserver script. The problem is I'm using a small "space sphere" for my skybox that contains a camera (with an Sgtobserver script), background nebulas (from another space package) one of your awesome wrapped starfields and some background asteroids. I'm then also using your thrusters on my ship viewed by my main camera that also contains an SgtObserver script.

Because there is no way to specify which SgtObserver a particular effect should pay attention to, my thrusters are pointing towards my background space scene camera, rather than my main camera. I have fixed this manually by forcing the thrusters script to just pay attention to the camera.main.transform.position, but thought it was worth mentioning on here after I just updated to the latest version and lost my manual changes

The only other issue is that at high speeds (greater than 300 meters per second) the flare effect on the thrusters lags behind the flare colliders I have in place to block it. This seems more related to the raycasting required in general because I have the same issue with default unity flares (probably because my physics time step is adjusted for mid-range mobiles and my main camera is a free-flying object that follows my ship). I'm not sure if there is much to be done about that, but a more 'static' (for want of a better word) flare option would be a nice addition. Without any flare the thrusters can quite clearly be seen rotating to the camera and look a bit to 'bill-boardy'.

Keep up the good work!

 

Ok, this has to have been addressed somewhere before but I cant find it. When I use the simple belt in my scene I cannot see the asteroids at all. I can see the outline in the Scene view, but nothing shows up in the Game view. Did I overlook something? Sorry I'm a little new at this.

 

1 - Yes, but this isn't built in. The easiest way to do this is by attaching (or modifying) a simple script to the main 6 SgtPatch components under an SgtTerrain, and recursively go through the children. You can then read the 'MeshCenter' or something to find which way that patch is pointing, and if it's outside of your requirements then you can disable the MeshRenderer.

2 - It's possible I forgot to add a SetDirty call somewhere in the planet's inspector, I'll check it out.

3 - Did you change the material in the SgtTerrain and/or the SgtPatches below it? If you only change it in the MeshRenderer then it will probably get reverted, and when new patches get split they may copy the material from the parent.

The SgtObserver system is designed so that all effects will get updated separately for each camera. For example: if you have two completely separate cameras that are looking at a thruster, it's possible for the flare to get occluded behind an object in one camera, but fully visible to another. But it looks like I made a mistake somewhere and it's no lnger working. I'll see if I can fix it now.

I may be able to fix the flare raycasting issue by only doing the raycasts in FixedUpdate. I'll see what I can come up with.

Post a screenshot of the SgtSimpleBelt inspector, or e-mail/PM me a unitypackage/project demonstrating this.

 

Ok, totally fixed it. I said i was new. i doubled checked the lighting between the demo scene for the simple belt and what i had, and saw the errors. I'm going to have a lot of fun now that that is solved.


The problem was my Ambient Intensity was at 0. i thought that would be what i need for space, but i guess i'm not to clear as to the relation between ambient color and intensity yet.

 

You're right, you may want to use an Ambient Intensity of 0 for space scenes, but due to a change in Unity there was a bug with some of the SGT shaders that caused them to fade away when you did this. This has been fixed in SGT 3.1.0, but it's still pending review. If you need this fix now then I can send it to you.

 

Hi there,.. Great toolkit ;-)

Any chance there could be an option to use real 3d mesh stars or perhaps 3d procedural ones to create the 3d spiral or elliptical galaxies? I know I would probably need to lower the amount of stars considerably performance wise but I really like the star distribution.... Just need the to be 3d

In case not is there any way to get the star positions so I could replace them with "real stars"

 

There's no built-in way to do this, but after you design a starfield you can open the context menu (component gear icon), and click 'Make Editable Copy'. This will create an SgtCustomStarfield component, which has a public 'Stars' list that you can use to spawn stars at.