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)

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 :slight_smile:

Thanks again for your work on this!


Thanks for the kind words :slight_smile:

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!:slight_smile:
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 :cool:

@SebHillaire Thanks for the response!:slight_smile:
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 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


, so in the same tick as I rebase the world, I say


, 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!

  • 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 :slight_smile:

@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.


@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.


@SebHillaire Do you have any suggestions for how to avoid the problem shown in the video above?:slight_smile:

@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 :wink:

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 if you want it. Otherwise it is going to be in 4.26.