Bug 1932124
Summary: | Blender not compatible with OpenColorIO 2.0 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Richard Shaw <hobbes1069> |
Component: | blender | Assignee: | Luya Tshimbalanga <luya_tfz> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 35 | CC: | awilliam, design-devel, kwizart, luya_tfz, negativo17, promac |
Target Milestone: | --- | Keywords: | Upstream, VerifiedUpstream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | blender-2.93.3-7.fc36 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-08-24 22:25:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1901430, 1972119 |
Description
Richard Shaw
2021-02-24 03:06:35 UTC
Bug filed upstream on https://developer.blender.org/T85940 Upstream set OpenColorIO 2.0.0 on their master branch (https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/cmake/versions.cmake) but not 2.91.2 (https://developer.blender.org/diffusion/B/browse/blender-v2.92-release/build_files/build_environment/cmake/versions.cmake). From the ticket on comment #2, upstream refused to backport the compatibility to 2.91.2 and suggest to build on 2.93.0 which will be available on May 2021 according to the schedule (https://developer.blender.org/project/view/125). The alternative will be a patch on future 2.92 which will be out in a few week or wait for 2.93. Another suggestion is to set a package OCIO 1.1.1 as a stopgap until Blender reaches 2.93. (In reply to Luya Tshimbalanga from comment #2) > From the ticket on comment #2, upstream refused to backport the > compatibility to 2.91.2 and suggest to build on 2.93.0 which will be > available on May 2021 according to the schedule This looks possible for f34+ if dependencies (LuxRender, others) are compatible. Of build with openvdb support dropped until moving to 2.93 ? This could be done with a copr. I don't mind waiting a little while, but May seems a bit long. If you want to do some testing I can add you to my COPR. Feel free to find an effective method. Another option is something like OpenColorIO1 for dependency as a stopgap until Blender 2.93 lands. This is where things get confusing for me. Would we also need a OpenImageIO compatibility package linked with OCIO 1.x instead of 2.x? The only consumers of OCIO right now are: Blender - not compatible Krita - builds look to be failing for Boost related reasons so I haven't tested OpenImageIO - Builds fine (In reply to Richard Shaw from comment #7) > This is where things get confusing for me. Would we also need a OpenImageIO > compatibility package linked with OCIO 1.x instead of 2.x? > > The only consumers of OCIO right now are: > Blender - not compatible > Krita - builds look to be failing for Boost related reasons so I haven't > tested > OpenImageIO - Builds fine According to the Blender version.cmake (https://developer.blender.org/diffusion/B/browse/blender-v2.92-release/build_files/build_environment/cmake/versions.cmake), it seems the case. I had similar case with embree 2.x in the past. Perhaps using upstream patch may help : https://developer.blender.org/diffusion/B/browse/master/build_files/build_environment/cmake/ Blender 2.93.0 is released. I already pushed the commit on all Fedora release. Feel free to rebuild Blender with OCIO 2.x. Thanks for following up. I'm still working on Krita, and a new dependency usd. Do you need access to usd commit? Maybe so options need to get disabled. No, I'm a PP, I just kinda gave up. The API has changed significantly in the 2.0 release and porting the projects myself is not practical. I do need to file some bugs upstream so they hopefully at least know about it and will adopt it at some point in the near future. (In reply to Richard Shaw from comment #12) > No, I'm a PP, I just kinda gave up. The API has changed significantly in the > 2.0 release and porting the projects myself is not practical. I do need to > file some bugs upstream so they hopefully at least know about it and will > adopt it at some point in the near future. Since Krita is the only dependent package for OCIO 1.x, it would be nice to push 2.x in the repository while making OCIO1.x as a stopgap for time being. The new version of Blender will refuse to support 1.x. Bah, I may have to do that. Currently fighting a similar problem with OpenEXR 2.x vs 3.x. This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35. So I looked into this little thicket a bit as I was looking at failed image builds, and blender being FTBFS prevents the design suite image building. It looks to me like to make Blender build with current OpenEXR, we need OpenColorIO 2.x plus this PR: https://github.com/AcademySoftwareFoundation/OpenColorIO/pull/1432 to deal with OpenEXR no longer having the "half" library that OCIO needs (that PR makes it use a half library from IMath instead, which we do seem to have packaged). https://bugs.kde.org/show_bug.cgi?id=435474 seems to be the upstream bug for Krita, who don't seem inclined to get around to porting it any time soon. so basically I guess we either need to bump the main OpenColorIO lib for Blender and add a 1.x compat build for Krita, or possibly we could drop *OpenEXR* back down to 2.x until Krita is ready? Hah, I need to see if I actually built it, but I've already gotten a opencolorio1 compat repo. Until very recently I was mostly fighting the OpenEXR/Imath disaster but it looks like the two are now converging. Ok, so usd is tied up in the OpenEXR/Imath update so if it can't be made to work with OCIO 2.0 then I'm not sure the whole stack can be upgraded... Bah. Well crap. I was hoping to push off the OpenEXR/Imath 3.1.x update until at least the dust settles but it looks like I need to update Imath at least... CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find Imath: Found unsuitable version "3.0.2", but required is at least "3.0.5" (found /usr/lib64/libImath-3_0.so) FYI, I forced it to 3.0.2 and it built... Also, here's my working COPR if anyone wants to request access: https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/builds/ FEDORA-2021-aef49a8d94 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. |