Blender Kitsu: New Way to Find Assets for Shot Builder #179
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#179
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?
Issue
The current shot builder relies on
Assets.pyto define classes for all assets to be loaded into production. This can be tedious and is not dynamically when new assets are made in Kitsu.Name Matching: Solution A
Remove the
Assets.pyfile and instead use the same in file naming convention for both data-blocks and names on Kitsu. This means the names on kitsu will match collection names.Name Matching: Solution B
Remove the
Assets.pyfile and instead...Match the name from Kitsu with the collection name. Using the Following Rules when converting names from Kitsu to Blender Collections.
_How it Works
After a user clicks operator to Build a New Shot This Feature Will Work as Follows
assets/directory via Project Root PreferenceAdditional Note
I would really like to re-write the shot builder to make it easier to maintain, this task could be grafted onto the existing shot builder or be part of that rewrite depending on how long until we are building shots.
Either way we need this feature for the next production.
Please advise @FoxGlove
@ZedDB as we discussed ^
this sounds good to me! where would the location of the asset be defined? Just automatically derive it from the asset type and our current project structure?
Hmm, I still think we should have the name mapping logic be as simple as possible.
For example on the Kitsu side with the current mappings I would expect the following rules on the Kistu side of things that we have to enforce:
Spider-as a prefix and drop it.For me personally, I would prefer the mappings to be "one to one" (the name is the exact same in Blender and in Kitsu).
Otherwise you can get into weird corner cases like if we have
CH-rock,PR-rock, andSE-rock.(IE, we have a character named "Rock", a rigged prop rock, and a set centered around a rock or the character Rock)
Of course it is a bit of a contrived example because you could avoid this by more careful naming. But I think being able to not have to think about these things at all would be good.
By having a "one to one" mapping we will never have any confusion about what asset something maps to and users will never be surprised when authoring assets as there is no chance of the code mangling the asset names and remapping it to the wrong thing.
For example: Someone in "The Rock" production gets a task to create a "Prop rock". They mistake their task and creates
PR-rockinstead ofPR-prop_rockand push data to Kistu unknowingly mangling the data ofCH-rock.If we instead go "one to one", the task/asset on Kitsu would be to create
PR-prop_rock. In this case they could just copy paste the name and not have to think about any special naming conversions.Less code, less mental overhead -> Win, Win.
@eyecandy Yes it in theory be based on the folder structure we have defined for SVN because we already get a project root from Kitsu Preferences we simply add
assets/to that path.I have updated the Issue with this information.
@ZedDB That is a good idea, so just a full one to one copy of the names in Kitsu to match the datablock naming in Blender. Essentially this means that the kitsu naming will follow the same in file naming convention as the datablocks and my propsal gets even simpler!
I have updated the issue with this as a possible solution
Had a chat with Nick, let's go with solution B, provided that there is a way to prefix the asset type to the name (as defined in the in-file naming conventions). For example, take the asset type, pick the fist 2 letters, make it uppercase.
Why not go with the most simple and straight forward solution?
I don't see any benefits of not having a one to one mapping of assets names.
Besides potential mistakes during production, it also means that we will have to employ two different naming conventions that we have to keep track of and maintain. Especially because the names will refer to the exact same data.
@fsiddi Sorry I didn't express my opinion on the call as I was trying to rush through the meeting agenda. If this is up to debate here is my opinion:
I agree with @ZedDB that option A is cleaner and requires less thought from the code side.
Mainly I would be concerned with another piece of documentation that needs to be created for users to understand the mapping between the two name types, if we use Solution B.
BUT if we don't include the prefixs in the names, maybe there is a happy medium between the two? So...
Solution C
Match the Kitsu Name Exactly to Collection Name minus the Prefix
Kitsu is about human-readable information. I rather see a new metadata field, called
slug, used to store that info. A bit more work when creating assets, but overall ok.I agree that storing this information is a slug is a good way forward.
Andy suggested that we could even have a slug for each category type in kitsu as well so we don't need to have any lookup there either. IE, the
Propcatergory has a slug withPR-in it so to get the name in Blender you just combine them.No guess work and easy logic. I like it!
To reiterate
CH-mikassaCH-european_sea_bassPR-sailboatClosed by studio/blender-studio-pipeline#183