Though there is still an issue with the built in raytracing feature. Depending on the angle of the camera I will get som really ugly lighting artefacts. The raytracing lighting also of some reason creates this weird volumetric fog where the further away you are the brighter the shadowy areas.
so… i know eevee next is still under heavy development so i’m not sure if its too soon for feedback, but there is definitely an issue with these new virtual shadow maps.
old eevee and cycles have near identical shadow penumbras, however eevee next seems to be doing some sort of awkward post process blur attempt that results in substantially less soft shadows with the same light settings, and often you can still see the the hard aliased edge of the pre-blurred shadow. also jagged aliasing on shadows seems to get worse the softer the shadow is, and changing the ‘shadow pool’ memory in the render settings doesn’t do anything to help matters.
edit: for my own embarassment and for anyone else experiencing issues, i somehow missed the ‘steps’ setting for shadows in the render settings, which seems to mostly address the issue (although some jaggedness near contact points on shadows is still present)
Probably guys is worth posting these tests you do in the devtalk thread of Eevee next for getting more attention of the devs (most if not all don’t check ba threads)
Feature parity with current Eevee is the main focus of the Eevee Next development. It seems like some bonus features are making it in, but my expectation is that the planned addition of anisotropic shading to Eevee will remain on hold until Eevee Next makes it to release.
I do wish they’d prioritize it higher though since anisotropic is absolutely essential for hair and fur and hacky workarounds to fake it have their limits. But I wouldn’t want Eevee Next delayed for it either.
I disabled the temporal accumulation for denoising as it makes the scene darker than it should be. It’s still darker than Cycles but looks much better. Also upped the samples to decrease the noise.
I assume this is still WIP and will get fixed right? There are some artefacts like if you can notice there are two giant fucking monkeys in lower middle
It’s a new feature. You can go to Render properties >> Monkeys >> Threshold and use the slider to reduce the amount of giant monkeys in your scene. With Eevee Next is 2 by default and you can’t go lower than 1 (Blender crashes)
Eevee NEXT looks really promising. I hope they’ll fix/tune the differences with Cycles.
Oh well, too bad for the artifacts. They actually make the engine unsuitable for pressional stuff
we are going to need a system that converts a baked simulation to vertex animation texture
so the sim ‘lives’ on the gpu and the only thing we are changing is a single uniform ‘time’ and it spits out positions, normals, tangents and ‘canned attributes’.
this will allow for instant playblasts with giant sims
Sounds like a roundabout way to resurrect Blender 2.49’s radiosity feature (minus the topology destroying subdivision and with animation this time).
That will only work for diffuse lighting though (as hard-baked reflections and refractions would only look bizarre if you looked at such materials from different angles). It also would not change the fact that it would be dependent on topology and vertex density, and the ‘simulation’ part I do not quite get unless this is an attempt to influence general Blender development for the purpose of shoring up performance issues with the UPBGE fork (which we have said time and again that Eevee is not designed for realtime 60 FPS interaction).
this is not baking lighting at all - it is displacing the mesh using ‘gpu displace’ and setting normal input so it does not need to be calculated - same with tangents.
we can animate a vast baked wind /waves sim - and then make a vat and play it at like 200fps / not have a depsgraph cost or the cost of streaming changes to the gpu.