blender: update to 2.93.11

[catap]

Description

Update to blender 3.x is required to update much more ports. Frankly, all this ports contains tons of patches and reinplace that makes such update a nightmare.

But I've achieved TLS version of blender which I can build via MacPorts on my laptop.

Much better than port which can't be build :)

Unfortently I can't switch it to OneTBB because some dependencies haven't supported OneTBB yet: PixarAnimationStudios/OpenUSD#1471 or PixarAnimationStudios/OpenSubdiv#1234 for example

Type(s)

• bugfix
• enhancement

Tested on

macOS 12.6 21G115 x86_64
Xcode 14.1 14B47b

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint --nitpick?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?
• checked that the Portfile's most important variants haven't been broken?

[macportsbot]

Notifying maintainers:
@jasonliu-- for port blender, embree, materialx, oidn, opensubdiv, openvdb, osl, partio, usd.
@MarcusCalhoun-Lopez for port opencolorio, openimageio, openvdb.

[jasonliu--]

Do you know whether your PR is able to be built on MacOS 10.11? I use MacPorts on my 10.11 laptop, and I have spent quite a lot of effort to keep the MacPorts builds for Blender running under 10.11.

[catap]

@jasonliu-- I haven't tried it on 10.11 to be honest

[jasonliu--]

Is this ticket either a blocker for openvdb, or is your PR supposed to resolve this issue?

https://trac.macports.org/ticket/66463

[catap]

@jasonliu-- yes, it should fix this ticket

[catap]

Just rebased to the last master.

[jasonliu--]

I would like to verify that this PR still allows the Blender port to work on my 10.11 machine. Since there are so many changes, it will take me some time to re-compile all of the dependencies. I will report back here when I have obtained results.

[catap]

@reneeotten if I rebase this one are you willing to merge it? :)

[reneeotten]

I will not unless @jasonliu-- agrees/approves

[jasonliu--]

I'm having a difficult time coming to grips with all of the changes that were made in this PR. So many dependent ports have been updated at once in this one PR... in addition, some dependencies have also received an update in #16915.

I appreciate all of the effort that I'm sure you have put into these couple of PRs, but as the person who generally maintains most of these ports, it's quite difficult for me to do verification if you lump all of the updates into one PR.

[catap]

@jasonliu-- #16915 is blocked by this PR. As soon as this one is merged, it decreases the size of #16915 :) because it contains this one and a lot of another PRs.

:)

[catap]

BTW I've just rebased it to the last master

[reneeotten]

since January 1st, Python 3.11 is the default so if possible let’s set that as the default for ports in this PR as well?

[catap]

Building it finally on 10.11

[catap]

@mascguy it successfully builds on macOS 10.11, anyway, it won't start in virtual machine because it required OpenGL 3.1 or something like that.

But after diging for couple of hours (like 6) why I've discovered a bypass: BLENDER_SOFTWAREGL. This is an environment variable. So, by running a command env BLENDER_SOFTWAREGL=1 open /Applications/MacPorts/Blender.app I've started it and captures screenshots.

[mascguy]

@mascguy it successfully builds on macOS 10.11, anyway, it won't start in virtual machine because it required OpenGL 3.1 or something like that.

But after diging for couple of hours (like 6) why I've discovered a bypass: BLENDER_SOFTWAREGL. This is an environment variable. So, by running a command env BLENDER_SOFTWAREGL=1 open /Applications/MacPorts/Blender.app I've started it and captures screenshots.

That is awesome Kirill, great work!

So are we ready to merge, once CI completes?

[catap]

@mascguy I guess this was the last remark :)

[mascguy]

Given that Kirill has confirmed that this all works on 10.11, are there any objections to merging (once CI conpletes)?

@reneeotten and @jasonliu-- ?

[catap]

@mascguy from my point of view all remarks addresed and this is ready to be merged.

[mascguy]

@mascguy from my point of view all remarks addresed and this is ready to be merged.

Sounds good, let's give Renee and Jason a few days to respond.

[catap]

@mascguy that should we do with this one?

[mascguy]

I'm definitely fine with this, and would love to see it merged.

But it's only been two days, so let's give folks another few days to respond.

[catap]

@mascguy thanks, it's clear. I'm pushing at two PRs because they are blocker for my huge TBB/OneTBB mess fix up, which is blocking a few another updates :)

[jasonliu--]

@mascguy, do you need to run the command with the added environment variable each and every time you start Blender? Or is this something the could be incorporated during the build process?

[mascguy]

@mascguy, do you need to run the command with the added environment variable each and every time you start Blender? Or is this something the could be incorporated during the build process?

To make it seamless, we'd probably want to use a launch script [within the app bundle] to set it when necessary.

Kirill, is that something you'd mind doing?

[jasonliu--]

If it should be in a launch script, then maybe we could make it a separate PR. I would be willing to submit that PR, since I have to create launch scripts for some of the open source games that I have made Portfiles for, so I could probably grab some of my existing code from those to repurpose for this case.

[mascguy]

If it should be in a launch script, then maybe we could make it a separate PR. I would be willing to submit that PR, since I have to create launch scripts for some of the open source games that I have made Portfiles for, so I could probably grab some of my existing code from those to repurpose for this case.

Sounds great! So can can we go ahead and merge this PR as-is then?

[catap]

@jasonliu--, @mascguy this environment variable only required because I've tested it inside virtual machine with quite poor OpenGL implementation.

For real use case it doesn't needed.

Have I missed something?

[mascguy]

Everything is now covered - including 10.11 - so we're good-to-go.

[catap]

Yahooo! Thanks Christopher!

[jasonliu--]

@jasonliu--, @mascguy this environment variable only required because I've tested it inside virtual machine with quite poor OpenGL implementation.

For real use case it doesn't needed.

Have I missed something?

That probably makes a certain amount of sense, since many virtual machine softwares aren't perfectly able to pass through hardware graphics rendering between the guest and host OSes. My googling skills are failing me right now, but I seem to recall that using BLENDER_SOFTWAREGL=1 was also quite inefficient, and puts a lot of additional load on the CPU.

But the environment variable is certainly a great find by @mascguy, since it's very likely that I'll probably need to use it personally going forward, as I spin up a macOS 10.11 virtual machine to do my MacPorts dev/testing, in preparation for the day that my physical 10.11 machine might die.