100% That’s why I think there needs to be a little of an internal switch in terms of how unmanaged workflow functions and make some tweaks that will make it accessible application-wide.
I can mock this up later, but first off, we need a global variable (token) for project location and then allow all pathing and other tokens to resolve relative to the project token. So if resolves to
/mnt/nas/projects/project01
…then we can start setting paths using like
<project>/show/shots/<shot>/renders/<batch>_v<iteration##>/<ext>/<batch>_v<iteration##>.<frame>.<ext>
Which might resolve to:
/mnt/nas/projects/project01/show/shots/shot_01/renders/project_shot_01_v01/exr//project_shot_01_v01.####.exr
Once that’s in place, Flame should by default create all setup directories under a user definable location in preferences allowing us to use that token. For example
<project>/flame/setups/<module>
…which would allow for all project metadata to be generated directly into a more useful location than things tend to default to and in a templated form. Those are the first structural changes that need to be made to support a more open workflow.
The second structural change that would need to be made in order to facilitate an open workflow would be creation of a rendering mode toggle that either enables “legacy mode” or enables “modern” mode. To explain a little further, “legacy” toggled-on means things function exactly as they do today… when you render a render node, it renders a SW managed clip which is completely opaque to the project file-system. The world continues as people are used to.
Conversely toggling to “modern” would default render to a a user-definable location, also a preference. So to continue to use the example from above that might be:
<project>/flame/setups/<module>/renders/<module>_<setup>/<nodule>_<setup>.<frame>.<ext>
The file format rendered would be defined by cache settings at startup. So in the instance of prores444/EXR PIZ, if you flipflop a 16bit clip on the desktop, which would normally create a new source on the desktop, it would render out a half exr to the path above and imports an uncached openclip of the render to the desk referencing the result of the render. The second that we can treat all renders (except timeline cache renders) as unmanaged renders referenced only on the desk, a whole world opens up. Batch can largely already be made to work this way, with the added benefit of multiple iterations being able to be stored in a single reference–the open clip. With this new structure there would be no reason why one couldn’t use the same strategy for every module and allow for versioning of clips from modules using open clips like batch. This is the second structural change that needs to be made.
The last structural change that needs to be made is to path translation so that it actually does what it should. An artist working unmanaged should be able to define a localized path to a project using the aforementioned token and that pathing should be able to be updated whenever and every reference to media, setups, models, whatever would remain in tact. As it is today, it’s to easy to break a whole project, clips, anything with incorrect pathing. In a truly unmanaged workflow, all references to media need to reference a central location. This is only possible with the changes listed above.
Beyond that the caching mechanism works by and large well enough to allow for this whole system to work. You cache a clip from the network you get playback. You’re working locally on a home machine you can work uncached with a reference point to the same location as your project metadata is housed. This system would also allow for centralization of a ton of other data that currently is spread all over the place–things like user profiles or color policies or even matchbox shaders. It also can scale well either by machines or by artists using existing tokens.
In my mind this is the way @fredwarren and what I was trying to explain (poorly) a couple months back at that dinner.