Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Space Graphics Toolkit & Planets

Discussion in 'Assets and Asset Store' started by Darkcoder, Aug 18, 2012.

  1. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    You mean increasing the Outer Radius in the SgtMeshDisplacer if you inside the atmosphere?
    Good idea. I never tried that out.
     
  2. Leewhitt

    Leewhitt

    Joined:
    Nov 29, 2017
    Posts:
    4
    Hi both! I'm after a copy of this fix if one is available please? Encountering the same issue.
     
  3. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Hi, is there a way to change the outer radius in the SGTMeshDisplacer without calling RebuildMesh every frame? What I want to do is increase the displacement height if you move closer to a planet.
     
  4. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Could do it based on distance. If you get X close update the mesh, but this will look jumpy unless lerp'd every frame with in a distance threshold.
     
  5. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    There's no feature like this, because as @Arkolis mentions, adjusting the mesh displacement in realtime as the camera approaches will incur a performance penalty each time you update, and this penalty would be proportional to the vertex count of the sphere you use. This kind of thing is best done using a custom vertex shader where there would be almost no performance penalty. However, this approach would be incompatible with the SgtAtmosphere effect, because that is rendered as a separate layer. Fixing this would require a custom atmosphere shader that uses matching displacement vertex shader code, which I don't want to implement because this means no other planet surface shaders would be compatible.

    I tested this in the editor just now and it appears to work as expected, since this fix was already implemented into the SGT code long ago. I'll test it further in VR builds and answer you via email.
     
  6. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    @Darkcoder
    1) Do you think ECS could do the calculation without a performance penalty?
    2) I send you a message. Did you see that?
     
  7. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    1 - ECS would make no difference, though multithreading with the job system would, and would be easy to implement since this mesh deformation is an example of an embarrassingly parallel problem. I'd rather not move the main build to Unity 2018 just yet though. It would also be possible to stagger the mesh update over several frames to reduce performance impact.

    2 - Yep, I just got back from holiday and have a backlog of messages to go through though. I'll reply as soon as I can!
     
  8. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Thanks for your answers. I hope you had a nice time on holiday.
     
    Darkcoder likes this.
  9. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    1 - Could use the SGT LOD system, keep it a somewhat round low poly terrain til you get within distance and swap to a reasonably higher poly mesh. Then you could adjust the displacement on late updates? Maybe throw in some entry effects to keep the eye on the ship/entry vehicle to keep the transition from being noticeable.
    ----
    On a separate question, could the way the warp system works be used for say moving ships within the local star system? Or is there a different way? Trying to design a simple orbit transfer system, Currently using transform.translate but that wont work very well down the line when Im moving a ton of ships around a solar system, at least I dont think.
     
  10. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Good idea, the planet LOD system could indeed be used to do this.

    Regarding moving ships, the origin shifting/universe system could indeed be used to do this. However, if your ships are far from your camera (and thus world origin), then you won't be able to accurately manipulate these values using the transform directly, you would have to use the SgtPosition class instead which allows for tracking of high precision GameObject positions. This may be a little trickier since I didn't implement most of the helper methods available in that.
     
    Last edited: Sep 24, 2022
  11. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Another option could be using blend shapes to blend from a normal sphere to a displaced sphere, but you need to set it up in Blender or Maya.
     
  12. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    Hi Darkcoder,
    The game I'm working on requires quite large planets. They don't have to be walk-able and the level of detail provided in the kit is more than adequate. I don't need detail textures for the surface nor shadows (although both would be nice!). What I do need is more terrain manipulation and object spawning options. Ideally a biome map (which the object spawning system uses), with each biome having two or more detail-heightmaps. Also, I need to fix the visible gaps in the geometry seams with large planets and the pixelation from the heightmaps (you mentioned that these might be fixed in an upcoming update).
    If these features aren't planned to be added in the next few months, would you be able to help me implement some of them?
     
  13. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    This would work too, it may have the same or worse performance as the existing mesh displacer though depending on the implementation. I haven't used blend shapes before so I'm not exacly sure about its performance.


    The current terrain implementation shouldn't have geometry seams besides from floating point inaccuracy at large scales, but it does have lighting seams across the UV edges when using normal maps. These aren't fixable using the current implementation despite using two blended UV sets, because the surface shader system only allows for one tangent set, and there's no way to seamlessly map tangents around a sphere.

    There are 3 ways to fix this:

    1 - Writing a new planet shader that passes two sets of tangents and blends the result. This requires additional mesh vertex data for the new tangents, but would more or less be a drop in solution. The biggest issue is that I would have to rewrite the planet shader to basically do everything the surface shader output does, but with some changes. This is quite difficult, and would also require me to make the same thing again using for SRP. It would also mean no other planet shader would work without heavy modification.

    2 - Writing a new planet shader that uses triplanar mapping, thus blending all 3 generated tangents. This requires no new mesh data and would be even easier for users, but it has most of the downsides of 1, as well as worse performance.

    3 - Changing the SgtTerrain generation system back to where you can specify one material per cube side face, and writing the UV data per side as a quad rather than a sphere. This would require additional steps for the user to make planet textures and materials, but it would allow for custom shaders and avoid cube face normal seams. The big issue with this approach is that you would still have lighting seams for detail normal maps, because their tangent space normals won't match across the cube faces that cross to the poles. This could be fixed by modifying the normal maps such that they tile not only across the x/y axes, but also the inverted x/y axes, so an additional tool would have to be written.

    Writing shaders for 1 & 2 doesn't sound like fun, and I don't want to make other shaders incompatible, so 3 is probably best. However, 3 requires a lot of code changes, documentation, and would break planets for all users. There are quite a few other more important tasks I'd like to finish before making such changes, so I don't think this will be done soon.
     
    joshua_42 likes this.
  14. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    I'm not using normal maps for my planets. One advantage of having large planets is that you can't see height details until you get closer to the surface where the geometry starts to show. But that creates the problem of geometry seams. Are these fixable currently? I tried using the floating origin option on sgt terrain but it doesn't seem to help. And what about the heightmap pixelation? You mentioned you might fix this with cubic interpolation. The geometry seams are the biggest problem for me at the moment. I'm trying a scale system with the visuals on a smaller planet and the collisions on the large one. I'll let you know if it works!
    Thanks dude.
     
  15. Amir-Ward

    Amir-Ward

    Joined:
    Jan 26, 2015
    Posts:
    30
    Hello, I've bought the toolkit and I'm wondering when LWRP support will be available? Eagerly awaiting it so I can use the planet features from the toolkit in my project.
     
  16. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Hmm, what kind of planet size (e.g. final world size +-) are we talking about, and how many LOD levels?

    Using the origin shifting system currently doesn't fix the seams because each terrain patch is calculated using 32 bit floats, and the vertices are still placed relative to the planet center. Fixing them would require 64 bit calculations, and placement relative to the center of the patch, then each patch can be placed using the origin shifting system. This is something I can fix soon though.

    Regarding bicublic filtering, since I last mentioned it I did experiment with it for the main heightmap samples, and while it does smooth out the stepping, it just makes the steps look like a weird smooth wave. I didn't think it improved the terrain that much relative to the performance penalty (over 4x), so I modified the sampling to smoothstep between each sample point. If you combine this with detail heightmaps of a high enough frequency then there's little visual difference between this and bicublic filtering, except the big performance difference.
     
    Last edited: Sep 24, 2022
    joshua_42 likes this.
  17. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Is there a way for me to implement these? Like what classes do I need to dig into or combine to make something for a hacked together prototype. Going to be moving ships both close too, and far away from the camera.

    --EDIT--
    Decided to make a modified version of your warp system to implement movement, at least for testing.

    Thanks again,
    ~Ark
     
    Last edited: Jun 26, 2019
  18. GhulamJewel

    GhulamJewel

    Joined:
    May 23, 2014
    Posts:
    351
    Previously I used older version of SGT in my space game. It had a solar system using SGT Simple Orbit that worked perfectly. I upgraded to the new SGT version. Now I see there is only SGT Floating Orbit.

    This seems to be hit and miss for me as some planets orbit fine but others orbit and randomly shake. I am not sure what is causing the planets to be shaking randomly even though they have been set up exactly as the other planet objects.

    Small gif showing it here. (you can see mercury and Saturn jittering)
     
    Last edited: Jun 25, 2019
  19. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    I'm not sure about using a scale system...if the geometry seams can be fixed then I probably don't need it.
    On another note, only DetailMapA is being applied to the sgtTerrain. I found this line of code and thought it would be the problem but changing DetailMapA to DetailMapB doesn't solve it -
    line 451 SgtTerrainCompute.SetDetail(MaskMap, DetailTiling, DetailMapA, DetailScaleA, DetailMapA, DetailScaleB);
     
  20. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Sounds like your hitting floating point inaccuracy. Did you attach the SGT Floating camera script to your camera?
    I had a similar issue with the warp commands not working, til I attached the camera script.


    @Darkcoder - I made a basic warp and orbit setup over the weekend and seems to be working. Going to start working on a slower setup based on the warp to simulate regular engines, with flip and decelerate! I really enjoy this kit!
    Thanks
    ~Ark
     
  21. liiir1985

    liiir1985

    Joined:
    Jul 30, 2014
    Posts:
    147
    Do you have any plan to support LWRP/HDRP?
     
  22. GhulamJewel

    GhulamJewel

    Joined:
    May 23, 2014
    Posts:
    351
    Yes I have the SGT Floating Camera attached. The camera also has mouse orbit script attached. SGT Floating Orbit seems unreliable in my experience. Sometimes it works perfectly other times it is just jittering and stops orbiting. Can the old SGT orbit script be provided in the new SGT? as don't need floating origin since it is a small scale model.
     
  23. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Windows - %Appdata%\Unity\Asset Store-5.x\
    Mac - ~/Library/Unity/Asset\ Store/

    If you haven't emptied your asset store directory you should see two folders under the folder Carlos Wilkes. Inside both folders will be a *.unitypackage, look at the timestamp on the SGT kit, if you see 2018 that will contain the simple orbit.
    I know because I recently did this trying to find his recalculate orbit code.

    ~Ark
     
  24. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Answered a few weeks ago.
     
  25. GhulamJewel

    GhulamJewel

    Joined:
    May 23, 2014
    Posts:
    351
    Thanks I have tried that but importing it give some errors.

    The type of namespace name ‘SgtEditor<>’ not found..
     
  26. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Yeah you'll basically have to rewrite the editor for simple orbit to match others, because all of that has changed.
     
    Last edited: Jul 4, 2019
  27. GhulamJewel

    GhulamJewel

    Joined:
    May 23, 2014
    Posts:
    351
    Thanks fixed it now can go back to working on game. Option to have normal or floating orbit would have been nice as didn’t need floating version.
     
  28. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Hello everyone.
    I found this video in an 2013 post. Can anyone tell me how to make a planet like this with SGT?
     
  29. WILEz1975

    WILEz1975

    Joined:
    Mar 23, 2013
    Posts:
    374
    This asset is truly extraordinary.
    I need to know if there is a functionl/utility to make the collider capsule of a character orientate with the gravity of the planet or I have to do it through a script.

    FROM:


    TO:
     
  30. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    Looks like one of his old planet packs.

    There used to be an example script for this, not at computer at the moment but I'll look.
     
  31. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    This could be helpful.
    http://wiki.unity3d.com/index.php/WalkOnSphere
     
  32. WILEz1975

    WILEz1975

    Joined:
    Mar 23, 2013
    Posts:
    374
    Thanks for your advice. But I can't change the motion system with another system (I use a rigidbody).
    But I hope to draw this script anyway. ;)
     
  33. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Here is another really good tutorial with rigidbody. ;)
     
    WILEz1975 likes this.
  34. WILEz1975

    WILEz1975

    Joined:
    Mar 23, 2013
    Posts:
    374
    Great. Thank you. ;)
    I will certainly be useful to integrate on my system.
    My character (and objects) has three "states" of interaction with gravity. Normal (FPS with Y -9.81 gravity), no gravity (in space in space suit) and aboard a space fighter. In short, it is already complex and now I will have to integrate the situation of "planetary gravity".
    If you are curious, this is the official website of the game: https://www.artistic-minds.it

    EDIT: solved, thank you very much :D
     
    Last edited: Jul 21, 2019
  35. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    No problem. Nice that I could help.
    Your game looks great! :cool:
     
  36. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Sorry for the late replies everyone. In the future please spam me with emails if I don't reply!

    I've attached the old SgtSimpleOrbit component. I'll see if I can include this and some other useful components in the next version.


    Yes, I'm currently working on this now. Most features already work, or with just minor changes, but the planet shader requires a lot of modification, so that will take a bit of time to find a good workflow.


    You can ask them, I think this user posted in this thread before.

    Currently there's no built-in component to do this, but I can see how it would be useful to speed up development time for many users, so I plan to include this soon, along with an updated orbit script, etc.
     

    Attached Files:

  37. WILEz1975

    WILEz1975

    Joined:
    Mar 23, 2013
    Posts:
    374
    I have another little question.
    Is it possible to increase the subdivision of the collider "under the feet" of the camera/character?
    Otherwise, in some places the collision is very inaccurate.
    It would be enough to increase the subdivision within a few meters from the camera.

    EDIT:
    Ok, found ...
    "Max Collider Depth" is helpful ;)
     
    Darkcoder and dirkjacobasch like this.
  38. Arkolis

    Arkolis

    Joined:
    Feb 6, 2015
    Posts:
    34
    You could also do a raycast that adds an offset based on visible mesh, might make it look more accurate without the physics complexity!
     
  39. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Finding that offset from the mesh might be expensive though, or complex to optimize.

    You could call the SgtTerrain.GetLocalHeight/GetWorldHeight or GetLocalPoint/GetWorldPoint methods to calculate the actual displacement from the raycast hit though. But this may be higher resolution than the visible mesh and cause different issues.
     
    WILEz1975 likes this.
  40. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    Hi Darkcoder,

    Have you managed to look at the detail map issue on the terrain?
     
  41. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Yes, I sent you a new build via email!
     
    joshua_42 likes this.
  42. dirkjacobasch

    dirkjacobasch

    Joined:
    Apr 24, 2018
    Posts:
    418
    Made my first planet with SGT terrain. :)
    SR_63699774533692_2560X1440.jpg SR_63699774951446_2560X1440.jpg SR_63699774934862_2560X1440.jpg
     
  43. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    Hi Darkcoder,
    Do you have any suggestions for spawning prefabs on the cloudsphere? I need to get the center position and alpha of each pixel. I know a raycast can get that information but I don't know how I would raycast to the center of each pixel that's wrapped around a sphere.
     
  44. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    The cloudsphere component wasn't designed for this, so it's difficult to do. You could use an SgtTerrain instead, and then the SgtTerrainSpawner can pick points on the surface as you approach. The cloudsphere texture uses a cube map, so finding the coordinate is more difficult, it's much easier if you sample the texture in its original cylindrical projection (e.g. SgtHelper.CartesianToPolarUV).
     
    joshua_42 likes this.
  45. GhulamJewel

    GhulamJewel

    Joined:
    May 23, 2014
    Posts:
    351

    Thanks I noticed there the sgtkeyboardthruster was removed was their a replacemeny for this? It was handy to have thruster control for spaceships and satellites.
     
  46. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Thanks for pointing this out, I'll add it in the next version. I also want to add some more components to allow for cooler demo scenes, like the new asteroid controlling scenes.
     
    dirkjacobasch likes this.
  47. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    Hey Darkcoder,

    Bit of a strange request but is there a way I can revert the spherical-cube created by sgtterrain to just a cube and still have the same functionality? And have you had a chance to look at the missing detail map in sgtterrain?
    Cheers!
     
  48. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    You can remove the spherization step in SgtTerrainFace.compute line 176, just delete the 'normalize' call. To make the normals and tangents match you will have to do the same on lines 142 and 146. For the CPU fallback the same must be done in SgtTerrainCompute.cs lines 362, 620, 624. There may be some other steps required though as I didn't design this code with this in mind.

    I haven't looked into the detail map issue since we last talked about it. I have no idea why it doesn't seem to even read the secondary texture, the code looks fine from what I can see.
     
    joshua_42 likes this.
  49. joshua_42

    joshua_42

    Joined:
    Jun 23, 2016
    Posts:
    104
    Can't find the normalize call in SgtTerrainFace...
     
  50. Darkcoder

    Darkcoder

    Joined:
    Apr 13, 2011
    Posts:
    3,406
    Are you sure you looked in SgtTerrainFace.compute and not SgtTerrainFace.cs ;)