Space Graphics Toolkit & Planets

Indeed, SgtRing isn't designed for small points lights, internally it just calculates based on a directional light (as does SgtAtmosphere). It also doesn't receive normal shadows, but it can receive planet shadows from SgtShadowSphere. Both of these design decisions are because having shadows or normal light support means making a surface shader or shader graph, both of which are a nightmare to support, don't work well with transparent objects, and offer very little customization with regard to how the lighting is handled. If you really need small point lights then it shouldn't be too difficult to modify the shader though, as I think the light position data is in the shader.

I just made a new project with Unity 2019.4.4f1 + standard rendering pipeline + SGT 3.73 + Burst & Mathematics packages + "08 Box Layering" demo scene. It works exactly as expected on 64bit Windows 10 with x86 or x86_64 build modes. I'll need some more information to debug this.

 

Nice to meet you.
I am thinking of purchasing [Space Graphics Toolkit] at Unity's asset store.
I want to use it in a VR game. Is this available for URP?
I am waiting for your reply.
best regards

 

Yes, SGT supports URP and VR. If you're planning to target Oculus Quest then it's my understanding that the dynamic LOD system (SgtDynamicPlanet) is a bit too heavy to run smoothly on this device, but it runs great on my Rift. All the other features are comparatively much faster though. I may revisit this component to improve the performance, as I've been looking into terrain generation quite a lot recently and I have some new ideas.

 

Some more pictures.

 

This looks great! how can I reproduce?

 

Here's a quick pic of my latest experiment for the new terrain asset.

It's an Earth sized planet made using a variant of geometry clipmaps. This is similar to how the dynamic terrain in SGT used to work, but at the time I had to ditch this approach because it ran slow when used on large planets. However, now that jobs and burst are a thing, this approach may turn out to be better than more common techniques like quadtrees, we'll see. I also have many nice ideas for how to handle texturing and biomes, more to come soon

 

Did you ever think of a concept of "floating orientation" ?
I mean keeping the player on the positiveY face of the planet all the time and rotating the terrain generation itself as you walk away. That would make all the standard character controllers (and ground vehicles) work on the planet.

 

First you find someone who loves you very much...

 

Earlier I saw mention of " SGT Terrain component" in preview. Do we PM you our invoice number or how to we get that to check it out?

 

Never considered this. It sounds like it would make scene setup very tedious though.

If you want to test it then sure. It's still heavily under development though, so I don't have any test versions ready.

 

pm sent

 

Is it possible emulate real planets, Like Mars os satellites like Moon?

 

A while back there was a "SphereToTexture" unity asset shared. And talk about Mars mapping using it. I don't remember where but I grabbed the asset he shared for future use. It is still there last I looked.

 

Yes, you just need to have/make the surface texture(s) for them. The free Solar System Pack for SGT comes with Mars and the Moon examples though. If you need higher resolution textures then you can probably find them online.

 

The clipmap is the same than the nvidia article on GPU gems?

Spoiler: NERD!

I hated that one lol, I redid something similar in blitz but much simpler with increasing power of two chunk ( github.com/Neoshaman/blitz-experiment/blob/master/blitz%20basic%20test/power%20of%20two%20test.bb ) and stitch mesh between chunk size increase. It was simpler because I only had a nxn mesh to scale (I use to cache it, but now memory access is a bottle neck, it's probably faster to recompute with burst) and tile in log2 grid, and the only two stitch (horizontal and vertical, with one being bigger by two to cover corner, could probably simplify to just one by having a "rotating offset").

 

It's loosely based on that, but their implementation goes out of its way to do everything on the GPU which makes it overly complicated and doesn't work well with colliders and such. With a mostly CPU implementation it's actually much simpler to implement as you don't need 'ring fix up' or 'interior' trim' parts, and in fact the core functionality need only be 400 lines or so. However, there are still quite a few technical challenges to optimizing it, almost there

 

I think we have a winner with this technique, I'll record a video and send out test builds soon. I've currently implemented this Earth sized planet with triangles that go down to 1m, and with quite a high triangle density. Each LOD level has vertex position stitching, vertex normal stitching, and I also implemented splat map generation that is also stitched.

Although it may not look like it due to using random colors, this splat map system is similar to MegaSplat, so you will be able to use many (e.g. 256) different textures with minimal rendering overhead. The best thing about using this texturing approach is that you can basically implement triplanar mapping and anti-tiling/stochastic sampling together for free. The downside is that I have to implement this shader code in Shader Graph some day...

To top it all off, I finished implementing most of the main optimizations. On my puny i7-4790 I get 1000FPS when idle, 500FPS when moving at a moderate pace, and even when moving fast it doesn't seem to dip below 150FPS or so. On weaker machines you can always reduce the overall mesh detail, as this is fairly high. There are further optimizations I can do like preventing lower LOD levels from appearing based on camera speed or something, but for now this works great.

 

Looks fantastic! What kind of texture resolution will large planets be able to handle? On previous versions, the normal and albedo textures would warp when tiled thousands of times over a planet's surface.

 

Can't wait to get my hands on it. If the performance is so high go down to 1cm.

 

Each colored 'pixel' you can see in that screenshot is a splat map pixel around 30m² (you can change the scale, with no performance penalty). This will later be replaced by an actual tiled texture (e.g. 4096²), so the resolution can be incredibly high. Each neighboring splat 'pixel' can then sample the same texture, but at a slightly different scale or rotation, which will hide the tiling (similar to THIS). I still have to test it, but I think it should work without distortion at any sensible planet scale.

Indeed you can, but at these scales you run into issues with the noise itself since Unity.Mathematics.Noise is single precision. I'd rather not copy+paste their code as doubles though, so I have some ideas I want to try out to work around this

 

It appears I can't access the namespace in HDRP. Any idea why?

 

This is probably due to the asmdef used by SGT, I replied to your PM with more details!

 

Someone had mentioned about using Mars terrain files etc...

If someone had tiles, what would be the process to integrate it into this?

Also I saw some of your newer posts about stitching etc etc... it looks like a lot of cool features.

Would any of these create a "warp like" affect for the mesh/terrain to curve slightly so that I can use the tiles?

 

The SGT Planet shader is designed to use a single equirectangular surface texture, not tiles. You could make it use 6 tiles one for each cube face with some code modification, but doing multiple tiles per face would quite a lot of modification.

The stitching for the new terrain asset has no impact on the texture mapping. However, this system will also have no support for tiles, and supporting multiple tiles per face would require even more code modification because this doesn't use quadtrees.

Tiles are only useful for projects that need really big planets with incredibly high resolution non-procedural planet textures (e.g. real satellite images). Most games don't need this, so this has never been the goal of any of the SGT terrain components.

 

How large of an equirectangular image can be used for the planet shader? Also, can it use an equirectangular height map file? (You had mentioned texture file, so just want to make sure).

The idea of it using 6 tiles (cubemap form) is probably a little bit more desirable in my use case.

Where do I need to go in the code to do this xD?!

Per always thank you for your awesome hardwork and assets. Bought the painting asset you made a few months back, and look forward to diving in on that pretty soon also.

 

Hello @Darkcoder I am creating a new VR project in Unity this week. My standard setup includes Unity 2019.4.8f1, URP, Oculus Integration, VRIF, and SGT. I haven't created a VR project with a space theme in a couple of months, so am just now getting back to testing out SGT with Unity/URP/VR. I am experiencing the same issue with the flare effect, where I can see the flare occlusion in the scene and game views before hitting play, but once I hit play, the flare occlusion no longer registers, and I get a repeating Render() error message. Here are the specifics.

Error Message:
Assertion failed on expression: 'IsMatrixValid(matrix)'
UnityEngine.Camera:Render()
SpaceGraphicsToolkit.SgtDepthCamera: DoCalculate(Vector3, Vector3) (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepthCamera.cs:100)
SpaceGraphicsToolkit.SgtDepth:Calculate(Vector3, Vector3) (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepth.cs:35)
SpaceGraphicsToolkit.SgtDepthScale:LateUpdate() (at Assets/Space Graphics Toolkit/Features/Billboard/Scripts/SgtDepthScale.cs:49)




(Note: Single Pass rendering is required for URP)

 

Scene View billboard works:

Oculus Rift (Unity Play), billboard doesn't work and 'IsMatrixValid(matrix)' error in console:

I did a little more research and not sure if this Unity issue tracker entry is relevant, but thought to share it. (BTW, it's a "won't fix" issue found in 2018.3.6f1) https://issuetracker.unity3d.com/is...rs-when-using-holographic-emulation-in-editor

 

WORK AROUND: If I disable the SGT Depth Scale script, the error goes away, but so does the beautiful flare effect. (screenshot below)

 

The texture size is limited by Unity or your GPU. I think in the editor you can load up to 8k, but via code you may be able to do 16k. The heightmap and albedo/normal/etc are all mapped using an equirectangular projection.

Looking at the code now, it seems harder than expected to draw 6 cube faces because all terrain chunks are batched together, so they would need to be separated. You would need to modify The SgtDynamicPlanet.GetVisual code to separate each SgtDynamicPlanetVisual into their own face (you would need to store the face ID in each chunk and visual), then in LateUpdate when they're drawn, you would change the 'material' based on the current cube face.

Indeed there seems to be an issue with SRP and the SgtDepthScale component. Last time I tested it worked in URP but not HDRP, but perhaps Unity finally improved URP so it breaks in both. I have plans to rewrite the way this component works so it still looks the same but doesn't require camera rendering.

 

Thank you Mr. Wilkes, that would be brilliant! Trying to find the balance between functionality/stability/visual quality in VR is such a balancing act. Your SgtDepthScale effect looks so amazing in VR, I look forward to using it with URP (which is becoming the defacto recommended Unity post-processing for VR experiences.) There is something so immersive to see an object pass between you and a distant star, and that star's radiant intensity fluctuate.

 

Is it possible to animate the Flare Noise Phase? I am trying to make a "twinkling star" and thought to change the SgtFlareMesh.NoisePhase value over time, but when I run the program, the float value changes, but the flare doesn't actually animate. Are there other ways I could do this? Thank you.

 

You must call the UpdateMesh() method after changing the values related to the mesh generation. This is done automatically from the inspector. I should really make some kind of automatic 'mark as dirty' system to make these kinds of modulations easier.

 

Look's very interesting. I have a 2080 ti, i9 9900k. Curious how high my FPS would be with this newer planetary stuff. Only thing thats rough with earth size planets is that unity scene editor, is unable to see large planets. Keep up the awesome work on this. Maybe eventually we can have our own microsoft flight simulator lol

 

Here's another picture of my progress:



I've now implemented splat map sampling with triplanar mapping, anti-tiling, LOD, and basic height blending. It's currently random just to test, but I'll make it use height/slope/etc next. This is 4 different materials, but it can easily be extended to 256 for any kind of biome, and the shader itself has more or less the expense of just sampling 3 materials. So far so good

You will be able to find out soon

 

Is there any plans of updating the atmospheric affects as well? I notice some clipping points through the mountain on the far left. There is some new atmospheric stuff I've saw recently that came out this year. Look's really good. God Rays, etc would add extra detail as well.

https://sebh.github.io/publications/egsr2020.pdf, But. I haven't messed with this asset since back in May, so I wouldn't know, if anything changed in that area.

 

Hello Space Rangers!
I search more video tutorials or exemples docs about this toolkit because the online Doc is not easy to understand.
Anyone ?

 

Can you explain what you mean by 'clipping points'? This is using SgtAtmosphere for now. I plan to add a screen space alternative in the future, but I don't want to spend too much time working on multiple things, so this terrain will come with this at first.

Which aspects of SGT do you need help with? I can always improve the documentation if someone gives me feedback

 

What do you mean when you say like megasplat? Do you mean barycentric reconstruction? If yes how did you do it, i never figured out.

 

Indeed, it basically works like 2D simplex noise. Given a UV you can %1 to get the quad/cell, and x>y to get the triangle, and a few more divides to get the barycentric weights. The main difference is that instead of interpolating between 3 gradients that you sample from a hash, you interpolate between 3 splat map samples. At its most basic level this splat map can store the material ID, but you can also store multiple materials and their weights, as well as some kind of transform data to handle triplanar as well as anti tiling as I do. It's actually pretty trivial to implement for a basic terrain (though planets need LOD so it's trickier), I'm surprised more terrain shaders don't do this.

 

The shape of the mountains is very nice, but the texturing just looks viscerally wrong.

I live in central Utah; there's a mountain range practically in my backyard. This sample looks... patchy, I guess is the right word. There are patches of green and brown scattered here and there randomly, which undermines the sense of vastness that actual mountains have. A mountain has large swathes of bare stone, of trees, or of snow, occasionally interrupted by other features, but you can still tell what the dominant "look" is in any given region of that mountain. And I don't get that sense from this image.

Not sure how you'd go about recreating that algorithmically, but if you want high-quality imagery, that's a good principle to guide your work by.

 

As I said, the texturing is completely random right now. I will make it based on the terrain features as the next step

 

Oh my bad lol, I thought the fog was clipping through the mountain. But it's actually a mountain in front of the fog

 

Thanx for response. I wish your project will be the Best in Future !!
i search videos who learn me to how to :

Make your Moon With Orbit around earth
Replace your Starship Model
Make Player Controller as FPS with rigibody & Enter/Exit Starship
Optimize Water Shader with/without another Asset in store

 

Hi there.

SGT looks really wonderful, and I am thinking of getting it as I could never come up with something this nice for a space sim game (similar to Rogue System) that I have in my head. Well done so far.

Quick and rather basic question.... Are the oceans on the SGTDynamicPlanet submersible? I would rather like the ability to traverse underwater like it was a thick atmosphere with a crisp boundary to the real atmosphere. If not, are you planning to implement that at all. Apologies (new to the forum) if this has been asked and answered before. Can't find it in the forum or documentation.

Cheers, Ken.

 

Oh thanks!

Unfortunately i was thinking about the arbitrary mesh version, not the terrain one , since the hash automatically gives you the vertices id but the mesh version must reconstruct it from the gradient data passed to fragment... which is the sorcery i try to solve as the application opportunities are huge!

 

1 - The "Space Graphics Toolkit/Features/Shared/08 Simple Orbit" demo scene shows you how to do this with the SgtSimpleOrbit script. You can just copy+paste the moon from the Solar System Pack into this scene. I guess I could make a video of this, but it's a really simple component.

2 - Just swap the mesh out? The main camera's SgtCameraMove component is used to control the spaceship, and its parent GameObject uses SgtFloatingFollow to stay glued to it. This is just a very basic example spaceship/Rigidbody controller though, for an actual game you probably want something better.

3 - That's beyond the scope of this asset.

4 - There's no way to swap the water out right now, maybe in the future.

The oceans are static and baked into the terrain, so you can't go inside them. Making an actual transparent ocean is something I've experimented with before, and plan to again, but it's very tricky to do for a full sized planet. The water mesh itself isn't that difficult to make, but making it render with the atmosphere, and have waves, and LOD, and be able to go under, etc, makes it very difficult.

One way to do this is to store an array (or texture) of weights for each triangle as well as the object space position of each vertex. In the fragment shader you can then use SV_PrimitiveID to grab the weights and positions for the triangle, and using the fragment position in object space you can calculate the barycentric weights.

Surface shaders of course don't allow you to use this semantic because reasons, so making this work with lighting would be annoying unless you used ASE or something. Another sane approach is to store the weights in a texture using lightmap UVs, then you can just use this terrain approach to do it.

Reconstructing the barycentric weights from some derivative values might be possible, and it's something I considered, but it sounds really difficult and probably a waste of time.

 

Question, when you say that it is beyond the scope of this asset to "Make Player Controller as FPS with rigibody & Enter/Exit Starship" are you saying it's not possible or you have to make your own?

Really would love a giant robot game similar to Armored core 2/mechwarrior but the planets are realistic and not just a glorified FPS map. This means adding locations on the map to go to/battle and being able to walk on the surface. Hopefully I can add that into your planet implementation because it's very good.

 

The primary focus of this asset is to render a wide range of space graphics so you can then put your own gameplay on top of it. It is of course possible for me to add an FPS controller with enter/exit spaceship controls, but if I advertise this as a feature of the asset then users would then be requesting things like a teleporting system, equip/unequip weapons, jetpacks, and other things you might expect from an FPS controller associated with space, and I have no plans to make anything like this. If I added a basic FPS controller that users could build off of, then they would still have to do a lot of programming, so I don't think it would make much sense.

 

That's what MegaSplat from @jbooth does though, each triangle vertex is tag offline with either full R,G or B value to differentiate them and A has the (random from data pov) index of the texture to sample, in fragment he blend the 3 textures index, using the position given by the RGB barycentric position, by reconstructing them. That's what i wanted to guess... so many potential use. My guess is that you have the position, you need velocity to discriminate.

Anyway thanks for answering, i thought you knew.

 

Interesting. I did read on their forum or something that this additional mesh data can increase the vertex count though. This leads me to believe it may not be reconstructing them, but instead it flips/rotates the weight order based on neighboring triangles, and splits the vertices if there is an impossible scenario. If the alpha does store the index as you say, then it must be reconstructing them though. Maybe I'll look into it one day, but for now this basic approach works for this kind of terrain.