blender/blender

USD: custom properties export improvements #124067

Merged

Michael Kowalski merged 3 commits from makowalski/blender:usd-export-props-namespace into blender-v4.2-release

2024-07-04 00:45:41 +02:00

Michael Kowalski commented

2024-07-02 22:51:40 +02:00

Member

Added a new custom_properties_namespace USD export option, to
allow replacing or omitting the current default "userProperties"
namespace prefix.

Note that this option does not apply to names that already have a prefix
(e.g., it would apply to name 'bar' but not 'foo:bar'). It also does not apply
to the internal Blender "object_name" and "data_name" properties which
always have the prefix "userProperties:blender".

Also added logic to handle ':' namespace delimiters in property names.

Added a new custom_properties_namespace USD export option, to allow replacing or omitting the current default "userProperties" namespace prefix. Note that this option does not apply to names that already have a prefix (e.g., it would apply to name 'bar' but not 'foo:bar'). It also does not apply to the internal Blender "object_name" and "data_name" properties which always have the prefix "userProperties:blender". Also added logic to handle ':' namespace delimiters in property names.

Michael Kowalski added the

labels 2024-07-02 22:51:41 +02:00

Michael Kowalski added 1 commit 2024-07-02 22:51:53 +02:00

USD export: custom properties namespace option 70dbba1edb

Added a new custom_properties_namespace USD export option, to
allow replacing or omitting the current default 'userProperties'
namespace prefix.

Michael Kowalski added this to the USD project 2024-07-02 22:51:57 +02:00

Michael Kowalski requested review from Jesse Yurkovich 2024-07-02 22:53:12 +02:00

Jesse Yurkovich requested changes 2024-07-02 23:23:16 +02:00

Dismissed

Jesse Yurkovich left a comment

Member

This introduces some asymmetry with Import. Given an object with custom property "prop", if you export as userProperties:prop then on Import this will just be read back in as prop - as expected. With this PR, if you export as customNs:prop then on Import this will now be listed as customNs:prop. Basically the Importer treats the userProperties namespace as special as well.

This introduces some asymmetry with Import. Given an object with custom property "prop", if you export as `userProperties:prop` then on Import this will just be read back in as `prop` - as expected. With this PR, if you export as `customNs:prop` then on Import this will now be listed as `customNs:prop`. Basically the Importer treats the `userProperties` namespace as special as well.

source/blender/editors/io/io_usd.cc Outdated

						
				@ -273,6 +273,9 @@ static int wm_usd_export_exec(bContext *C, wmOperator *op)

				  RNA_string_get(op->ptr, "root_prim_path", root_prim_path);

				  process_prim_path(root_prim_path);

				  char custom_properties_namespace[FILE_MAX];

Jesse Yurkovich commented

2024-07-02 23:20:32 +02:00

Member

Better to use MAX_IDPROP_NAME here too I think.

Better to use MAX_IDPROP_NAME here too I think.

makowalski marked this conversation as resolved

Michael Kowalski added 1 commit 2024-07-02 23:39:10 +02:00

Fixed array size. e79752ad23

Michael Kowalski commented

2024-07-02 23:49:26 +02:00

Author

Member

This introduces some asymmetry with Import. Given an object with custom property "prop", if you export as userProperties:prop then on Import this will just be read back in as prop - as expected. With this PR, if you export as customNs:prop then on Import this will now be listed as customNs:prop. Basically the Importer treats the userProperties namespace as special as well.

Yes, I see what you mean. However, without this PR, there is currently an asymmetry with export. I.e., if the original USD coming from some other DCC had a namespace customNs:prop then it would always be exported as userProperties:customNs:prop which is not usually what the user wants. With the current PR the user at least has the option to keep the original namespace by clearing the custom_properties_namespace option.

In my opinion, the asymmetry introduced by this PR is less of an issue than the original one. But am open to discussing this, of course.

> This introduces some asymmetry with Import. Given an object with custom property "prop", if you export as `userProperties:prop` then on Import this will just be read back in as `prop` - as expected. With this PR, if you export as `customNs:prop` then on Import this will now be listed as `customNs:prop`. Basically the Importer treats the `userProperties` namespace as special as well. > Yes, I see what you mean. However, without this PR, there is currently an asymmetry with export. I.e., if the original USD coming from some other DCC had a namespace `customNs:prop` then it would always be exported as `userProperties:customNs:prop` which is not usually what the user wants. With the current PR the user at least has the option to keep the original namespace by clearing the `custom_properties_namespace` option. In my opinion, the asymmetry introduced by this PR is less of an issue than the original one. But am open to discussing this, of course.

Michael Kowalski requested review from Charles Wardlaw 2024-07-02 23:56:41 +02:00

Jesse Yurkovich commented

2024-07-03 02:22:38 +02:00

Member

Yes, I see what you mean. However, without this PR, there is currently an asymmetry with export. I.e., if the original USD coming from some other DCC had a namespace customNs:prop then it would always be exported as userProperties:customNs:prop which is not usually what the user wants. With the current PR the user at least has the option to keep the original namespace by clearing the custom_properties_namespace option.

Hmm, if a blender property is currently called "customNs:prop" then it will become "customNs_prop" during export since invalid USD identifier characters are turned to underscores. I suppose this also exists in main too, so either way the user is kind of stuck if they want to round-trip. Maybe we need to adjust the processing of these properties on export further to treat all ':' as namespaces and leave them unchanged when writing out?

> Yes, I see what you mean. However, without this PR, there is currently an asymmetry with export. I.e., if the original USD coming from some other DCC had a namespace `customNs:prop` then it would always be exported as `userProperties:customNs:prop` which is not usually what the user wants. With the current PR the user at least has the option to keep the original namespace by clearing the `custom_properties_namespace` option. Hmm, if a blender property is currently called "customNs:prop" then it will become "customNs_prop" during export since invalid USD identifier characters are turned to underscores. I suppose this also exists in main too, so either way the user is kind of stuck if they want to round-trip. Maybe we need to adjust the processing of these properties on export further to treat all ':' as namespaces and leave them unchanged when writing out?

Michael Kowalski commented

2024-07-03 16:00:27 +02:00

Author

Member

Hmm, if a blender property is currently called "customNs:prop" then it will become "customNs_prop" during export since invalid USD identifier characters are turned to underscores. I suppose this also exists in main too, so either way the user is kind of stuck if they want to round-trip. Maybe we need to adjust the processing of these properties on export further to treat all ':' as namespaces and leave them unchanged when writing out?

Ah, good point! I apologize, I made hasty assumptions about the behavior by looking at the high level code.

Handling the nested namespaces should be an easy fix and I think will improve the implementation anyway. I'll make the fix now.

> Hmm, if a blender property is currently called "customNs:prop" then it will become "customNs_prop" during export since invalid USD identifier characters are turned to underscores. I suppose this also exists in main too, so either way the user is kind of stuck if they want to round-trip. Maybe we need to adjust the processing of these properties on export further to treat all ':' as namespaces and leave them unchanged when writing out? > Ah, good point! I apologize, I made hasty assumptions about the behavior by looking at the high level code. Handling the nested namespaces should be an easy fix and I think will improve the implementation anyway. I'll make the fix now.

Michael Kowalski added 1 commit 2024-07-03 22:26:07 +02:00

USD export: respect ':' delimiters in prop names 207d01b140

Also, only applying default namespace prefix if the prop
name does not already have a prefix.

Michael Kowalski changed title from ~~USD export: custom properties namespace option~~ to USD: custom properties export improvements

2024-07-03 22:27:47 +02:00

Michael Kowalski commented

2024-07-03 22:32:38 +02:00

Author

Member

@deadpin I updated the logic to handle ':' delimiters in the name. Also, per the updated description, the default namespace is no longer applied if the property already has a namespace prefix.

@deadpin I updated the logic to handle ':' delimiters in the name. Also, per the updated description, the default namespace is no longer applied if the property already has a namespace prefix.

Jesse Yurkovich approved these changes 2024-07-03 23:51:39 +02:00

Jesse Yurkovich left a comment

Member

This is really nice now, and makes the behavior more intuitive and flexible! Thanks for taking the time and adjusting things here.

This is really nice now, and makes the behavior more intuitive and flexible! Thanks for taking the time and adjusting things here.

Michael Kowalski merged commit 94c184d2a7 into blender-v4.2-release

2024-07-04 00:45:41 +02:00

Michael Kowalski referenced this issue from a commit

2024-07-04 00:45:42 +02:00

USD: custom properties export improvements

Michael Kowalski deleted branch usd-export-props-namespace

2024-07-04 00:45:45 +02:00

Sign in to join this conversation.

No reviewers

No Label

Animation & Rigging

Automated Testing

Blender Asset Bundle

Code Documentation

Dependency Graph

Development Management

Images & Movies

Motion Tracking

Nodes & Physics

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Viewport & EEVEE

Virtual Reality

Asset Browser Project

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

Nodes & Physics

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Viewport & EEVEE

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#124067

No description provided.