Just as a heads up, the dithering behavior of Blended materials is not expected and is a bug. This will be fixed.
The result of using ShaderToRGB is supposed to be the same as using the Blended render mode.
However, there is currently a bug with the tetrahedral mapping that makes this harsh lighting at the bottom. This is present in both Blended and ShaderToRGB lighting and will be fixed.
Please bring back Sphere captures applying light to diffuse surfaces. In some old Eevee NEXT builds Sphere captures could do also do diffuse lighting. It would be great if you make it an option, I think itâs useful when it comes to things you wanna render quickly without baking irradiance volumes
I am not sure I get your point. Sphere Lightprobes never applied light to the Diffuse surfaces.
@OmarEmaraDev
Iâve just tried the new GPU âSoft Glowâ at work and is indeed much better than it used to be! Great job!
Thanks for mentioning it! I didnât made a clue!
I also noticed that indeed feels more accurate than the Bloom from Eevee-Legacy.
So yeah, if you could just bring back the other sliders (knee, color, clamp, intensity) seems that it will work fine without any damage
Note A:
But Iâm now realizing that the Eevee-Legacy Bloom looks âmore cinematicâ⌠itâs more soft⌠as if applied in a larger scale⌠doesnât detect all the small spots (which is good for some cases). The Soft Glow node kind of blows details up and focus a bit too much on small zones without having the controls to minimize that.
Note B:
I know one can just use a mix node to reduce intensity, more nodes to color it and such⌠but I in most case I donât have any big plan for bloom/Sof Glow, I just want try things fast until I get a combination that works
To give artists same sliders that panel had, how about we create node group asset Bloom that has couple of math nodes and mix colors and gives same inputs as panel. That way we dont have to think about how Mix is calculated from intensity
Some of my ShadertoRGBA materials looked very overexposed on the new EEVEE, but I just found out the problem resides in the World Shader I use in many of my setups.
The Is Camera Ray option on the Light Path node doesnât seem to be working.
ÂŹ
EEVEE Legacy ÂŹ
EEVEE ÂŹ
Iâm using main.69d22a42d06f-windows.amd64
You cant imagine how happy i am to hear that.
There is a huge GPU (RTX 3080) spike (over %90 continuous GPU use) when multiple main windows are open (on another monitor) and one of the viewports is set to EEVEE or the legacy renderer. I use this setup for quite sometime, not sure if this was ever the case prior to 4.1.
There is no animation playback, no other activity in the scene in the video, just sitting there. Closing one of the Main windows (so only one scene open) brings the GPU use to 0 with EEVEE on in the same viewport window.
On the other had Cycles (GPU or CPU) does not have this issue with the same setup.
Here I disabled all objects/collections (view layer, viewport and render flags), completely empty camera view , it still uses average %30 GPU.
Hi @kurk can you report a bug, think it might not be related to EEVEE solely
I couldnât upload any media/video from the error I got from trying to reply on this post. But this is build:
" blender-4.1.0-alpha+main.fc21513709aa-windows.amd64-release " from october 16th
In the image you can see I have ray tracing turned off and I am getting âindirect light bouncesâ from the sphere probe which I thought was very interesting and could save times if implemented as an option in the settings.
That looks like a reflection cube (sphere) map and itâs contributing to the reflection of the material.
I noted this earlier in the thread that having RCM enabled in the scene regardless of baking seems to enhance or change the reflections in EEVEE Next.
RCM? whatâs that? I donât see an option called RCM anywhere. Or that relates to words
Does this look like an Eevee bug crash?
use_snap_selectable=False) # Operator
bpy.ops.object.editmode_toggle() # Operator
bpy.ops.mesh.select_all(action='TOGGLE') # Operator
bpy.ops.transform.edge_slide(value=0.431718, mirror=True, snap=False, snap_elements={'INCREMENT'}, use_snap_project=False, snap_target='CLOSEST', use_snap_self=True, use_snap_edit=True, use_snap_nonedit=True, use_snap_selectable=False, correct_uv=True) # Operator
bpy.ops.mesh.select_all(action='TOGGLE') # Operator
bpy.ops.object.editmode_toggle() # Operator
bpy.ops.transform.resize(value=(0.961995, 0.961995, 0.961995), orient_type='GLOBAL', orient_matrix=((1, 0, 0), (0, 1, 0), (0, 0, 1)), orient_matrix_type='GLOBAL', mirror=False, use_proportional_edit=False, proportional_edit_falloff='SMOOTH', proportional_size=0.148644, use_proportional_connected=False, use_proportional_projected=False, snap=False, snap_elements={'INCREMENT'}, use_snap_project=False, snap_target='CLOSEST', use_snap_self=True, use_snap_edit=True, use_snap_nonedit=True, use_snap_selectable=False) # Operator
bpy.context.space_data.context = 'MODIFIER' # Property
bpy.ops.object.modifier_add(type='SUBSURF') # Operator
bpy.ops.object.editmode_toggle() # Operator
bpy.ops.view3d.snap_selected_to_grid() # Operator
bpy.ops.transform.edge_crease(value=1, snap=False) # Operator
bpy.ops.object.editmode_toggle() # Operator
bpy.ops.object.shade_smooth() # Operator
# backtrace
Exception Record:
ExceptionCode : EXCEPTION_ACCESS_VIOLATION
Exception Address : 0x00007FF758C07083
Exception Module : blender.exe
Exception Flags : 0x00000000
Exception Parameters : 0x2
Parameters[0] : 0x0000000000000000
Parameters[1] : 0x0000000000000008
Stack trace:
blender.exe :0x00007FF758C07070 DRW_shgroup_uniform_float_copy
blender.exe :0x00007FF758C12370 EEVEE_lightprobes_cache_init
blender.exe :0x00007FF758C17430 EEVEE_render_cache_init
blender.exe :0x00007FF758C19750 eevee_render_to_image
blender.exe :0x00007FF758BEE2B0 DRW_render_to_image
blender.exe :0x00007FF759616290 engine_render_view_layer
blender.exe :0x00007FF759617970 RE_engine_render
blender.exe :0x00007FF75961E580 RE_PreviewRender
blender.exe :0x00007FF759492D20 shader_preview_render
blender.exe :0x00007FF759492F50 shader_preview_startjob
blender.exe :0x00007FF759491B40 icon_preview_startjob
blender.exe :0x00007FF759491DE0 icon_preview_startjob_all_sizes
blender.exe :0x00007FF758AE4120 do_job_thread
blender.exe :0x00007FF758B0CB70 _ptw32_threadStart
ucrtbase.dll :0x00007FFD824D6BB0 recalloc
KERNEL32.DLL :0x00007FFD83EC53D0 BaseThreadInitThunk
ntdll.dll :0x00007FFD85024830 RtlUserThreadStart
scene set 000001C2D7FB6078
scene set 000001C326A4C0B8
ERROR (gpu.shader): GPU_material_compile VertShader:
|
1090 | typedef enum ClosureType {
|
| gpu_shader_codegen_lib.glsl:131:0: Error: C0000: syntax error, unexpected reserved word, expecting "::" at token "enum"
|
1121 | ClosureType type;
|
| gpu_shader_codegen_lib.glsl:162:0: Error: C0000: syntax error, unexpected ';', expecting "::" at token ";"
|
1126 | ClosureUndetermined closure_new(ClosureType type)
|
| gpu_shader_codegen_lib.glsl:167:0: Error: C0000: syntax error, unexpected ')', expecting "::" at token ")"
|
1129 | cl.type = type;
|
| gpu_shader_codegen_lib.glsl:170:0: Error: C1009: "type" is not member of struct "ClosureUndetermined"
| gpu_shader_codegen_lib.glsl:170:0: Error: C1503: undefined variable "type"
ERROR (gpu.shader): GPU_material_compile FragShader:
|
1098 | typedef enum ClosureType {
|
| gpu_shader_codegen_lib.glsl:131:0: Error: C0000: syntax error, unexpected reserved word, expecting "::" at token "enum"
|
1129 | ClosureType type;
|
| gpu_shader_codegen_lib.glsl:162:0: Error: C0000: syntax error, unexpected ';', expecting "::" at token ";"
|
1134 | ClosureUndetermined closure_new(ClosureType type)
|
| gpu_shader_codegen_lib.glsl:167:0: Error: C0000: syntax error, unexpected ')', expecting "::" at token ")"
|
1137 | cl.type = type;
|
| gpu_shader_codegen_lib.glsl:170:0: Error: C1009: "type" is not member of struct "ClosureUndetermined"
| gpu_shader_codegen_lib.glsl:170:0: Error: C1503: undefined variable "type"
ERROR (gpu.shader): GPU_material_compile VertShader:
|
1114 | typedef enum ClosureType {
|
| gpu_shader_codegen_lib.glsl:131:0: Error: C0000: syntax error, unexpected reserved word, expecting "::" at token "enum"
|
1145 | ClosureType type;
|
| gpu_shader_codegen_lib.glsl:162:0: Error: C0000: syntax error, unexpected ';', expecting "::" at token ";"
|
1150 | ClosureUndetermined closure_new(ClosureType type)
|
| gpu_shader_codegen_lib.glsl:167:0: Error: C0000: syntax error, unexpected ')', expecting "::" at token ")"
|
1153 | cl.type = type;
|
| gpu_shader_codegen_lib.glsl:170:0: Error: C1009: "type" is not member of struct "ClosureUndetermined"
| gpu_shader_codegen_lib.glsl:170:0: Error: C1503: undefined variable "type"
ERROR (gpu.shader): GPU_material_compile FragShader:
|
1122 | typedef enum ClosureType {
|
| gpu_shader_codegen_lib.glsl:131:0: Error: C0000: syntax error, unexpected reserved word, expecting "::" at token "enum"
|
1153 | ClosureType type;
|
| gpu_shader_codegen_lib.glsl:162:0: Error: C0000: syntax error, unexpected ';', expecting "::" at token ";"
|
1158 | ClosureUndetermined closure_new(ClosureType type)
|
| gpu_shader_codegen_lib.glsl:167:0: Error: C0000: syntax error, unexpected ')', expecting "::" at token ")"
|
1161 | cl.type = type;
|
| gpu_shader_codegen_lib.glsl:170:0: Error: C1009: "type" is not member of struct "ClosureUndetermined"
| gpu_shader_codegen_lib.glsl:170:0: Error: C1503: undefined variable "type"
Another question that I have, Is that is it really planned for all draw engines to have Non blocking rendering? Like Eevee Next?
So far, Eevee Next is unusable on my M1 Macbook Pro (16GB, MacOS 14). When I switch to it, it slows down whole computer and doesnât even work properly (no light with default cube and light).
Lights not rendering in EEVEE next on some Apple devices has already been reported to the developers and they are looking into it (although they are probably away on holiday so it may take some time to be fixed). #116128 - EEVEE Next: Lights do not render with Metal - blender - Blender Projects
As for performance. It is currently work in progress and I believe Apple is working on providing patches to improve performance in the future. But even with these patches, itâs highly likely that EEVEE Next will continue to perform worse than Legacy EEVEE in many situations due to EEVEE Next making use of more advanced and computationally expensive rendering techniques.
âŚIs there any danger of Eevee-Next becomes so heavy that is actually faster render in Cycles!?
In some cases seems that itâs heading that way and now that the Bloom will be a compositing node one can use it on Cycles too⌠so Eevee-Next may fall in the situation that is competing with cycles⌠and the only cards that has in it favor is the âShader to RGBâ and faster âvolumesââŚ
Cycles on the other hand has many cards in it favor.
On my work, in Eevee-Legacy, I make an effort that, for a normal creative we do, renders in around 30 seconds per frame, while a high quality trailer renders around 1 minute and 30 seconds per frame. Because Eevee-Legacy is noise free and allows for the usage of many volumes, within that time frame, it has been the only option for me.
Itâs confusing for me, just a normal artist without programming knowledge, that any game engine can do perceptually better quality than Eevee in the very same computer⌠and itâs not just about the big bucks from Unreal ( a HQ frame of a complex catedral in Unreal renders in under 10 seconds per frame), Unity or Unigine⌠GoDot and Armory game engine are doing better quality with much higher frame rates.
⌠and yes, I do understand that has to do with having objects in Eevee editable and that the game engines bake all the stuff⌠but even so.
Eevee is getting slower
As with anything in 3D, rendering speed is completely based on what you do in the scene. Some things might be faster in one engine vs another, and thus testing a/b comparisons is always the best idea to determine where optimization might be called for - or, it will suggest which engine you should be using.
(For comparison, my ânormalâ final output HD renders are in the range of 1-6 seconds per frame.)
Game engines such as Unreal etc. are not pragmatically applicable to the conversation. They are faster at certain things because they are designed for realtime interaction and playback under limited conditions, not the extensive list of authoring that is possible with software like Blender. You donât get one without sacrificing the other.
And agreed, Eevee is getting slower in some situations; some are expected (bsdf), some are not (code issues). But hardware is also getting faster, and sometimes is solution that needs to be explored as well.
as it is right now, eevee next is kinda slower than cycles already. to get rid of all the noise you need a crazy amount of samples
some magic needs to happen for it to be a realtime engine
i wish they kept both engines tbh. legacy as eevee, and this new one as eevee raytrace or something
When your scale an objects and move inside the viewport eevee next is laggy as f**k