Space Graphics Toolkit & Planets

I am trying to make a moon that the player can take off from using a spacecraft. What is the best way to make a moon landscape. Doesn't have to be accurate but decent looking. Should I use the Terrain Heightmap? Or is it better to use Terrain Procedural. I tried by applying moon texture to land texture on terrain procedural scene. Then adjusted the variables it looked pretty cool as from a distant looks like a normal moon but close up has some bumpy landscape. However the textures were all messed up.




EDIT

I think I am going to use heights maps that does look great!!

 

Looks good. The textures get messed up because the SgtTerrain component generates a round cube, which has 6 sides. So when you apply your moon texture to the terrain it applies the same texture to all 6 sides, and you get those seams along the edges. Also, I assume your moon texture is spherical/equirectangular, which would add even more distortion along the edges. To fix this you can make your moon texture a cube map using the texture import settings, then use the context menu SGT adds to extract the 6 separate textures, and apply them to each SgtTerainFace separately. You can see the 'Creating Cube Textures.pdf' documentation for a bit more elaboration on this.

 

Hi Darkcoder,

Would like to use this awesome looking asset in my space tbs project, but have a couple of questions regarding its functionality.

I'm interested in:
1. Ability to generate planet textures as deterministic function from seed (int number)
2. Ability to specify basic characteristics during generation (all 'ice' planets should look similar): color shades, clouds, etc
3. Ability to generate backgroud (galaxy view) with random comets, flares and other space effects.

Also, is it OOB possible to generate any types of planets without additional 3rd party textures, shaders etc?

I'm sorry if I've misunderstood asset description in store and these questions were already answered.

Thanks in advance!

 

1 & 2 - SGT has no feature to procedurally generate planet textures. I don't plan to add this any time soon either, because making such a generator that outputs good results is immensely difficult. For example, the free media pack planets were made using Grand Designer on Steam, which is a very advanced tool that probably took hundreds of hours to develop, and even this tool requires a lot of knowledge and fiddling to produce good results.

3 - You can use the starfield feature to procedurally create backgrounds like you describe. Starfields aren't animated though, so for more advanced space effects you'd want to place them manually alongside the starfield.

No it's not possible to generate planets without external textures. You can generate atmospheres, aurorae, black holes, and a few other things completely procedurally though.

 

Ok, thanks for answer!

 

Is there a way to bypass the precision point scaling? Say If I scaled the planets large enough. And tried to play around that? Or is this breaking the unity engine

 

This breaks any game engine. You have to use an origin shifting system to keep things within sensible position ranges. I will release a media pack that implements this eventually, but I believe there's something like this on the unity wiki or somewhere.

 

I was wondering what is the best way to find the light references for planets that are instantiated. Normally you would drag the light object onto the light reference on the editor but not sure how I would do that for the light reference for spawned objects. Can you please advise?

Do I have to edit your code and add a line or make a separate script and attach it to the planet to spawn? lets say something like this?

Code (CSharp):

1. this.gameObject.GetComponent<SgtJovian>().Lights = Transform.Find("Sun");

Something like this? Or is there another way? As without the lights the planets spawn all dark!

 

@Darkcoder, it is planned to have Terrain Collider and for player to walk on planet (or orbit) because I test SgtGravityReceiver doesn't properly but if I disable FirstPersonController and Kenitic, is work. Also the player can pass through the planet.
Also Terrain Object is pink for me but I use Unity 2017, maybe I will edit the code for work properly ? (I read we must compile to shader 3, how to ?)
And what is unit for the mass to SgtGravitySource ?
Also good work for thruster, like KSP and other feature.

 

That's one way to do it, another is to store the light array in some GameManager component and copy it over after you spawn the planet.

Now that you mention it though, I should make a component that can automatically search the scene for them. I'll include this in the next version.

SgtGravityReceiver should work on all GameObjects with Rigidbodies, as long as the central planet has the SgtGravitySource. You can look at the Gravity demo scene to see what kind of settings you can use. I'm not sure why your player can move through the planet, can you select the planet and verify the MeshColliders have correct data in the scene view?

Pink terrain objects mean there is no material, if you're talking about the 'Terrain Procedural Spawner' demo scene objects then they're supposed to be pink, because I haven't created the final objects for this scene and just used pink ones to demonstrate how the spawning worked. If you're talking about the terrain itself then there must be some bug, an issue with your install of SGT, or you set a null/missing material in one of the components.

The gravity Units are the same ones used in Unity's ForceMode.Acceleration relative to inverse square distance.

 

So I use collider 'Mesh Collider' but I don't know how to use with your terrain. So it is the planet (Terrain/Terrain Procedural Spawner) or each level in Positive/Negative X/Y/Z ? Maybe a screen can help me.
And for the player can walk or orbit the planet with gravity realist (no fake gravity) how I can ?
So here my test scene, I use Standard Assets for character.
Thanks for help in advance.

And I talk about 'Terrain objects' so is normal is pink because I don't set materials.
Good luck for the next.

 

The normal MeshCollider won't work with procedural SGT planets. For that, you need to set the 'MaxColliderDepth' setting, which will automatically build working MeshColliders for your planets.

Yes, you can just add the SgtTerrainObject component to your prefabs and use them instead.

 

Ah OK, thanks. And for information, I need to active to the planet 'Is Kenematic' for collider but if active, I can't orbit the planet (with SgtGravityReceiver I test) so do you have a solution ?

Ok, thanks .

And for characters/spacecrafts can move with SgtGravityReceiver, do you have a solution (because don't work correctly) ?

Also I don't know why water don't working correctly (I update the scene if you want to see more precision) :


Good continuation for the asset, I hope we can make wormhole and see clouds on the surface (I don't know if you planned to use for walk on the planets/moons).

 

isKinematic shouldn't affect the orbit system, unless I misunderstand what kind of orbit system you're using? SgtRotate for example should work fine.

You have to use a character controller that supports an arbitrary up-axis. I don't know which ones do though, so you'll have to experiment, or write your own.

The water in your example scene works fine for me. In your screenshot you can see it selected in orange, maybe it's just hard to see? You can try adjusting the material settings.

I have plans to extend SgtCloudsphere to spawn actual clouds as you get closer, but no eta yet. I've experimented with wormhole like effects before, but they usually end up being very complex and game specific. If you have a video example of what you're looking for then I can check it out though.

 

Hi @Darkcoder

Can you get rid of the GC allocations every frame because of the string concatenations in the following methods:

SGTHelper.WriteLights
SGTHelper.WriteShadows
SGTHelper.WriteShadowsNonSerialized

Also, it would be great if the scripts could use Shader.PropertyToID to set shader variables using ints instead of using strings as well, for efficiency. I made all these changes and rewrote SGTHelper methods to not allocate in previous versions of SGT, but when new awesome updates arrive, it's a pain to have to redo all of that.

Thanks for your consideration.

 

Using shader property IDs is something I've wanted to add for a while, I'll try and add it to the next update. Thanks!

 

Ok, I test SgtSimpleOrbit and the collider work fine.

Ok but I not a good programmer, so maybe later or if I find a script who worked.

Is rework, I just reload the project, I don't know why.

Oh, OK. For wormhole, doesn't a video but maybe it can helped you : https://sirxemic.github.io/wormhole/

Good luck for the next.

 

I recently bought your asset. Very nice work!

Some of the shaders/textures/effects are hidden or created on the fly and I was wondering if that could cause a problem on certain platforms that need pre-compiled shaders. I have seen that be an issue before on mobile devices.

Specifically we are developing for Amazon Fire TV and the latest device is rendering the SgtAtmosphere shader wrong. I am using the darkstar example. It looks like an alpha or Z problem.

It works on the rest of mobile, TV, Tablet devices I have tried so far, so I was guessing about the "on the fly" shader as a possible issue.

Interested to see if you have any guesses that might cause a device specific issue.

 

As far as I know it's not an issue, because Unity is still loading the shaders using the same API. The reason why these shaders are hidden is because they all contain properties that need to be updated at runtime, or per-camera, or need to be calculated from simpler values, so allowing the user to manually create them doesn't make sense. There are some exceptions like SgtThruster and SgtDepth, so these aren't in Hidden/.

Can you upload a picture demonstrating the issue? Also, do scenes like 'Star' work fine? These scenes are basically identical except for the star surface shader, where 'Dark Star' implements 8 octave 4D noise, which might be the problem.

 

Thanks for the quick reply!

I tried the sun with a simple mobile/unlit shader, so its definitely the atmosphere. It happens on TV so hard to get a screen shot for you. I looked over the shader code, I don't see anything that seems too intensive or out of the ordinary.

If I were to guess it looks like z fighting or overflow of low precision variable. Not sure why that would happen only on that device.

I'll see how to get a screen shot for you or check some number calculations between devices to see if I can see anything.

 

Unity changes some things between platforms, like depth buffer precision. I don't think that scene uses any extreme values though, so it sounds a bit strange. You may want to check the project settings for that build platform and make sure nothing is set differently that might cause this. Another thing is SgtAtmosphereInner.shader uses Offset -0.1,0, you may need to increase this to -1,0 or similar if precision is the issue.

 

Hey, definitely love the pack, but I was wondering if there was a way to have the alpha for box starfields work off an channel from the texture, rather than the color.

 

I'm not sure I understand, the BoxStarfield component simply distributes the stars inside a box without reading any color data. It sounds like you're talking about NebulaStarfield, but that has options to read the alpha.

 

No, definitely box starfield (based off the one used from the Infinite Starfield 3D example). I'm using an alternative texture to help with an asteroid field, but I noticed when when using textures it uses darker colors to determine the alpha. As an example

Notice the transparency, compare this to a texture that's completely white.

Which has no transparency.

 

Oh I see. Starfields use the Additive blending mode, which is why it looks like the opacity is based on the color. To make it based on the alpha, a different blending mode such as Alpha blending is required. The reason why I used Additive blending is because it is commutative and doesn't require depth sorting, which allows for incredibly fast rendering speed. Whereas Alpha blending results change based on draw order, so the stars/asteroids would need to be depth sorted in order to look good, but doing this is kind of slow.

One easy solution that I should add is to use Alpha Testing like the Belt components do, because that blending mode doesn't require sorting. However, I'm not sure how useful this would be in your scenario, since the asteroids are so big, and would surely kill immersion.

I recommend you instead use the DebrisGrid component (see Debris Grid demo scene), which allows you to create a similarly infinite field of asteroids, but allows for collision and Alpha Blending, because they're just normal prefabs.

 

Well, this isn't actually for the infinite asteroid field, which is already implemented in a different way. This is for a system akin to Freelancer's, which has a bunch of asteroid billboards around the actual 3D asteroids to give an illusion of parallaxing. It works fine and looks good, but I just need those billboards to be opaque rather than transparent.

EDIT: Got it working the way I wanted to, just had another shader based off it that used a different blend mode, works fine, so far no performance issues.

 

Another issue. Well, more an observation. I've found that static starfields tend to kill my framerate the bigger I make the star radius. Why?
On a related note, is it possible with these starfields to change the color of the background from just black, so I could say, render a series of red stars on a blue backdrop?

 

The higher the star radius, the more pixels on the screen they fill up. This is fine up to a point, but eventually the pixels start to overlap. If they overlap a lot and you have a lot of stars then you can easily begin rendering millions of pixels, or even billions, and this will cause even the best GPUs to lag. To fix this you have to reduce the amount of stars or reduce the radius.

If you look at the example scenes for the infinite dust you can see the settings have been carefully balanced so the stars fill up most of the screen, but don't overlap too much, and the near/far fade settings are used to make the transition less abrupt as the camera goes through. To improve performance in your game you must do the same, and also pay attention to the star opacity.

And yes, it's possible to a different colored background, just change the clear color on the Main Camera. Just keep in mind it uses additive blending, so it won't work with a white background.

 

Question, I've got a bunch of flares representing stars in my scene. I need to dynamically move them through code while keeping their relative sizes the same on screen. If I move them out in Z and scale them up the same then the flare effects become too large and blast the whole thing out. How do I properly scale flares (and other objects with generated materials) properly?

 

To keep the same apparent size you need to scale them exactly based on distance. So if your flare looks good at 100 units away with a scale of 5, then to look the same at a distance of 400, the scale should be 20. Maybe you're incorrectly calculating the distance, and not accounting for the camera position? Also keep in mind perspective projection will make objects distort and get larger the farther from the center of the screen they are (e.g. corners).

 

Thanks. Yeah I've got that part, and for solid objects it works well. However, for the flare components it seems all the flare values are scaling up and they all blow out in terms of brightness and flare size. I don't believe it respects the scale on parent transforms so I guess I need to scale all the individual radius, wave strength, etc parameters as well?

 

Can you describe the steps required to reproduce this issue?

I tried scaling the flares in the 'Flare' demo scene, and if I adjust the position by the same factor as the scaling then it works exactly as expected.

If the flares are set to 'Follow Cameras' like in the 'Aurora' demo scene, then adjusting the 'Follow Distance' to match the scale also gives appropriate results.

 

Hi I got a vehicle going around a planet with some gravity script. It has a rigidbody and uses wheel colliders. I put the terrain max collider to 3 but the vehicle goes through some of terrain. I guess increasing the max collider will make the collider more accurate but guess that will slow down the scene? Any advice? Thanks

 

You can use the SgtTerrainPlane component to create a collider plane underneath the vehicle or each wheel, or you can calculate the collisions yourself by finding the terrain height underneath each wheel (e.g. myTerrain.GetWorldHeight(...)).

 

Hi Carlos,

I got the newest version of SGT (moving from 3.3.6 to 3.3.8) and suddenly my elliptical starfields are not showing any stars or quads. It doesn't work even if I make one from scratch for some reason? The box Starfield also doesn't show any stars. Only the Static Starfield displays stars.

Any idea what could be causing this ?

Thanks!

 

Which version of Unity are you using, what's your build platform set to, and on which device?

In 3.3.8 I changed the way point starfields are rendered so you now have the option to change between Additive Blending (Default) and Alpha Testing. I didn't notice any issues in my testing, but I could have missed something.

Also, does changing your starfield's 'Blend Mode' setting do anything?

 

Hi Carlos,

Thanks so much for your reply. I changed that setting but it wasn't doing anything. Stars/billboards were not showing regardless. Platform build setting was set to PC/Mac/Linux. I am on a Mac using Unity 2017.1

Was the additive blend the previous behaviour before 3.3.8? I could give 2017.2 a shot and see if that fixes it.

Please let me know if you need more information. Thanks!

 

3.3.7 and earlier only had additive blending, but 3.3.8 added the ability to change it (same for Sgt__Belt). However, I can't reproduce the error your mention, on either Windows and Mac. I only tested on Mac using 2017.2 though, but I don't imagine there's much difference.

Can you try making a new project and importing only SGT and seeing if starfields work?

 

Hi Carlos,

Thanks for the explanation. It worked fine in a new project in 2017.2. After that, I reimported the package again in my old project and now for some reason it works! Maybe something did not import correctly the first time. I really don't know, but its working now...

Thank you again for looking into it!

 

Whats a good size for a planet to have a flat view distance to the point where you can't see any curvature?

 

Hi I am having some problems with SGT in 2017.3 beta

1) The document on creating cubemaps doesn't seem to be accurate with the current workings of the tool? It says to set Texture Type to Advanced but there is no such type in the drop down. I tried setting Texture Shape to Cube, and that maybe was the right option? But in the gear menu the option to Extract Cubemap is disabled.

2) I am not sure what is causing this but even in the demo scenes, un touched, the console is spamming:
Assertion failed: In order to call GetTransformInfoExpectUpToDate, RendererUpdateManager.UpdateAll must be called first.
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

This goes away if I remove SGT from the scene.

 

Also I wonder if anyone has tried generating planet textures and heightmaps procedurally using Substance and if so any tips on outputting proper textures to work with SGT and look proper on the sphere?

 

This depends on your game scale, just increase it until the curvature is low enough?

Hey,

1 - I'll update the documentation. Now you just need to set the 'Texture Shape' to Cube.

2 - This is a bug with Unity I can't do anything about, but it seems to be harmless.

 

Ok I had tried that but the option to export a cubemap was in the menu disabled. Is there some other setting I need to set?

 

You also need to check the 'Read/Write Enabled' setting, and hit apply.

 

Could you add in radius settings to the flares to create bigger / better suns? At the time, im using the flare material component (width setting to get this kind of inner scale, but not working out too well)
Here's what we have now:

I want to be able to like adjust that outer radius so it looks more better. Trying to make my sun look similar to this.

 

To make SgtFlares bigger you can adjust the SgtFlareMesh.Radius setting, or adjust the scale of the GameObject itself. If you want to adjust the gradient falloff to compensate for the scaling then you can increase the SgtFlareMaterial.PowerR/G/B settings.

If you look at the 'Flare' demo scene, you can see how each flare uses a different Radius and Power.

 

Hi, I bought your asset the other day and so far it looks great. I'm having a bit of a trouble with applying custom materials/shaders to water though. Most water assets on the asset store do not work well with anything but a flat mesh and lots of custom camera setup. I've found one that I like the look of, and it's just a simple shader: https://www.assetstore.unity3d.com/en/#!/content/38748

Problem is, when I apply the water material to the water GameObject (in the terrain with heightmap example scene), it just renders black. I've tested with different meshes, and it displays just fine when I use a geosphere mesh for a water face, but using the auto-generated Terrain mesh causes it to not render at all. Any idea what might be causing this and how I can address it?

Or is there an asset on the store that works particularly well for simulating oceans with SGT?

 

I'm not sure why this custom water shader would render correctly on a geosphere, but not on an SgtTerrain.

What about if you set up a very simple terrain with no atmosphere, and no land, just the one terrain for the ocean with the custom material?

 

Same result. Attaching a screenshot here:

The material is applied and it is having some effect, since it does not render pink, but it seems to ignore all textures specified in the shader. Can I share the shader with you if you'd like to take a look?

And I want to ask again if you know of a good water/ocean simulation package on the asset store that works well with SGT.