- Reunify 'util_sky_model' for cycles and eevee (reduce code duplication)
Mon, Jul 6
Hey, congrats for the work you did here, i'm the Nishita Sky guy and would like to talk with you about porting the model in Eevee, do you have an email or something so i can contact you? Otherwise here's my email firstname.lastname@example.org
Anyway as said by Clement, the porting of Nishita should be a different patch.
Sun, Jul 5
Hi, I would really appreciate this feature, specially to play well with GLTF export pipelines
Sat, Jul 4
- Use the XYZ colorspace variant of the Hosek-Wilkie sky
If you want an OpenColorIO config with a different rendering space (and the XYZ role setup) for testing you can find one here: https://github.com/sobotka/ACES-1.2-Displays-Formatted/tree/blender-configuration
I haven't found a way to make blender use anything other than sRGB linear as its internal color format in eevee nodes but if it can really change then sure, let's use IMB_colormanagement.
(in the meantime I was checking if there is a way of to add uniforms in GLSL library functions (so for example, xyz_to_rgb() would only consume the uniform matrix once, even when used by 5 instances of the sky texture) and it seems than the set of builtins (gpu_codegen.c) is not easily extendable(?))
use 'imbuf_xyz_to_rgb' as uniform instead of literal constants
Mon, Jun 29
Sat, Jun 20
Thu, Jun 18
Archiving old task, we decided not to go with this design.
Wed, Jun 17
Tue, Jun 16
OK, will assume this is fixed then and close.
For the remaining question if this is a candidate for 2.83 LTS, please refer to T77851.
(and of course: for anyone still experiencing this in 2.90, please comment again here, we can always reopen)
I confirm that the problem, in my case, is solved in the most recent 2.90 build.
Thanks for the report, yes environment renderpass should follow cycles.
Mon, Jun 15
Since T77851: black and white textures eevee and cycle has been reported again, and that one is resolved in 2.90, could someone check again if this report is still valid in 2.90?
Wed, Jun 10
Tue, Jun 9
Mon, Jun 8
It looks like a bug, but it also seems to be a limitation.
@Clément Foucault (fclem), what do you think?
Jun 7 2020
Would this capability to render 360* make it possible for Eevee to offer screenspace raymarching reflections that can be raymarched in 360* directions? So for example, behind the camera?
Jun 6 2020
Jun 5 2020
Jun 4 2020
@Clément Foucault (fclem) Your commit fixes the slow shader compilation slowdown.
I found a solution to workaround for fading volumetrics in eevee on macOS with Vega. you can easily work this further and combine this with the texture node by smooth minimum combining it. hope this helps someone, since it drove me nuts:
Huh, this seems to be caused by glGetActiveUniformsiv. I don't have a quick test to see if that really is the culprit; but, there is another way to exclude the UBO uniforms which is a bit more involved.
Hi All, I also experience this kind of problem in the point of switching to eevee, will turn all materials to white. I already reported it a few months ago (sorry I don't know how to tag names). I also found a way on how to solve this problem quickly with out making a new blend file. I don't know why this solves the issue for me but it works all the time I get that problem in eevee.
I'm not sure if this is any help narrowing this down, but when this occurs for me my workaround to immediately resolve is:
Jun 3 2020
@Victor Bonnet (vbonnet) and what is inside GPU_shaderinterface_create?
Ah sorry about that.
@Victor Bonnet (vbonnet) I'm sorry I don't have a Mac nor instrument. Could you unfold the view and see where the hotspot is and just past a screenshot here?
I have sumbled across the same issue on MacOS with Vega external eGPU in EEVEE. No volumetrics is rendered when plugging in a procedual Texture Node into the density of the volumetric principled shader. But using the geometry as th input works fine like that :
Here it is.
@Victor Bonnet (vbonnet) can you give me a detailled screenshot of instrument profiling this, like you did for the original issue?
@Clément Foucault (fclem) Yes the slowdown is caused by this commit.
I think that's shader compilation. When I switch from the workbench to eevee.
when I first switch to render mode it's slower
What do you mean? what are thoses ~1m50s? Render time? Time for shader compilation?
... I'm not sure how far Clément got in investigating this ...
This task has not yet been confirmed, so in theory it has not been investigated.
The original description does not reflect the real problem that is "Connecting the Volume output on the Surface input brings unpredictable results on Eevee".
This report could be edited, but in this case, in order not to confuse, it is better to make another report.
I checked on my macbook. The animation is now even faster than in blender 2.80.
Can you see if connecting to the Volume input solves the problem?
Can anyone test with latest master and tell me if this is fixed?
I can't reproduce the problem, but in the video I could see that you connected the Volume output to the input Surface of the Output Material.
This seems wrong.
Ok, perhaps some more hints to narrow this down:
Jun 2 2020
P.S. (after just having found out) If you need to do testing or require others to; the files are here: https://download.blender.org/opengl/software-emulation/
Fair enough, was just curious...
Then I'll leave the testing and fixing of this issue to Clément and other users.
Just wack this in you bleder directory.
@Alaska (Alaska) Out of curiosity what do you get with opengl32.dll?
@Alaska (Alaska) Out of curiosity what do you get with opengl32.dll?
I've tried a variety of Blender versions from the branches 2.82, 2.83, and 2.90 and I'm personally unable to reproduce this issue on a GTX 1050Ti with drivers 440.82 on Linux. Also tested with Windows with a variety of Blender versions with a GTX 1050Ti with driver 445.87.
Jun 1 2020
I'm running Blender on a 2018 Macbook Pro with a Radeon Pro 560X internal GPU & Radeon VII eGPU with this problem.
May 31 2020
@Clément Foucault (fclem) I noticed that the issue with the Texture Coordinate is only reproducible on tmp-eevee-material-refactor branch but not on master.
May 29 2020
May 27 2020
May 26 2020
May 25 2020
May 23 2020
May 22 2020
I tried P1412 but unfortunately it doesn't fix.
In renderdoc capture it shows that there is almost nothing happening between the 2 drawcalls. I did a capture of the 2.80 release and it is almost the same.
Ok, it seems so.
If I use same texture in both materials then it's fine.
@Victor Bonnet (vbonnet) What if you use the same texture in both materials?
I simply copy the two objects into a new blender project and I am able to reproduce. Hopefully it's gonna help.
May 21 2020
Have you tried plugging a 'ghost' HDMI or DP headless dongle on the eGPU?
@Victor Bonnet (vbonnet) this is still a too big/complex file. From the bug triaging playbook "Normally .blend files can be simplified by removing most objects and disabling settings, until the problem reveals itself more clearly."
This is a known limitation with EEVEE. This is because EEVEE uses a method of rendering glass material known as "Screenspace retractions". I won't go into detail as to why it produces these issues as I believe it may not translate well. But hopefully with a term to research, you should hopefully be able to find resources on it in your language. As for why this method of rendering glass is used, it's because it's faster than other methods. And EEVEE was designed to be fast.