How to improve aliasing?

[CarlG]

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:

Note that windows have blinds (it’s a projected screen cinema setup, so it makes sense to have ti dark/light controlled), so world is not hooked up.

These are the Render settings:

And these are the Preferences (system):

So a lot of things are upped from the defaults with no apparent effect on the aliasing. What do I need to do to improve this?

Note that this is my first attempt with Eevee (I used to get crashes within 1 minute), so I have no idea if probes/materials are well setup.

[yogyog]

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.

[mib2berlin]

Hi, there are also settings in the Render Menu > OpenGL Render Settings > Anti Alias Samples

Cheers, mib

[CarlG]

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.

[zanzio]

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.

[CarlG]

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.

[zanzio]

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.

[J_the_Ninja]

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.

Bump channel, 64 samples:

Basecolor channel, 64 samples:

Basecolor channel, 1 sample:

Simple test file here: http://pasteall.org/blend/index.php?id=49860

[qomolangma888]

i think if you want to improve shadow quality, you should turn on highbitdepth , shadow mode should toggle vsm, improve indirect reflection times.

[CarlG]

@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.

Simplified version working in closeup:

And completely broken when zoomed out:

(Previous attempts used 0-1 as the input smootherstep points, I was just messing around here).

And no way to report bugs. How to remind myself when the regular bug tracker starts?

[Ace_Dragon]

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).

[gritche]

you can try to bake the bump to a 16 bits high resolution map

[Piotr_Adamowicz]

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.

[J_the_Ninja]

How does Eevee get around this problem for the color channel though? (see my test example above)

[brecht]

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.

[CarlG]

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.

Edit: Oh, right - cubic not supported yet

[wiimote]

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.

[mib2berlin]

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.

Cheers, mib

[wiimote]

I am keeping that in mind. Still worried though. What Brecht said further up in this thread sounded really alarming.

[sozap]

yes using bump node in eevee result in this aliased / pixelated look.
With normal maps it’s working really fine.