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)
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
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.
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
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.
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âŠ
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.
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) :
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.
Please YES 
@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
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
ASkyAtmosphere
, so in the same tick as I rebase the world, I say
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.
@Stiian thanks a lot!
And by the way: cool planet in the video
@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
@Blakeanator I think youâre misunderstanding. Or maybe I amâŠ
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.
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).
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:
@SebHillaire Do you have any suggestions for how to avoid the problem shown in the video above?
@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.
@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.
@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/UnrealEngine/commit/45d28db9eeb467e897225b528dffb37397ea12d0 if you want it. Otherwise it is going to be in 4.26.