Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AY-1262_Unreal Content Plugin system #128

Open
ynbot opened this issue Oct 7, 2024 · 0 comments
Open

AY-1262_Unreal Content Plugin system #128

ynbot opened this issue Oct 7, 2024 · 0 comments
Labels
sponsored This is directly sponsored by a client or community member type: feature Adding something new and exciting to the product

Comments

@ynbot
Copy link
Contributor

ynbot commented Oct 7, 2024

Please describe the feature you have in mind and explain what the current shortcomings are?

tatiana_43379 : Unreal Content Plugin system
tatiana_43379: Parts of the related Discord discussion about that topic:

If UE Projects have all their large files, like create/binaries, external to the project (via content plugins), then a UE Project - with a fast-style zip - becomes comparable to a Maya Binary in size. If that is the case, then one can version control just like every DCC - Maya, Nuke, and Houdini - with a version-numbered file. The problem disappears. Furthermore, Ayon already has all the code to implement this style of version management. Regarding sync: There is no need to. We have had pretty good success working directly off network storage. If a studio did want to localize, then it is just a simple copy to the local machine to a scratch disk... then again, we are pretty much in the Maya/Nuke/Houdini situation. The scratch disk could be an in-memory representation, similar to what one has in Maya. Remember, with a version-numbered file, we are back into the Maya-like workflows. Just to restate - we see several versions of an Asset being available at once in these plugins. Ideally, Ayon's manager would be able to switch to the file to load a ###_version.uasset. In this way, everything is static. Everything references an explicit version of a thing. One does not render dog.uasset, but rather dog_v001.uasset. As such, rendering would always be stable.
tatiana_43379: Setting the .uasset path for every instance of a thing (and thereby meaning on a single "Version Number" could be consumed at once for all instances), it would probably be fine in the vast majority of cases. And if that is the only thing that can be done now, I think that is a very acceptable compromise and step forward. We would never hot-swap Content Plugins. These would be high-level groupings to data libraries. For example, Build and per Sequence perhaps. These would always be installed. We do this currently by using the .uproject JSON. And we also put a JSON file in the root of the Plugin Library to declare the folder on disk as a Content Plugin. We then just write directly to those folders. Nested folders also work fine. So, we tend to use a classic folder approach to organize our data.

How would you imagine the implementation of the feature?

No response

Describe alternatives you've considered:

No response

Additional context:

link to discussion on Discord
(might be a private channel)

This issue was automatically created from Clickup ticket AY-1262

@ynbot ynbot added sponsored This is directly sponsored by a client or community member type: feature Adding something new and exciting to the product labels Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sponsored This is directly sponsored by a client or community member type: feature Adding something new and exciting to the product
Projects
None yet
Development

No branches or pull requests

1 participant