During world origin rebasing, how can I add the offset into Absolute World position of materials?
Hello, I am not noob to Unreal, but pretty close to a noob with material graph stuff. Not a math skilled person. However, I think I know what needs to be done, just not the way to say it in code.
I Set World Origin periodically like this:
So there will be a resultant difference between actual world origin and what has been currently reset too. I think the easiest way to find this difference is to compare the Players location to some actor that never moves. This vector would always represent same coordinate space as the original origin.
I am sure I explained that wrong but hopefully somebody might understand what I mean. I am currently using this difference during save and load of the players position, so I know that it does what I desire - by adding or subtracting, it effectively negates the world origin shifting.
So, I have this vector value, but how can I pass it into my world aligned materials? For example here:
A global snow material is used. The absolute world position should account for the offset vector somehow. There is two steps involved: 1. getting the value in there, and 2. applying the value in correct way.
Can anybody say, have I understood the problem correctly? If so, do you know how I can pass the information and apply it within the material?
Replies
Once you have the delta vector in there you can use it in the same way you'd use it in blueprints to 'negate the world origin shifting'. That is, by adding or subtracting it from the Absolute World Position UVs.
Could you just add another vector parameter to the material parameter collection you appear to already be using, and then set it after you rebase the coordinates? Like so:
Then you can just read it normally in shader:
You'll want it as a float2, so you'll need to component mask it to the axes you're concerned with (likely XY). This should be the most idiomatic way to get this done.
@rexo12
i didn't know about MPC - was just reading about this and it seems like the solution.
The one in the image I shared is from a plugin so I had just plugged stuff in but didn't actually know what all the nodes are doing. Previously I had only known about dynamic material instances but didn't see how I could easily communicate with landscape material that way.
Looks like MPC is the way to go here - more like a many-to-one* dispatch so I don't have to find the material, material just subscribes to the MPC.
Thanks! Will actually test this out shortly but looks pretty certain that it will work
MPC seems to be sort of the shader equivalent of Delegates (as you describe) in order to decouple objects via dependency injection.
Honestly don't know why MIDs still exist given that MPC is a far more convenient way of interfacing with shaders at runtime. MPCs do have a hard limit at 2x 1024 parameters per material, but that's just an organisational problem really.
Let me know how you go fixing the UVs.
(I did test it myself on a simple static mesh blueprint. I hope landscape mats give you no trouble :) )
Well, I am happy to learn about the MPC because it seems broadly useful and I see myself using it a lot in the future. Unfortunately, for solving this specific issue, there is a bit of a rabbit hole due to the nature of the plugin being used for the dynamic snow trails.
It looks like the basic theory works for a "normal" material though.
is that the same mechanism that world composition/partition use to shift the origin? if not you might want to try that in case it sidesteps the problem
I have no idea how world composition is doing it, but that is a good idea to check.
Only complication is that I want to call the shifting explicitly - perhaps that can be more or less achieved with world comp by adjusting distance or something like that. I'll have to dig into it a bit more.
sadly I never got round to using it but there's a system in there. you may be able to provoke it in the same way you can provoke level streaming explicitly (alternatively you may not)
Thanks @poopipe , i'll report back if it solves the issue or not. Should be relatively easy to at least do the simplest check for which would be to just enable world comp and trigger an origin shift. If that works, then will be worth the (hopefully) small effort to enable world comp on the maps and then just set the streaming size to something that triggers the shift as often as I need it.
And it probably wouldn't be too hard to find somebody who may be able to help in exposing some c++ functionality to just explicitly call the function as well - assuming I can't get to it from blueprints.
But I am putting this issue on back burner probably for a couple weeks at least, and also relegated this to lower priority than I initially thought because it turns out I don't really seem to need the origin shifting very much anymore after making some other, simpler changes. (turns out the small things that were jittering can just be scaled up and it doesn't make any difference to player, and seems to effectively solve the jittering issues)