Announcement

Collapse
No announcement yet.

SkyAtmosphere and World Rebasing

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

    SkyAtmosphere and World Rebasing

    Hi, wanted to write to see if there is any solution to Rebasing the world, and having the Sky Atmosphere maintain its world position, as it shifts when rebased, im guessing because its values are set off of absolute world position.

    Are there any workaround for this?
    Additionally, is there a world position node in the material editor that respects the original world origin? (in the case of making my own atmosphere shader)

    #2
    In my tests, the actual rendering of the sky atmosphere is not tied to the scene component, and thus it does not respect origin rebasing (i.e. it will always render at world zero). Not sure if this was an oversight, or is there is some rendering reason for doing this. I definitely see the value in a movable/rebasable sky atmosphere. Not sure how much modification to the engine this would take, but I'm definitely inclined to give it a look.

    Comment


      #3
      Originally posted by Blakeanator View Post
      In my tests, the actual rendering of the sky atmosphere is not tied to the scene component, and thus it does not respect origin rebasing (i.e. it will always render at world zero). Not sure if this was an oversight, or is there is some rendering reason for doing this. I definitely see the value in a movable/rebasable sky atmosphere. Not sure how much modification to the engine this would take, but I'm definitely inclined to give it a look.
      yea, would be very awesome to have it localized, I also figured out the absolute world position offset for the time being, if you manually set world rebasing, then you can pass that value to a collection param and add it to world position, works fine, though id love to make use of the in engine atmo instead of my own raymarch

      Comment


        #4
        im actually curious, if anyone sees this and knows if you can rebase a streamed level and leave another streamed level at a location, that might be a hack for now. i know you can set level transform, but ill have to tinker with it. just some ideas for anyone going through the same path.

        Comment


          #5
          Hello and thank you for your feedback.

          Rebasing has not been done yet because we were focusing first on the typical case where a terrain is around the origin. It is also a way to make sure things looks good when the component is drag and droped in the level for the first time without having to deal with the large transform required by the virtual planet radius.

          Having the sky component transform being the top or center of the virtual planet (selectable mode) is something we have as a todo because yes it can be useful (also for later if we support multiple planets). Would that be ok? Any other suggestions? I cannot give any ETA for now but this is definitely something I want to fix.

          Comment


            #6
            Originally posted by Guest View Post
            Hello and thank you for your feedback.

            Rebasing has not been done yet because we were focusing first on the typical case where a terrain is around the origin. It is also a way to make sure things looks good when the component is drag and droped in the level for the first time without having to deal with the large transform required by the virtual planet radius.

            Having the sky component transform being the top or center of the virtual planet (selectable mode) is something we have as a todo because yes it can be useful (also for later if we support multiple planets). Would that be ok? Any other suggestions? I cannot give any ETA for now but this is definitely something I want to fix.
            Thanks for the reply Sebastian, your hard work on the Sky Component is much welcomed.

            I was able to "toggle" the sky component transform between the top and center by a simple edit to line 117 of SkyAtmosphere.usf. A built in function for this would be super nice though. As for it actually following the component transform (and thus respecting origin rebasing), I was going to pass this data to the usf file but haven't had the time yet, might take another look this week. Having that functionality would be beneficial in a number of scenarios (primarily aerial scenes where looking down on the atmosphere from space).

            Also, not sure if this is clamped for some mathematical reasons, but allowing a larger range for the ClampMax/Min of the radius would be nice

            Thanks again for your work on this!

            Blake

            Comment


              #7
              Thanks for the kind words

              Yes that is basically what needs to be done (mode, handle update transform, shader update) I have a CL ready that should go in the next release.
              I'll have a look at increasing the radius range but be aware that it is only clamped for the slider: you can type the radius yourself and cross the boundaries.

              Comment


                #8
                Is rebasing planned for any upcoming release? It is still not supported in 4.25.
                With the "suggested" values being 100km planet size and 10km atmosphere height, I don't completely understand why this component is "advertised" as supporting "transitions from ground to sky to outer space with proper planetary curvature" when rebasing isn't supported..
                In it's current form, it is pretty much useless for any large-scale planets. Would be really nice to see rebasing supported, because the component looks absolutely stunning when it works!
                I've tried repositioning the component whenever the world is shifting, but it visibly flickers..

                Comment


                  #9
                  Hello Stiian and thank you for your input.
                  I do not understand what you mean by "suggested". This "advertised" sentence seems valid to me because it is not talking about rebasing/transform.
                  But in any case: in 4.25, the Transform Mode can be set on the SkyAtmosphere component under the Planet section. We still have to update the documentation.

                  Comment


                    #10
                    Hi, SebHillaire!
                    By "suggested" I meant the UIMin/UIMax, which I now see is minimum 6000km for ground radius, while the limit of 100km I mentioned actually is the clamped minimum.
                    What I'm struggling to understand is; how am I going to transition from ground to outer space when my planet is minimum two hundred kilometers in diameter without experiencing floating point precision errors? As far as I know, rebasing the world origin (+ some clever "always spawn 'LOD' relative to current world center(after rebase)"-logic) is the best/easiest/only way to get around that. The TransformMode doesn't help with that, as far as I can tell? I am already using `PlanetCenterAtComponentTransform`, which works nicely for positioning it initially. But it doesn't follow the rebasing.

                    So for my use-case: my planet is the size of earth, I.E 6.371.000.000 units(cm) in radius. It consists of several individually generated terrain-meshes making up the entire planet, depending on how far the player is from the surface. It's a QuadTree, meaning it divides itself when getting closer, giving high vertex-count when I'm on the surface, and lower when I'm far away.
                    I'm doing this by always spawning each of these terrain meshes relative to the current world origin, not relative to the planet center.
                    If I were to generate terrain mesh that was translated relative to the planet center, it would mean the terrain's translation would always be +- 6.371.000.000 units (given that the planet is at 0,0,0, which it's not, so it's more), which leads to precision errors. With my approach; when rebasing the world every +-400.000 units, I can ensure that any terrain mesh is translated relatively close to my player's location, and everything happens close to world origin, always. (while I keep track of where the planet center is, with a double value, and convert these manually).

                    This is the only way I know to have good precision both on the surface and in outer space for a planet of this size.
                    Since the SkyAtmosphereComponent requires a planet to be at least 10.000.000 units (100km) in radius, I can't have precision on the surface and in space without world rebasing, unless I have misunderstood something?

                    Here you can see what happens to the atmosphere when I manually reposition it every time the world origin is rebased (this planet is 100km radius) :
                    Last edited by Stiian; 04-24-2020, 09:40 AM.

                    Comment


                      #11
                      Ah then I am sorry I missunderstood: transform indeed does not solve floating point accuracy issues. It is just a way to move the atmosphere around because it was fixed before. That would require a larger engine change that is completely independent form the SkyAtmosphere rendering. I will of course report about it.

                      Flickering: I have never seen that before. What is the repro? Just changing the sky transform in blueprint?
                      Sky radius: I guess I can reduce the minimum planet radius to 1km in absolute. And maybe make the UI range larger too.

                      Comment


                        #12
                        Originally posted by SebHillaire View Post
                        Sky radius:
                        guess I can reduce the minimum planet radius to 1km in absolute. And maybe make the UI range larger too.
                        Please YES

                        https://www.artstation.com/chesire

                        Comment


                          #13
                          SebHillaire Thanks for the response!
                          Well, I have no need for small planets, I want them big. My point was just that I didn't understand how they can be big, without rebasing, without losing precision either on surface or in space. Actually, anywhere. And I still don't really understand it. If I have an Earth-sized planet without supporting rebasing; in the best case, my planet must be at world 0,0,0, meaning that a rock on the surface of the planet must be placed on ±6.371.000.000 units, which is a lot more than 2^32. The entire surface will be deformed and stuff would be bouncing around. As far as I understand, when using floats, if the number is high, then fewer decimals will be available. Which means that any math relative to the planet center will lose a lot of precision.
                          I am doing this math myself using doubles now, which keeps the precision, and then convert it to vectors basically relative to the player instead of the planet center, and then converting it to float. This works perfectly, because a rock on the surface will always have a translation of less than 400.000 units relative to world origin when it's within 400.000 units of me. But if I can't rebase the world origin, this approach is completely useless.
                          And what if I want to fly to the moon? That's another 40.000.000.000 units.That should obviously be split up in some way, but with rebasing it's actually possible.

                          Rebasing really needs to be supported for this atmosphere to be usable as an actual atmosphere. Without rebasing, this component is just either a Sky seen from a small area of the ground, or an Atmosphere on a planet you can't orbit.

                          As for the flickering:
                          I do everything in C++. At every tick, I check if the player has moved more than 400.000 units, simply by checking if any of x/y/z of actorLocation is more than 400.000. If it is, I say
                          Code:
                          world->SetNewWorldOrigin(actorLocation + oldOrigin);
                          .
                          When doing this, the SkyAtmosphere teleports negative that direction. Or rather, everything else moves based on the rebased location, and the atmosphere stays still. That's the issue, because it doesn't support rebasing.
                          So to counter-act this, I am physically moving the atmosphere component the same amount.
                          I am using the
                          Code:
                          ASkyAtmosphere
                          , so in the same tick as I rebase the world, I say
                          Code:
                          atmosphere->SetActorLocation(offsetFromWorldCenter);
                          , where this offset is its previous translation plus the vector difference between the old origin and the new origin. Or something like that.

                          The atmosphere appears to be flickering because I'm moving extremely fast, and I update actorLocation of the atmosphere every time I move more than 400.000 units, which can be several times a second (less than once per tick) when moving this fast.
                          Mathematically, I'm updating the actorLocation of the atmosphere correctly, so it shouldn't be flickering. It should be moved to the correct location every time. But because these are extreme distances, the atmosphere is translated to approximately what I calculate, because of floating points having such low precision at these values.

                          Again, I think rebasing is the only thing that will make this work.

                          Comment


                            #14
                            Stiian thanks a lot!
                            • Agreed: you can go to space and do large scale visualization but you cannot see details and play/walk on a distant moon. We know about that one and right now it sits as designed because there were no uses cases to test this.
                            • Thanks for the details => that should help me to reproduce that case. I did not know we had a SetNewWorldOrigin (even though it makes sense). Something must be missing then.
                            • I'll try to squeeze a fix for that in time for 4.26 (after everything else I must do).
                            And by the way: cool planet in the video

                            Comment


                              #15
                              Stiian, I'm confused why you need precision on the planet and in space at the same time? You should really only need it where the player is.

                              If rebasing works for you, but it isn't big enough, simply change the world origin code to use int64 instead of int32. This should solve your problem as you go from a max of 42,000 cubic KM to like 19 cubic LY of rebaseable space (iirc). I say this because if you are doing your planets to real world dimensions as you say you are, then the max rebasing distance the engine can handle by default is 21,000 KM. The distance from the earth to the moon is around 380,000 KM. So you'll hit the rebasing max. This is an issue our team had early on in a project of ours. Changing to int64 easy solved it.

                              Side note: You can also "modulate" the world origin code to get even more space, if you really needed it.

                              If you truly need to be precise in two distant and separate locations simultaneously then you may need to rethink your game design. You *can* change the engine code to use doubles instead of floats (I know a team that successfully did it) but the amount of modification it takes to the engine almost isn't worth it. But it does give you a "precise" volume of 72 cubic AU (following the precision standard of 0.25 CM max that the engine has by default for floats).

                              To put that into comparison with floats, that's going from a volume of 200 city blocks of "precise space" to a volume the size of the orbit of Neptune. All without rebasing, which makes it much easier to use with multiplayer as using origin rebasing in multiplayer games is very difficult and complex imo.

                              I don't think any of this relates to the sky atmosphere, unless it's not rebasing correctly.

                              Cheers,
                              Blake
                              Last edited by Blakeanator; 04-26-2020, 07:33 PM.

                              Comment

                              Working...
                              X