Space Graphics Toolkit & Planets

Never had that issue, perhaps it's an issue with the version of Unity you're using? SGT comes with cube maps converted from cylindrical textures though

 

Yes, from what I read in the forum it is a Unity bug.

Just made a test. I increased the size of the planet from 300Km to 1000Km. That makes the terrain look better but flying around with 500 m/s is so damn low.

 

Is there anything in SGT for easily doing asteroid belts like this one in a screenshot from Stellaris?

 

Ahh yeah just found it. SGT is so great. Doing all my work for me!

 

Hi, how can I increase the maximum SpaceTimeWell objects that can interact with SpaceTime?

 

The current limit is based on the limits of the shader compilation target "2.5". If you want to increase this then you must modify the target to 3, and then you need to modify the code to accept these new limits. There's quite a bit to change though, and it would require a little bit of C# knowledge. If you can do this then I can detail the steps required. If not, how many and which type of wells do you need?

 

I think that I will do it myself. Please tell me the steps.
If I don’t succeed, I will write to you.
I need >= 25 Gaussian wells.

 

Alright, first you must open SgtSpacetime.cs and change the gauPos array length on line 171 from 12 to 25 (or whatever you need).

Next, you must modify the UpdateWells method on line 245 so that it writes more keywords. Right now you can see the gaussianCount causes keywords to be written to the keywords SGT_C, SGT_D, SGT_E, and LIGHT_0. These keywords allow the shader to count how many gaussian wells there are, where the first keyword adds 1 if it's defined, the second adds 2 if it's defined, the third adds 4 if it's defined, and the fourth adds 8 if it's defined. This means the current setup can define a gaussian well count between 0 to 1+2+4+8 (15). To support 25 you would need to add one extra keyword for +16 (0..31 range). The current keyword names are like this because at the time of development Unity shader keywords were shared between ALL shaders, so it was good practice to re-use as many shader keywords as possible. In newer versions of Unity you can define local keywords, but for your needs you could probably just use SGT_F or whatever you like, as long as you remember it for the next steps.

Next, you must open SgtSpacetime.shader and find the shader code starting from the CGPROGRAM declaration. Below this, you can see a list of #pragma statements. Add the following new one: #pragma target 3.0

Next, you must define the extra shader keyword(s) you defined earlier. Depending on the name you picked just add something like: #pragma multi_compile __ SGT_F

Next, you must modify the GAUSSIAN_COUNT macro definition to include this additional keyword(s). It should now be something like: #define GAUSSIAN_COUNT (SGT_C * 1 + SGT_D * 2 + SGT_E * 4 + LIGHT_0 * 8 + SGT_F * 16)

Finally, change the GAUSSIAN_COUNT_MAX macro to be the same as C# from the first step.

You should now have support for more gaussian wells!

With this higher instruction limit you can also remove the preprocessor code under this comment: // Keep under instruction limits

 

Any progress on this? I'm still not able to put a SgtFloatingObject component on the Player object without completely breaking the scene.

 

I briefly tested this and didn't notice the issue I described. Parenting the floating camera + origin to a floating object + point appeared to work without issue, so perhaps this can work if the order of operations is correct. As soon as I finish this update to my other asset I'll continue testing.

 

OK, I've simplified the scene down to a repro case. (Attached.) The player's ship is represented by the cube, which is parented to an object called Player. The Player object has a SgtFloatingObject attached, which is disabled, and a SgtFloatingOrigin, which is enabled. If you enable the SgtFloatingObject object in the editor, it immediately breaks the scene and becomes impossible to restore the scene to its proper positioning (Player at Y=0, Camera at Y=3000) without disabling it or some other essential component.

 

@Darkcoder Does that reproduce for you, at least?

 

Hi Darkcoder, I have two questions.
1. Will SGT launch the Pro version or SGT2 version in the near future? I heard that SGT has begun to support SRP gradually, so I want to know if SGT will release a separate version for SRP.
2. If I buy SGT now, can I use it to do a basic space game in HDRP?

 

Sorry for the late reply!

I checked your scene and indeed it does behave unexpectedly. When I designed SgtFloatingOrigin, it was supposed to be put on a standalone GameObject, merely used to store the location of the camera in the universe. The reason why I didn't include this code in SgtFloatingCamera is because I designed the system to work with multiple cameras, so using a separate component made sense. The issue in your scene is that you have the SgtFloatingObject component attached as well, which interacts with SgtFloatingPoint (and thus interacts with SgtFloatingOrigin). Since the position of floating objects depends on the location of the origin, when you put these components all together, it creates a scenario where the object is moved to position itself relative to the origin, but now the origin has moved, so then the origin updates which causes all objects to update, and so on. To fix this I could add extra code to warn the user or disable this interaction in this scenario.

I plan to continue supporting the current SGT asset for a very long time. Any new assets I release will just be very high fidelity versions of existing components (e.g. the new terrain features I'm experimenting with).

LWRP/URP will be fully supported in the next version of SGT, which is currently pending review by Unity

HDRP is mostly supported in this upcoming version, but some features (e.g. Flare, Singularity) do not work for some reason, so I will have to investigate this some more. HDRP also requires me to change all textures to linear, so I will have to see what changes are required to maintain the current visuals, as well as how this may impact the other pipelines. If your game requires HDRP then I wouldn't recommend using it with SGT yet, unless you don't mind tweaking a lot of settings and textures to achieve similar results to what is shown in the screenshots & videos.

 

That feels very strange. IMO unless you're in a first-person view, it doesn't ever make sense to have the camera be at the locaation of the floating origin; it just seems intuitively obvious that that should be defined by the player.

...wait, wait, what? If this is supposed to work with multiple cameras, then which camera is it supposed to be storing the location of?

 

Any news about the new SGT asset?

 

The SgtFloatingOrigin+SgtFloatingPoint stores the position of the 'observer', and this position can be anywhere in the universe. Multiple cameras can be used to render the scene at multiple scales, e.g. 1:1, 1:1000, etc. The reason why this must be separated is because when the 1:1 camera moves 10 units (10 meters), the 1:1000 camera must move 0.01 units (10 meters) to visually match. The actual transform.localPosition of each camera can have seemingly no correlation to its actual universal position.

When each SgtFloatingCamera's transform.localPosition exceeds the snap distance (e.g. 100 units), then that camera alone must snap back to a localPosition of 0,0,0. When this happens, the SgtFloatingCamera stores its snapped position, but its actual universal position (SgtFloatingPoint) hasn't changed. This snapping then causes every floating object in the scene to be re-postioned based on this snapped position the SgtFloatingCamera stores, as long as the camera and object scale values match.

I hope this clears things up.

The reason why I implemented multiple camera rendering like this is because Unity's shadow rendering breaks when a camera renders past 100,000 units or so. So if you want shadows and to be able to see distant objects you either need to use multiple cameras, or to dynamically scale objects so they're closer. It's my understanding that multiple camera rendering like this is no longer possible with SRP though, so I may have to implement this scaling.

Not yet, I've been very busy updating every asset for the new asset store design, as well as adding SRP support, fixing bugs, etc. Hopefully in a few weeks I'll have more time!

I did manage to implement a NativeArray fallback that uses Vector3, allowing the new code to compile in earlier (non beta/alpha) versions of Unity though. However, it runs at about half the speed of what can be achieved with the newer method, so hopefully Unity releases it soon!

 

It does a little.

We still have the fundamental problem of the camera snapping itself to the origin, when the invariant that must be preserved is that the Player is at Y = 0 and the camera is at Y = 3000. How do I fix that?

 

If you require the player to be at y=0 at all times, and the camera to be at y=3000 at all times, then either:

a) You modify SgtFloatingCamera to not require a Camera, and attach it to your player, you must then constantly snap the 'camera' (player) so it doesn't stray from 0. You are then free to parent the camera with a y=3000 offset.

b) You disable Y axis modification from the whole floating origin system, so your object is at Y=0, and your camera is at Y=3000, and it will never snap.

Neither of these sound like good solutions though. Why can't you use the existing components like SgtFollow to parent a floating camera to your floating object, and just forget about the actual positions?

 

Because I'm trying to do a top-down view of a solar system in an orbital plane, but with 3D objects and with certain objects at varying distances (Y positions) from the camera so as to enable perspective tricks, and it immensely simplifies the math if it's safe to assume that the plane is always at Y = 0.

 

Hello.

Is there a way to access the planet terrain height in the planet shader. I want to add textures depending on height.

Thanks.

 

In this case you would have to modify the code to ignore Y, or not require being attached to a camera, or calculate the camera offset and subtract it before performing your calculations (SgtFloatingCamera.SnappedPoint). You basically want a floating origin system on only the XZ axis, which is pretty project specific.

The planet shader only has _HeightMap data, which isn't that useful for terrains. The SGT Terrain Gradient shader shows you how to calculate the exact height though.

 

Hey everyone,

Space Graphics Toolkit version 3.6.8 is now out!

Also,

50% OFF during the Black Friday sale!

This version fixes some bugs, improves VR support, adds a new VR demo scene, and adds full support for LWRP/URP, and nearly full support for HDRP!

It took quite a bit of time to come up with a good way to manage both the standard pipeline and SRP, but I'm really happy with the solution I came up with (see documentation for steps). This allows me to support all pipelines quite easily, and testing between them is quite smooth.

Before I get back to the new terrain stuff I want to finish off SRP support with full support for HDRP. I've also been experimenting more with VR using Unity XR, and I want to make at least one proper demo scene using it, as I imagine many VR devs may be interested in this asset.

Enjoy!

 

Hi,
should I update if I don't use SRP, VR, LWRP/URP or HDRP?

 

Check the version notes and see if you're using any of the components that have bug fixes for them.

 

Probably not, but the next version may be more interesting

 

Hi Darkcoder, I am using HDRP + Unity 2019.3.0b12 + SGT 3.6.8, I have 3 questions.

1.In the "Terrestrial Planet + Ring" demo scene, the planet is transparent, and you can see the stars behind it.
2.TAA Anti-aliasing does not work properly.
3.I do n’t quite understand the meaning of the ‘Space Probe’ scene. I can’t control the movement of the Space Probe. What does it do?

 

Keep in mind HDRP support isn't complete yet. Full support will be in the next version, which should be ready very soon.

1 - The planet isn't transparent, the stars are just rendering in front of the planet. To fix this, make sure the SgtBackdrop.RenderQueue is set to Geometry (2000) (Unity removed backdrop in HDRP for some reason?!), then you must increase the Transform.Scale to for example 10,10,10. If you increase it too much then it will render outside the camera view, so you may also need to increase the Camera.ClippingPlanes.Far. When you select the camera it changes the background color to default blue (Unity changed the serialization for some reason?!). As you can see, there are quite a few annoying things Unity changed, so I'm working on a way to easily fix these, stay tuned

2 - I haven't tested TAA yet, I'll make sure to.

3 - This is just a random scene I made after watching a video of the Space X Dragon. You can't control the probe, but maybe I'll add some kind of spaceship control script to change that in the future.

 

Just picked up this asset, loving it show far. Is there any further documentation on the Terrain feature? Also do you have a good workflow using Grand Designer with the planet shader for the terrain? I created a moon and did an export full so I could get the BaseColorGround, Normal, and a Height map from it but when I use it with the terrain and move closer it doesn't generate heights or really anything, just becomes a blurred mess of colors. Im figuring its just because I dont fully understand it and not seeing too much in the documentation. Thanks!

Edit: Wanted to throw out another heads up. When throwing a CubeMap onto the Main Tex of Sgt Jovian and assigning a Geosphere40 (planet) mesh to it, the console spits out the below continuously

Error assigning CUBE texture to 2D texture property '_MainTex': Dimensions must match
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)

 

Besides the documentation, component documentation (also in tooltips), and demo scenes, nope. Is there a specific aspect you want elaboration on?

My Grand Designer workflow is to tweak the texture colors a bit in photoshop, and to export the depth as 48bit png, normalize in photoshop, then export to 24bit png for Unity. The planet shader is set up so the PBR smoothness is stored in the albedo alpha, and the height is stored in the alpha (you may need to adjust the import settings if yours is in RGB). If you want specific settings then I'll have t get back to you, as I currently can't log into Steam for some reason.

Regarding the Jovian error, indeed I should change this texture name, as I doubt Unity will ever fix this bug.

 

Hi Darkcoder, I have made some further adjustments to sgt terrain - it now takes five mask maps; one main mask and one for each channel of the main mask. Now the terrain height and type is determined by the sub-masks. The sub masks have been added to the shader. This enables me to colour the sub-masks. With one texture, the details of the surface need to be visible before the main texture becomes a blurry mess but this tends to make the tiling of the details too obvious. With the sub-masks you get very high detail from space down to the surface.
I wonder if this approach might be useful for the terrain update.

 

Hi. How do you manage that the mask maps are exactly above the detail maps. Tried this with no success. The mask maps still have a different tiling than the detail maps.

 

I'd have to test it. It sounds like this would work for medium sized planets, but 1:1 Earth is insanely huge. I'll get to it soon

 

Last saturday I watched the planet tech panel at CitizenCon and they use climate data (e.g. temerature and humidity) in their Planet Tech v4 to determine how the planet looks like. That sounds like an interesting approach.

 

hello,
I'm thinking to buy this asset, but I have a question.
Is the planet shader suitable for terraformation?
How difficult is to change any aspect of the planet, maintaining his shape?

 

Assuming you want to gradually change the planet from one look to another, the planet surface shader is mostly based on the planet textures you specify, so you wouldn't be able to gradually change them. One exception is the water height, which can be changed in game. The planet atmosphere however would be very easy to transition over time, as the look of this is based on simple component settings (e.g. floats and colors) you specify.

 

Hey everyone,

Just a reminder that you can get the Solar System Pack (among others) for free from the documentation HERE.

If you copy+paste each individual scene together and tweak the positions and stuff then you can get something like this:



The next update to the solar system pack with this demo scene

 

I bought it, but when I try Terrain examples I get an error. What am I doing wrong?

Code (CSharp):

1. Compute shader (SgtTerrainFace): Property (_HeightMap) at kernel index (0) is not set
2. UnityEngine.ComputeShader:Dispatch(Int32, Int32, Int32, Int32)
3. SpaceGraphicsToolkit.SgtTerrainCompute:DispatchFace(Mesh, Int32, SgtBoundsD&, Boolean) (at Assets/Space Graphics Toolkit/Features/Terrain/Scripts/SgtTerrainCompute.cs:254)
4. SpaceGraphicsToolkit.SgtTerrainFace:BuildVertices() (at Assets/Space Graphics Toolkit/Features/Terrain/Scripts/SgtTerrainFace.cs:250)
5. SpaceGraphicsToolkit.SgtTerrainFace:UpdateInvalid() (at Assets/Space Graphics Toolkit/Features/Terrain/Scripts/SgtTerrainFace.cs:408)
6. SpaceGraphicsToolkit.SgtTerrain:Rebuild() (at Assets/Space Graphics Toolkit/Features/Terrain/Scripts/SgtTerrain.cs:452)
7. SpaceGraphicsToolkit.SgtTerrain:OnEnable() (at Assets/Space Graphics Toolkit/Features/Terrain/Scripts/SgtTerrain.cs:633)
8.  

 

Is your project set to WebGL by any chance? Also, what exact version of Unity are you using?

Also, can you check the documentation and confirm that you're running version 3.6.8?

When I noticed this error I only saw it in WebGL, and it looked like a bug with Unity, because my declaration of _HeightMap looked correct.

 

No, I'm not using WebGL.
Unity version is 2019.3.0f1 with URP and DOTS
The asset version is 3.6.8

EDIT: I think I found the problem. If I load first 00 Terrain scene, it don't work. But If I load Terrestrial Planet 1k all fixes and I can use 00 Terrain again.

 

Thanks for info and finding a workaround, I'll see if I can trace this back to actually fix it!

 

Request: Please add "set" method to SgtBackdrop.StarColors property. All it needs is "set { starColors = value; }" and it works fine.

I am using it for a blueshifting effect as a traveling ship gets close to light speed. It works fine when changing the colors (and then calling UpdateMeshesAndModels/UpdateMaterial), performance is good for my purposes.

I can change the source easily but I have to make the modification again every time I upgrade SGT. It just seems like an omission because StarColors is settable for all of the starfield classes.

Thanks.

 

Thanks for the feedback. Although StarColors doesn't have a property or method like you describe, the Color setting does have SetColor, which can be used to tint all the stars. I recommend you use this instead, because it will have almost no performance impact. StarColors on the other hand is calculated once for each star, so changing this requires the whole star mesh to be regenerated. I'll consider adding Set methods to every setting in one of the upcoming versions!

 

Is there a possibility to use the SgtTerrain not with a texture as height input but f.e. with height data in raw (16 bit) format?

And: using the GPU for accessing the texture is nice on client machines, but servers typically don't have a GPU. Then everything is done on the CPU and the mesh data could be created in a thread (if read from a raw file) and not in a coroutine is it is done now. Of course assigning it to Unity still needs to be done on the main thread.
Also having no heap allocations when updating the mesh grids would be great.

But overall the terrain is pretty awesome! Are there any updates/improvements planned in the near future for it?

 

SgtTerrain is written for both CPU and GPU (compute shaders), so using texture sampling is the easiest for cross compatibility. Compute shader support has some notable exceptions though (WebGL, Switch, older mobile), so I'm not too happy with it. Another issue is the CPU fallback is a little tedious to maintain and hard to optimize because it's a port of the GPU version, which isn't necessarily the best design for CPU. I definitely have plans to investigate this to perhaps make it CPU only, we'll see. I've rewritten this terrain feature something like 5 times already, so before I spend too much time changing it I want to focus on some of the other features.

 

Is there a Homeworld style orbital camera in this pack?

 

The SgtCameraLook component is used in some examples to orbit the camera around an asteroid you can control. The orbit distance could be increase to act like an orbital camera. The ability to switch between a local and overview like in Homeworld would have to be written separately by you though.

 

Thanks! I'll get right on that!

 

Why does sgt make my main camera used for the 3rd person player zoom out really far and break the rotation? I havent added any sgt components to the camera yet neither my player, so why is it doing this is it due to me using the floating point system?

 

If you've added no SGT components to your camera (e.g. no SgtFloatingCamera), and only SGT components to your objects (e.g. SgtFloatingObject), then nothing should happen.

If something is happening then I need more information about your scene, like screenshots of all inspectors for GameObjects with SGT components, or a video showing them, or a package I can test.