First attempt with Eevee (which required hours of work hooking up nodegroup inputs to values, and I probably even missed a few) based on a Cycles setup. I showed the 3 minute render to a college and (although I can spot other things) the only thing he really commented on was the bad aliasing artefacts on the floor:
Strange. Your floor is pixelated. Just your floor. I thought at first it was a low-res texture, but it’s pixelated relative to the screen. Very strange. Try making a new floor and see how that works.
Tried 5 and 16 without a difference. Tried 512 samples in the sampling menu without a difference. Tried the full sample setting on without a difference.
I’m using builtin brick texture generator (mortar for boards/bump and another one to generate color which is used to lookup a texture map randomly), and the problem seem to be where the mortar mask is used as a bump. Mortar size is 0.001 and mortar smooth doesn’t seem to matter - the problem is more evident where the bump bevel catches light.
This is just a shot in the dark, but did you scale the floor in object mode? You could try applying the scale. There is also this cycles bumpmap glitch which probably isn’t related to your issue here, but you can try his solution. He divided his bumpmap by a large amount (35) before connecting it to the bump node.
Object scale is applied, yes. Brick texture has a map scaling of 0.8, height width at 1 and 0.1 which shouldn’t be an issue. Bump strength is 0.1 and bump distance is 0.001 (on a separate test project with just a plane basically). Big difference between Cycles and Eevee wrt aliasing.
Yea, i didn’t think dividing the texture would work. That guy’s issue was in cycles. I just thought maybe there was a remote chance eevee had a similar issue.
Looks like a texturing filtering issue. Being procedural, the brick texture isn’t filtered directly like an image texture would be. In Cycles all the primary samples you’re tracing brute force away the problem. Eevee multi-sample AA function seems to deal with it fine when the brick texture is on the color channel, but something doesn’t seem to be filtered correctly when the brick texture is on the bump channel.
@J_the_Ninja:
Ok, I never tried it as a color (although I use a separate one without mortar to create random colors after a noise node - added to coordinates for image texture lookup). I guess I have to ignore the bumping and use it to apply a darker shade instead then. The mortar smooth seem to be a linear gradient, which I feed through a smootherstep function for very nice bevels. Not sure how to achieve that effect as a color since its purpose (catching better highlights) is completely lost.
Part of the issue here could be that AA in realtime (in general, not just Blender) is a bit trickier to pull off at interactive framerates than the same thing in offline rendering.
From reading the various techniques used in games, the best technique we have now is one from Nvidia that automatically downsizes footage rendered at a higher resolution (ie. old-fashioned supersampling applied to realtime).
This type of artefact is called shader aliasing, and the only way to combat this is to supersample, either spatially or temporally. It happens because with normal (MSAA) antialiasing only geometry edges are multisampled. The interiors of faces are still evaluated only once. With a texture you can filter it away with texture filtering, but with a shader this is problematic because the shader would just return the same value each time.
You’d think Eevee’s “temporal” antialiasing would solve this, but apparently nope.
For bump mapping Eevee uses derivatives provided by the hardware. GPUs shade in blocks of 2x2 pixels which means derivatives can be computed “for free” by reading neighboring pixels within that block, and I can imagine it causing this type of artifact.
The solution may be to manually compute the derivatives at the cost of performance. Not sure it would even be considered a bug at this stage, there’s dozens of render quality issue like this that could be improved.
For image textures you also ideally need cubic interpolation for smooth bump results, which Eevee does not support currently. But there is linear interpolation, which is better than closest which you effectively get with a procedural brick texture.
Closest interpolation does sound like a valid reasoning.
Ace mentioned supersampling and downscaling as an option. I haven’t tried it yet with the full image, but I’ll try and see if I can handle it memory wise. Is this something that in future could be done internally only on “problematic channels” (like bump) only? Maybe setting for viewport and rendered?
@gritche: I’ll try 8bit bw with cubic interpolation to see if this is enough. For random nontiled appearance I prefer procedural over image (or procedural to lookup image - random woodgrain parts per tile, but not tile itself), and each time I tweak the seed I’d need to render out a separate (possibly massive) bw bump texture - not ideal for me.
I also just realized today that Eevee indeed renders all bump map textures at 50% of the actual screen resolution, and there’s still no way of correcting that.
This will be fixed eventually, right?
I am making extensive use of bump maps on every video game asset that I produce at my day job. I won’t be able to work with Blender anymore if the rendering in Eevee remains as broken as it currently is.
Hi, keep in mind Blender 2.8 is in Alpha status-
Not feature complete, hell of bugs, crashing, .blends are not backward nor forward compatible.
Wait for Beta -> feature complete, hell of bugs, crashing .
Or better Release Candidate for serious work but not production.
.