@Jean Da Costa (jeacom256) We cannot do this because we cannot distinguish between pixels that are unlit from pixels comming from another object at this point in the pipeline. The lighting is masked before doing the SSS passes.
We could add a thickness option for the SSS, similar to the one the SSR have.
This is a limitation of eevee's SSS. The occluders have infinite thickness.
The counter argument is that the planar reflections are not necessarily visible if you don't have SSR on and the surface if a big rough.
Also I did enable it by default to comply with unreal's default.
The behavior is not expected. Drawing vertices selected or unselected should take the same amout of time.
I cannot reproduce this issue. Is it only happening on nvidia+linux?
Ok let's go then.
Known limitation. Hopefully one day we will have raytraced shadows.
Looks good to me. Just remove the uneeded DRW_shgroup_stencil_mask and we are good.
We did remove the automatic depth test. Now you have to explicitly set it inside your drawing function and reset it to no depth test.
Sat, Jun 22
Great! Everything is working!
Fri, Jun 21
There is DRW_STATE_BLEND_ALPHA_UNDER_PREMUL for that purpose but we can add a non premul if you need.
@Antonio Vazquez (antoniov) The issue comes from these lines. When drawing a line, the draw depth function is called first, and only used basic engine and GPencil. But then when the viewport is redrawn, an other set of engine is enabled which reset all engines data for this viewport.
Ok it is caused by a VERY bad usage of DRW in GPencil. My patch just unveiled the problem.
Thu, Jun 20
Fine as it is.
Wed, Jun 19
- Workbench: Use resource_id instead of own index
- Workbench: Remove object_id and optimize material hash generation
- DRW: Add draw call sorting
- GPU: Add API to use multidrawindirect using GPUbatch
- DRW: Use new GPUDrawList to speedup instancing
- Workbench: Simplify / Speedup Material Hash
This was fixed by rB8f4b7083d3a5
Tue, Jun 18
This is because the overlay does not use the same matrices transform.
Just add a comment saying its temporary waiting for clear commands inside shgroups.
Mon, Jun 17
Limitation. SSReflections use the previous frame as reflection input, leading to a feedback loop that saturate metals colors.
This is a limitation, It was just undocumented. Thanks!
This is because we recalculate the tangent space if the mesh changes. There is no workaround because normalmaps uses it. Realtime engines assume the tangents do not change and use GPU skinning, 2 things we cannot do in a program in blender (at least without special cases that are going to tangle everything).
Sun, Jun 16
Fri, Jun 14
This is only happening if you put crazy values in clip distances. This is a float precision issue. I did improve the situation from the initial problem but we will always have the issue at some point unless we really change the algorithm.
This has the same behavior in 2.79. So not a regression or a bug. (my view was not aligned with the mesh so only a part of the wires were missing)
To my knowledge, all these bugs were fixed. Closing.
I did not know this was valid under cycles.
Thu, Jun 13
Ok I finally found the issue. The issue is caused by the GPUOffscreen not being created in the same GL context as the one in which it is used for drawing. Framebuffers are not shared between contexts. So appart from creating it in the right context (which, if i'm not mistaken, is not possible with the current API) we can only do a subsystem under the hood with one framebuffer per context and use the right one depending on active context. This is the only flexible way of doing it that won't complicate the pyGPU API usage.
I have already fixed this issue locally i just didn't pushed it yet. :)
Wed, Jun 12
Tue, Jun 11
This feature needs preprocessing that is intensive. It wouldn't be realtime. It's a complex problem and will not be tackled for 2.80 release.
Sun, Jun 9
I can repro on nvidia+linux.
Sat, Jun 8
Fri, Jun 7
- DRW: Remove common_view_lib uniform default values
- Edit Curve: Fix curve normals
- Cleanup: GPUBatch: rename arguments
- DRW: Make workaround for drivers with broken gl_InstanceID
The artifact is because the Screen Space Refraction does not know what is behind the suzanne or the red cube. Using Alpha Blend removes the objects from the prepass so refraction is done before rendering these objects. This could be an option for all shaders in the future but for now it is a limitation.
Unfortunately I cannot reproduce this time. I tried a blind guess and maybe it will fix the issue.