Unexpected material compile failure

I’ve stumbled upon a certain series of nodes which break the material compiler:

http://zspline.net/temp/Clipboard%20Image%20(68).png

Directly linking the source gradient or the power’s result to the black body node works fine, as does using a linear gradient at the beginning. Only this particular chain seems to cause an issue. If the output of the black body is actually used in the main material node then some “internal error” is the message. I can’t remember exactly because the editor promptly crashed.

Min() and Clamp() nodes also seem to clash with the black body node.

I just can’t use BlackBody in any meaningful way as it fails with all the implementations of the algorithm I need. How does the node generate its output? Maybe I could recreate it manually. I searched the github repository for the source but couldn’t find it.

An even weirder showcase:

http://zspline.net/temp/Clipboard%20Image%20(69).png

Compile fails but if in the Lerp the value A is set to 1.414 then it works. O_o

Hello ZoltanE,

I would like to gather more information from you in order to understand this issue better.

1.) Can you link me your DxDiag?
2.) What are you trying to achieve by using the BladBody node? Why are you using this node specifically?
3.) Can you provide reproduction steps leading to when the editor crashes.
4.) If the editor crashes and the “Crash Reporter” window appears have you reported the crash. The crash will not report if you do not write a brief description int he reporter window. Also in that window it will give you a Machine ID and epic account ID. Can you link both of those ID’s here?

I have been trying to reproduce this crash on my end with the last screenshot you added and I have been unable to. After I have this information I will investigate this issue further.

DxDiag: http://zspline.net/temp/DxDiag.txt

The material where I’m having this issue is for a particle sprite, a smoke puff with adjustable amounts of fire mixed in with the smoke. The black body node is supposed to determine the fire’s color and its branch is linked to the emissive input of the main material node.

As for the crash it went like this: I was previewing the black body node to check the logic feeding. Things went sideways and the preview remained the default gray checkers. The log showed this:

LogShaderCompilers:Warning: Failed to compile Material /Engine/Transient.SmokeCrashtest_mat for platform PCD3D_SM5, Default Material will be used in game.

Then I stopped previewing the black body node and allowed the editor to attempt to show me the final material. It failed with

MaterialEditorStats:Error: Error [SM5] internal error: compilation aborted unexpectedly

Puzzled I started messing around to see what causes the problem and suddenly the editor crashed. Unfortunately I’m not sure if I let it send crash data. After that I was careful and never let the black body node output reach the main material node unless I confirmed that everything is ok using the preview.
Right now I can not reproduce the crash, the material has changed a lot since the original bug report. I managed to find a working algorithm where the only concession I have to make is that the lerp(), shown in the image above, has to have 0 as input A.

I’ll simplify the material and link it here so you can at least take a look at the errors.

.UASSET files are native to your project and are unable to be imported into other projects. If you would provide a screenshot of when this error is occurring or post a link to a dropbox with your project I will be able to view what you are seeing.

Here you go: zspline.net - This website is for sale! - zspline Resources and Information.
Turn on the static switch parameter to get the compile error.

Ah right right, fortunately the setup is rather simple:

http://zspline.net/temp/Clipboard%20Image%20(70).png

This issue seems to be due to the clamp you have before passing it to your switch. I changed the clamp mode from Clamp to either min or max and the problem is resolved. Also bypassing the clamp completely fixes this. I do not believe this is expected behavior and as I am able to reproduce the issue I will be entering a bug for it. In the meantime please use the mentioned workarounds.

The ticket number is UE-23765

Thank you very much for reporting this issue to us. I will monitor this bug’s progress and keep you informed of it’s progress.

Actually using Min() AND Max() does produce the issue and can even push it to a crash, like it did for me just now. I made I sent the report and included the bug ID and this URL in the description. However I’m not able to reliably reproduce the crash.

It’s also worth noting that if the affected nodes (Clamp, Min and Max pair, others?) are present upstream even as hidden inside a material function, the problem will appear.
The key to a workaround seems to be making sure that if incoming values are clamped in some way then one has to make sure that the lowest possible value the black body can receive is less than 1.414214. (Weird rule I know but this is my observation after trying for a day to make things work.)

EDIT: So 1.414213 is sqrt(2)… interesting…

If you would link the ID’s here so I may look them up in our Crash Reporter database. This should give me a closer look into why this crash is happening via logs.

Sure, I’ll try to make it crash again. In the meantime you might be able to locate the crash report in the database provided you can search the description field. Look for either the ticket number or this question’s URL.

just and FYI this also occurs on 4.11, and breaks a bleepload of my particles, even some I have on the marketplace.

both of these give the same errors.

errors:

Reproducible on 4.12.5 too