The Idea of this topic is to have a place to get a general idea of how the software works when starting from zero.
Hi, I’ve been test driving OP today to try to understand the paradigm it uses, I have a few questions that I’m sure almost everyone here have already figured out
-As far as I understand, artist are meant to work locally and then push their work to a shared drive through publishing, if this is so, are artists meant to name their local file? is there a way to automate this that maybe I’m not seeing?
-through publishing we not only save the file in it’s final/shared location, we also may export formats like USD ABC and FBX, is there a way for the artist to change options for these formats?
-Before publishing the publisher runs some tests, if some of them fail is there a way for the admin to override and publish anyway?
Hello and thank you for the questions. Here are some brief answers. This topic might accidentally grow quite a bit I suspect, so let’s see where it takes us.
Both are supported options, but by default the setup is to work from a centralized storage. AYON takes care of all the file naming. Workfiles are named automatically and publishes too.
Artist can affect some of export options (depending on the studio settings), but in general they are determined and pre-set in the pipeline settings by the supes or TDs, so artist outputs are as consistent as possible
Yes, each validator can be made optional, or enabled/disabled by default, depending on the combination of studios settings, the artist may be allowed to override them.
Thank you @BigRoy and @milan , more than missing it I didn’t realized what it was for, wrapping your head around so many concepts is daunting at first but the picture is getting clearer and clearer, I actually ike the concept .
is it possible to add custom exporters to the publisher?
let’s say, we have a custom json exporter for camera animation from Blender to fusion, since alembic or FBX give the wrong result and our manager has a template for camera exporting and loading, can I add these exporters as plugins without recompiling or modifying the code?, like plugins
If you would create classes that would inherit from publish.Extractor (most likely as Extractors are meant to produce some stuff), you could point OP to their custom location per project in Settings in project_settings/global/project_plugins.
No re-compile necessary.
this next question may not be relevant since I’m still trying to understand OP’s paradigm, on our manager I made a small temporary “lock” temp file which flags when a file is open and prevents it from being opened by another user (as long as they are using the system to open it of course), is far from being sophisticated but it helps a lot on preventing files to be overwritten by mistake.
Is there something similar on OP or is this not very relevant?
Thank you @milan and @Petr_Kalis for the support, it has helped a lot.
Another question that has popped at the studio regards to our NAS workflow, we separate the project into a main project and a “mirror” of sorts, the idea is to have all the source files like .blend, .hip, textures, edits, etc in one drive or drive group, and all that can be generated from said sources like render files, or caches, go into another drive.
This allows us to inject resources to protect the most important data, it also lets us backup easily the source project on our project vault for as many years as contractually obligated without backing up all the extra data that comes from said files.
Is this possible using OpenPype? is it even relevant? maybe Open Pype’s nature achieves the same thing in some other way.
Technically your ‘publishes’ are the outputs that are “reproducable” in a way so you could technically ditch them and recreate later. Wouldn’t recommend it hehe.
Anyway, if you require that hard of a physical separation you can set up an extra root directory for your projects in Tray > Admin > Studio Settings > Project Settings > Anatomy > Roots and then use that to separate e.g. Work template from the Render/Publish/Hero templates, etc.
This is a quick mockup in the settings - I might have mistyped things. I also haven’t tested this, I personally don’t use these separated roots but I’ve heard others do. Likely they are better about confirming whether this is how it should be done and whether there are any gotchas to the approach.
Note that without separating the roots that OpenPype also has some tooling to delete old published versions (to clean up if it’s huge in size) but those are features I’d recommend to use with caution since, like deleting files anywhere, it means you’re removing what might still be important.
Perfect, thank you, I browsed the repository yesterday and was really happy to find that publish implementations seem to be extremely clean and easy to understand.
I’ll look into it over the weekend and try to implement a USD publisher and camera to fusion camera for Blender, we have both implemented for our local tool so it shouldn’t be hard.