Asset Pipeline v2 #145

Closed
Nick Alberelli wants to merge 431 commits from (deleted):feature/asset-pipeline-v2 into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

This is a re-design of the asset pipeline add-on. This Add-On was designed to allow multiple artists to collaborate while contributing to a common Asset. It enables simultaneous work on the same asset by multiple artists. The add-on works by tracking what data each artist contributes to the asset and merges the assets together into a final "Published" asset. This published asset is marked to be discovered by Blender's asset manager.

Demo

Tracking for Further Issues

studio/blender-studio-pipeline#170

Stuff that works:

  • Asset initialization
  • Publish to Staged, Review, Active and Depreciating old Publishes
  • Object ownership/deletion (this includes drivers & custom properties)
  • Collection assignments
    Transferable Data (only matching topo for now)
    • Shape Keys (+drivers)
    • Modifiers (+drivers)
    • Constraints (+drivers)
    • Vertex Groups
    • UV Maps
    • Materials (one task layer owns all materials)
    • Generic Attributes
    • Shared IDs (NodeTree & Image)
    • User Remapping
  • Replace File Names with Full Name "Rigging" instead of "RIG"
  • Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc
  • Change Message No new transfer data found to No new local transfer data found
  • Allow each task layer to add multiple top level collections
  • Add Dialogue to Save Images and File

TODO

UI Changes

  • Make transfer data ownership overview collapsable
  • Add Task Layer Prefix to JSON File and use on MOD names
  • Rename Material Slots to Materials
  • Rename all task layer types to plural

Must Haves (High)

Get an MVP of each of these done, then move them to lower priorities

  • Multiple Task Layers in a Single File
    • Customizable Task Layers
    • Init of asset (for many task layers in single file)
  • Ownership defaults will re-assign default things add to object like UVMap and Materials
    • Change Default Ownership for new objects only (user customizable)
  • Material Ownership exists even if no slots are populated
  • Mark as Asset for latest Publish
  • Non-matching topology. For now, we wanted to focus on the ownership logic, and I'm kind of awaiting/poking for assistance from the modeling module for better ways to transfer attributes. (Hopefully doesn't need to be implemented on our end)?
  • Surrendering Ownership Operator/UI
    • No batch operations yet for surrendering
  • Add Proximity Transfer for Attributes
  • Add Proximity Transfer for Shape Keys

Medium

  • Add Advanced Menu
    • add/remove local task layers
    • Reset ownership button for obj
  • Update prefixes on Mods etc when changing ownership
  • Save Backup before pull/push offer to revert if operations fails
  • Add Task Layers on the Fly
  • Update Prefix during Merge Process
  • Convention Checker Integration / Enforce Naming Conventions
    • @Mets to deliver list of conventions to check
    • Check for prefix name conflicts RIG.name == MOD.name
  • Post Merge Actions like resetting armatures, removing actions and applying modifiers
  • Create Separate Operator for Publish Review
  • Ensure OBJS don’t share mesh data blocks until we have ID level ownership

Low

  • Un-Surrender Option (to cancel a surrender)
  • Operator to split up existing file (hard)
  • Add UI to revert file after successful Pull
  • Task Layer Locking
  • Show New Transfer Data after Pull
  • Consider integration with Kitsu (meta data etc)
  • Fancy changing ownership user should be able to surrender a ownership
  • Consider New Validate Ownership Feature (By Pulling but not Merging)

For Next Production

  • Switch to ID Level Ownership

BUGS

  • Fix Bug where update collection ownership runs before invalid objects
  • Bug where Vertex Groups wont transfer in 4.0
  • Merge Fails if not in object mode (always go back to OBJ Mode during merge)
  • unmark external collection as asset during merge
This is a re-design of the asset pipeline add-on. This Add-On was designed to allow multiple artists to collaborate while contributing to a common Asset. It enables simultaneous work on the same asset by multiple artists. The add-on works by tracking what data each artist contributes to the asset and merges the assets together into a final "Published" asset. This published asset is marked to be discovered by Blender's asset manager. ### Demo <video src="/attachments/ddfd137a-5a0d-4c66-9f70-d655d3f3c096" title="Asset_pipeline_merge_demo_process.mp4" controls></video> ### Tracking for Further Issues https://projects.blender.org/studio/blender-studio-pipeline/issues/170 #### Stuff that works: - [x] Asset initialization - [x] Publish to Staged, Review, Active and Depreciating old Publishes - [x] Object ownership/deletion (this includes drivers & custom properties) - [x] Collection assignments **Transferable Data (only matching topo for now)** - [x] Shape Keys (+drivers) - [x] Modifiers (+drivers) - [x] Constraints (+drivers) - [x] Vertex Groups - [x] UV Maps - [x] Materials (one task layer owns all materials) - [x] Generic Attributes - [x] Shared IDs (NodeTree & Image) - [x] User Remapping - [x] Replace File Names with Full Name "Rigging" instead of "RIG" - [x] Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc - [x] Change Message `No new transfer data found` to `No new local transfer data found` - [x] Allow each task layer to add multiple top level collections - [x] Add Dialogue to Save Images and File ## TODO ### UI Changes - [x] Make transfer data ownership overview collapsable - [x] Add Task Layer Prefix to JSON File and use on MOD names - [x] Rename Material Slots to Materials - [x] Rename all task layer types to plural ### Must Haves (High) *Get an MVP of each of these done, then move them to lower priorities* - [x] Multiple Task Layers in a Single File - [x] Customizable Task Layers - [x] Init of asset (for many task layers in single file) - [x] Ownership defaults will re-assign default things add to object like UVMap and Materials - [x] Change Default Ownership for new objects only (user customizable) - [x] Material Ownership exists even if no slots are populated - [x] Mark as Asset for latest Publish - [x] Non-matching topology. For now, we wanted to focus on the ownership logic, and I'm kind of awaiting/poking for assistance from the modeling module for better ways to transfer attributes. (Hopefully doesn't need to be implemented on our end)? - [x] Surrendering Ownership Operator/UI - [x] No batch operations yet for surrendering - [x] Add Proximity Transfer for Attributes - [x] Add Proximity Transfer for Shape Keys ### Medium - [x] Add Advanced Menu - [x] add/remove local task layers - [x] Reset ownership button for obj - [x] Update prefixes on Mods etc when changing ownership - [x] Save Backup before pull/push offer to revert if operations fails - [x] Add Task Layers on the Fly - [x] Update Prefix during Merge Process - [ ] Convention Checker Integration / Enforce Naming Conventions - [ ] @Mets to deliver list of conventions to check - [ ] Check for prefix name conflicts `RIG.name == MOD.name` - [ ] Post Merge Actions like resetting armatures, removing actions and applying modifiers - [ ] Create Separate Operator for Publish Review - [x] Ensure OBJS don’t share mesh data blocks until we have ID level ownership ### Low - [ ] Un-Surrender Option (to cancel a surrender) - [ ] Operator to split up existing file (hard) - [x] Add UI to revert file after successful Pull - [ ] Task Layer Locking - [ ] Show New Transfer Data after Pull - [ ] Consider integration with Kitsu (meta data etc) - [ ] Fancy changing ownership user should be able to surrender a ownership - [ ] Consider New Validate Ownership Feature (By Pulling but not Merging) ### For Next Production - [ ] Switch to ID Level Ownership ### BUGS - [x] Fix Bug where update collection ownership runs before invalid objects - [x] Bug where Vertex Groups wont transfer in 4.0 - [ ] Merge Fails if not in object mode (always go back to OBJ Mode during merge) - [ ] unmark external collection as asset during merge
Nick Alberelli added 130 commits 2023-08-28 17:03:30 +02:00
- Add Function to find latest Publish
 - Re-use import_data function from pervious add-on
 - Adapt Pull Operator to Append Data
 - Add TODO to re-implement pull core function for this context
- Rename Pull Function to Merge_Task_Layer
 - Open Publish on Push and Pull in Data from 'pushing' layer
- Update TODO for Suffix
 - Update TODO to remove id from prop group
- Object key is needed for temp override in vertex group transfer
- Rename target and source object for accuracy
 - Remove vertex group before transfer
Nick Alberelli added 1 commit 2023-08-29 17:38:29 +02:00
Nick Alberelli added 1 commit 2023-08-29 17:40:34 +02:00
Nick Alberelli added 1 commit 2023-08-29 17:42:45 +02:00
Nick Alberelli added 1 commit 2023-08-29 17:51:34 +02:00
Nick Alberelli added 2 commits 2023-08-29 20:17:55 +02:00
Nick Alberelli added 1 commit 2023-08-29 20:20:25 +02:00
Nick Alberelli added 4 commits 2023-08-31 22:55:59 +02:00
Nick Alberelli added 2 commits 2023-09-01 00:19:15 +02:00
Nick Alberelli added 1 commit 2023-09-01 00:22:00 +02:00
Nick Alberelli force-pushed feature/asset-pipeline-v2 from 3756abad65 to 1c2693725f 2023-09-01 23:33:12 +02:00 Compare
Nick Alberelli added 2 commits 2023-09-01 23:37:24 +02:00
Nick Alberelli added 2 commits 2023-09-01 23:42:35 +02:00
Nick Alberelli added 4 commits 2023-09-02 00:57:43 +02:00
Nick Alberelli added 1 commit 2023-09-02 02:57:20 +02:00
Nick Alberelli added 3 commits 2023-09-04 18:25:33 +02:00
Nick Alberelli added 1 commit 2023-09-04 18:34:13 +02:00
Nick Alberelli added 1 commit 2023-09-05 22:15:39 +02:00
Nick Alberelli added 2 commits 2023-09-05 22:58:46 +02:00
Nick Alberelli added 1 commit 2023-09-06 18:41:20 +02:00
Nick Alberelli added 1 commit 2023-09-06 18:42:14 +02:00
Nick Alberelli added 1 commit 2023-09-06 18:45:26 +02:00
Nick Alberelli added 1 commit 2023-09-06 22:58:33 +02:00
Nick Alberelli added 1 commit 2023-09-07 15:49:20 +02:00
Nick Alberelli added 1 commit 2023-09-07 17:23:28 +02:00
Nick Alberelli added 1 commit 2023-09-07 17:24:03 +02:00
Nick Alberelli added 2 commits 2023-09-07 18:28:43 +02:00
Nick Alberelli added 1 commit 2023-09-07 18:29:34 +02:00
Nick Alberelli added 2 commits 2023-09-07 19:03:25 +02:00
Nick Alberelli added 1 commit 2023-09-08 16:23:58 +02:00
Nick Alberelli added 4 commits 2023-09-08 17:32:16 +02:00
Nick Alberelli added 1 commit 2023-09-08 18:04:21 +02:00
Nick Alberelli added 4 commits 2023-09-11 17:28:53 +02:00
Nick Alberelli added 1 commit 2023-09-11 17:56:41 +02:00
Nick Alberelli added 1 commit 2023-09-11 18:59:00 +02:00
- Rename `get_transfer_data_by_name` to `get_transfer_data_as_names`
Nick Alberelli added 1 commit 2023-09-11 21:38:20 +02:00
Nick Alberelli added 1 commit 2023-09-11 22:03:12 +02:00
Nick Alberelli added 1 commit 2023-09-11 22:04:19 +02:00
Nick Alberelli added 3 commits 2023-09-12 21:27:33 +02:00
Nick Alberelli added 1 commit 2023-09-12 23:54:23 +02:00
Nick Alberelli added 1 commit 2023-09-13 00:23:42 +02:00
Nick Alberelli added 1 commit 2023-09-13 17:13:21 +02:00
Nick Alberelli added 1 commit 2023-09-13 19:29:51 +02:00
Nick Alberelli added 1 commit 2023-09-13 20:16:04 +02:00
Nick Alberelli added 1 commit 2023-09-13 20:22:29 +02:00
Nick Alberelli added 1 commit 2023-09-13 20:47:28 +02:00
Nick Alberelli added 2 commits 2023-09-13 21:38:12 +02:00
Nick Alberelli added 1 commit 2023-09-13 21:54:11 +02:00
Nick Alberelli added 1 commit 2023-09-13 21:55:33 +02:00
Nick Alberelli added 1 commit 2023-09-13 22:28:15 +02:00
Nick Alberelli added 2 commits 2023-09-14 00:57:59 +02:00
Nick Alberelli added 1 commit 2023-09-14 15:10:49 +02:00
Nick Alberelli added 1 commit 2023-09-14 15:22:20 +02:00
Nick Alberelli added 2 commits 2023-09-14 17:20:49 +02:00
Nick Alberelli added 1 commit 2023-09-14 18:07:06 +02:00
Nick Alberelli added 1 commit 2023-09-14 18:07:45 +02:00
Nick Alberelli added 2 commits 2023-09-14 18:09:03 +02:00
Nick Alberelli added 2 commits 2023-09-14 19:55:44 +02:00
Nick Alberelli added 2 commits 2023-09-16 01:16:43 +02:00
Nick Alberelli added 1 commit 2023-09-19 15:09:29 +02:00
Nick Alberelli added 1 commit 2023-09-20 22:18:10 +02:00
Nick Alberelli added 2 commits 2023-09-20 23:33:00 +02:00
Nick Alberelli added 1 commit 2023-09-21 02:47:44 +02:00
Nick Alberelli added 2 commits 2023-09-21 03:09:03 +02:00
Nick Alberelli added 1 commit 2023-09-21 17:59:52 +02:00
- Remap Node Groups
 - Remap Images
Nick Alberelli added 6 commits 2023-09-21 19:13:28 +02:00
Nick Alberelli added 1 commit 2023-09-21 19:23:28 +02:00
Nick Alberelli added 1 commit 2023-09-21 19:24:07 +02:00
Nick Alberelli added 1 commit 2023-09-21 19:42:49 +02:00
Nick Alberelli added 1 commit 2023-09-21 20:15:12 +02:00
Nick Alberelli added 1 commit 2023-09-21 21:53:45 +02:00
Nick Alberelli added 1 commit 2023-09-21 22:08:29 +02:00
Nick Alberelli added 1 commit 2023-09-21 22:15:30 +02:00
Nick Alberelli added 1 commit 2023-09-21 22:17:07 +02:00
Nick Alberelli added 1 commit 2023-09-21 22:29:01 +02:00
Nick Alberelli added 2 commits 2023-09-21 22:53:14 +02:00
Nick Alberelli added 1 commit 2023-09-22 15:45:47 +02:00
Nick Alberelli added 2 commits 2023-09-22 15:57:30 +02:00
Nick Alberelli added 1 commit 2023-09-22 16:28:11 +02:00
Nick Alberelli added 2 commits 2023-09-22 18:04:40 +02:00
Nick Alberelli added 1 commit 2023-09-22 20:58:08 +02:00
Nick Alberelli added 1 commit 2023-09-22 21:34:19 +02:00
Nick Alberelli added 1 commit 2023-09-22 21:42:49 +02:00
- Confirm that there is a difference between these functions
 - Clear TODO
 - Update docstrings to clarify difference
Nick Alberelli added 1 commit 2023-09-22 21:46:14 +02:00
Nick Alberelli added 1 commit 2023-09-22 21:50:49 +02:00
Nick Alberelli added 1 commit 2023-09-22 22:04:57 +02:00
Nick Alberelli added 1 commit 2023-09-22 22:11:13 +02:00
- Fix attributes_get_editable()
 - Update required Blender Version
Nick Alberelli added 1 commit 2023-09-22 22:11:42 +02:00
Nick Alberelli added 1 commit 2023-09-22 22:15:43 +02:00
Nick Alberelli added 3 commits 2023-09-22 22:32:01 +02:00
Nick Alberelli added 2 commits 2023-09-22 22:40:54 +02:00
Nick Alberelli added 1 commit 2023-09-22 22:48:11 +02:00
Member

Very cool to see this taking shape! Really like how much more transparent this is already looking than what we previously had.

Small Disclaimer:
I haven't gone into a lot of detail with the testing yet. I simply used Met's example rig setup to get a feeling for the base functionality but I want to already give a batch of feedback and we can go from there. Later it would be good to start a character setup from scratch and go into more complicated details of potential merge conflicts.

Some initial feedback:

I'm not 100% sure what aspects aren't ready for feedback yet, so take it with a grain of salt.

Probably not that relevant right now, but I'd stick to the file naming scheme we had. E.g. rigging rather than rig. The file contains more than just the rig, it sounds a bit misleading to me and should be rather task oriented than data oriented.

There were some nice aspects of keeping the ownership as an explicit prefix for the modifier name. It makes it clear to see on first glance who owns which modifier. That is a lot more intuitive than hunting it down in the ownership Inspector and then having to remember it. Even having a context based operator to check the ownership wouldn't be as convenient and immediate as that.
Additionally by engraving the prefix in the name, we avoid potential name collisions between modifiers of different task layers. This is the same issue we might have in other places as well (e.g. generic attributes), but for modifiers it is a lot more common to leave them at a default name after adding for example a Subdivision modifier. So name collisions can happen quite easily.

The existence of the update ownership button is a bit unclear to me. Shouldn't the ownership just be updated either explicitly by the user, or automatically whenever there is an exchange between task layer and publish data? So I don't see why this button would be necessary. I guess it could make sense to have a Validate Ownership button that can expose conflicts which can then be resolved manually.

It bothers me a bit that the push and pull buttons are always greyed out unless you just saved the file. You end up just always saving before pressing the button. Which is the intended behaviour, but it would make more sense to me on a UX level to just keep the buttons available and give the user a dialog to save.

I already do get the strong feeling that we should not deviate from the idea of datablock level ownership as we had planned it initially. Having the ownership information of attributes, vertex groups and such defined on the object level rather than the mesh data-block feels quite wrong to me. I also think that this is a quite elegant way of solving the pending issue with de-duplicating shared data-blocks with users from different task layers. I don't think you explained to me why you opted to go for that approach instead, would be nice to go over that in detail.

The message No new transfer data found on pull seems a bit misleading/not very intuitive imo. I would specify local.
I like how on push you show what new data will be pushed to the publish. Would be nice to do the symmetrical thing of what new data has been pulled.

And a few questions:

  • Am I correct that changing ownership is currently not possible?
  • I'm not totally up to date, but I remember not being entirely aligned with Met on this: Are the individual task layer collections currently supposed to have an actual impact in the current design, or are they more cosmetic for organisation?
  • The user preferences right now don't specify any configuration. Is it indeed fully generic up to this point or is there any type of production based configuration that can be done? Also to split up new task layers and define ownership defaults and such.
Very cool to see this taking shape! Really like how much more transparent this is already looking than what we previously had. Small Disclaimer: I haven't gone into a lot of detail with the testing yet. I simply used Met's example rig setup to get a feeling for the base functionality but I want to already give a batch of feedback and we can go from there. Later it would be good to start a character setup from scratch and go into more complicated details of potential merge conflicts. Some initial feedback: I'm not 100% sure what aspects aren't ready for feedback yet, so take it with a grain of salt. Probably not that relevant right now, but I'd stick to the file naming scheme we had. E.g. `rigging` rather than `rig`. The file contains more than just the rig, it sounds a bit misleading to me and should be rather task oriented than data oriented. There were some nice aspects of keeping the ownership as an explicit prefix for the modifier name. It makes it clear to see on first glance who owns which modifier. That is a lot more intuitive than hunting it down in the ownership Inspector and then having to remember it. Even having a context based operator to check the ownership wouldn't be as convenient and immediate as that. Additionally by engraving the prefix in the name, we avoid potential name collisions between modifiers of different task layers. This is the same issue we might have in other places as well (e.g. generic attributes), but for modifiers it is a lot more common to leave them at a default name after adding for example a `Subdivision` modifier. So name collisions can happen quite easily. The existence of the update ownership button is a bit unclear to me. Shouldn't the ownership just be updated either explicitly by the user, or automatically whenever there is an exchange between task layer and publish data? So I don't see why this button would be necessary. I guess it could make sense to have a `Validate Ownership` button that can expose conflicts which can then be resolved manually. It bothers me a bit that the push and pull buttons are always greyed out unless you just saved the file. You end up just always saving before pressing the button. Which is the intended behaviour, but it would make more sense to me on a UX level to just keep the buttons available and give the user a dialog to save. I already do get the strong feeling that we should not deviate from the idea of datablock level ownership as we had planned it initially. Having the ownership information of attributes, vertex groups and such defined on the object level rather than the mesh data-block feels quite wrong to me. I also think that this is a quite elegant way of solving the pending issue with de-duplicating shared data-blocks with users from different task layers. I don't think you explained to me why you opted to go for that approach instead, would be nice to go over that in detail. The message `No new transfer data found` on pull seems a bit misleading/not very intuitive imo. I would specify `local`. I like how on push you show what new data will be pushed to the publish. Would be nice to do the symmetrical thing of what new data has been pulled. And a few questions: - Am I correct that changing ownership is currently not possible? - I'm not totally up to date, but I remember not being entirely aligned with Met on this: Are the individual task layer collections currently supposed to have an actual impact in the current design, or are they more cosmetic for organisation? - The user preferences right now don't specify any configuration. Is it indeed fully generic up to this point or is there any type of production based configuration that can be done? Also to split up new task layers and define ownership defaults and such.
Author
Member

Hey @SimonThommes,

Thank you for your detailed feedback, I have gone ahead and updated the TODO with new tasks based on your feedback, for the simpler suggestions.

  • Replace File Names with Full Name "Rigging" instead of "RIG"
  • Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc
  • Change Message No new transfer data found to No new local transfer data found
  • Consider New Validate Ownership Feature?
  • Consider New "Preview External Transfer Data on Pull" Feature?

For things that require further discussion I have posted responses to each below

Ownership

The Update Ownership button is mainly used for testing and we will likely remove it for the final version, it is just so that a user can see what new things they own without pushing/pulling. This ownership update process also occurs automatically before Push/Pull so this button is redundant.

The idea to have a Validate Ownership button is a good idea, there is some complexity, as we need to append in the external files to read it's ownership, but it is a good feature to consider, I have added it to the TODOs to consider.

Saving

The reason we grey out the operators right now is a suggestion by met. We want the user to manually save because we need them to save their images as well as the .blend file. We are trying to take advantage of this dialogue
image

From Met:
"When texture painting, it needs to be saved explicitly before opening a new file, or it's gonna get lost. I would say don't implicitly save it on Push or Pull, but interrupt and return {'CANCELLED'} and force user to manually save their shit."

ID Level Transfer Data

To answer what I assume is the most pressing question in regards to why we didn't go for an ID-Level ownership for everything I decided to go that way mainly for simplicity for both the UI and the transfer process it self, it was a lot easier to implement, showing the user ever ID they created may be a bit confusing/overwhelming and there are more a lot more edge cases to consider if we go down that route, my main concern is that I am trying to make sure we are on time for the beginning of the next production with this add-on but I am willing to consider reverting back to the original design if met agrees with your concerns, for me it's mainly a time based thing. We can discuss this further on a call.

Show New Transfer Data on Pull

This is just a technical problem, related to the above validate ownership suggestion we would need to append in the asset to read this data before transferring which may be a lot of data to load slowing down the UI. I am willing to consider the feature, just not decided on how to achieve it yet. I have added it to the TODOs to consider.

Questions

  • Am I correct that changing ownership is currently not possible?
    • Yes, at this time there is no way to change the ownership of an item.
  • I'm not totally up to date, but I remember not being entirely aligned with Met on this: Are the individual task layer collections currently supposed to have an actual impact in the current design, or are they more cosmetic for organisation?
    • We have it set-up this way as it was simpler for reconciling the different hierarchies of collections. Otherwise if there is one big tree everyone contributes to we will need a secondary ownership system to track and adjust to changes in the collection structure. It's not clear to me how this would work, but I am open to suggestions.
  • The user preferences right now don't specify any configuration. Is it indeed fully generic up to this point or is there any type of production based configuration that can be done? Also to split up new task layers and define ownership defaults and such
    • The system is quite generic, we still need to expose the adjustable task layer to the user, users will be able to define what task layer names they want using a JSON file.
    • Ownership defaults are something that Met and I didn't think was useful, we decided this when I was at the studio, I may have forgot to mention it to you, as it's only a suggestion that the user can override anyway, it didn't seem useful enough to implement, but if there is a good reason it is quite easy to add as a feature, I just haven't been focused on it.
Hey @SimonThommes, Thank you for your detailed feedback, I have gone ahead and updated the TODO with new tasks based on your feedback, for the simpler suggestions. - [x] Replace File Names with Full Name "Rigging" instead of "RIG" - [x] Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc - [x] Change Message `No new transfer data found` to `No new local transfer data found` - [x] Consider New Validate Ownership Feature? - [x] Consider New "Preview External Transfer Data on Pull" Feature? For things that require further discussion I have posted responses to each below ### Ownership The Update Ownership button is mainly used for testing and we will likely remove it for the final version, it is just so that a user can see what new things they own without pushing/pulling. This ownership update process also occurs automatically before Push/Pull so this button is redundant. The idea to have a `Validate Ownership` button is a good idea, there is some complexity, as we need to append in the external files to read it's ownership, but it is a good feature to consider, I have added it to the TODOs to consider. ### Saving The reason we grey out the operators right now is a suggestion by met. We want the user to manually save because we need them to save their images as well as the .blend file. We are trying to take advantage of this dialogue ![image](/attachments/6d9ecb16-7f96-4b8a-b3fb-12e59ffb7492) From Met: "*When texture painting, it needs to be saved explicitly before opening a new file, or it's gonna get lost. I would say don't implicitly save it on Push or Pull, but interrupt and `return {'CANCELLED'}` and force user to manually save their shit.*" ### ID Level Transfer Data To answer what I assume is the most pressing question in regards to why we didn't go for an ID-Level ownership for everything I decided to go that way mainly for simplicity for both the UI and the transfer process it self, it was a lot easier to implement, showing the user ever ID they created may be a bit confusing/overwhelming and there are more a lot more edge cases to consider if we go down that route, my main concern is that I am trying to make sure we are on time for the beginning of the next production with this add-on but I am willing to consider reverting back to the original design if met agrees with your concerns, for me it's mainly a time based thing. We can discuss this further on a call. ### Show New Transfer Data on Pull This is just a technical problem, related to the above `validate ownership` suggestion we would need to append in the asset to read this data before transferring which may be a lot of data to load slowing down the UI. I am willing to consider the feature, just not decided on how to achieve it yet. I have added it to the TODOs to consider. ### Questions - *Am I correct that changing ownership is currently not possible?* - Yes, at this time there is no way to change the ownership of an item. - *I'm not totally up to date, but I remember not being entirely aligned with Met on this: Are the individual task layer collections currently supposed to have an actual impact in the current design, or are they more cosmetic for organisation?* - We have it set-up this way as it was simpler for reconciling the different hierarchies of collections. Otherwise if there is one big tree everyone contributes to we will need a secondary ownership system to track and adjust to changes in the collection structure. It's not clear to me how this would work, but I am open to suggestions. - *The user preferences right now don't specify any configuration. Is it indeed fully generic up to this point or is there any type of production based configuration that can be done? Also to split up new task layers and define ownership defaults and such* - The system is quite generic, we still need to expose the adjustable task layer to the user, users will be able to define what task layer names they want using a JSON file. - Ownership defaults are something that Met and I didn't think was useful, we decided this when I was at the studio, I may have forgot to mention it to you, as it's only a suggestion that the user can override anyway, it didn't seem useful enough to implement, but if there is a good reason it is quite easy to add as a feature, I just haven't been focused on it.
Member

Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc

Just to make sure that's clear. We have to pick and choose a bit here. For attributes, vertex groups and such we can't do this unfortunately, since the names actually matter (outside of API). Modifiers and Constraints are fine though

Consider New "Preview External Transfer Data on Pull" Feature?

That could be nice as well, I was mainly thinking about just a version that shows you what has been added after the fact.

The reason we grey out the operators right now is a suggestion by met. We want the user to manually save because we need them to save their images as well as the .blend file. We are trying to take advantage of this dialogue

I'm not suggesting to just silently implicitly save, I think it's good to keep that explicit. But if the buttons are basically always greyed out it kind of defeats their purpose. Is there no way to invoke that dialogue with python? That would be preferable imo.

We have it set-up this way as it was simpler for reconciling the different hierarchies of collections. Otherwise if there is one big tree everyone contributes to we will need a secondary ownership system to track and adjust to changes in the collection structure. It's not clear to me how this would work, but I am open to suggestions.

Without thinking it through in detail, I have the suspicion that datablock level ownership would also mean we can define the linking of objects to a collection as owned by the collection's owner. If we are fully generic on any level that should fit in nicely and give all the necessary flexibility if I'm not mistaken.

Ownership defaults are something that Met and I didn't think was useful, we decided this when I was at the studio, I may have forgot to mention it to you, as it's only a suggestion that the user can override anyway, it didn't seem useful enough to implement, but if there is a good reason it is quite easy to add as a feature, I just haven't been focused on it.

Maybe I'm misunderstanding something, but When an object is created by modeling, I'd personally find the need to explicitly claim ownership over material assignment, UV maps and such in the shading task layer quite tedious. Especially considering that I can't simply claim it, but it needs to be given by modeling in that case. (iirc)

> Add Prefix indicating ownership on Transfer Data like Modifiers/Constraints etc Just to make sure that's clear. We have to pick and choose a bit here. For attributes, vertex groups and such we can't do this unfortunately, since the names actually matter (outside of API). Modifiers and Constraints are fine though > Consider New "Preview External Transfer Data on Pull" Feature? That could be nice as well, I was mainly thinking about just a version that shows you what has been added after the fact. > The reason we grey out the operators right now is a suggestion by met. We want the user to manually save because we need them to save their images as well as the .blend file. We are trying to take advantage of this dialogue I'm not suggesting to just silently implicitly save, I think it's good to keep that explicit. But if the buttons are basically always greyed out it kind of defeats their purpose. Is there no way to invoke that dialogue with python? That would be preferable imo. > We have it set-up this way as it was simpler for reconciling the different hierarchies of collections. Otherwise if there is one big tree everyone contributes to we will need a secondary ownership system to track and adjust to changes in the collection structure. It's not clear to me how this would work, but I am open to suggestions. Without thinking it through in detail, I have the suspicion that datablock level ownership would also mean we can define the linking of objects to a collection as owned by the collection's owner. If we are fully generic on any level that should fit in nicely and give all the necessary flexibility if I'm not mistaken. > Ownership defaults are something that Met and I didn't think was useful, we decided this when I was at the studio, I may have forgot to mention it to you, as it's only a suggestion that the user can override anyway, it didn't seem useful enough to implement, but if there is a good reason it is quite easy to add as a feature, I just haven't been focused on it. Maybe I'm misunderstanding something, but When an object is created by modeling, I'd personally find the need to explicitly claim ownership over material assignment, UV maps and such in the shading task layer quite tedious. Especially considering that I can't simply claim it, but it needs to be given by modeling in that case. (iirc)
Nick Alberelli added 1 commit 2023-09-28 17:45:32 +02:00
Nick Alberelli added 1 commit 2023-09-28 17:50:57 +02:00
Nick Alberelli added 1 commit 2023-09-28 18:43:23 +02:00
Nick Alberelli added 2 commits 2023-09-28 19:14:20 +02:00
Nick Alberelli added 1 commit 2023-09-28 20:01:24 +02:00
Nick Alberelli added 1 commit 2023-09-28 21:09:18 +02:00
Nick Alberelli added 1 commit 2023-09-28 23:22:23 +02:00
Nick Alberelli added 3 commits 2023-09-29 17:56:38 +02:00
Nick Alberelli added 1 commit 2023-09-29 18:24:49 +02:00
Nick Alberelli added 3 commits 2023-09-30 21:29:20 +02:00
Nick Alberelli added 1 commit 2023-09-30 21:55:29 +02:00
Nick Alberelli added 1 commit 2023-09-30 22:10:46 +02:00
Nick Alberelli added 1 commit 2023-10-01 00:01:45 +02:00
Author
Member

Glad we were able to settle most of the above discussion on a call @SimonThommes, looking forward to our next call with @Mets and I will continue to update the TODO section with the changes we discuss.

Below I have a quick demo video to document where the add-on currently stands.

Asset Pipeline Demo

Glad we were able to settle most of the above discussion on a call @SimonThommes, looking forward to our next call with @Mets and I will continue to update the TODO section with the changes we discuss. Below I have a quick demo video to document where the add-on currently stands. ## Asset Pipeline Demo <video src="/attachments/a064d3d8-475c-4520-a657-b4f78f3e523d" title="Asset_Pipeline_Demo_v1 (2).mp4" controls></video>
Member

I watched your demo and have some additional feedback. Beyond the things that we've already been discussing this mainly just brings up questions about the asset initialization process.
Some of these things are mainly low priority design topics, as they are not a hard requirement to work with the addon.

  • Initializing the asset removes all local data? How do I initialize the asset with existing data? I don't necessarily think that we should assume that we always create asset file structure first
  • Predefining the collection structure should give way to dynamic collection ownership including object linking
  • Not all files will be necessary for most assets like small props. The previous system supported dynamically switching between owning individual task layers from one file. The working files should not be created redundantly, but when they are needed. Imo the initialization should only create the subfolders and an empty asset collection.

Some additional topics I had to think of:

  • We previously talked about attaching some meta-data to the main asset collection, to create some association with kitsu and also more easily/clearly identify asset collections in shot files.
  • Did we already talk about the integration of assets into the asset browser? Only the latest publish version of an asset should show up in the asset browser. Linking assets only using the asset browser (besides the shot builder) would also avoid people linking to working files, which shouldn't ever happen.
  • On a related note: We also talked about being able to define custom task layers more on-the-fly like such that could just link a collection and remap dependencies for a sub-set of an environment for example. For those you'd need to deviate from the rigid file structure as well.
I watched your demo and have some additional feedback. Beyond the things that we've already been discussing this mainly just brings up questions about the asset initialization process. Some of these things are mainly low priority design topics, as they are not a hard requirement to work with the addon. - Initializing the asset removes all local data? How do I initialize the asset with existing data? I don't necessarily think that we should assume that we always create asset file structure first - Predefining the collection structure should give way to dynamic collection ownership including object linking - Not all files will be necessary for most assets like small props. The previous system supported dynamically switching between owning individual task layers from one file. The working files should not be created redundantly, but when they are needed. Imo the initialization should only create the subfolders and an empty asset collection. Some additional topics I had to think of: - We previously talked about attaching some meta-data to the main asset collection, to create some association with kitsu and also more easily/clearly identify asset collections in shot files. - Did we already talk about the integration of assets into the asset browser? Only the latest publish version of an asset should show up in the asset browser. Linking assets only using the asset browser (besides the shot builder) would also avoid people linking to working files, which shouldn't ever happen. - On a related note: We also talked about being able to define custom task layers more on-the-fly like such that could just link a collection and remap dependencies for a sub-set of an environment for example. For those you'd need to deviate from the rigid file structure as well.
Author
Member

Glad we covered these topics in a call, I have updated the TODO with all the points we discussed, I will tag you when the next demo is ready!

Glad we covered these topics in a call, I have updated the TODO with all the points we discussed, I will tag you when the next demo is ready!
Member

Couple of solution proposals.


Multiple Task Layers in a Single File

  • scene.task_layer_name is changed to a CollectionProperty that gets populated by the Initialize operator. There's an entry for all task layers that are in the current config, and each entry has a boolean for enabled state. (Allow re-ordering this list!)
  • Each TransferableData can be optionally configured a default task layer, eg. Vertex Groups->Rigging, UV Maps->Shading.

When adding new data:

  • If this file only has one enabled TaskLayer, just assign that as the owner.
  • If it has multiple, and one of them is the default for this kind of data, use that.
  • If it has multiple, and none of them are the default for this kind of data, use the first enabled one.

Surrendering Ownership

At first I thought of a hard-coded task layer type which is "All", but that runs into issues with removal being difficult.

Let's indeed go with a boolean like you guys were saying. I think it works fine. Each ownership info has this is_surrendered bool. Then we can differentiate data that is undergoing an ownership change from other data, which should be all we need to enable an ownership change workflow.

So, it could go something like this:

  • Asset is under development, Modeling artist wants/needs to surrender Subsurf modifiers to Rigging.
  • Set is_surrendered flag of Subsurf modifiers to True and push.
  • Pull into rigging. the flag gets pulled in.
  • Set ownership of Subsurf modifiers to "Rigging". This automatically clears the is_surrendered flag with the update() callback. Then push.
  • On push, we should run into a conflict; The same data is owned by both source and target. But one of them has is_surrendered==True, so we can resolve the conflict, and that one loses. Let's call this a "soft-conflict".
  • Pull into modeling. Same deal; There's a conflict between source and target, but the flag resolves the conflict, so in the end the modifiers are owned by Rigging.
  • Ownership transfer is complete.

Other cases:

  • Unclaimed surrendered data should work the same as before; It still has an owner, so that owner can modify and remove it. If nobody claims it, it's not a problem.
  • Since it still has an owner, the owner can clear the is_surrendered flag too, to un-surrender it.

Stupid case:

  • If there's a conflict and both flags are set to True, it's still a conflict, should result in an error just the same as if both flags were False. This should never happen intentionally in the first place, must be a mistake on user's end.

So in my head this is a very small amount of code; The flag bool, some UI for that flag, an update() callback on the ownership enum/string, and an if statement somewhere in the source/target mapping, or wherever conflicts are currently checked for.

Couple of solution proposals. ---------------------------- > Multiple Task Layers in a Single File - `scene.task_layer_name` is changed to a CollectionProperty that gets populated by the Initialize operator. There's an entry for all task layers that are in the current config, and each entry has a boolean for enabled state. (Allow re-ordering this list!) - Each TransferableData can be optionally configured a default task layer, eg. `Vertex Groups->Rigging`, `UV Maps->Shading`. When adding new data: - If this file only has one enabled TaskLayer, just assign that as the owner. - If it has multiple, and one of them is the default for this kind of data, use that. - If it has multiple, and none of them are the default for this kind of data, use the first enabled one. --------------------------- > Surrendering Ownership At first I thought of a hard-coded task layer type which is "All", but that runs into issues with removal being difficult. Let's indeed go with a boolean like you guys were saying. I think it works fine. Each ownership info has this `is_surrendered` bool. Then we can differentiate data that is undergoing an ownership change from other data, which should be all we need to enable an ownership change workflow. So, it could go something like this: - Asset is under development, Modeling artist wants/needs to surrender Subsurf modifiers to Rigging. - Set `is_surrendered` flag of Subsurf modifiers to `True` and push. - Pull into rigging. the flag gets pulled in. - Set ownership of Subsurf modifiers to "Rigging". This automatically clears the `is_surrendered` flag with the `update()` callback. Then push. - On push, we should run into a conflict; The same data is owned by both source and target. But one of them has `is_surrendered==True`, so we can resolve the conflict, and that one loses. Let's call this a "soft-conflict". - Pull into modeling. Same deal; There's a conflict between source and target, but the flag resolves the conflict, so in the end the modifiers are owned by Rigging. - Ownership transfer is complete. Other cases: - Unclaimed surrendered data should work the same as before; It still has an owner, so that owner can modify and remove it. If nobody claims it, it's not a problem. - Since it still has an owner, the owner can clear the is_surrendered flag too, to un-surrender it. Stupid case: - If there's a conflict and both flags are set to True, it's still a conflict, should result in an error just the same as if both flags were False. This should never happen intentionally in the first place, must be a mistake on user's end. So in my head this is a very small amount of code; The flag bool, some UI for that flag, an update() callback on the ownership enum/string, and an if statement somewhere in the source/target mapping, or wherever conflicts are currently checked for.
Nick Alberelli added 15 commits 2023-10-03 19:52:36 +02:00
Nick Alberelli added 1 commit 2023-10-03 19:57:50 +02:00
Member

@Mets just to clarify: The solution for the ownership surrendering that you're proposing is the fancier method, which we put on low prio, right?

(also, shouldn't that flag be invisible to the user? It can bet set and cleared automatically as part of the merge process. If everything works the user shouldn't have to set it. Just change the ownership of some data you own to something else and the rest should happen automatically, right?)

@Mets just to clarify: The solution for the ownership surrendering that you're proposing is the fancier method, which we put on low prio, right? (also, shouldn't that flag be invisible to the user? It can bet set and cleared automatically as part of the merge process. If everything works the user shouldn't have to set it. Just change the ownership of some data you own to something else and the rest should happen automatically, right?)
Nick Alberelli added 3 commits 2023-10-03 22:56:14 +02:00
Nick Alberelli added 1 commit 2023-10-03 23:22:26 +02:00
Author
Member

Hey guys so here is a new demo here is what's changed... @SimonThommes @Mets

  • Creating Files

    • When creating new assets we keep the existing data in your blend file
    • We don't cerate default collections anymore
    • Select Custom Task Layer during File Creating
    • Select how many task layers in current file
  • Collections now can be assigned to a task layer by user (Top Level children of asset collection only)

  • Custom Task Layers

    • Added Custom Task Layers
    • Added an option to add additional custom task layers defined by user
  • Ownership Defaults

    • If this file only has one enabled TaskLayer, just assign that as the owner.
    • If it has multiple, and one of them is the default for this kind of data, use that.
    • If it has multiple, and none of them are the default for this kind of data, use the first enabled one.
  • Multiple Task Layers Per File

    • Add-On now supports multiple task layers per file
    • Drop down included on all data to select local task layer as owner

Note: I still haven't made material ownership a property that exists even if there are no slots, that is being added as a seperate TODO. Please let me know ur feedback on the current state of things, might be good to have a debrief call to get feedback on these existing changes so I can note down my next steps.

Asset Pipeline Demo

Hey guys so here is a new demo here is what's changed... @SimonThommes @Mets * Creating Files * When creating new assets we keep the existing data in your blend file * We don't cerate default collections anymore * Select Custom Task Layer during File Creating * Select how many task layers in current file * Collections now can be assigned to a task layer by user *(Top Level children of asset collection only)* * Custom Task Layers * Added Custom Task Layers * Added an option to add additional custom task layers defined by user * Ownership Defaults * If this file only has one enabled TaskLayer, just assign that as the owner. * If it has multiple, and one of them is the default for this kind of data, use that. * If it has multiple, and none of them are the default for this kind of data, use the first enabled one. * Multiple Task Layers Per File * Add-On now supports multiple task layers per file * Drop down included on all data to select local task layer as owner ***Note: I still haven't made material ownership a property that exists even if there are no slots, that is being added as a seperate TODO. Please let me know ur feedback on the current state of things, might be good to have a debrief call to get feedback on these existing changes so I can note down my next steps.*** ## Asset Pipeline Demo <video src="/attachments/e3916690-b705-484d-a7fb-a69e9b383efe" title="Asset_Pipeline_Demo_v2.mp4" controls></video>
Member

The solution for the ownership surrendering that you're proposing is the fancier method, which we put on low prio, right?

I think maybe during the meeting we thought we needed a fancier solution, but I'd say this ends up being quite non-fancy, while also covering all we need, so I'd say we can nuke the TODO entry from the low prio set, and keep the other one? Having two feels redundant now that I have a clear idea of how it could potentially work.

In my proposal you can't change data's ownership to a task layer that you don't own, you can only put it "up for grabs". I think this results in fewer potentially confusing cases.

For example, if you could set the ownership of some data to another task layer which you don't own, you can also undo that, which makes it appear like you can take ownership of some data you don't own. But that won't work on other data, it only works on this because of a hidden flag that got automagically set previously. And if that happened a long time ago, it won't be clear in the UI why one piece of data is behaving differently than another.

Asset Pipeline Demo

Looks great!
I guess for assigning attribute defaults, the name must match exactly atm, so something like "UVMap.001" won't work anyways... But solving that would probably be quite a hassle. I think it would involve breaking up attributes to separate data types for UVMaps, Vertex Colors, etc, and everything else. Maybe something for the far future / low prio list.

> The solution for the ownership surrendering that you're proposing is the fancier method, which we put on low prio, right? I think maybe during the meeting we thought we needed a fancier solution, but I'd say this ends up being quite non-fancy, while also covering all we need, so I'd say we can nuke the TODO entry from the low prio set, and keep the other one? Having two feels redundant now that I have a clear idea of how it could potentially work. In my proposal you can't change data's ownership to a task layer that you don't own, you can only put it "up for grabs". I think this results in fewer potentially confusing cases. For example, if you could set the ownership of some data to another task layer which you don't own, you can also undo that, which makes it appear like you can take ownership of some data you don't own. But that won't work on other data, it only works on this because of a hidden flag that got automagically set previously. And if that happened a long time ago, it won't be clear in the UI why one piece of data is behaving differently than another. > Asset Pipeline Demo Looks great! I guess for assigning attribute defaults, the name must match exactly atm, so something like "UVMap.001" won't work anyways... But solving that would probably be quite a hassle. I think it would involve breaking up attributes to separate data types for UVMaps, Vertex Colors, etc, and everything else. Maybe something for the far future / low prio list.
Author
Member

Asset Pipeline Demo

Looks great!
How does default ownership work with attributes though, is it just based on the name of the attribute? Then "UVMap.001" wouldn't get auto-assigned to shading anyways, since it doesn't match "UVMap"? Not too sure how to solve this yet though, but maybe you already did somehow.

We are just using the names of the attributes for the special attribute ownership defined in the JSON file.

    DEFAULT_OWNERSHIP_ATTRIBUTES: {
        "sharp_face": "Modeling",
        "UVMap": "Shading"
    }

So in theory you can mess this up if you create a new object, then rename the UVMap before updating the ownership it won't be assigned to 'Shading' just whatever the general attribute default is, which is "Rigging" in the default character JSON.

> > Asset Pipeline Demo > > Looks great! > How does default ownership work with attributes though, is it just based on the name of the attribute? Then "UVMap.001" wouldn't get auto-assigned to shading anyways, since it doesn't match "UVMap"? Not too sure how to solve this yet though, but maybe you already did somehow. We are just using the names of the attributes for the special attribute ownership defined in the JSON file. ```Python DEFAULT_OWNERSHIP_ATTRIBUTES: { "sharp_face": "Modeling", "UVMap": "Shading" } ``` So in theory you can mess this up if you create a new object, then rename the UVMap before updating the ownership it won't be assigned to 'Shading' just whatever the general attribute default is, which is "Rigging" in the default character JSON.
Nick Alberelli added 1 commit 2023-10-17 22:59:13 +02:00
Author
Member

Hey guys another update here, so I will need feedback on the previous update plus this one in our next feedback session.

I have set material ownership to work how we planned so it now always gets assigned to the default task layer even if there are no materials yet assigned.

I'll be honest, I don't love this behaviour I think it makes this a little confusing and it's just another thing to explain, but im happy to do it as you both agree this is something you want.

Material Ownership Demo

Hey guys another update here, so I will need feedback on the previous update plus this one in our next feedback session. I have set material ownership to work how we planned so it now always gets assigned to the default task layer even if there are no materials yet assigned. _I'll be honest, I don't love this behaviour I think it makes this a little confusing and it's just another thing to explain, but im happy to do it as you both agree this is something you want._ ## Material Ownership Demo <video src="/attachments/e52f19d8-df3c-456a-8a3f-de9fb0a76378" title="material_ownership_update.mp4" controls></video>
Member

So, IIRC, the initial problem we're trying to solve is that "Material Data", unlike other transferable data, includes not only list elements, which don't always exist, but also properties, which do always exist, and therefore would need to be owned by somebody. The same could be said for "Parenting Data", since the parent pointer and parent type are also properties.

So, the problem boils down to "when do we define ownership data when that ownership data includes properties".

I agree the current solution can be confusing and clutters the UI, but I would be fine with it if it could be implemented it in such a way that it's configurable at a production level, rather than hard baked into the add-on.

Alternatively or on top of that, we could also implement a lazy-initialization pattern for such ownership data, where we check whether the relevant properties are on their default values, and only create ownership data for them when that is not the case.

So for example, if I change the Auto-Smooth settings, or the Object Color, then ownership data for Materials gets created even if there are no materials yet.
The default value of an RNA property can be accessed like this btw:
bpy.types.Mesh.bl_rna.properties['use_auto_smooth'].default

So, IIRC, the initial problem we're trying to solve is that "Material Data", unlike other transferable data, includes not only list elements, which don't always exist, but also properties, which do always exist, and therefore would need to be owned by somebody. The same could be said for "Parenting Data", since the parent pointer and parent type are also properties. So, the problem boils down to "when do we define ownership data when that ownership data includes properties". I agree the current solution can be confusing and clutters the UI, but I would be fine with it if it could be implemented it in such a way that it's configurable at a production level, rather than hard baked into the add-on. Alternatively or on top of that, we could also implement a [lazy-initialization](https://en.wikipedia.org/wiki/Lazy_initialization) pattern for such ownership data, where we check whether the relevant properties are on their default values, and only create ownership data for them when that is not the case. So for example, if I change the Auto-Smooth settings, or the Object Color, then ownership data for Materials gets created even if there are no materials yet. The default value of an RNA property can be accessed like this btw: `bpy.types.Mesh.bl_rna.properties['use_auto_smooth'].default`
Nick Alberelli added 2 commits 2023-10-18 22:19:11 +02:00
Nick Alberelli added 1 commit 2023-10-19 17:56:51 +02:00
Member

Some feedback on the current version according to what we talked about:

UI:

  • ownership overview collapsable
  • stylized task layer prefix (SH, RIG, C02)
  • use new naming and notation conventions (. -> -)
  • Material Slot -> Material Slots / Material Assignments / Materials (?)
  • Same of others (e.g. Modifier -> Modifiers)

Other:

  • ownership transfer ?
  • file task layer change
    • eventually have some overview of what file owns what task layer to add warnings for collision
  • Auto-Prefixing not working properly
  • resetting ownership on duplicated object (?)
  • Problem: Datablock sharing. Since data layer ownership is specified per object this creates collision on mesh level, where ownership is not clearly defined
  • reverting to temp on pull /error
Some feedback on the current version according to what we talked about: UI: - ownership overview collapsable - stylized task layer prefix (SH, RIG, C02) - use new naming and notation conventions (`.` -> `-`) - Material Slot -> Material Slots / Material Assignments / Materials (?) - Same of others (e.g. Modifier -> Modifiers) Other: - ownership transfer ? - file task layer change - eventually have some overview of what file owns what task layer to add warnings for collision - Auto-Prefixing not working properly - resetting ownership on duplicated object (?) - Problem: Datablock sharing. Since data layer ownership is specified per object this creates collision on mesh level, where ownership is not clearly defined - reverting to temp on pull /error
Nick Alberelli added 2 commits 2023-11-08 16:42:59 +01:00
Nick Alberelli added 1 commit 2023-11-08 16:45:24 +01:00
Nick Alberelli added 1 commit 2023-11-08 17:04:42 +01:00
Nick Alberelli added 1 commit 2023-11-08 17:54:33 +01:00
Nick Alberelli added 1 commit 2023-11-08 18:06:55 +01:00
Nick Alberelli added 2 commits 2023-11-08 18:16:54 +01:00
Nick Alberelli added 1 commit 2023-11-08 18:27:58 +01:00
Nick Alberelli added 2 commits 2023-11-08 19:22:22 +01:00
Nick Alberelli added 1 commit 2023-11-08 19:25:30 +01:00
Nick Alberelli added 1 commit 2023-11-08 20:07:53 +01:00
Nick Alberelli added 1 commit 2023-11-08 22:06:41 +01:00
Nick Alberelli added 2 commits 2023-11-08 23:00:15 +01:00
Nick Alberelli added 3 commits 2023-11-09 00:22:12 +01:00
Nick Alberelli added 1 commit 2023-11-09 00:48:15 +01:00
Author
Member

Ok here is another update, I didn't tackle the ownership surrendering, but I will be starting on that tomorrow.

One important issue @Mets that we need to handle is a bug in 4.0 where Vertex Group transfer fails, this only happens on push when we change the context to another file. May need your help debugging this. I think we should resolve that before we move onto non-topo matching transfer.

The demo mainly covers things that I discussed with @SimonThommes as new features and fixes to little paper cuts.

Various Updates Demo

The Changes are as follows...

  • Collapsible Transfer Data UI
  • Plural New Transfer Data Names
  • Add Reset Transfer Data Operator
  • Add UI/Operator to change Local Task Layers
  • Prefix Added to JSON File
  • Add Operator to Fix Prefixes
  • Error Message for Multi User Meshes
  • New Revert Button in Advanced Menu
  • New Revert UI if Pull/Push Fails
Ok here is another update, I didn't tackle the ownership surrendering, but I will be starting on that tomorrow. One important issue @Mets that we need to handle is a bug in 4.0 where Vertex Group transfer fails, this only happens on push when we change the context to another file. May need your help debugging this. I think we should resolve that before we move onto non-topo matching transfer. The demo mainly covers things that I discussed with @SimonThommes as new features and fixes to little paper cuts. ## Various Updates Demo <video src="/attachments/45ff42bf-52a1-44a2-9727-4a07871aba75" title="Nov8-Asset-Pipe-2-Demo0000-11494.mp4" controls></video> The Changes are as follows... - Collapsible Transfer Data UI - Plural New Transfer Data Names - Add Reset Transfer Data Operator - Add UI/Operator to change Local Task Layers - Prefix Added to JSON File - Add Operator to Fix Prefixes - Error Message for Multi User Meshes - New Revert Button in Advanced Menu - New Revert UI if Pull/Push Fails
Member

Awesome! These changes add a lot in terms of UI/UX!

Since the name prefixes are only a visual thing and not actually used for the merge process, shouldn't this also just happen on push/pull (whenever ownership is being validated/updated). I don't really see myself pressing this button ever, if it isn't required for the merge process to work properly.

Everything else I have no comments on, looking good 👍

Awesome! These changes add a lot in terms of UI/UX! Since the name prefixes are only a visual thing and not actually used for the merge process, shouldn't this also just happen on push/pull (whenever ownership is being validated/updated). I don't really see myself pressing this button ever, if it isn't required for the merge process to work properly. Everything else I have no comments on, looking good 👍
Nick Alberelli added 4 commits 2023-11-10 00:18:48 +01:00
Nick Alberelli added 2 commits 2023-11-10 00:41:48 +01:00
- Also Move `data_type_from_transfer_data_key` to util to avoid circular import
Nick Alberelli added 1 commit 2023-11-10 00:58:15 +01:00
Nick Alberelli added 1 commit 2023-11-10 00:59:28 +01:00
Nick Alberelli added 2 commits 2023-11-10 01:08:51 +01:00
Nick Alberelli added 2 commits 2023-11-10 01:35:37 +01:00
Nick Alberelli added 1 commit 2023-11-10 01:40:21 +01:00
Nick Alberelli added 1 commit 2023-11-10 02:15:37 +01:00
Nick Alberelli added 2 commits 2023-11-10 19:54:54 +01:00
Author
Member

Thank you for the feedback @SimonThommes I have added a TODO to update Prefixes during the merge process.
See the task under Medium priority Update Prefix during Merge Process

In this update I have for @Mets mainly, I have completed the work for the surrender ownership button, as a proper feature considered in the merge process, Surrendering Ownership Operator/UI. Below I have a demo of that feature...

Surrender Ownership Demo

Thank you for the feedback @SimonThommes I have added a TODO to update Prefixes during the merge process. See the task under Medium priority `Update Prefix during Merge Process` In this update I have for @Mets mainly, I have completed the work for the surrender ownership button, as a proper feature considered in the merge process, `Surrendering Ownership Operator/UI`. Below I have a demo of that feature... ### Surrender Ownership Demo <video src="/attachments/a7a10d08-4efb-48e7-a28b-46a06c5d3e23" title="2023-11-10 13-49-14.mp4" controls></video>
Nick Alberelli added 1 commit 2023-11-10 22:41:27 +01:00
Author
Member

@Mets thank you for sending me that vertex transfer code from easy weights, I implemented it in this commit 019c610f78 now we have vertex transfer working again, and it works for non -matching topology so thats two more TODOs cleared!

@Mets thank you for sending me that vertex transfer code from easy weights, I implemented it in this commit https://projects.blender.org/studio/blender-studio-pipeline/commit/019c610f7830e102294f4a44ccfd96509bf0475a now we have vertex transfer working again, and it works for non -matching topology so thats two more TODOs cleared!
Nick Alberelli added 1 commit 2023-11-13 17:29:32 +01:00
- Ensure only ony vertex group is transferred via `precalc_and_transfer_single_group()`

 - Add Debug TODO because this code doesn't appear to be working on a single vertex transfer
Nick Alberelli added 1 commit 2023-11-13 18:25:16 +01:00
Nick Alberelli added 1 commit 2023-11-13 21:05:00 +01:00
Nick Alberelli added 1 commit 2023-11-13 22:09:11 +01:00
Nick Alberelli added 3 commits 2023-11-13 22:36:53 +01:00
Nick Alberelli added 1 commit 2023-11-13 23:54:51 +01:00
Nick Alberelli added 2 commits 2023-11-14 00:10:54 +01:00
Nick Alberelli added 1 commit 2023-11-14 00:12:04 +01:00
Nick Alberelli added 1 commit 2023-11-14 00:18:22 +01:00
Nick Alberelli added 1 commit 2023-11-14 01:12:35 +01:00
Author
Member

Hey @Mets we have batch operations now, you can use it to surrender the ownership of objects or transfer data, I have added some filtering for this

Batch Operator Filters

  • Selected or All Objects
  • Ownership Status (Locally Owned, Owned by Anyone, No Filter)
  • Transfer Data Type (transfer data mode only)
  • Object/Transfer Data by Name

You can batch update the ownership to both a local task layer and all task layers (use all option with care)

Batch Operator Demo

@SimonThommes I have added a commit 4a110ca68e so prefixes will now be updated before the merge process begins as requested in this comment studio/blender-studio-pipeline#145 (comment)

Hey @Mets we have batch operations now, you can use it to surrender the ownership of objects or transfer data, I have added some filtering for this Batch Operator Filters - Selected or All Objects - Ownership Status (Locally Owned, Owned by Anyone, No Filter) - Transfer Data Type (transfer data mode only) - Object/Transfer Data by Name You can batch update the ownership to both a local task layer and all task layers (use all option with care) ### Batch Operator Demo <video src="/attachments/0004e379-4697-4018-9905-5f6a524e7073" title="2023-11-13 19-24-16.mkv" controls></video> @SimonThommes I have added a commit https://projects.blender.org/studio/blender-studio-pipeline/commit/4a110ca68e0aa4028a7c5293b663d90b8be2aa24 so prefixes will now be updated before the merge process begins as requested in this comment https://projects.blender.org/studio/blender-studio-pipeline/pulls/145#issuecomment-1060872
Member

Great work, mate. I think now we can start working on assets without stressing too much about what ownerships we assign when, since we'll be able to relatively easily change ownership of things later. Just some minor UI suggestions:

Surrender:

  • Don't hide Surrender checkbox when the assigned task layer is still one of the local task layers.

Batch Op:

  • "Batch Ownership" -> "Batch Set Ownership"
  • "If Owned" -> "If Owned By Any"
  • "Transfer Data" -> "Transferable Data"
  • Add a label at the top: "Filters:"
  • Add a separator and a label after the filters: "Set To:"
Great work, mate. I think now we can start working on assets without stressing too much about what ownerships we assign when, since we'll be able to relatively easily change ownership of things later. Just some minor UI suggestions: Surrender: - Don't hide Surrender checkbox when the assigned task layer is still one of the local task layers. Batch Op: - "Batch Ownership" -> "Batch Set Ownership" - "If Owned" -> "If Owned By Any" - "Transfer Data" -> "Transferable Data" - Add a label at the top: "Filters:" - Add a separator and a label after the filters: "Set To:"
Nick Alberelli added 1 commit 2023-11-14 18:01:37 +01:00
Nick Alberelli added 3 commits 2023-11-14 19:57:04 +01:00
Author
Member

@Mets I have updated the batch operator UI per your notes here and on the call we had

image

@Mets I have updated the batch operator UI per your notes here and on the call we had ![image](/attachments/98d179cb-cdfa-4e7a-9264-fdb3805f067c)
Nick Alberelli added 2 commits 2023-11-14 20:12:28 +01:00
Nick Alberelli added 3 commits 2023-11-14 20:45:13 +01:00
Nick Alberelli added 1 commit 2023-11-14 20:48:47 +01:00
Nick Alberelli added 2 commits 2023-11-14 20:55:33 +01:00
Nick Alberelli added 2 commits 2023-11-14 21:46:07 +01:00
Nick Alberelli added 2 commits 2023-11-14 22:15:22 +01:00
Nick Alberelli added 1 commit 2023-11-14 22:18:16 +01:00
Member

@Mets I have updated the batch operator UI per your notes here and on the call we had

My eyeballs flow peacefully from top to bottom. <3

> @Mets I have updated the batch operator UI per your notes here and on the call we had My eyeballs flow peacefully from top to bottom. <3
Demeter Dzadik added 2 commits 2023-11-16 16:26:29 +01:00
Nick Alberelli added 1 commit 2023-11-16 17:29:50 +01:00
Nick Alberelli added 1 commit 2023-11-16 18:02:11 +01:00
Nick Alberelli added 1 commit 2023-11-16 18:49:19 +01:00
Nick Alberelli added 1 commit 2023-11-16 18:59:52 +01:00
Nick Alberelli added 1 commit 2023-11-16 20:37:44 +01:00
Nick Alberelli added 1 commit 2023-11-16 21:34:21 +01:00
Nick Alberelli added 1 commit 2023-11-16 21:40:58 +01:00
Nick Alberelli added 1 commit 2023-11-16 21:47:45 +01:00
Nick Alberelli added 1 commit 2023-11-16 21:55:14 +01:00
Author
Member

@Mets As we discussed I have updated the Create New Asset Operator to optionally re-use the current directory/file and keep the assets from that file or create a new directory with a blank file.

image

Also I found a bug that is now possible based on some things we changes..

The Change was: We only remove orphan objects under the top level collection

The Bug: Now (this is case for Mikassa) if you parent object is outside the asset (which use to be invalid), the parent relationship will break down during sync, we need to consider this in the parent relationship trasnfer data property, and return an error if the parent object is outside the asset col or go back to all objects needing to be part of the asset col.

@Mets As we discussed I have updated the `Create New Asset` Operator to optionally re-use the current directory/file and keep the assets from that file or create a new directory with a blank file. ![image](/attachments/8a8b0687-89a2-43f4-9e29-68cccd9b387f) Also I found a bug that is now possible based on some things we changes.. The Change was: We only remove orphan objects under the top level collection The Bug: Now (this is case for Mikassa) if you parent object is outside the asset (which use to be invalid), the parent relationship will break down during sync, we need to consider this in the parent relationship trasnfer data property, and return an error if the parent object is outside the asset col or go back to all objects needing to be part of the asset col.
Demeter Dzadik added 2 commits 2023-11-17 16:09:58 +01:00
This also required shuffling some other things, like passing
asset_pipe to get_task_layer_objects & get_transfer_data_owner.

Would like to move more functions to the asset_pipeline PropertyGroup,
wherever it may make sense.
Nick Alberelli added 1 commit 2023-11-17 20:05:59 +01:00
Nick Alberelli added 1 commit 2023-11-17 20:18:23 +01:00
Nick Alberelli added 3 commits 2023-11-20 20:13:12 +01:00
Author
Member

Hey @Mets @SimonThommes here is the new UI we discussed for the surrendered data.

The heart icon now indicated if the data is surrendered or not. We also have the claim button, renamed from update surrendered.

image

Hey @Mets @SimonThommes here is the new UI we discussed for the surrendered data. The heart icon now indicated if the data is surrendered or not. We also have the claim button, renamed from update surrendered. ![image](/attachments/a2b94a1a-3aca-4d9f-9aae-d0ed09006170)
Nick Alberelli added 1 commit 2023-11-20 22:57:10 +01:00
Nick Alberelli added 1 commit 2023-11-20 23:05:50 +01:00
Nick Alberelli added 1 commit 2023-11-20 23:34:42 +01:00
Nick Alberelli added 1 commit 2023-11-20 23:41:58 +01:00
Nick Alberelli added 1 commit 2023-11-20 23:42:29 +01:00
Nick Alberelli added 1 commit 2023-11-20 23:54:16 +01:00
Nick Alberelli added 1 commit 2023-11-21 00:26:19 +01:00
Nick Alberelli added 1 commit 2023-11-21 00:28:34 +01:00
Author
Member

@Mets @SimonThommes to recap our last discussion, in addition to the UI updates I completed above we also discussed removing the Default Ownership feature and replacing it with the ability to auto surrender some transfer data items when they are created (configurable via JSON). I have added that functionality, demo is below.

Auto Surrender Demo

@Mets @SimonThommes to recap our last discussion, in addition to the UI updates I completed [above](https://projects.blender.org/studio/blender-studio-pipeline/pulls/145#issuecomment-1068215) we also discussed removing the `Default Ownership` feature and replacing it with the ability to `auto surrender` some transfer data items when they are created (configurable via JSON). I have added that functionality, demo is below. ### Auto Surrender Demo <video src="/attachments/064694d5-99ae-407f-b16f-0ca6620376dc" title="2023-11-20 18-37-23.mkv" controls></video>
Demeter Dzadik added 1 commit 2023-11-21 12:52:28 +01:00
Nick Alberelli added 1 commit 2023-11-21 21:11:17 +01:00
Demeter Dzadik added 1 commit 2023-11-22 15:44:50 +01:00
Nick Alberelli added 1 commit 2023-11-22 22:21:52 +01:00
Nick Alberelli added 1 commit 2023-11-22 23:20:18 +01:00
Nick Alberelli added 1 commit 2023-11-23 00:01:35 +01:00
Nick Alberelli added 1 commit 2023-11-23 17:06:35 +01:00
Nick Alberelli added 1 commit 2023-11-23 17:23:01 +01:00
Nick Alberelli added 2 commits 2023-11-23 18:04:45 +01:00
Nick Alberelli added 1 commit 2023-11-23 18:05:34 +01:00
Nick Alberelli added 1 commit 2023-11-23 18:06:26 +01:00
Nick Alberelli added 1 commit 2023-11-23 18:31:02 +01:00
Nick Alberelli added 5 commits 2023-11-23 19:48:10 +01:00
Nick Alberelli added 1 commit 2023-11-23 20:18:19 +01:00
Nick Alberelli added 1 commit 2023-11-23 20:21:31 +01:00
Nick Alberelli added 1 commit 2023-11-24 17:07:11 +01:00
- Published file has asset collection marked as asset
 - When Published col is loaded as external col, it remains marked as asset and doesn't purge
 - Non Published col are also not marked as asset so it is safe to always remove asset mark from any external col
Nick Alberelli added 1 commit 2023-11-24 17:43:21 +01:00
Nick Alberelli added 1 commit 2023-11-24 17:47:47 +01:00
Nick Alberelli added 1 commit 2023-11-24 18:48:44 +01:00
Nick Alberelli added 1 commit 2023-11-24 19:00:37 +01:00
Nick Alberelli added 1 commit 2023-11-24 19:02:22 +01:00
This reverts commit ea6002dc1a.

Reverting this commit because for some reason it appeared to be causing crashes when interacting with Task Layer Preset selector
Nick Alberelli added 1 commit 2023-11-24 20:20:56 +01:00
Nick Alberelli added 1 commit 2023-11-24 20:26:19 +01:00
Nick Alberelli changed title from WIP: Asset Pipeline 2 to Asset Pipeline v2 2023-11-24 20:45:19 +01:00
Author
Member

Closed by 1af2d41bdc

Tracking for incomplete TODOs at studio/blender-studio-pipeline#170

Closed by https://projects.blender.org/studio/blender-studio-pipeline/commit/1af2d41bdc71c414c17568bbf8162b99d47b5a64 Tracking for incomplete TODOs at https://projects.blender.org/studio/blender-studio-pipeline/issues/170
Nick Alberelli closed this pull request 2023-11-24 20:54:23 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
3 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: studio/blender-studio-tools#145
No description provided.