Great, in future do and if you plan to add floating origin please keep it optional. Thanks
@Darkcoder1
Could I please put in a request? I saw you mention you were looking at a fast solution for spawning grass on the new terrainā¦ could you please implement it for the old SGTTerrain? Itās my biggest frame rate hit at the moment as Iām spawning it using the existing prefab swapner but Iād love something more efficient at generating and batching it!
Also some way to have more randomly spaced clumps of prefabs rather than a constant spread across the planet would be amazing. So you could have patches of trees with just grassland in between etc.
If you read the devās previous post about unityās limitations, you will notice that the floating origin system is essential for generating large planets, and large universes, but not for anything else specifically.
Also notice that most of the Planet Forgeās and SGTās current example scenes do not implement SGTās floating origin system. They are smaller planets/phenomena that do not rely on the floating origin system
@Darkcoder1, I am just pushing this old post back to the front as I know there have been a lot of questions. Regarding the floating origin system issue, Iāve narrowed it down to an issue with how I implement custom Scifi Ship Controller-run ships (SSC ships). Nothing wrong with SSC or SGT specifically, just my manner of integration.
In any case, I would welcome your perspective on how the floating origin system might be interfered with by external code!
Thanks for proactively replying to my concerns.
Btw planet forge is genuine and significant improvement over SGT planets.
@PsigenVision
Which aspects of it do you want to access with code? At its core, you just need to add the SgtFloatingObject/Camera components to your scene, and assign positions that make sense in your scene. Things like spawners, seeds, scaler, etc are just built on top and might need to be modified for specific projects.
@ahmedaliadeel
Thank you!
Also, hereās a sneak peak of cloud shadows:
They look much better than Unityās built-in shadows, and have no range limitations. Now I just need to make them cast based on the light angle.
3 Likes
Looking really nice! Iām working on Earth sized planet so might wait a bit though.
Some have wondered how to do high speed collisions with the surface or prevent ship from flying throught. One thing Iāve used is planet sized sphere collider though thatās bit inaccurate, but I also found out at least in the old system you can modify the SGT Terrain Object script to calculate the distance from sampledPoint to planet center to get the terrain height, then calculate the shipās distance from planet center and define what happens when itās less than the terrain height. With some work one could possibly go all way without using colliders, or use it as fallback in case colliders fails.
Though of course that way itās measured from the shipās center so need to take that into consideration, while it would allow things like a ship sinking into ground when crashlanding or in soft ground or sand and stuff which would be harder to do with colliders. Couldnāt get the delta or aligning to surface normals to work with that yet, which might be for some silly mistake somewhere.
1 Like
Whats the maximum safe radius of planet including the area where aircrafts can fly without visual or phyisical floating point artifacts?
1 Like
Also just for my future note, is the author considering adding floating origin support in future?
1 Like
Just to add weight to my request as I think its probably not going to happen. This is a full size planet (5,000,000 Radius) at ground level using the OLD terrain system, running at a solid 72fps in VR.
If it just had a proper grass renderer it would be perfect.
@Susihiisi
A giant sphere collider might work if accuracy isnāt too important. However, since you mentioned Earth Sized Planets, you would need to place the collider at the minimum radius, which would be at least 9km below the peak of Everest. So in the worst case scenario, your objects would have to fall over 9km before anything happens, and even then they would just stop far under ground.
What you should do is similar to what you mentioned, and reposition the object if it goes below the terrain, which doesnāt require colliders. The SgtSphereLandscape component has the GetWorldPoint and GetLocalPoint methods, which can give you the nearest surface point up/down from the input point. Using this, you can detect if youāre inside the planet and reposition it.
1 Like
@ahmedaliadeel
This depends on the graphics API, LOD level, camera position, planet position, camera draw distance settings, and probably many other factors, so itās best to test for yourself with your target hardware as I donāt know.
I plan to implement origin shifting in the future, as itās required for massive planets. However, Iām currently trying to get smaller planets working super well before I go for higher scales, as this will require many changes to the code that will make it more complex.
1 Like
@Mulbin
Your work looks great! I havenāt written a proper grass renderer for any terrain system yet, so we will see. I plan to implement one into Planet Forge, and hopefully get large planets working well, so maybe you could port your work into that. If the grass renderer doesnāt end up being too complex then I might be able to port that to SGT Terrain.
1 Like
Since this issue comes up a lot in this circle, I wanted to mention that Unity made its own double3 origin shifting system, and although they barely advertise it, it actually works great. Iāve been using it for my project, and once I figured it out itās been just what I need. Itās got a nice simplicity, and itās versatile in that you could use it to offset the origin every X units, offset every frame, follow specific transform, etc:
2 Likes
Will you also add the ability to have multiple planets like the old system? Also Massive Floating Point objects like in SGT?
@maximblake254
Thereās no limitation on the amount of planets, where did you get this idea? The only issue is the new cloud system doesnāt render clouds correctly in areas where the clouds of two planets overlap. You can use the Universe system from SGT. I havenāt decided how I will integrate this into the Planet Forge asset yet, but if you have both you can still do it. It wonāt work with SgtFloatingMassive though.
@adsilcott
Wow thanks, I had no idea. Iāll have to check it out. However, when developing the SGT Universe feature I found that double precision wasnāt enough for universal coordinates, which I why I made SgtPosition use doubles + longs. For solar system scale, doubles would be great though, and it also greatly simplifies the math for any kind of calculation.
2 Likes
Indeed. I use the HPFramework for the local system and ints to track the galaxy wide location ā longs would be better but I have a technical reason for using ints. 
1 Like
I believe the problem is when you insert two planets, the scheduling goes crazy and performance tanks.
Havenāt tried it in builds.
The ideal would be for all planets in the scene to be aware of one another so they can access the same scheduler instead of conflicting over it.
And yes, this asset is very beautiful. Awe-inspiring in the literal sense when you find the rocky terrain features in Star Citizen and Starfield lacking compared to this, but I believe the cloud system is what makes it an awe-inspiring asset even more so than the terrain itself 
which says a lot about how striking it is. Only have some issues with walking inside of clouds resulting in lots of graphics artifacts in HDRP but outside of that it just works. Of course, SGT is way more performant so I still have some specific uses for it.
Example of said graphics artifact is the jagged contour that can be visualized in here which flickers a lot while moving:
And I love this cloud system enough I wouldnāt mind having a planar version that we are able to use with Planet Forget Square Landscapes and also our very own Unity Terrains 
Right now you can make the sky component work with square landscapes juts fine, but not the clouds component.