Space Graphics Toolkit & Planets

PhysX will still use single precision, right?

 

I don't know what PhysX is using.

At first you should really define what data you will share with other clients in a multiplayer game. In most space games there is no need to share all data with everyone, because there is often a huge distance between them. Player 1 at planet 1 does not need to know where player 2 at planet 2 is. But I think this is out of the scope of this thread. If you start a thread with this topic somewhere else let me know. I am always highly interestet in those stuff.

 

Most likely will open such a thread as I also like this thought and reasoning processes.

But just to wrap this up, I believe (haven't tried it yet but will and share results) if I send the local origin coords ( those with large numbers ) to the authoritative server and then the server sends those coords to players within a certain radius of those coords, those players probably just need to calculate the difference between their own local coords with the ones from the remote player and translate that difference to their world origin.

An example would be:
Player A is at (0,0,10000000) and writes those coords to the server.
Player B picks this message.
Player B is at (0,0,10000005).
Then, Player A should be drawn on Player B's screen at WORLD space (0,0,5).

Makes sense or maybe I am overlooking something?

 

That's how it should conceptually work. The question is could you send a player position relative to a fixed position in the universe to the server. For example in a solar system relative to the sun or in a galaxy relative to the center of the galaxy. That could be easier and could be done without calculations.

 

Hey Darkcoder,

Been trying to change Nebula color when I touch it like this:

Code (CSharp):

1. var nebulaComponent = gameObject.GetComponent<SgtStarfieldNebula>();
2. nebulaComponent.Color = new Color (0, 255, 0);

If I change it from the editor it works perfectly. If I use the code above, the end result looks really bad and the only way to fix it is to use the color picker in the editor to assign a different color. Changing the color from the editor without the color picker won't help.

I have included the before picture, what happens after executing the code above and the right way to do it (from the editor). Am I doing something wrong or is this a bug?

And sometimes this error pops up when I play around in the Editor (while running)"

Code (CSharp):

1. Error assigning cubemap texture to 2D texture property '_MainTex': Dimensions must match
2. UnityEngine.Material:SetTexture(Int32, Texture)
3. SpaceGraphicsToolkit.SgtQuads:BuildMaterial() (at Assets/Space Graphics Toolkit/Features/Shared/Scripts/SgtQuads.cs:276)
4. SpaceGraphicsToolkit.SgtStarfield:BuildMaterial() (at Assets/Space Graphics Toolkit/Features/Starfield/Scripts/SgtStarfield.cs:226)
5. SpaceGraphicsToolkit.SgtQuads:UpdateMaterial() (at Assets/Space Graphics Toolkit/Features/Shared/Scripts/SgtQuads.cs:155)
6. SpaceGraphicsToolkit.<>c:<OnInspector>b__0_7(SgtStarfieldNebula) (at Assets/Space Graphics Toolkit/Features/Starfield/Scripts/SgtStarfieldNebula.cs:70)
7. SpaceGraphicsToolkit.SgtEditor`1:DirtyEach(Action`1) (at Assets/Space Graphics Toolkit/Features/Shared/Scripts/SgtEditor.cs:91)
8. SpaceGraphicsToolkit.SgtStarfieldNebula_Editor:OnInspector() (at Assets/Space Graphics Toolkit/Features/Starfield/Scripts/SgtStarfieldNebula.cs:70)
9. SpaceGraphicsToolkit.SgtEditor`1:OnInspectorGUI() (at Assets/Space Graphics Toolkit/Features/Shared/Scripts/SgtEditor.cs:30)
10. UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)

 

Fixed it with

Code (CSharp):

1. nebulaComponent.Color = Color.green;

instead of

Code (CSharp):

1. nebulaComponent.Color = new Color (0, 255, 0);

 

Hi,
I have a few questions. Is there a way to cache the Terrain LOD splits so we don't have to recalculate when scrolling through the planet?
Also you mention SgtTerrainCubeMaterials but it doesn't show up on the latest update, so we can't use a cube texture for a terrain planet.
Also, if I would like to make a realistic planet in size (like the moon), how would you go about doing it?

 

Sorry for the late reply guys, it's too easy to miss notifications here.

Regarding sending origin shifting system positions over the network, this can be done using SGT's origin shifting system, because the SgtFloatingPoint component used to position objects in the universe is a fixed position, and won't change when a camera snaps. You will of course have to manage transmission of this data, and any interpolation of its values yourself though.

I have no plans to set up any shared repository for any of my assets.

All of the effects work with any layer you specify, and will look the same regardless of scale, so it should work with the camera system you describe. Just keep in mind the terrain system sin't designed for "full-scale-planet-terrain-LOD systems".

That's the problem with planets, they contain everything, thus require writing every Unity asset while accounting for being around a sphere

This is because color values are floats typically in the range of 0..1, not bytes of 0..255.

1 - The UpdateSplits method can be called on your terrain to instantly update its LOD. If you want to fly to a specific point and you want to cache that before you arrive, then you can add a GameObject to your target point, ad its to the terrain's Targets list, and then UpdateSplits, or let it gradually update over time.

2 - The current terrain implementation only allows for one material, because the terrain mesh is UV mapped with a cylindrical/equirectangular projection. If I left that documentation in then it was a mistake.

3 - You can adjust the terrain's Radius setting, as well as add detail textures with high enough Detail Tiling, and make sure the planet material has a high Detail Tiling value too. Just keep in mind the moon is still very big, and the terrain system wasn't tested so much with bodies this large, and even if you can make it, the surface will look very boring.

 

Hey @Darkcoder

I purchased this asset a while ago and now I am only beginning to find it extremely amazing...especially your atmosphere shader which is amazing for smaller sized planets.

However I am trying to get it to work with extremely large planets...Planets that are about a 100 thousand meters (in Unity units). The normal part of the shader works except the atmospheric scattering doesn't.

Is there a way to tweak the code to work with very large planets?

 

It should work. In fact, if I modify the "03 + Scattering" demo scene to have a planet scale of 100000, place the camera at 0,99990,0, then everything works as expected. It even works if I turn the light into a point light and place it far away. Perhaps you're doing something extra in the scene like placing everything really far from the origin until it starts breaking down?

 

Yes I am placing them extremely far away from the origin point. How would I go about getting it to render far from the origin scene?

 

By not doing that, using an origin shifting system and/or reducing the scale of everything. If you have really extreme values then it's likely the scattering is breaking simply due to floating point precision issues in the shader, which likely can't be fixed without some difficult modifications.

 

Hey everyone, just a reminder that the sale will end in 24 hours!

Also, today version 3.6.3 came out, which fixes issues with shadow casters in some scenarios, as well as some other changes. Here's a picture of a pretty planet to celebrate:

 

I've recently purchased your asset and absolutely love it, thank you!

I have a question however, which I hope you might help me with.

Building on the Universe Warp LOD example I try warping an object(this case the "player" object).
The camera has a script attached which follows the player and allows rotation around the player. It's attached.
If I however "warp" the player object, by using the Floating Warp(set to the player's floating point), I get extreme jitter while warping. I've been breaking my head over this for a couple hours and have no idea how to fix this.

Any insight would be greatly appreciated.

 

I can replicate this jittering too. I imagine it's some kind of order of operations issue. I'll try and fix this in the coming days and send you a new build.

 

Hi, first of all thanks for the wonderful assets,
I tried the night texture which's added recently, but I found it that the emission of the city lights conflicts with the water emission value, which leads the night texture to be invalid with water enabled. Am I doing something wrong or it is a bug?

 

Thanks for pointing this out. I've sent you a private message with a fix for this shader.

 

Thank you very much

 

Have you had any luck, so far I've tried updating the position on camera precull, in update and late update too, none of them really help.

 

I found the issue, but fixing it is a bit more difficult than I initially imagined. Basically, this is what happens:

1 - Player and camera are near each other and near the origin, everything is fine.
2 - Player begins warping slowly, camera is placed in orbit using transform.position, if out of bounds they both snap back to the origin, everything is still fine.
3 - Player warping accelerates to be millions of units per frame, this places the player in an inaccurate transform.position far from the origin (though the true position is still accurately stored in SgtFloatingPoint). The camera is then placed in an also inaccurate orbital position around it using transform.position (your script), this new inaccurate camera position delta is then added to the SgtFloatingPoint of the camera, which now degrades the positional accuracy. The camera and player are then snapped back to the origin.
4 - Repeat for some frames and you get jitters, because the camera delta that gets added to the camera floating point is inaccurate each time.

To fix this you can either warp using SgtFloatingPoint/SgtPosition calculations only (maybe difficult), or perform your current orbit calculations, force the camera to snap, then perform the calculations again now that the player is near the origin (maybe easier, but more overhead).

 

Hi Darkcoder,
Have you changed the way the terrain detail maps work? I've updated to the latest version and my terrain generates differently (more obvious heightmap pixels, terrain splitting).
Cheers.

 

Depends which version you're updating from, I don't think I've changed it in the last few months at least.

 

I have a question, can this tool kit be use in a 3d space combat simulator? and, the player cloud land on a planet?

 

Yes, and yes. Just keep in mind there is no spaceship controller or player controller scripts to do these things, you would have to make those yourself, or use some other asset. There is an asteroid controlling example with flying down to a planet with gravity though.

 

Hi Darkcoder,

I have a problem. In the first image you can see how the planet looks in the editor in play mode. When I build the game the planet looks like the second image. Any idea what the problem is?

 

Which exact version of Unity are you using? Which platform are you building for? Which device (especially GPU) are you running this on? Do the example planet scenes also break like this?

 

I use Unity 2019.1.4f1 and I build for the windows x64 platform. My GPU is a GTX 1070.
I never used the example scenes. What I did is I opned the Alien 3 scene, copied the planet into my scene and added a cloud sphere to the planet. That worked well until today. Today I have added the SgtMeshDisplacer script and now I have this effect.

 

Looks possibly like you're mesh displacer has lowered the terrain below the atmosphere.

 

The terrain is below the atmosphere. It changes the surface color completly. When I fly down to the planet the surface has the color you can see in the second image. When I disable the mesh displacer it works again.

 

The atmosphere component has an inner radius variable. You can lower the atmosphere with this.

 

Yes, but the atmophere is not the problem. I deactivate all components exept the mesh displacer and I have the same effect.

 

Can you write a micro script that reports the displacer's settings to the console log? Almost looks like the scale of your texture for the displacement is going out of control, or something with LOD's.

 

This is the log. Everything as expected.

Enabled: True
ZeroCutoff: True
InnerRadius: 1
OuterRadius: 1,03
HeightmapCutoff: 0,301
HeightmapCutoff: Alpha
Heightmap: Alien3_Height (UnityEngine.Texture2D)
Original Mesh: Geosphere100 (Planet) (UnityEngine.Mesh)

Material 1: Alien3 (Instance) (UnityEngine.Material)
Material 2: Atmosphere Inner (Generated) (Instance) (UnityEngine.Material)

I've made a new planet from scratch and I have the same problem. I have no idea how to fix it. In Unity play mode everthing is fine and when I build the game it is broken. When I build from a SGT sample scene the same planet looks as expected. All project settings are the same. I don't know what the difference is between the Unity player and the live build player.

 

Could that be a shader problem with shaders I use in my project?

 

Looks like a floating number precision problem, can you try to put the position/scale of your planet to a small value like under 1000 and see if the problem persists? I used to encounter similar problems, which was caused by the light(sun) too far away

 

Hi I've tested it with a small planet of size 250 and a close directional light and close to 0,0,0. The result is the same.
I am running out of ideas how I can fix this.
Thanks for trying to help.

 

Try keeping it at radius of 1, then make it a child of a gameobject that you scale up. Like below, Ive had reasonably good luck setting it up this way.

Planet - Floating point, Floating Object, orbit stuff, gravity stuff
--Scale - XYZ 300 (or the scale your aiming for)
-----Terrain
-----Atmosphere

 

The same result

 

@dirkjacobasch - I haven't found a way to recreate your setup, so I am lacking a way to test it further. Hopefully Darkcoder is already on it or will be able to look at it. Might email him.

@Darkcoder - Can you give me a suggestion of quickly calculating tilt for orbit of an object based on its direction. The way I was thinking it could happen is based on the direction and offset from the orbiting body, but I haven't tested it yet. Any suggestions would be great.
Thank you for a great product!

 

Hi Darkcoder,
just wondering if you have a time-scale for up-coming updates.
Cheers!

 

Yeah, I found a solution for my problem. When I export the mesh and set it manually it works.
No idea why.

 

Hi Darkcoder,

how can I make the clouds visible from the planet surface? Setting Cull=Off in the SgtCloudsphere shader doesn't work.

 

Sorry for the late reply everyone!

I'm not exactly sure what would cause this. The SGT Planet shader shouldn't change based on the mesh displacement or the presence of an atmosphere or cloudsphere. Since you mention the SgtMeshDisplacer, perhaps this component is somehow breaking the generated mesh, like the UV data or something. In terms of code this just instantiates the source mesh, displaces the vertex positions, then writes those, so there should be no potential for anything else in the mesh data to break, but perhaps there's some kind of bug with some combination of settings you're using.

You currently can't, because rendering it two sided causes draw order issues with other transparent materials. To modify the shader to render both you also have to modify the rim fading code, because it currently falls off and clamps to 0, you would have to modify it so it goes to 0 then back to 1 on the backfaces. However, as I said this does cause rendering issues that can't easily be fixed, so I designed it like this to not be visible. For surface clouds it would be better to spawn cloud particles, prefabs, or some other alternative approach.

 

Sorry for the late replies everyone!

I'm not exactly sure what would cause this. The SGT Planet shader shouldn't change based on the mesh displacement or the presence of an atmosphere or cloudsphere. Since you mention the SgtMeshDisplacer, perhaps this component is somehow breaking the generated mesh, like the UV data or something. In terms of code this just instantiates the source mesh, displaces the vertex positions, then writes those, so there should be no potential for anything else in the mesh data to break, but perhaps there's some kind of bug with some combination of settings you're using.

For a simple orbit you can use sin/cos for the x/z axis, scale it by the orbit distance, this will give you a circular orbit around the y axis. You can then multiply this by a Quaternion.Euler(rot), where rot is the tilt of the orbit.

Not sure about new features, but I will soon add as much support for LWRP and HDRP as I can. I've now almost finished updating the documentation and such for my other assets, so I will have time to add new features like this. I also want to make some new tutorial videos, as the ones I make always get outdated by new changes

You currently can't, because rendering it two sided causes draw order issues with other transparent materials. To modify the shader to render both you also have to modify the rim fading code, because it currently falls off and clamps to 0, you would have to modify it so it goes to 0 then back to 1 on the backfaces. However, as I said this does cause rendering issues that can't easily be fixed, so I designed it like this to not be visible. For surface clouds it would be better to spawn cloud particles, prefabs, or some other alternative approach.

 

Hi Darkcoder,
thanks for your answers. Like I said in my last post I fixed the texture issue with exporting the mesh. That's ok for me.

Feature request:
It would be nice if you add a feature to the atmosphere shader which increase the height slightly if the camera is close to the atmosphere. With this feature you can set the atmosphere very thin from a far distance (more realistic) and if you are close or inside the atmosphere has more height to fly around in it.

 

@dirkjacobasch - You could raise the atmosphere as you get within a certain distance, you just need to call the update material and update mesh functions after you make changes. I did something similar with Singularities, used them as a thruster visual and as long as you call the update material and or update mesh it should update as you see it.

@Darkcoder - I was actually asking as a way to drop values into SGT Orbit scripts without the ship/object jumping to 0, based on the direction and vector, but I'll figure out something just have to play with it enough.
Thanks
~Ark

 

This was added recently via the SgtAtmosphereHeight component. This is also mentioned in the documentation under Atmosphere > Atmosphere Thickness

Ah, if you want to convert a world point to orbit values then you can transform.InverseTransform your point to get a local space point of your ship, then use Mathf.Atan2 with the new local x/z values to get the angle, and the magnitude of this vector will be the orbit radius.

If you're using the old SGT_Orbit script then it has the RecalculateOrbit method, which more or less does this.

 

Awesome thats exactly what I needed thank you!

 

Awesome, that's exactly what I need.
Thanks

 

Not sure if its already available to do, but is it possible to keep a planet perfectly a sphere in space? I noticed using height maps creates hills, and these hills can be visible in space, even if you use the LOD system.