What would a negative value for fe mean?

Unreal Engine Rendering

Using solution shown below doesn’t result with getting negative values.
And the flag “Allow negative emissive value” doesn’t work with decals.

It is intended and not a bug. Use Abs material expression before power node to get the functionality, you’d expect.

Indeed.

But power doesn’t work like that - so it is a bug. If you want to add such node which works like that then add another one - don’t mess with basic math please.
I fount this only in one place right now - obvious to fix, but it can cause a lot more bugs, and why? this change is totally illogical and counter-intuitive.

It’s not. It is how shaders work:

Returns the specified value raised to the specified power.

https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/pow.xhtml

As you may notice:

I am not talking about shaders - only about math - in math power works also for negative values - so wehn you see a node with name “power” you expect to see it works like power. If you want to use in other way name it differently. It should not be needed to read description for such simple and basic nodes. Also you don’t change such basic functionality without giving alternative solutions.

And argument about working in such ways in shader is irrelevant - because otherwise we should work on ones and zeros.

It was still working in 4.15 - so why it was good then and not now? please explain.

Also:

So it works somehow in custom node - so there is logical and in regular node it’s not?

It is shader optimization. pow(x,2) will be compiled to x*x.
Try to change exp to 2.1.

This is change is totally backed up by logic and is intuitive. Before 4.16 Power Material Expression used to translate to:

in 4.16 and above Power Material expression translates to:

Reason is pretty obvious: errors when using X values near 0;

Not a bug. Intended change.

why should you optimize shader on this level with cost of usability?
why from 4.0 - 4.15 it worked fine?

From my point of view it doesn’t matter - I generate effects based on nodes - and suddenly the mechanics of node changes - and in a way it is not logical in math point of view (I don’t care about code).

Don’t ask me. Ask Microsoft and Khronos Group. It is how shaders work.

If you’re talking why Epic changed it. So it’s to avoid spiking when negative base is used.

I think it is clear that optimization made not by Epic.

Wen you type pow(x,2) it will be interpreted by the driver as x*x. Shader code will be the same.
But that creates major issue. pow(x,y) is defined as pow(x,y) = exp2 (y * log2 (x)) and it is not defined when X < 0. So even values of Y produce “errors” when Y defined explicitly.

Fair enough. At least now i know who to blame.

For me the main issue is that for years I used power to modulate values in places like normals and coordinates which naturally have negative values - an now I would have to check all my functions and materials if they are still working properly. And As I tend to generate a lot of procedural complex materials it will potentially generates a lot of bugs - that is the main reason I am considering this a bug - because from my perspective it brakes things.

From context examples 4.19.
At least change the name of the node and fix content sample.

What’s wrong with the content example?

“Notice that negative values become positive just like ABS”

Hah. I didn’t notice the description.

next page →

Using Arduino Programming Questions

Ran into problems with this very specific case. First I switched from float to int * 100. I measure small voltage changes.

Some Values of “Volt” are negative, some positive. This instruction only triggers if “Volt” is positive.

int Volt= 0;

Volt=(int)analogRead(PIN_TEST)REF_VOLTAGE/PIN_STEPS100; // Read new Value

if (Volt > -3 && Volt <= 8 ){ display.println(“Switch 1”);

}

So my question:
How can I make the Arduino trigger my <> statement for both, positive and negative values?

OT

Btw. The comparison of floats was even weirder. I had to use this (wrong!) <> statements to make it work correctly:

if (Volt < -0.03 && Volt >= 0.08){ display.println(“Switch 1”);

}

Smaller in my sense means that the value of “Volt” is f.e. -0.04. But here it only seems to take the absolute value (0.03) in account, neglecting the minus.
Also, >= 0.008 is obviously wrong, because I want to catch all the values between -0.03 and 0.08. But that is no my problem for now, since I switched all values to integer now.

If you’re getting this from analogRead then it shouldn’t ever be negative. Arduino can’t handle negative voltage. You’ll fry it.

I have a 1.60V offset circuit added to the probe and A1 where I also measure the offset voltage constantly. So the "real" measured value of -0.03V is 1.57V.
I skipped the part where I subtract that 1.60V.

// Measure Voltage & add offset Volt0=Volt; // Save old Value first

Volt=(int)analogRead(PIN_TEST)REF_VOLTAGE/PIN_STEPS100; // Read new Value

counter1++;
Volt=Volt-VOffset; // add hardware offset

EDIT: Do I need signed ints here?

int is already signed.

Have you tried printing some of these values to make sure you’re getting what you think? How are REF_VOLTAGE and PIN_STEPS defined

You should least post something complete and compilable that exhibits the problem. You’ve got issues somewhere and you’re not posting all the code.

Hi Delta_G,

Thanks for the replies. Next time I will post the full sketch. Meanwhile, I tracked down my problem with the calculations. I ran out of RAM. No warning nothing, just funny effects. Once I cropped some array here and reduced some other variables it all worked. Once I increased the arrays again, it reappeared.

So for all other beginners, with funny effects better have a look at your RAM usage

MarcelBozz:
Is there a way to see the RAM left?

Look at your code and see how much you use. Yest another great reason to post your damned code when you have a question. I still don't understand how people expect us to diagnose code we can't see.

When you compile in the IDE it will tell you about your global usage, but that doesn't always tell the whole story. At the end of the day it's on you to watch how much you use as you write your code.