adds support for group import

[lfertig]

Adds feature group import

Adds feature to import group structure from rhino file and link objects

detailed explanation

• collects all group ids from rhino objects and creates the according collections in Blender
• has option to recreate nested group hierarchy as collections instead of importing all groups in parallel
• tested for named and unnamed objects, nested and simple groups, reimporting the same file and reimporting over a previously ungrouped file
• possible issue that needs to be adressed: since the r3d group ids are simple integers and dont carry a uuid they are not unique and will create unpredictable behaviour when importing another file with same group names

fixes / resolves

Fixes #7

[tsvilans]

Cool! Will look through when I have some time.

For the last point, perhaps we could prepend the document id or something like that...

[lfertig]

I was thinking about naming them incrementally, like blender does with its objects, but that would break the reimport. Sounds like a better idea to use the doc id, even though it's gonna look a bit cryptic in the outliner.

[jesterKing]

In general looks good. But please don't change the PR template.

Regarding import of groups with same name from different files: there shouldn't be a problem here, since imports are already distinguished through top-level collections.

[tsvilans]

In general looks good. But please don't change the PR template.

Regarding import of groups with same name from different files: there shouldn't be a problem here, since imports are already distinguished through top-level collections.

I need to double-check, but I seem to remember this causing problems when searching for Collections by name in bpy.data.collections. Maybe that needs to be changed to a more tree-like search, starting with the scene collection instead...

[lfertig]

Tom is right, even if they're not linked to the scenes collection, or to a different one, they still coexist in the file under context.blend_data.collections.

wouldn't it be possible to tag the group collections with the file id instead using it as a prefix to the name, to make them uniquely identifiable? the names would still have to be incremental, the blender way maybe (.001 etc.. ). this way you could fish out all the groups that were imported from the current file before, get the raw group name using a simple string split and rebuild the group.

[jesterKing]

You can tag any ID data type, including collections. We already do it for many objects. The nice part of it is that these tags are automatically saved with the .blend.

# get collection
col = bpy.data.collections['Collection']
col['sometagname'] = 3 # or a string for instance, like the document id.

# after saving, and reloading the file
col = bpy.data.collections['Collection']
print(col['sometagname'])

Check the utils.py file with a few functions that help tagging our objects that we already handle.

[lfertig]

checked the utils. looks to me like this would be the cleanest way to go?

[tsvilans]

Another way would be to do it through parenting in Blender. We can parent the objects in a group to an Empty that is named after the group. It's more or less the same as groups in Rhino then, with only the extra step of having to do Select children on the Empty to select the whole group...

[lfertig]

The nice thing about parenting would be that the objects are (even without selecting the children) connected to their parent and move along with it. On the other hand I can also see Joels point from the forum, that it would be consistent to have them behave similarly to blocks. This way you have the option to turn the collection into an external asset, or instance it within the file etc.

I think the best behaviour is really dependent on what you want to do with the groups, so maybe I should just add an option to do either one or the other?

[joel-putnam]

I like the idea that they behave in Blender in a similar fashion to that in rhino. What if we create a folder called "Group Definitions" and we create each group as a collection here but we actually instance the collection to the scene in the layer collection? This way they are all contained definitions and if you want to modify them you can change the group definition?

Edit:

I suppose this would be similar to what we do for blocks, and yes I realize we may have equal definition group collections as instanced collections. There is just something really nice about being able to select the instance in the outliner and move it, not selecting an empty in the collection and moving that. Personally i also do not like all of the visual clutter that parenting can create. Sure I can turn off the overlay.

[lfertig]

should we try to get to a decision on this?

After thinking about it twice, I would prefer Joels last suggestion of treating this in a similar fashion to the blocks by creating a definition and an instance for each group. This way we'd have a consistent data structure in the blender file and could reuse the instance code.

[tsvilans]

I'm a bit conflicted, because I understand the ease of use in handling them as Collections, the same way as blocks, but it veers off from the way groups are actually used in Rhino. For purity's sake, I would at least start with the parented version, but I also won't put up a fight if the votes are against that method :)

[joel-putnam]

I have no preference for one or the other. Generally I feel that what ever we end up doing should be as close to the rhino intent but we should prioritize where we can creating an optimized blend file. It is my impression "and opinion" that users are modeling in rhino and transferring to blender to render/animate and or prep for game engine usage. We should help that process as much as possible.

Groups should feel like groups(i.e. one object) and blocks should be instanced and editable with the ability to propagate to all instances.

[jesterKing]

Regarding groups I'd use just a collection that can be used to select everything related to the group. Since that is really what groups are in Rhino - selection groups. They aren't one object, even if in Rhino they all get selected when clicking on any part of the group. I don't think parenting objects to an empty is a good thing, since it changes the relationship and structure.

Block Definitions are collections that are instanced into the scene.

addendum: oops. I had written this already yesterday, but apparently I completely forgot to press the comment button. Apologies!