Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Square root node breaks alpha masking in materials

I was having a lot of issues with the spheregradient2d material function breaking lerping and figured out the culprit. The image shows how to recreate the issue. The simple solution is to replace the square root node with a power node that has a power of 0.5 because a square root is just another term for something raised to the 1/2 power.

Notice the bottom result and how it's all masked in black, instead of red: alt text

Product Version: UE 4.18
more ▼

asked Nov 10 '17 at 04:21 AM in Bug Reports

avatar image

96 1 3 7

avatar image IronicParadox Nov 10 '17 at 02:45 PM

A bit of continuation on this topic: I've found that even using the power^0.5 node, it still bugs out for certain values of the scalar. At 0.2, it works fine, 0.3 doesn't work, 0.31/32/33/34 work, but then 0.35/36 doesn't work, 0.37 works, and so on.

I don't know how UE handles roots, but is it possible that this could be some kind of lookup table error?

(comments are locked)
10|2000 characters needed characters left

2 answers: sort voted first

It's definitely a floating point accuracy issue. It's not the expression because it's just a direct rip of the spheregradient2d material function. It's breaking at the point where the two squares are subtracted from each other and are supposed to be equal to zero(when their values are the same and that would coincide with the red area that's getting messed up). The FP precision is dipping below the zero threshold and that's causing the number to go negative, which is causing the square root to go NaN.

The bandaid fix is to use an IF node right after the difference of the squares and it fixes it all. It's very rare that I need to work with square roots in materials, so I guess I know what to keep in mind for the future.

EDIT: I propose that in cases of "NaN," the engine should default them to zero for things like a lerp node. A simple "If the input is NaN, then the input equals zero" would suffice. Also, it's using an IF, instead of a clamp, because the clamp still doesn't properly clip it to zero. The only way it will properly reach zero is with the IF setup. alt text

fixfornow.jpg (116.5 kB)
more ▼

answered Nov 10 '17 at 10:27 PM

avatar image

96 1 3 7

(comments are locked)
10|2000 characters needed characters left

This is NOT a bug, just a misuse of material expressions.

Black area in resulting lerp corresponds to the area, where extracting square root from a negative number is attempted, which results in NaN.

There are no issues with power node either. It is just the fact, that the area, you are expecting to give 0 input to ceil is not necessary 0-ish enough.

more ▼

answered Nov 10 '17 at 07:18 PM

avatar image

7.8k 130 30 292

(comments are locked)
10|2000 characters needed characters left
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question