My masks from version 4020 do not work properly in new 4031 vesrion, the rescale node turns black mask in to white, while turn on “Normalize input”. This occurs only when there is no other imput.
1 Like
Well, approaching this from a sound design perspective, “Normalize” usually means to expand the current input to take up all available values. In sound, this generally means the loudest bit gets pumped up to 0db, and the quietest bits get dropped to silence. If we’re going by the same rules here, a completely black landscape would have the highest point be 0, so that would get pumped up to white.
Though if I think about it critically, I feel like it would make more sense for normalize to take a completely black mask/heightmap to 50% grey, as it should be simultaneously trying to make it 100% white and 100% black.
Editing to undelete, as I thought I misunderstood what was happening in the post, but I guess I didn’t.
When Normalize is checked in the Clamp device, the lowest value present is set to 0 and the highest value is set to 1.
Normalizing a constant value where those are the same is thus a degenerate/illogical situation, as one of the two post-conditions above will be violated no matter what; you can only choose which one.
The final behavior of Artist Point changes the degenerate case handling so that a constant value normalizes to 1 instead of 0. This is intentional as this choice loses less information. It does appear though that the Clamp device is not preserving the old behavior when using the old device version, which is an error…
But now it is a big problem, because when you have a e.g. 20km terrain and you add some details in a part of the terrain and you are using Extents to work just on a small part of the terrain because you can not work on a large terrain with many features and details in 20k resolution in real time, so I use smaller sections(Extents) to work on with more speed and details. The masked detail is not more masked out in the new Extend which does not contain the mask, because the black part of the mask is now white. I attached a sample file. In the sample try to switch to RadGrad Extent from the main. Maybe I am doing Something wrong ?MaskNotWorking.tmd (56.5 KB)
Best would be to have an option to select between normalize to black or normalize to white.
1 Like
I agree with this! The old behaviour is very baked in to the minds of users and, to me, is a lot more intuitive. You don’t expect a 0 to suddenly become a 1 in a new version of the software.
Regarding choosing the value, I’d like to suggest the following. For a constant value, if the value is ≤ 0.5, it will be turned into 0, otherwise it will be turned into 1. That makes more sense to me, but I’m not sure how others think about that.
The current behaviour is not something I’d like to use, and I rather use the older versions of the clamp device.
1 Like
Those are good points raised. There is no “right” answer here, so “most useful” is the only metric we can go by.
A few thoughts:
@P_B, using Normalize and multiple render extents is always problematic, as there can always be a failure case. No matter the behavior, especially with partial-value masks you will run into issues as the extents will normalize differently. I strongly recommend when you want to normalize with different extents or a tiled build: go to your biggest one, click “Find Extents”, and don’t use normalize. You will have no further problems.
As an example of how normalize will always cause trouble:
In the situation above, if I simply invert the mask provided to the clamp using the old normalize behavior, the opposite situation occurs: An all-white mask will (very UNexpectedly!) become a zero mask and remove all output that should rightfully be there. It is certainly arguable about whether losing “all white” or “all black” is more unintuitive, but they’re both pretty bad 
@blattacker , I thought of this as well, as it seems reasonable. However, it makes BOTH of the cases above fail! Now you have 50% mask bleed for all-black and all-white areas, which seems definitely unintuitive.
@HYLK , This is an interesting idea. It’s not “correct”, but it is very useful. It might be the way to go forward. Another option, that I’m currently leaning towards, would be to simply do nothing and maintain the input value when it is constant. As we’ve demonstrated normalize is nonsensical in this case.
4 Likes
Oh absolutely, I wasn’t offering the 50% as a possible solution, more just thinking aloud, sorry!
This bug has been fixed in the slipstream release 4031.2 - you can redownload it on the Update Center and receive the corrected version.
The new degenerate-normalize behavior is to do nothing, which most closely matches expectations. In particular, all-black and all-white masks will exhibit intuitive results.
3 Likes
I did not expected such a fast response. Everything is working perfectly 
Thank you so much!
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.