Asset Pipeline: Improvements and Fixes #170
Labels
No Label
Kind
Breaking
Kind
Bug
Kind: Community
Kind
Documentation
Kind
Easy
Kind
Enhancement
Kind
Feature
Kind
Proposal
Kind
Security
Kind
Studio Request
Kind
Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: studio/blender-studio-tools#170
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
TODO copied from studio/blender-studio-pipeline#145
High
blender_assets.cats.txtstudio/blender-studio-pipeline#185Medium
df6e8943e8RIG.name == MOD.nameab1d98b025Post Merge Actions like resetting armatures, removing actions and applying modifiersstudio/blender-studio-pipeline#208Create Separate Operator for Publish Review1af2d41bdcLow
478554a40920b903e7fdTask Layer LockingConsider integration with Kitsu (meta data etc)432e9b840bConsider New Validate Ownership Feature (By Pulling but not Merging)For Next Production
BUGS
272600a5461af2d41bdc9846af3db21af2d41bdc20b903e7fd20b903e7fdd31a624df1c8f5e04936ab1d98b025Convention checker list is currently here: studio/blender-studio-pipeline#84 (comment)
Can be moved somewhere else if needed.
Also added a bullet point there just now about multi-user object datas.
Hi!
Thanks for that big work!
I am currently testing the V2 asset pipeline. And I am trying to contribute by giving my feedback.
First of all, the tool looks really good and performs these functions, which is really cool and completes a real missing functionnality in Blender. Too bad, it’s not co-branded with a reference system(link).
In the V1, it was possible to versionning the tasks in order to group them in work/publish(staged/active) versions, this is not the case for the moment with the V2. Did I miss some things? Don’t you have plans?
When working, it is sometimes necessary to switch from modeling file to rigging file and vice versa. However it is necessary to go to get the file by hand in the folder. Knowing the location and the name of the files of the tasks, wouldn’t it be useful to have buttons in order to open the file staged or publish or modeling, rigging, shading etc in order to access it in a single click? (a bit like the addon "Edit Linked Library"), that should be really usefull, isn't it ?
Can someone like me help this project by coding some features, ui etc?
I believe previously a publish had a status, which was only stored in a metadata .xml file, and possibly synced to Kitsu. Today, there's Published, Staged and Review states, which are their own folders, and they are meant for specific use cases (and their names might still change). In short: "Published" means the asset is considered ready to be used in shots. "Staged" means the asset needs work from other asset artists before it can be used in shots. "Review" is sandbox to share ideas.
Currently, the file names of the working files aren't hardcoded to any convention, they can be named anything. But you can just press Ctrl+O to open a neighbouring working file pretty fast as it is.
Thanks for picking up the project so quick and testing it and wanting to contribute. I would say the project is still too young to welcome contributors, but Nick can correct me.
Yes, @Mets is correct we aren't ready yet for outside contributors yet, as this add-on is very new and most of the changes are being driven by the Blender Studio but I will update this issue with information about how to contribute and some clear TODOs for contribution once we are ready to accept contributions. Thank you for your interest @Eqkoss Any comments or ideas you have are welcome.
Thanks Demeter and Nick for your answers.
No problem, I will continu to explore the addon and try to give you relevant feedbacks.
atm what I can tell you is:
For me, it is not clear that it is necessary to push(+save ?) after claiming a surrender, couldn't it be automated ? Maybe I did something wrong ?
I'm not sure for this point, but I think the task_layers.json reading is a little bit bugged.
I create my own one and for "MATERIAL" I change the "default_owner" from "Modeling" to "Shading" and change "auto_surrender" from "true" to "false". But When I create an asset the materials data are owned by the Modeling and not surrended.(the task_layers that I used is share in this message. To let you know, Yes I add the dir in the "Custom Task Layers" Preference. The Grooming Task Layer was perfectly add)
It seems that the Push&Pull system is unidirectional: from tasks to staged/active files. Shouldn’t it be bidirectional? (having the possibility to push to MOD/SHD/RIG/etc from the staged/active file and pull MOD/SHD/RIG from tasks file ?)
When a staged (or an active) file is create, a “Task Layer Config is invalid” label appears, because no “task_layers.json” is created in the folder. Is it relevant/usefull ? If it’s to “lock” the Push&Pull system in the staged/publish file, shouldn’t you disable “Asset Management” menu or recreate an ui without the top part (only keep, avanced, tools and ownership Inspector) ?
Hope that's feedback will be relevant for you (And I’m sorry if they’re misuses from me)
Thanks for the feedback @Eqkoss here are my replies.
It could be automated, but we try to let the user do things explicitly we don't want to auto-save after each surrender claim in case the user needs to revert.
I don't think there is a bug based on ur feedback.
auto_surrenderIf it is set tofalsethe data is not surrendered, which is the behaviour you have reported, so that is correct.Default Owneris only used if the default is part of your local task layers for that file, the software cannot assign the transfer data to Shading, unless Shading is a task layer that is local to your file. We could consider renamingdefault ownertoprefferred owneras it is more accurate.No, this is not the behaviour the users at blender studio want, each user needs to explicity push/pull from the active/staged file, otherwise things will change in their file without the user being informed.
As discussed above the add-on is still in early development staged, the invalid message appears on published files when it shouldn't that is an issue we will address in the future, but it is non-critical.
You cannot push/pull from the published file, only the task layer files.
Please leave your additional feedback on the channel https://blender.chat/channel/blender-studio-pipeline because this issue is focused on the needs of the Blender Studio users.
@TinyNick thanks a lot for your replies.
That seams pretty clear now with your explaination.
Sorry for that ! I Will do it
Per a discussion I had with @SimonThommes I have added/updated the following Feature Requests to the main TODO
We have also added the following Bugs
There are some additional things that need to be owned in the shading process:
Currently these are just owned by the object owner together with the object data. But we need to be able to own them on a separate task layer.
One reason is the workflow:
The active data context is used for editing and having this change when you pull from the publish is a major risk for losing data by working on the wrong data layer.
This could in the future also be solved by always keeping the active layer selection from the local workfile.
The second (main) reason is that the active layer matters for viewport display. For example the active UV layer is used to map the active texture when this mode is set in the viewport display settings.
I found another bug:
When changing the ownership of a modifier by surrendering and claiming, the modifier moves to the end of the stack.
I'm guessing it's being recreated but then not moved to the right spot.
And something that might be a bigger problem:
When surrendered data is claimed and then deleted, there is nothing in place to enforce that deletion, so it is effectively still owned by the task layer that surrendered it.
Example:
From rigging
From modeling
This can be worked around by just pushing before deleting the modifier to establish the change in ownership. But the problem comes if this change in ownership is not pushed/pulled all the way back into the task layer that initially surrendered the ownership. Unless that happens it will always come back in a surrendered state.
OK as we discussed on the phone I have prioritized this task. Active UV and Active Color Attribute have been completed. I have started the UVseam transfer as a PR,
I have added a task to the bug's section of the TODO
This will be a hard one to resolve will have to think on it, but per our discussion this is lower priority. I added it to the low priority TODOs
Issue with Saving on Push
Right now, when I disable saving the file in the push operator it still saves.
Nick from the chat:
Then why is there even an option in the operator to save or not? If it's really absolutely necessary to always save before a push that option shouldn't even exist. Right now it just saves, even though the user says not to.
But additionally, I think it would be nice if only optionally saving would actually be possible. I don't see an issue with alternatively saving to a temp file next to the working file and appending from there. But this is lower priority.
Would appreciate your feedback on this as well @Mets. In the past I have suggested we rename the operator PUSH to SYNC because Sync implies both Pulling and Pushing. And in theory yes we can remove the save bool. Overall considering the long list of existing TODOs I agree this isn't high priority. I also don't like changing some many things about this add-on right before production starts.
Also I have added UV Seams to Material Transfer
Enforcing Pulling on Push
We had multiple discussions about how we enforce pulling before a push in a way that it's reliable but also not restricting to the workflow. The way it's done currently is, in my opinion, not sufficient to allow for a smooth workflow.
First off:
Regardless of any potential functionality changes. The label of the push button has to change if it works the way does now. Effectively, right now it always does a pull before a push. Calling this button 'Push' while there is a separate button for pulling next to it is misleading at best.
On top of that:
In my opinion there should be an accessible option to push without pulling. It is part of my regular workflow to push or pull very intentionally, since I'm aware whenever the publish can even have changed between two pushes.
Enforcing redundant pulls at all times with the cost of doubling the runtime of the entire process is undermining a smooth workflow and taking away the judgement of the user to make the right decision.
Right now the ability to push without pulling exists, but it is hidden behind the advanced toggle in the settings and needs to be toggled every time the push operator is run. This is not a sufficient solution imo.
I'd propose to rename the current
Pushbutton toPull and Pushand add an additional button that only pushes. Enforcing to use this button can still be done in a 'soft' way rather than the 'hard' way it currently works, by choices in the UI. For example ordering that button at the top, making it bigger and such.I have created a Pull Request to satisfy your request, studio/blender-studio-pipeline#199 we can merge it after Met has had a chance to provide feedback and he agrees.
I have updated the TODOs with this feedback, consolidating your last two comments into one task.
For saving I will remove the bool, and updated the tooltip to explain saving is mandatory. We cannot allow users to Push from a temp save, because this can easily cause out of sync issues.
@TinyNick
The problem is that most of the UX topics can only come up now, that we're actively using the addon. I briefly talked to Francesco and he confirmed that fixing these things, when they are necessary is fine to prioritize. When that interferes with your schedule regarding other things on your plate, make sure to let him know. But some things we'll just have to tackle now, so that we can create the assets.
I'll try to be more clear about what parts are imo necessary for a smooth asset creation process and what can wait for later.
If something turns out to require a major change in the merge process, of course that's a different topic and we should find a solution that is not disruptive.