DEMoCap Tools

Extension is ready for initial review

Hi, thanks for submiting the add-on.

According to the terms of service this platform requires all the extensions to be self-contained. This add-on is a bit on the edge since its dependency is another add-on hosted on the same platform.

That said, it would be ideal if you could make it fully independent (so e.g., they don't go out of sync). Some ideas:

• Bundle the I/O add-on components here with wheels or other solution.
• Merge both add-ons together on this add-on (fine to keep the other add-on still as a lean version of this).

I could include the export/import extension into this one. I have only one concern with it. If somebody installs also the export/import extension the operator names would clash (since they are global in Blender) leading to problems. On the other hand if I rename the operators to avoid the clashing they would be duplicate potentially confusing the user. What do you think is the best solution for this problem?

The most elegant way would be to check if operators with their names (and panels, and everything else …) are already registered before registering them.

You will need to do this on both add-ons since you don’t control which one Blender will register first.

Something else, I think this add-on is not unregistering itself. If I enable it and then disable it, the tab on the 3D Viewport doesn't go away.

This is strange. It uses the same auto-register code. I'll look into it.

Applied the requested fixes and embedded the "Drag[en]gine Import Export" extension in a way it does not conflict (version 1.22.2 or newer)

Hello!

In 4.2 new "Online Access" property was added in preferences. It's a read-only property that Blender and add-ons should refer to. Add-ons that access the internet are now expected to check for bpy.app.online_access and not connect if user turns it off.

Could you please update your add-on to adapt to that requirement? You can read more here https://developer.blender.org/docs/release_notes/4.2/python_api/#additions

Live-Connect does not automatically connect to DEMoCap on the LAN. The user has to explicitly press the connect button to initiate a connection. For this reason I think this rule does not apply to this add-on since connections need to be actively initiated by the user.

In some corporate environments Blender will be launched with --offline-mode. Realistically speaking, in those places people wouldn't be installing "random" add-ons from the internet.

But you do have a point. This is not so different than Blender still launching a User Manual page even if running in offline mode. We will get back to you on this.

Any news on this? I mean you said you would get back to me about this topic.

Sorry about the delay. I'm still not sure how this add-on is supposed to work with same operators and classes that IO one uses. Have you made sure there are no clashes, and also nothing appears twice in UI?

In File > Import menu, Dragnegine resources is empty menu with error

layout.operator("dragengine.import_animation", text=OBJECT_OT_ImportAnimation.bl_label)
                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^
NameError: name 'OBJECT_OT_ImportAnimation' is not defined

Accessing bpy.data items via name is not safe and can cause errors if user (or some other add-on, system) renames those

output\democap_tools\source\democap-tools\DEAddonImportExport\de_tool_eclassproperty.py:54:11: 
                        text = bpy.data.texts["DE Element Class Properties"]

I'm not sure how possible it is with texts in particular, but can you try accessing them directly, without name?

Looking more into the code, in DEAddonImportExport folder there is entire different add-on basically, with its own blender_manifest. That I'm not sure I'm ok with. Best way to avoid all this is to remove IO functionality entirely from this add-on. Since they're both hosted on the same platform and maintained together it makes more sense. If user wants just IO will install 1 add-on, if users wants all functionality will install both. That is better than duplication, and no matter how much we can try there will always be conflicts that will pile up bug reports.

No problem about the delay.

On my system the extensions work. The IO extension is modified in a way it can detect if it has been loaded already or not. This ensures the classes are only added once not twice. This works though only with the Drag[en]gine extension version 1.22.2+ and DEMoCap extension version 1.0.2+ since only these two releases contain the modified code able to handle this.

Can you try with the latest version on both extensions? There you should no more get into troubles. Otherwise I would have to take another look.

Concerning bpy.data I'm not sure I see the problem here. The operator in question simply outputs the data to a text object named "DE Element Class Properties". If that object does not exist (for whatever reason) it creates a new one. Otherwise it picks up the existing one. Since this is only an "output" type operator for the user to copy the text over to EClass XML files I don't see how renaming could be a problem. But maybe I'm missing the point here.

Concerning the embedding I'm quite confused now. In one of the earlier comments I've been told to embed the extensions since this platform does not want extensions to depend on each other. Now that I've embedded it I'm told to split them since embedding is not liked. I'm confused on what I should do.

EDIT: I'm refering to this comment: "According to the terms of service this platform requires all the extensions to be self-contained"

I'm asking why do you embed at all? What is the purpose of it? IO add-on is already on extensions, whoever needs it can already it install it. Why have everything duplicated in here as well? This is a major weakness in design that requires double maintenance that I'm not comfortable allowing at this moment. It is very error-prone workflow and I see absolutely no reason for it to exist. It can just be two separate add-ons, one for IO and other for utilities, if utility add-on users want IO as well they can simply install it too.

In that case please ask "dfelinto" if he is fine with returning the extension to the split state it has been from the beginning. I just want to avoid that I return to the split state and getting then told by "dfelinto" to embed it again.

Hey everyone,

Just a heads-up about a recent change regarding the licensing of add-ons on the Blender extension platform. Moving forward, all add-ons will need to be released under the GNU/GPL 3.0 license (SPDX:GPL-3.0-or-later). This is mainly to keep things simple and consistent across the board.

Previously, we accepted various licenses as long as they were compatible with Blender’s distribution. However, to avoid any confusion and streamline the process, all add-ons using the bpy API should now be presented as GPL 3 (the same license the Blender bundle is distributed). Regardless of whether the original code was under GPL 2, or something else like MIT or ZLIB.

Existing add-ons versions won't be affected. However, new updates will need to comply to the revised requirements.

Thanks for understanding, and feel free to reach out if you have any questions.

@nickberckley Can you please confirm that the other admins/mods consent with you that not embedding the IO extension into this extension is accepted? I'll not separate them unless I have a clear confirmation that I'll not be told afterwards to embed them again. Thanks.

I will move this topic to the moderator channel and align with @nickberckley here, and we get back to it

We want to know reason why you're shipping IO add-on in this one as well. Bundling add-ons is recommended when one add-on depends on another (like rigging add-ons depending on CloudRig for example), basically if one add-on can not work if another isn't present. What is the dependency between this add-on and IO one? Why can't IO add-on be just standalone add-on and why does it have to be in this one as well?

Keeping the extensions separate has been by first submission. I would not embed the IO one in this extension but I've been told by dfelinto that I have to embed it otherwise it will not be allowed.

This extension requires the IO extension to import *.deanim files (DEMoCap stores captures in this format). If somebody only wants to use Live Capture he would not need the IO extension. The usual workflow though is to do captures then import them to do post processing and readying them for whatever engine is used in the end.

Yes its been a misunderstanding of our part, sorry about that. Having them separate would be the best choice

Okay. Then I'll upload a new version with the embedded extension removed.