Blender 2.91.0 Alpha - Blender cannot export proper image when containing smooth gradient of Alpha #81390

Open
opened 2020-10-02 19:21:47 +02:00 by Ivaylo Gogov · 34 comments

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-25 20:54, hash: 83dc97ccc0
Worked: (newest version of Blender that worked as expected)

Short description of error
ISSUE is appearing when you try to save-as and export an RGBA image as .PNG etc, out of Blender result looks completely different by color, different brightness, etc. (3), not only in Photoshop but also in Windows Viewer.

Exact steps for others to reproduce the error

  1. Open the attached blend file

  2. Press render

  3. Save-as RGBA ... .PNG file format, etc. save on your local device

  4. Open the outputted image in any program or viewer and compare again vs blend file to see the difference

  5. By the way .EXR format looks correct, but not the PNG. Once I render the.EXR needs to convert all the sequences to.PNGs once again

ISSUE-RENDERING.blend

Blender_Rendering_issue.PNG

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-25 20:54, hash: `83dc97ccc0` Worked: (newest version of Blender that worked as expected) **Short description of error** ISSUE is appearing when you try to save-as and export an RGBA image as .PNG etc, out of Blender result looks completely different by color, different brightness, etc. (3), not only in Photoshop but also in Windows Viewer. **Exact steps for others to reproduce the error** 1. Open the attached blend file 2. Press render 3. Save-as RGBA ... .PNG file format, etc. save on your local device 4. Open the outputted image in any program or viewer and compare again vs blend file to see the difference 5. By the way .EXR format looks correct, but not the PNG. Once I render the.EXR needs to convert all the sequences to.PNGs once again [ISSUE-RENDERING.blend](https://archive.blender.org/developer/F8947767/ISSUE-RENDERING.blend) ![Blender_Rendering_issue.PNG](https://archive.blender.org/developer/F8947768/Blender_Rendering_issue.PNG)
Author

Added subscriber: @IvayloGogov

Added subscriber: @IvayloGogov

Added subscriber: @jenkm

Added subscriber: @jenkm

I can see a big difference between 2.83.6 and 2.91.0.

The problem is how the file is displayed in Image Editor.

#81390.jpg

I can see a big difference between 2.83.6 and 2.91.0. The problem is how the file is displayed in Image Editor. ![#81390.jpg](https://archive.blender.org/developer/F8948270/T81390.jpg)
Author

@jenkm they fix The Image Editor issue in Blender 2.91 there is no issue, you can see my image above. Check here: https://developer.blender.org/T52680

So the BUG you are showing is fixed already. But..

The problem is coming now about the output of this. When you save as such image as RGBA -png, exr.. etc the result out of Blender looks really, really different.
I test via Window Image Preview, Photoshop, AE same.. result..

@jenkm **they fix The Image Editor issue in Blender 2.91 there is no issue, you can see my image above.** Check here: https://developer.blender.org/T52680 So the BUG you are showing is fixed already. But.. The problem is coming now about the output of this. When you save as such image as RGBA -png, exr.. etc the result out of Blender looks really, really different. I test via Window Image Preview, Photoshop, AE same.. result..
Author

Quick Update,
I tried the same with.EXR and TIFF - and working but not completely fine.
.PNG is not working at all. Now all sequences and render passes from EXR need to be converted to .PNG, and it is really time-consuming and annoying process.

  • Could you please check and advise for a solution to this bug?

I would like to properly render many sequences as PNG's from Blender.

Quick Update, I tried the same with.EXR and TIFF - and working but not completely fine. .PNG is not working at all. Now all sequences and render passes from EXR need to be converted to .PNG, and it is really time-consuming and annoying process. - Could you please check and advise for a solution to this bug? I would like to properly render many sequences as PNG's from Blender.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export. Though, I don't insist on it, just a quick test.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export. Though, I don't insist on it, just a quick test.

Added subscriber: @mano-wii

Added subscriber: @mano-wii

This is the same problem as described in #81101 (Saving image with Alpha (like bloom) not saving correctly)
In short, emission + transparency does not do well in some image formats.

This is the same problem as described in #81101 (Saving image with Alpha (like bloom) not saving correctly) In short, emission + transparency does not do well in some image formats.
Member

Added subscribers: @Jeroen-Bakker, @lichtwerk

Added subscribers: @Jeroen-Bakker, @lichtwerk
Member

I think @Jeroen-Bakker already worked on this? #81199 (Some effects [bloom, smoke, fire, ..] still don't save in PNG with transparent background (occlusion vs. emission)) D9033: #81199: Store Emissive Colors when writing to sRGB 3 channel files

I think @Jeroen-Bakker already worked on this? #81199 (Some effects [bloom, smoke, fire, ..] still don't save in PNG with transparent background (occlusion vs. emission)) [D9033: #81199: Store Emissive Colors when writing to sRGB 3 channel files](https://archive.blender.org/developer/D9033)

This not related to "emission + transparency", this also happens with normal 8bit png images,
it looks different in the Image Editor (2.91.0) than in photoshop or in the 2.83.6.

I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export.

This not related to "emission + transparency", this also happens with normal 8bit png images, it looks different in the Image Editor (2.91.0) than in photoshop or in the 2.83.6. > I created a similar image in "photoshop" and passed it through the Compositor, and re-saved it in PNG, the result is identical to the original PNG. This is why I don't see a problem in import/export.
Author

@Jeroen-Bakker You can use the file I attached, you can see there is no difference between viewport rendering and image editor, once is get rendered. The problem is coming when you want to Save as the output. Please check, simply following the steps above.

@Jeroen-Bakker You can use the file I attached, you can see there is no difference between viewport rendering and image editor, once is get rendered. The problem is coming when you want to Save as the output. Please check, simply following the steps above.
Member

When comparing you should add the comparison with the whole 3d pipeline. The bug was that the alpha of rendered image in the image editor was off from the 3d viewport, The 3d viewport was correct.
The reason was that the image editor (2.90 and earlier) used to be doing the alpha blending in display space and not in scene reference space.
Alpha blending should be done in scene reference space (follow the color management settings and ocio configuration).
PNG images and other file formats do alpha blending in display space (srgb), the issue of alpha differences is now moved towards Image IO.

NOTE: that the same problem exists when importing a PNG file with transparencies and use it the transparency in a material or compositor. The image editor shows the effect that it has.

Keeping this in mind you see that a solution will always have limitations. For now if transparency is important use a file format that is flexible in color management for best results. I believe that the best option for usability is to decode and encode the alpha channel to get close to expected results. Not sure if OCIO can help in this case.

When comparing you should add the comparison with the whole 3d pipeline. The bug was that the alpha of rendered image in the image editor was off from the 3d viewport, The 3d viewport was correct. The reason was that the image editor (2.90 and earlier) used to be doing the alpha blending in display space and not in scene reference space. Alpha blending should be done in scene reference space (follow the color management settings and ocio configuration). PNG images and other file formats do alpha blending in display space (srgb), the issue of alpha differences is now moved towards Image IO. NOTE: that the same problem exists when importing a PNG file with transparencies and use it the transparency in a material or compositor. The image editor shows the effect that it has. Keeping this in mind you see that a solution will always have limitations. For now if transparency is important use a file format that is flexible in color management for best results. I believe that the best option for usability is to decode and encode the alpha channel to get close to expected results. Not sure if OCIO can help in this case.
Author

@Jeroen-Bakker I completely agree with your comments.
My observations after many hours of comparison and analyzes are the same.

I would like to recommend you for fixing the issue, counting the complete process and pipeline of render production.
Based on my latest observation RESULT compared between 3D view-port and Image Editor --- THERE IS NO DIFFERENCE. The difference is coming when I want to Save As the product out of it.

So here, my thoughts are dividing by 2 possible projections. You tell me, which one is correct, and it can be used.

1/ Projection of thought:

  • After the Setup the Scene in 3D-view-port and calculation of all DATA is stored temporary "somewhere", by definition of TYPE [buffer for poly/meshes; buffer for vertex color, textures, buffer fro shaders]
    In this way as an output of rendered image we have result of that buffers combinations merged based on Zdistance, space-AO,GI, REFLECTIONS, EMISSIONS etc.
    So the first logic calculating and merging the data -by- transferring it on ImageEditor Screen, and based on transfere here, alpha it cannot be calculated properly because is not stored properly, or it is not projected properly compare the life 3D-viewport-screen.

2/. Projection of thought

  • IF the data of the Alpha cannot be stored properly, there will be no way of projecting it properly. Which mean the focus should behow this data need to be a/stored b/transferred c/projected on final output image.
    Probably the HIGH dynamic range images as you mentioned will look more accurate on look, but again it will not be exactly based on the present. Additional alpha adjustment will be always required.

Some questions:

  • how you store the alpha?
  • what approach you are using to transfer the color data and how you combine it with the alpha?
  • what should be added in addition to make possible Image Editor to Save As properly images with such Alpha.

Thank you, Respect for you work and huge effort!
Regards,
Ivaylo

@Jeroen-Bakker I completely agree with your comments. My observations after many hours of comparison and analyzes are the same. I would like to recommend you for fixing the issue, counting the complete process and pipeline of render production. Based on my latest observation RESULT compared between 3D view-port and Image Editor --- THERE IS NO DIFFERENCE. The difference is coming when I want to Save As the product out of it. So here, my thoughts are dividing by 2 possible projections. You tell me, which one is correct, and it can be used. 1/ Projection of thought: - After the Setup the Scene in 3D-view-port and calculation of all DATA is stored temporary "somewhere", by definition of TYPE [buffer for poly/meshes; buffer for vertex color, textures, buffer fro shaders] In this way as an output of rendered image we have result of that buffers combinations merged based on Zdistance, space-AO,GI, REFLECTIONS, EMISSIONS etc. So the first logic calculating and merging the data -by- transferring it on ImageEditor Screen, and based on transfere here, alpha it cannot be calculated properly because is not stored properly, or it is not projected properly compare the life 3D-viewport-screen. 2/. Projection of thought - IF the data of the Alpha cannot be stored properly, there will be no way of projecting it properly. Which mean the focus should be**how this data need to be a/stored b/transferred c/projected on final output image.** Probably the HIGH dynamic range images as you mentioned will look more accurate on look, but again it will not be exactly based on the present. Additional alpha adjustment will be always required. `Some questions:` - how you store the alpha? - what approach you are using to transfer the color data and how you combine it with the alpha? - what should be added in addition to make possible Image Editor to Save As properly images with such Alpha. Thank you, Respect for you work and huge effort! Regards, Ivaylo

Added subscriber: @gurlaldeep

Added subscriber: @gurlaldeep

I am having the same problem.
unfortunately, I can't share the blend file but I have attached a screenshot, and is there any workaround for this?
I am working on a really imported project.

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-10-26 17:29, hash: edf4378c44

render.PNG

Thank you,
Regards,
Gurlaldeep

I am having the same problem. unfortunately, I can't share the blend file but I have attached a screenshot, and is there any workaround for this? I am working on a really imported project. **System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38 **Blender Version** Broken: version: 2.91.0 Beta, branch: master, commit date: 2020-10-26 17:29, hash: `edf4378c44` ![render.PNG](https://archive.blender.org/developer/F9141524/render.PNG) Thank you, Regards, Gurlaldeep
Member

If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

I am setting as confirmed, since it was classified as a Known Issue.

I am setting as confirmed, since it was classified as a `Known Issue`.

In #81390#1060780, @Jeroen-Bakker wrote:
If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

I tried open EXR and keeps the alpha but not glow\bloom

> In #81390#1060780, @Jeroen-Bakker wrote: > If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example. I tried open EXR and keeps the alpha but not glow\bloom
Author

Added subscriber: @fclem

Added subscriber: @fclem
Author

Hello @fclem
Same here, I see a big difference between what people are trying to mention and what the reality is.

Real example: I'm using a blender to showcase and develop assets using alpha and smooth gradient effects.
After this confirmed, I'm moving this production to the development stage from which we need to collect the data from Blender. The standard format for 95% of the real-time render engines we used is PNGs. Not because we want it, but because the support of Open .exr's and others are not compatible with the render engines for embedded systems in Automotive Industries, where I work and develop using Blender.

  • I see a big difference when I export transparency open.EXR image especially when this not 32bit.
    Basically, 90% of the TFT's for that field are supporting 16bits but not 32bits.
    When I Open the.EXR and convert it to 16bit, there is a big difference in the colors, through the alpha, and basically this simply was not working.

!!! Converting the data once again, after is been ready in Blender is something that I really struggle with since I found such a defect exists.

All capabilities of Blender exporter are not in sync when this related to > **an image with alpha-transparent - smooth-gradient, especially when we save out of Blender to any format.

I still cannot understand what is so difficult for that fix?
Tell me please, where is the blocker?

The program it is been in serious development for years, and I'm really thankful for that.
However, we have been part of it also, and we have been supporting the process all the time. Now, I see something which I'm told cannot be resolved for more than 1 year ..?

Hello @fclem Same here, I see a big difference between what people are trying to mention and what the reality is. `Real example: `I'm using a blender to showcase and develop assets using alpha and smooth gradient effects. After this confirmed, I'm moving this production to the development stage from which we need to collect the data from Blender. The standard format for 95% of the real-time render engines we used is PNGs. Not because we want it, but because the support of Open .exr's and others are not compatible with the render engines for embedded systems in Automotive Industries, where I work and develop using Blender. - > I see a big difference when I export transparency open.EXR image especially when this not 32bit. Basically, 90% of the TFT's for that field are supporting 16bits but not 32bits. When I Open the.EXR and convert it to 16bit, there is a big difference in the colors, through the alpha, and basically this simply was not working. !!! Converting the data once again, after is been ready in Blender is something that I really struggle with since I found such a defect exists. All capabilities of Blender exporter are not in sync when this related to > **an image with alpha-transparent - smooth-gradient, especially when we save out of Blender to any format. I still cannot understand what is so difficult for that fix? Tell me please, where is the blocker? The program it is been in serious development for years, and I'm really thankful for that. However, we have been part of it also, and we have been supporting the process all the time. Now, I see something which I'm told cannot be resolved for more than 1 year ..?
Author

In #81390#1060780, @Jeroen-Bakker wrote:
@Jeroen-Bakker If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example.

@Jeroen-Bakker I'm giving you an example that, your suggestion won't work properly

  1. You create an image in Blender using a smooth alpha transparency gradient. Then you render it F12.
  2. Save this image in any format (however you want Open EXR for example)
  3. Open EXR is supported only as 32bit, when you load this in photoshop or AE or any other program, you will have a number of limitations to do simple post-production. THEN
  4. You have to convert the image from 32Bit to 16Bit and look what will happen?! -> it will look completely different

Even you won't do any post-production. The image will be completely different when you convert it from 32bit to 16bit.

How does this work for you? I don't know :) Still wondering ...

> In #81390#1060780, @Jeroen-Bakker wrote: > @Jeroen-Bakker If alpha is important, please don't use PNG they aren't capable of handling pure emissive colors. Use other file formats that store in linear space with premultiplied alpha. OpenEXR is a good example. @Jeroen-Bakker I'm giving you an example that, your suggestion won't work properly 1. You create an image in Blender using a smooth alpha transparency gradient. Then you render it F12. 2. Save this image in any format (however you want Open EXR for example) 3. Open EXR is supported only as 32bit, when you load this in photoshop or AE or any other program, you will have a number of limitations to do simple post-production. THEN 4. You have to convert the image from 32Bit to 16Bit and look what will happen?! -> it will look completely different Even you won't do any post-production. The image will be completely different when you convert it from 32bit to 16bit. How does this work for you? I don't know :) Still wondering ...

@IvayloGogov
I'm not sure I understand the issue. I've edited the original file to include some 3D solid color planes to check if blending is
the same in other applications. Of course it only works if said application uses the same colorspace. Here this works because Scenere Refered colorspace is the same as Display Linear space (using the Standard view transform).

ISSUE-RENDERING.blend

untitled.png

What I can say is this: exporting the render as .png and opening it in Gimp shows wrong alpha blending with the alpha checker / background color, BUT it does blend correctly if I put a layer with same color below it.

Over black checkerboard/background Over black layer
Capture d’écran du 2021-02-04 14-57-11.png Capture d’écran du 2021-02-04 14-56-50.png

To me this looks like blending in the wrong color space. Maybe there is an issue with this in photoshop as well? I know there is an option to enable linear blending. https://blog.prototypr.io/psa-on-mischievous-opacity-72bb355e6069

If this isn't the issue please post an image of what you get when you open the render with photoshop.

@IvayloGogov I'm not sure I understand the issue. I've edited the original file to include some 3D solid color planes to check if blending is the same in other applications. Of course it only works if said application uses the same colorspace. Here this works because Scenere Refered colorspace is the same as Display Linear space (using the Standard view transform). [ISSUE-RENDERING.blend](https://archive.blender.org/developer/F9630443/ISSUE-RENDERING.blend) ![untitled.png](https://archive.blender.org/developer/F9630447/untitled.png) What I can say is this: exporting the render as .png and opening it in Gimp shows wrong alpha blending with the alpha checker / background color, BUT it does blend correctly if I put a layer with same color below it. |Over black checkerboard/background| Over black layer| | -- | -- | |![Capture d’écran du 2021-02-04 14-57-11.png](https://archive.blender.org/developer/F9630430/Capture_d_écran_du_2021-02-04_14-57-11.png)|![Capture d’écran du 2021-02-04 14-56-50.png](https://archive.blender.org/developer/F9630432/Capture_d_écran_du_2021-02-04_14-56-50.png)| To me this looks like blending in the wrong color space. Maybe there is an issue with this in photoshop as well? I know there is an option to enable linear blending. https://blog.prototypr.io/psa-on-mischievous-opacity-72bb355e6069 If this isn't the issue please post an image of what you get when you open the render with photoshop.

Added subscriber: @srfall

Added subscriber: @srfall

I was about to create a new bug report when I found this task.
I am using 2.93.5 and still have the same problem as described in the original report: When saving a PNG with smooth alpha transparency, the colors get completely messed up.
untitled.png
I tried correcting the color space using ImageMagick but no success.

Is there any solution available to fix this?
(And no I can't just use exr. I need a png with correct alpha transparency)

I was about to create a new bug report when I found this task. I am using 2.93.5 and still have the same problem as described in the original report: When saving a PNG with smooth alpha transparency, the colors get completely messed up. ![untitled.png](https://archive.blender.org/developer/F11793508/untitled.png) I tried correcting the color space using ImageMagick but no success. Is there any solution available to fix this? (And no I can't just use exr. I need a png with correct alpha transparency)

After reading the lengthy discussion here: https://developer.blender.org/T52680 I just want to summarize to see if I have gotten the correct points.

  1. Blender handles and display the alpha transparency correctly now
  2. Blender saves the alpha correctly, but PNG as a format is broken, which is why the saved images appear wrong
    To which I reply: Even if PNG transparency is broken, since it is a widely used format, Blender should adapt and try its best to store it in a WYSIWYG manner.

For anyone having a similar issue and trying to get at least a somewhat accurate result: I was able to get an improved result by exporting the image as RGB PNG, then exporting the Alpha channel as separate grey scale PNG and then use ImageMagick to apply the transparency following this answer:
https://stackoverflow.com/questions/55376263/set-alpha-according-to-gradient-with-imagemagick/55377377

Also, since this appears to be a well known (and accepted ?) issue, how about a warning note in the export settings? This still seems to me like a major bug, but when the current position is: "Don't fix" then at least a heads up for the users would be nice.

After reading the lengthy discussion here: https://developer.blender.org/T52680 I just want to summarize to see if I have gotten the correct points. 1. Blender handles and display the alpha transparency correctly now 2. Blender saves the alpha correctly, but PNG as a format is broken, which is why the saved images appear wrong To which I reply: Even if PNG transparency is broken, since it is a widely used format, Blender should adapt and try its best to store it in a WYSIWYG manner. For anyone having a similar issue and trying to get at least a somewhat accurate result: I was able to get an improved result by exporting the image as RGB PNG, then exporting the Alpha channel as separate grey scale PNG and then use ImageMagick to apply the transparency following this answer: https://stackoverflow.com/questions/55376263/set-alpha-according-to-gradient-with-imagemagick/55377377 Also, since this appears to be a well known (and accepted ?) issue, how about a warning note in the export settings? This still seems to me like a major bug, but when the current position is: "Don't fix" then at least a heads up for the users would be nice.
Member

Your points seems to be correct. Note that the described work-a-round can still introduce incorrect alpha blending as when apply-ing the transparency on a different color space than it was generated.
Adding an warning note in the export setting is a good idea.

Your points seems to be correct. Note that the described work-a-round can still introduce incorrect alpha blending as when apply-ing the transparency on a different color space than it was generated. Adding an warning note in the export setting is a good idea.

Thanks for the quick answer.

Yeah, maybe I should have said it more clearly, the work-around doesn't give you a perfect result, but in my situation (where I need the png and care more about the overall look than perfect accurate blending) it gets me about 80% of the way, which is something I can work with.

*Sidenote: I guess an additional option in Blender to save it directly in a way similar to this hack may already be an improvement for many people

Thanks for the quick answer. Yeah, maybe I should have said it more clearly, the work-around doesn't give you a perfect result, but in my situation (where I need the png and care more about the overall look than perfect accurate blending) it gets me about 80% of the way, which is something I can work with. *Sidenote: I guess an additional option in Blender to save it directly in a way similar to this hack may already be an improvement for many people
Author

@srfall yes indeed. yes indeed. I was talking about this issue for a long time, but looks like was neglected, due to other urgent priorities on the road map, and squeezed schedule.
I think is a significant misalignment (bug) when we talk for high fidelity production, which is being there for years. There is no way to export a correct alpha from blender at the moment, doesn't matter if you use blender compositor e or other file type. At the end you always have to composite 2 flat images (once used as an alpha) the other as color, out of Blender to have an accurate look. Unfortunately, this is been for a long, long time.

@srfall yes indeed. yes indeed. I was talking about this issue for a long time, but looks like was neglected, due to other urgent priorities on the road map, and squeezed schedule. I think is a significant misalignment (bug) when we talk for high fidelity production, which is being there for years. There is no way to export a correct alpha from blender at the moment, doesn't matter if you use blender compositor e or other file type. At the end you always have to composite 2 flat images (once used as an alpha) the other as color, out of Blender to have an accurate look. Unfortunately, this is been for a long, long time.

Added subscriber: @jorditorres

Added subscriber: @jorditorres

Same bug happening to me. This is not a minor thing. There is any progress on this?

Same bug happening to me. This is not a minor thing. There is any progress on this?

Added subscriber: @capnm

Added subscriber: @capnm

Added subscriber: @Bradley_G

Added subscriber: @Bradley_G
Philipp Oeser removed the
Interest
EEVEE & Viewport
label 2023-02-09 15:14:28 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
11 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#81390
No description provided.