Announcement

Collapse
No announcement yet.

SkyAtmosphere and World Rebasing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Blakeanator I think you're misunderstanding. Or maybe I am..

    I'm confused why you need precision on the planet and in space at the same time?
    I don't need that, so maybe that's why you're confused.. If I'm far away from the surface, my LOD system turns the surface into a really low resolution mesh, so while precision errors would occur, it doesn't really matter that far away. Any vertex could be off by several kilometers without you seeing any difference.

    That said - since the SkyAtmosphere doesn't work with rebasing, I have to update its location manually, basically "fighting the translation system". This results in flickering, as you can see at the end of the video I posted. Every time I set the atmosphere position after a rebase, it moves "approximately" correctly. If this is due to precision or not, I'm not sure. But it sure doesn't look nice.

    If rebasing works for you, but it isn't big enough, simply change the world origin code to use int64 instead of int32.
    Thanks, I'll look into that. At this point, I'm not sure I need it though. I mentioned the moon as an example, but as I also stated, it should be split up in a different way. I'd argue it's better to transition between different "world spaces". E.g having a "world" for "surface and orbit" and another world for "solar system" (including travel between planet and moons). The "solar system"-world space would be scaled down, but you'd also move a lot slower. So when you move out of orbit, you'd transition between these worlds.
    This way, it could also be expanded easily to work with an interstellar world, and an intergalactic world. I assume even int128 would be too small to rebase the world billions of light years. (I may be wrong though, I didn't do the math, and powers are scary big. But it doesn't matter).

    I don't think any of this relates to the sky atmosphere, unless it's not rebasing correctly.
    That's literally the problem. And also the title of this thread. When rebasing, every actor in the world gets offset with the rebase-distance, except for the sky atmosphere. Meaning, as soon as you set a new world origin, the atmosphere no longer covers the planet.
    I can upload a video showing this in action when I get the time later today.

    Edit:
    Here:
    Last edited by Stiian; 04-27-2020, 11:48 AM.

    Comment


      #17
      SebHillaire Do you have any suggestions for how to avoid the problem shown in the video above?

      Comment


        #18
        Stiian I cannot think of any workaround unfortunately(apart from settranslation that you have already tried), sorry.
        As I said in a previous post: I hope I can squeeze a fix in 4.26.

        Comment


          #19
          SebHillaire, great work on the new Sky Atmosphere features in 4.25. Been playing around with it the past day or two.

          Unfortunately, I can confirm I have the same issue as Stiian in 4.25. The "pivot point" (as it were) of where the Sky Atmosphere renders seems get more and more distorted translations as the player rotates around the atmosphere and rebases. To clarify, the scene component is always in the right place, it is the render side of the atmosphere that is off, which seems very odd to me. I would assume the hsf code just uses a transform, and the underlying engine properly puts that transform in the right place after rebasing.

          Oddly enough, it only seems to happen when possessing a pawn. When I eject and fly around the scene, there does not seem to be any issues. I believe this is due to rebasing not taking place when ejected, but I'm not sure.

          I understand the "planetary view" of the Sky Atmosphere is probably not a high priority, but if you can find a fix it'd definitely be appreciated. I know I'd like to integrate it before 4.26 comes out, however far out that may be

          I'm going to try and go through the code myself later tonight and see what's going on. If I find anything I'll post it here.
          Last edited by Blakeanator; 05-06-2020, 11:23 AM.

          Comment


            #20
            Stiian Blakeanator I have created a cl in dev-rendering adding support for SkyAtmosphere world rebasing. It works as far as my tests go.
            Have a look at https://github.com/EpicGames/UnrealE...ffb37397ea12d0 if you want it. Otherwise it is going to be in 4.26.

            Comment


              #21
              SebHillaire, I cherry-picked your cl and the Sky Atmosphere does now properly work with origin-rebasing. Thank you for fixing this so swiftly it is very much appreciated!

              Comment


                #22
                Originally posted by SebHillaire View Post
                Stiian Blakeanator I have created a cl in dev-rendering adding support for SkyAtmosphere world rebasing. It works as far as my tests go.
                Have a look at https://github.com/EpicGames/UnrealE...ffb37397ea12d0 if you want it. Otherwise it is going to be in 4.26.
                Seb could you also lower the minimum world size to 1km (or just remove the clamp at all)? The 100km minimum it is now is still way too big and severely limits the creative use of the sky atmosphere for spherical worlds. Thank you!

                Comment


                  #23
                  Originally posted by spacegojira View Post

                  Seb could you also lower the minimum world size to 1km (or just remove the clamp at all)? The 100km minimum it is now is still way too big and severely limits the creative use of the sky atmosphere for spherical worlds. Thank you!
                  Just wanted to mention as a workaround that you can set the size to whatever you want via cpp. Pretty sure there is a "soft" minimum and maximum size where the rendering side of the sky atmosphere doesn't play well.

                  Comment


                    #24
                    Originally posted by Blakeanator View Post

                    Just wanted to mention as a workaround that you can set the size to whatever you want via cpp. Pretty sure there is a "soft" minimum and maximum size where the rendering side of the sky atmosphere doesn't play well.

                    I sadly don't use a cpp project, blueprint only. And Seb said in a previous comment in this discussion that he could lower it to 1km.

                    Comment


                      #25
                      Hi,
                      Yes, this has been done for 4.26 already. The radius slider can go down to 1km now, IIRC you can go lower, down to 100 meters but problems can start to show.

                      If you go with a lower radius, you will likely have to increase the sample count when tracing the atmosphere (to catch higher frequency details and planet shadows). There is now a quality slider on the SkyAtmosphere component that you can use.

                      Comment


                        #26
                        I did some experiments and it looks like it's purely because the skyAtmoshphere does not aware the world origin has been changed and I have found workaround. After you call "SetWorldOriginLocation" you just need to change a variable a little bit(i.e. Call "SetMieAbsorption" and add a small value say 0.001) to force the skyAtmosphere component to rebuild its status.

                        Comment


                          #27
                          Originally posted by SebHillaire View Post
                          Hi,
                          Yes, this has been done for 4.26 already. The radius slider can go down to 1km now, IIRC you can go lower, down to 100 meters but problems can start to show.

                          If you go with a lower radius, you will likely have to increase the sample count when tracing the atmosphere (to catch higher frequency details and planet shadows). There is now a quality slider on the SkyAtmosphere component that you can use.
                          Thank you for adding that option, you are my hero!

                          Now I just have to "impatiently" wait for 4.26..

                          Comment

                          Working...
                          X