ggbion.blogg.se - Blender 2.8 properties panel

#BLENDER 2.8 PROPERTIES PANEL UPDATE#
#BLENDER 2.8 PROPERTIES PANEL FULL#
#BLENDER 2.8 PROPERTIES PANEL REGISTRATION#
#BLENDER 2.8 PROPERTIES PANEL CODE#

If you have 2.7 code dealing with changing viewport layers, you will have to make some adjustments to fit Blender 2.8.

It is a bit funny to be grabbing a collection and naming it as though it were a group, so as you make your updates consider also generalizing the terminology away from “groups” and “collections” where it makes sense.

#BLENDER 2.8 PROPERTIES PANEL UPDATE#

Want to update your code to work with groups in 2.8? Try this snippet out, so it can keep working on blender 2.7 as well.

Be also mindful of the concept of a scene’s “master collection” which is accessed via, which is not available through.

Thus, beware of code that makes assumptions of object visibility not being tied to group/collection membership!.

Removing an object from all collections is the equivalent to removing it from the scene itself, much like in blender 2.7x we have ()

As you add new objects to a scene, you are simultaneously adding them to the scene’s default collection if it has one, or the scene’s master collection.

Check out this page for more details, noting also the 2.8 concept of View Layers.

Instead of the original 20 layers in 2.7, users will toggle visibility of collections or “View Layers”, which can be even nested sets of collections.

All blender scenes by default will start with a collection.

At a first glance, most code can very simply be updated from to, but there are a few more nuances to understand: One of the major workflow shifts of Blender 2.8 is the movement from the previous visual layers and groups into the world of collections. Register, unregister = _classes_factory(classes)

#BLENDER 2.8 PROPERTIES PANEL REGISTRATION#

Make_annotations(cls) # what is this? Read the section on annotations above!ĭef unregister(): # note how unregistering is done in reverseįurthermore, if you are doing no other property registration or funny things like the make_annotations above, you can even use this builtin shortcut instead of manually defining register and unregister functions. if those operators depend on MyPropertyGroup See this recommended pattern, limiting code duplication: # List of the name of the classes inherited from Blender types like AddonPreferences, Operator, Panel etc

This is definitely a move for the better – I have seen many addons that have had weird behaviors or even fail on enable due to issues of using this shortcut and classes registering in a random order. You have to register classes explicitly and one-by-one. In the past, you could be somewhat lazy and put this line in your register function to auto register all classes in the entire addon, even across files _module(_name_). In the long term, it may be a good idea to just embrace the new way – but this is a viable workaround in the meantime.

#BLENDER 2.8 PROPERTIES PANEL FULL#

Use this on any class just before registering it via _class (check out the next section for full code sample). If '_annotations_' not in cls._dict_:Īnnotations = cls._dict_ """Converts class fields to annotations if running with Blender 2.8"""īl_props = You can continue to use the normal syntax with = instead of :, while preventing blender warnings. But, a workaround exists! Take a look at this function below, a sort of anti-pattern solution to this problem (credit to Darkblader24). That means to make code work with both 2.7x and 2.8x, you might think you need to accept the warnings (and pray they turn into errors a long time from now). The trouble is, Blender 2.7’s python (ie before python 3.6) does not recognize this new syntax. I was able to confirm that at least as of Jan 3rd 2019, the Blender Foundation has no timeline for converting these warnings into errors again( source) (earlier versions of blender 2.8 raised errors). to the scene or outside an operator.Įverything will actually still work fine without making this change, but you will find a plethora of console warnings. This applies to properties parameters of operators or within property groups this does not apply to properties directly registered e.g. Without going into too many of the details of this newer python 3.6 syntax notation, the short is that Blender is pushing developers from writing propname = () to using this syntax instead propname: () for class fields.