Final position v. Position in terrain/texture

[WAS]

Sooo, it's not the same as Final Position, is what I'm saying...

Good to know the exact offset though.

[Matt]

Yes, in a cloud layer Final Position is different from Position in Terrain/Texture if the cloud layer has "move textures with terrain" enabled. This is by design. It doesn't work properly in cloud v2 but it does in cloud v3 and easy cloud. It sounded like you thought it wasn't working this way and gave an example where you thought you needed to use Final Position, but I tested your example with Position in Terrain/Texture and it works the way I described here. So I guess I misunderstood what you were saying.

In a cloud you can use Position in Terrain/Texture but you have to be aware that it's different from Final Position because it's meant to be different. It's meant to be relative to the cloud space, not world space (unless you uncheck "move textures with cloud", and then they are the same). This is useful because you can create layers like you did in your example and then you can move the cloud to any height and your layers will continue to work.

[WAS]

In a cloud, "Position in terrain/texture" depends on whether the cloud layer has "Move textures with cloud" enabled. If it does, the texture space is relative to the localisation centre, otherwise it's simply world space and gives the same result as "Final position"

Sorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.

[Matt]

Sorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.

Yeah, they should be the same if "move textures with cloud" is turned off, so I don't know what this difference is. Unless you are warping or transforming. That only works with position in texture. But there wasn't any of that in your file.

[WAS]

Sorry I was just trying to get clarification on that. You indicated they are the same as Final Position without "Move textures with cloud". I can see the difference of localization with v3 though.

Yeah, they should be the same if "move textures with cloud" is turned off, so I don't know what this difference is. Unless you are warping or transforming. That only works with position in texture. But there wasn't any of that in your file.

Nope, especially the Corona and Aurora's share in the bigben post, that's just basic surface layers and fuzzy zones in soft fractals.

Does the octave warp of the fractals themselves change this space maybe?

[Matt]

I don't know what you're referring to, but it sounds like a separate issue.

[WAS]

https://planetside.co.uk/forums/index.php?msg=273163

v2 clouds don't have move textures enabled by default, and final position and position in terrain/texture are different, contrary to your comment.

Unless I'm misunderstanding.

[Matt]

But they are v2 clouds. We already established they work differently. So there is nothing contrary to my statements above which were about v3.

[WAS]

In a cloud, "Position in terrain/texture" depends on whether the cloud layer has "Move textures with cloud" enabled. If it does, the texture space is relative to the localisation centre, otherwise it's simply world space and gives the same result as "Final position". Cloud Layer V3 and Easy Cloud have the localisation centre at the base of the cloud, and Cloud Layer V2 puts it midway between the top and bottom.

Here's the whole quote. My question was regarding both cloud types (cloud space). The only difference you mention is the localization of the centre at the base. And we already established there's a difference now in both v3 and v2... In both circumstances, move with textures or not there are offsets.

[Matt]

That was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?

[WAS]

That was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?

Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.

I'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.

[Matt]

That was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?

Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.

Sorry, I didn't mean to. I thought you knew I was talking about v3 this whole time.

I'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.

-2500 was the offset for your cloud because your cloud had an altitude of 2500m, but for a different cloud it would be different. This is how to convert from world space to texture space if you were working in world space before, but it depends on your cloud position. If you have a cloud whose base is 2.5km altitude and you want to set a mask that starts at the base, that's simply 0 in the cloud's texture space.

[WAS]

That was the first thing I said about clouds, yeah. But that's before you reminded me that v2 wasn't working like that. So we established that v2 was broken, I thought you understood that. Then after that we had a whole conversation about v3. You thought that v3 also had that problem. I told you I loaded your file with v3 clouds and it worked how I claimed it should. But now you are going back to talking about v2 and using v2 examples to try to convince me that there's an issue in v3?

Well, I think you're putting words in my mouth now. We're done here. I asked if I was misunderstanding.

Sorry, I didn't mean to. I thought you knew I was talking about v3 this whole time.

I'm trying to understand the exact offset between keying and surface layers between clouds types, you know, to work around them with knowledge rather than guessing. You found it was -2500 for v3.

-2500 was the offset for your cloud because your cloud had an altitude of 2500m, but for a different cloud it would be different. This is how to convert from world space to texture space if you were working in world space before, but it depends on your cloud position. If you have a cloud whose base is 2.5km altitude and you want to set a mask that starts at the base, that's simply 0 in the cloud's texture space.

That's the formula I think was getting stumped on, thanks.