Can someone explain this in a little more detail please?
Does this affect Cycles in anyway?
Does this mean render your whole scene at twice the resolution?
Will this be addressed in 2.81?
doesn’t affect cycles, it’s an EEvEE limitation
And normal mapping means image based normal mapping. Converting a bump to normal, via (custom) normaltoworld into a normal map don’t work, I tried. Kinda obviously when you think about it.
It means you can’t have good looking procedural bumps (like the brick texture which I use a lot!).
If memory usage could be kept less if we had a supersample value, I would prefer that over manual scaling. Not sure what downsample algorithm should be used though, selectable?
Possibly optional to not use OpenGL derivatives of 2x2 pixels? I don’t know how bad the impact would be though.
I am confused about doubling the resolution.
Are they saying if I need a 2K texture I will have to use a 4K texture?
Or Render out my entire scene at double the resolution?
I believe the reason Clement took the 2x2 approach is that doing it for greyscale bumpmapping is very cheap while having to calculate the derivatives beforehand (as in Cycles) can be quite costly.
Remember that Eevee is supposed to be a really fast engine that does not leave noise, and the viewport needs to run at interactive speeds to be workable during scene building.
Well I did not implement this. I just used what was already in 2.79.
The thing is that not using the GL derivatives means evaluating the height input 3 times instead of 1 and that’s what cycles does.
I want to implement it at some point but I need to do the same trick as cycles and duplicate the incoming nodegraph to the height input 3 times while changing all texture coordinates.