Ensure blender 4 compatibility

[joepal1976]

This is a bit of a meta-issue, see below for the particulars.

TL;DR summary: blender 4 mostly works, but there are still some glitches with materials

To get a blender4 compatible build, download the file called mpfb2-blender4-*.zip from the download directory linked at http://static.makehumancommunity.org/mpfb/downloads.html

General

Until the blender 4 changes have been merged to master, there is a blender4 branch at https://github.com/makehumancommunity/mpfb2/tree/blender4

This branch is build nightly to a separate zip in the normal download dirs, called mpfb2-blender4-*.zip.

As per early september, this is mostly identical to the master branch version, but can be expected to deviate as b4-specific fixes are put into it.

Wavefront obj

fixed

Modifiers

fixed

Shader nodes

The node model has changed around. Particularly the socket set on principled need to be adapted for the new model. This is particularly visible in regards to SSS. It doesn't crash, but it looks strange.

• ShaderNodeBsdfGlossy can't be created. When requesting a new instance, a ShaderNodeBsdfAnisotropic is returned instead
• ShaderNodeBsdfVelvet seem to have been removed

Rigify

mostly fixed

this needs a lot more testing

[Vidyut]

Oh yes, please.

[joepal1976]

Note to self: The temp_override construct will break compatibility with older blenders. Should note in docs or otherwise that minimum required blender version is now 3.3.0. But should also consider if it should be bumped to 3.6.0 instead, since that is LTS.

[joepal1976]

Some enouraging first results:

Proves that it didn't take that much to at least get it up and running, but I'm sure we'll run into a lot of glitches in various areas. I'll keep the issue open until blender 4 is released and everything is validated against the final version.

[angavrilov]

@joepal1976 You should abandon the operator based hackery and use object.modifiers.move.

Also, because of bone collections there would have to be a 4.0 branch with the minimum required version set to 4.0. I'm planning to look into updating Rigify support for that, so what are your views on that? E.g. which branch, and should the rig json files be updated with a compatibility break or provide backward compatibility?

[joepal1976]

I've discovered a few other things that are breaking and which might eventually make it cumbersome to support both 3.6 and 4.0 simultaneously in the same branch.

While I dislike the thought of having two long-lived parallel branches, I don't think the alternative of having a lot of conditionals for backwards compatibility is very appealing either.

So my current thinking is having a blender4 branch where breaking changes can happen and which does not try to keep compatibility with 3.6. I've pushed a new branch for this now: https://github.com/makehumancommunity/mpfb2/tree/blender4

I agree with the modifier stuff.

[Vidyut]

Is it solid enough to start using? I'm thinking of trying out Blender 4 the next time I take a pause in the writing.

No hurry. Unless I put in solid work on book 2, there won't be much point learning blender to make promos. So I'll be getting it to a place where I can send it out for feedback and then beginning for a new promo with blender 4. Also makes sense because Blender 4 breaks many things and is still in alpha I think, so waiting till beta/RC at least and letting more plugins catch up before beginning anew makes sense.

If you have a recommendation to "wait until x stage/date to use reliably", much appreciated.

[hxorasani]

blender's bcon2 dev stage will end this month sep27 i think is the deadline. blender 4 fixes important 3.6bugs. for those of us on older hardware, there's no other choice but blender 4. even the alpha is valuable on its own. so i suggest not waiting for RC.

mpfb crashes when trying to add a rigify rig!

[joepal1976]

@Vidyut : Well it works mostly, but there are issues to resolve with for example rigify before it can be considered stable. Leaving rigify aside my experience so far is that most things work as expected. My suggestion is give it a try and see what happens. We'll need plenty of testing to find the glitches which in all likelihood are there anyway.

@hxorasani As seen with the fixes listed above: I'm not going to wait. But I'll need help finding issues in order to fix them. There are tips at http://static.makehumancommunity.org/mpfb/faq/how_do_i_report_a_bug.html on what information to include in a bug report. A traceback is usually a good start though. But I'll add a note in the top post that rigify needs an overhaul.

[angavrilov]

I'd avoid using blender 4 for critical things for a bit yet. For example, on the topic of bone collections, currently they are broken by armature edit mode undo (fix being worked on, obviously).

I'll try to look into fixing Rigify integration in mpfb during the weekend.

[Vidyut]

@joepal1976 I'm just a champion complainer. Not sure I know enough code stuff for testing. I'm more the type to blunder around, run into trouble and head here for help... but I'll give it a shot the next time I take a break from writing.

I can take directions and do as told, so even if I can't understand the code, I can probably copy-paste warnings, try fixes, etc. Pretty much what I've been doing.

[joepal1976]

@Vidyut : that is actually the type of testing that is needed. Coders tend to find expected errors when testing. Real users who, as you say, blunder around, tend to find the unexpected errors.

[hxorasani]

@angavrilov my iGPU has bugs in blender 3.6, https://projects.blender.org/blender/blender/issues/111161 blender 4 fixed those bugs, so i'm stuck with blender 4a, it's very limiting right now but i'm trying to make the best of a bad situation. can't afford to upgrade just yet.

i'm really grateful to see mpfb2 being developed so actively and how much y'all care <3 it's been extremely useful to me. (like so many others) if my python was fluent, i'd have contributed fixes myself. (maybe in the future i might)

[joepal1976]

@hxorasani it isn't necessary to be a python developer to help. Testing and suggesting improvements is very important too. There's a page with inspirational tips for people looking to engage a bit in mpfb: http://static.makehumancommunity.org/mpfb/contributing.html

[joepal1976]

I have now started to build nightly builds of the blender4 branch. These can be downloaded from the normal download locations (see http://static.makehumancommunity.org/mpfb/downloads.html). Atm, they're more or less identical with the master variant.

[angavrilov]

@joepal1976 Are you planning on merges from the 3.6 to the 4.0 branch?

At the start of the year I added a couple of operators for freely exporting and importing individual shape keys as targets (opposed to the very restricted way the MakeTarget thing works) but didn't submit a PR. After dealing with rigify I plan to rebase and submit those, and wonder which branch to target.

[joepal1976]

@angavrilov : Yes, I will try to keep the master and the blender4 branch as tight as possible. So new features which are not blender4 specific should be PRs against the master branch. I will then continuously merge master into blender4 and fix what merge problems may arise.

[joepal1976]

Seems something has changed with ShaderNodeTree in later builds of blender4. There is no attribute "inputs" anymore, which sounds kind of strange. Will have to research this further.

Traceback (most recent call last):
  File "/home/joepal/.config/blender/4.0/scripts/addons/mpfb/ui/assetlibrary/operators/loadlibraryskin.py", line 38, in execute
    HumanService.set_character_skin(self.filepath, basemesh, bodyproxy=bodyproxy, skin_type=skin_type, material_instances=material_instances)
  File "/home/joepal/.config/blender/4.0/scripts/addons/mpfb/services/humanservice.py", line 591, in set_character_skin
    enhanced_material.apply_node_tree(blender_material)
  File "/home/joepal/.config/blender/4.0/scripts/addons/mpfb/entities/material/enhancedskinmaterial.py", line 99, in apply_node_tree
    NodeService.apply_node_tree_from_dict(blender_material.node_tree, node_tree_dict, True)
  File "/home/joepal/.config/blender/4.0/scripts/addons/mpfb/services/nodeservice.py", line 571, in apply_node_tree_from_dict
    NodeService._ensure_group_interfaces_exist(dict_with_node_tree)
  File "/home/joepal/.config/blender/4.0/scripts/addons/mpfb/services/nodeservice.py", line 540, in _ensure_group_interfaces_exist
    if not input_name in node_tree.inputs:
AttributeError: 'ShaderNodeTree' object has no attribute 'inputs'

[joepal1976]

For reference, the breaking python changes for b4 is listed here: https://wiki.blender.org/wiki/Reference/Release_Notes/4.0/Python_API

However, this is obviously incomplete. It doesn't list several changes (such as the data type change for sheen and the removal of inputs).

[joepal1976]

Comparing python references:

• "Current", ie 3.6.3: https://docs.blender.org/api/current/bpy.types.ShaderNodeTree.html
• "Dev", ie 4.0.0: https://docs.blender.org/api/dev/bpy.types.ShaderNodeTree.html

The inputs property is indeed gone from the NodeTree base class. I have yet to find any form of hint on what to use instead.

[angavrilov]

The inputs property is indeed gone from the NodeTree base class. I have yet to find any form of hint on what to use instead.

I would imagine, https://docs.blender.org/api/dev/bpy.types.NodeTree.html#bpy.types.NodeTree.interface

[Andrej730]

The inputs property is indeed gone from the NodeTree base class. I have yet to find any form of hint on what to use instead.

I beileve you can just use material.node_tree.nodes['Group'].inputs instead of material.node_tree.nodes['Group'].node_tree.inputs, should work the same way. And it should be compatible with both 3.6 and 4.0.

[joepal1976]

I beileve you can just use material.node_tree.nodes['Group'].inputs instead of material.node_tree.nodes['Group'].node_tree.inputs, should work the same way. And it should be compatible with both 3.6 and 4.0.

Thanks for the hint. Here we don't have a node yet though, as we're about to create a new node tree. We're basically doing:

node_tree = bpy.data.node_groups.new("my_new_node_tree", type="ShaderNodeTree")

And then want to define the interface of the new node_tree.

It seems kind of strange that I would have to create a group node and assign the node tree to it in order to define what inputs the node tree accepts.

But if that's the way it is intended, it wouldn't be impossible to refactor things to follow that procedure. It's a way forward.

[angavrilov]

@joepal1976 um, I already mentioned where to look. And there is no way it can be compatible both with 3.6 and 4.0 because the node and node group interface was changed in 4.0 to support collapsible sub-panels.

[Andrej730]

Oh, sorry I think I've confused node_tree inputs with specific node tree instance's inputs.

[joepal1976]

@angavrilov : yes, I saw. I was just too stupid to figure out how to use the new interfaces until now.

[Tony2371]

Addon doesnt appear in the addons list

[joepal1976]

The blender 4 branch has now been merged into master.