Space Graphics Toolkit & Planets

I dont know how to save it. How can I do it?

 

Hi @bonniespace080,
I recommend learning about how to save serialized data in general, then applying this to the SgtPosition.
Here are some tutorials:
https://www.youtube.com/results?search_query=unity+save+serialized+data

 

Thx. Do I need to do it with JSON? SGT doesn´t use JSON.

 

You can choose one of many formats. JSON, YAML, XML... Those are data structures where you can put in the (serializable/serialized) data that you want to put in. This is a step done before saving the data aka exporting them to a file. SGT cannot do this for you as every game has other needs. Which one to use is your decision. One you can make after you have learned what these are, their differences and how to use them. I recommend looking at the three I mentioned. This is not comprehended in a few minutes but can take some hours of research. Take your time.

Once you are there, more things come on top, e.x. do you want to make the saved data readable easily with a text editor or do you make custom binaries when exporting the data? How do you handle versioning, like, when you change the save and load procedures (add new fields, remove others, ...), how do you make sure that old saved data can still be read?

First of all, I recommend looking into unitys playerPrefs. Those save data for you and if they fit your needs you can skip the stuff above.

 

Im getting some HDRP errors

Shader error in 'Space Graphics Toolkit/Planet': 'GetDecalSurfaceData': cannot implicitly convert from 'float3' to 'struct FragInputs' at line 4032 (on d3d11)​

and

Shader error in 'Space Graphics Toolkit/Planet': "Undefined area shadow filter algorithm" at HDShadowAlgorithms.hlsl(53)​

Are there any known fixes for these?

 

I answered you via email.

 

Any scripts for 3rd person controler movements using SgtGravityReceiver and SgtGravitySoucer?

 

No idea, maybe someone else can chime in.

 

Is it possible to stop shadows being cast on to planets?

 

Currently you have to modify the code. SgtPlanet.cs line 341, change the DrawMesh call to an overload that has the receiveShadows flag, and set it to false. If you're talking about terrain planets, then the same thing but SgtTerrainPlanetMaterial.cs line 101.

In what scenario would you not want your planets to receive shadows?

 

Thanks!

 

Ive got ships in close atmosphere for a battle scene shot, and I don't want their shadow hitting the terrain, the planet is not to scale.

 

Alright, I'll send you a new build with these settings.

 

Hi @Darkcoder, I've got a strange issue where planets don't look the same in Editor and once the game is built.

Earth in Editor:


Earth in Build:


Mercury, Mars, Jupiter in Editor:


Mercury, Mars, Jupiter in Build:



As you can see, this seems only to happen with SGTPlanet, not SGTJovian.

I'm sure there's a setting somewhere that has been badly setup, but I don't know what to look for.
Could you help me on this?

Thanks in advance

 

It looks like the planet surface isn't rendering. Can you try building one of the example scenes in the Planet feature folder (e.g. "01 Planet") and see the same issue occurs?

If so, let me know the exact version of Unity, SGT, and render pipeline you're using.

 

Hi @Darkcoder,
Here is the build for "01 Planet":


I'm on Unity 2021.3.21f1 (but had the same problem on 2021.3.3f1), SGT 4.1.1 (had the same problem with 4.1.0) on the built-in render pipeline.
Also, this is a PC VR project using the Oculus XR plugin, Single Pass Instanced.

The strange thing is that the build worked fine a few weeks ago, I actually just rebuilt on older version and it does work fine, I just can't find what setting has been changed to impact that.

Any idea what setting I should look at..?

 

Hello, are there any downsides to having a solar system with a 1:1 scale of the real-life one? For example, having all the planets be earth-sized planets? It's my understanding that I can use the universe feature to avoid having floating point precision errors, allowing me to place the GameObjects at very far distances. I am just wondering if there are any negative effects on the game's performance.

 

I wasn't able to notice any issues in a normal build. When I have a bit more time I'll test it out in VR.

In terms of performance there should be little difference. The main difference is that it makes scene setup more difficult, and most other code will require modification to be compatible.

 

@Darkcoder Are there any "Best practices" to maximize fidelity of the planets ?
When Using a planet shader, I have planet textures in the scale of 8k wide by 4k tall but they appear as such.
(At full size you can better see the muddiness of the details)



I ask because I noticed when adding detail and Enabling Normal, the normal maps are 1k squared but create very crisp edges and detail in how they are tiled.
Thank you in advance

In response to BonnieSpace080, I serialize the SGT position to a JSON file. I just first break down the component value into individual longs and doubles and then reconstruct the SGT_Position onLoad.
Haven't had any issues.

 

How does your planet compare to the example one shown in the "Water Level" demo scene? This is 4k and looks higher resolution than yours. Perhaps your albedo texture has compression or you didn't increase the Max Size.

 

In the demo I see the scale of the planet is 1000.
I am using much larger sizes of 750k. Compared to the Earth Sized Planet Demo size of 6,371k I figured I'd be safe. Though looking more closely at it, the Earth Size planet also has muddy textures from orbit until you get close and the mesh takes over the detail.

I have taken many steps to copy settings exactly as you have them.
Here is the texture settings from the original post

 

if you want to match perspective the position of the planet is
Vector3(-625000,0,625000) with a scale of 750000

 

Why does Shadow on Terrain Planet (and I guess on Terrain Ocean too) not work?

 

@Darkcoder
Can you help me understand what I may have done wrong with the floating origin for particle systems?
Here is a video of it in action

And here is how I have the object set up.

 

I haven't used it but I remember when I went through all the demo scenes seeing a component called (I think) shadow caster.

UPDATE: Found it. Scene 06 Planet Shadow
Component SGT Shadow Sphere

I see you used very high values of 500 each. I think they work as a ratio so high numbers are only needed if you want subtle changes. 1,1,1 will create black just as well.

Did you check your radius setting and make sure the light source is a SGT Light?

UPDATE 2: No, I check shadow layer and shadow sphere and I too am unable to get a SGT light (either directional or point) to cast a shadow from planet to planet

 

I don't notice any difference between the source texture and what is rendered on the planet.

One thing I notice is that the planet's Normal Strength setting is ignored, so if your normal map is too strong then it can stand out. Even an 8k texture stretched around a large planet means each pixel will be very large, which can result it in looking 'muddy' up close or at a high display resolution. The detail textures are designed to mask this though.

I'll fix the Normal Strength setting in the next version.

The SgtShadowLayer component allows you to drag and drop renderers (e.g. MeshRenderer) into it, and it will apply shadows on top of the specified objects. The terrain planet component does not have renderers, so you can't do this. The shadow system is only implemented by features/materials that use SGT's custom lighting system, like SgtJovian, SgtRing, SgtAtmosphere. Planets and Terrains use Unity's built in lighting system, which also use Unity's built in shadow system. It would be possible to modify SgtTerrainPlanet to implement something like SgtShadowLayer, but it would have some performance penalty as it would have to re-render the planet again.

It's hard to tell what's going on. If I modify the "02 Floating Object" demo scene so the asteroid has a Particle System, then everything works as expected. If I switch the Particle System to Simulation Space = World, then I must ad the SgtFloatingParticleSystem component, then it continues working as expected.

 

I have three particle systems as children of a gameObject. One is the flame, one is the embers and one is the smoke.
When passing the threshold for the floating origin, the smoke seems to get dragged to the reset point. Particle system are launched outwards from the side of the vessel, perpendicular almost. When passing the reset point, the smoke becomes horizontal (pretty much showing its path from where it was before reset to where it is after reset) instead of being moved to the new point. I hope that is a better explanation. I'll keep testing on my end

 

Thx, it worked, but still there is the bug with the City Lights:

 

Can you try the steps I mentioned? If you can get it to work the same as I did, then check to see what the difference is between this and your scene. If your scene using some special setup then modify the scene I mentioned in a way that demonstrates the issue, and send it to me, or describe exactly the difference is.

I'll send you a fix. Keep in mind there is no possibility to enable night lights in the shadow/eclipse area of the planet, only on the normal dark side.

 

I found the issue. Particle systems that use Rate over Distance seem to have issues to floating origin since they deploy a particle after some distance has been passed.
Switching to rate over time (as the default PS system uses. The way I tested with the 02 Floating Object Scene) seems to fix the issue.
So I took a closer look at Rate Over Distance and what I saw was
The emitter begins emitting particles as the object moves through world space. A certain amount of particles are emitted (In my case up to 3,000) they begin to die off and the number drops rapidly, then...as I pass through the origin reset distance, the particle count shot immediately up to 3,000.
This tells me something isn't handling the particles properly. I THINK it is a combination of the position being reset from the floating origin mixed with Unity Particle System monitoring position for particle emission.

Unity doc for emission module
https://docs.unity3d.com/ScriptReference/ParticleSystem.EmissionModule-rateOverDistance.html
The emitter only spawns new particles when it moves.

Armed with this information I tried 02 Floating Object Scene again and yup the particles didn't update properly.




What I think is happening:
While the Floating Origin Particle System is grabbing the particles and updating their position, once the object the particle system is attached to moves, UNITY sees the new position and tells the emitter "Hey, you travelled 100 units. Emit the particles to cover this distance" which causes the effect seen here when using
Simulation Space: World
Emission: Rate Over Distance

I tried adding Floating Origin Object to the same object but with Floating Origin Particle System present that causes interference.

 

Hey Everyone, I'm using Game Kit Controller, has anyone found a way to allow the character to walk on one of the planets?

 

I was wondering if anyone has had luck integrating the SGT Universe with a form of Pathfinding? I currently have A* Pathfinding on my scene, if I was to introduce SGT assets, and use SGT Universe to scale out a system, pathfinding would immediately break as it uses the unity coordinate system. Is integration possible? Has anyone had luck using SGT Universe for scale, and then creating pathfinding within such a large level?

 

You could modify the pathfinding to use your GameObject's local space coordinates, or hook into the SgtCommon.OnSnap event and adjust all world space positions (e.g. navigation targets), or use some invisible non-moving pathfinding setup with a custom script that moves the AI actors around relative to the moving object in your scene (e.g. planet).

 

I'm not sure how I'd set up a grid the encapsulates all the gameobjects I want to be scanned as part of the pathfinding setup. I believe once there was a grid and all the gameobjects were scanned I could adjust the updating based on the OnSnap event and handle translation. I'm just not clear on how you define a grid for such a large space?
https://imgur.com/a/k69RsGN

e.g my current grid in this screenshot is 1024x1024 nodes. Representing 10km2.

If the grid starts at origin, 0,0,0 I'm not sure how to specify the scope of what it should be scanning to build a picture of the level for pathfinding.

When using FloatingObject to place gameobjects, where actually are they according to Unity's coords? I can no longer use the editor to visualise anything once I'm moving shifting origin.
edit: maybe I don't have permissions to post images..
https://imgur.com/a/ALv7RiU

 

The Transform.position of floating objects depends on how your camera moves and snaps, so if you use this data you must listen for camera snaps and update your positions. The 'universal' position data is stored in the SgtFloatingObject/Camera component as the Position, which will remain stable. How you solve this depends on your game and how you want to use pathfinding.

If pathfinding is such an important aspect to your project then you should probably not use the Universe feature, and instead configure your scene in a more traditional 'static' fashion. If a large scene is such an important aspect then you should probably use a more dynamic type of pathfinding, e.g. based on realtime raycasts and forces acting on each agent.

 

Thank you for the information. It looks like we need to think about which way to go and what kind of compromise to make.

For navigation around features such as asteroid belts and such we'll need some kind of pathfinding or it'll look ugly. We have a large amount of AI Pathfinding required in our game as we have AI drones and other things flying about.

Even the player's ship is not manually piloted, but takes instructions and then pilots itself, so again Pathfinding needs to be smooth and fluid.

I think we'll need to somehow have a hybrid system. For large distances it'll be more of a steering approach, then once it gets to certain features like asteroids we do some kind of raycast pathfinding, or set up a pathfinding grid local to that asteroid cluster etc.

A lot to think through.

 

SGT Starfield Nebula component generates always LIT material and therefore nebulas and smoke clouds made from it are rendered in with different brightness from different angles. How can I change it to me UNLIT ?
Thanks.

 

Are you sure it's lit? There is the HorizontalBrightness setting, which can be used to dim it when viewed from the edge (useful for galaxies), but if you set this to be the same as the Brightness setting then the brightness should remain uniform from any angle.

 

The Shared Atmosphere doesn´t work, when I use Vertex Offset on a Shader Graph Shader (Even when the Vertex Offset is set to 1):


But If I am setting the Vertex Offset of my Shader to 0 It will work:


My Vertex Shader looks like this:


And also in the Console is an Error since I imported the new Terrain Planet Shader, where the Night Light got fixed.

 

And can I convert my Noise in Shader Graph to SGT Terrain Heightmap?

 

The shared material component works by adding the atmosphere material on top of your other material. Since the atmosphere vertex shader doesn't know about your base shader vertex displacement, it causes this difference so it doesn't work. There is no automatic way to give it this displacement, you would have to modify the atmosphere shader the same way which is probably quite difficult.

I'll look into the error.

Yes, using a RenderTexture and rendering your material to it some way.

 

And how? I didn´t used RenderTexture in my Life.

 

The Water Ocean made the Probleme. I forget to add a Sgt Terrain Shared Material to the Ocean, lol.

 

I love what you're making.

 

It depends how your shader is designed. You may be able to use Graphics.Blit, or you may need to set up a camera with mesh, it depends and is probably quite complicated.

 

Hi @Darkcoder,
while trying to optimize my project for the Oculus Quest, I noticed something strange, I don't know if it's a known issue:
when setting the far clipping plane of my camera to a smallish value, the lights started to flicker strangely.

Here's an video of the issue with a far clipping plane set to 5000:

I had to set the far clipping plane to a minimum of 300000 for the issue to disappear.

Any idea how I could avoid that with a lower value?

Thanks in advance

 

Does this issue occur in the editor, or only on the Quest? Which rendering pipeline? Does the issue resolve if you remove the CwLightIntensity component from your light? If your light uses SgtLightPointer, does removing it fix this? Does disabling the SgtLight's TreatAsPoint setting fix this?

 

Error: 'SgtShadowLayer' does not contain a definition for 'Material'

Material is defined in SgtShadowLayer as;
[System.NonSerialized]
private Material material;

Assets\Plugins\CW\SpaceGraphicsToolkit\Features\Terrain\Required\Scripts\SgtTerrainShadowLayer.cs(36,37): error CS1061: 'SgtShadowLayer' does not contain a definition for 'Material' and no accessible extension method 'Material' accepting a first argument of type 'SgtShadowLayer' could be found (are you missing a using directive or an assembly reference?)

Unity 2022.2.18 URP
SGT: 4.1.3

 

Inside SgtShadowLayer is a public property:

Code (CSharp):

1. public Material Material
2.         {
3.             get
4.             {
5.                 return material;
6.             }
7.         }

At least in 4.1.3.

Try reinstalling it and see if this file is different from yours.

 

Can anyone tell me if its possible to use SGT to make aplanet you can walk the surface of.. on a Quest 2?

I'm working on a PCVR game using the asset which does just that, landing and leaving your craft on a full size world, but so far my attempts to optimize this to work on a standalone quest version haven't got me above 50fps (way below the target 72).

Can anyone recomment a terrain/collider (and preferably atmosphere) setup with this that wont kill a quest 2? I'd love to tell my follower its coming out on Quest as well as PCVR but really not sure its going to be possible with the hardware limitations.