Better collaboration ideas with published openclips

Flame Flame Questions
1

Would this he worth a feature request maybe?

“Relative paths for openClips”.

getting the same file paths across systems is not very easy when you collaborate with other people that have their own flame at home.

It would be much more straightforward if I could send a folder that contains the source, a location to render to and all the openclips that I published and then everything is relative to the location of the openclip or whatever really , main idea is that a artist could just open it , render it and then send the whole folder (minus the source) back and boom.

just takes 1 problem with filesync and paths our of the equation.

Nuke can do that, houdini can do that, even blender can do that. :slight_smile:

3 Likes
2

You can do this with archives and changing relative path. Any use?

3

Relative paths are great but they all need to be relative to something. There needs to be a project location established somewhere to ultimately relate to—a $HIP. One could argue you could do relative paths to <shot> but it’s way less powerful in the end.

Starting with a few global variables that define those key locations with tokens gets the first step done. Global paths to be relative to, then we can try to convince the powers that be to have relative pathing.

That was the genesis of my reverse user request.

…speaking of which @Slabrie if you do want to discuss my reverse user request I’m totally down. Perhaps we can involve some of the other openclip jockeys like @finnjaeger, @Josh_Laurence etc…

3 Likes
4

This is something I’m looking at engineering with Shotgrid by the way. I’m pretty sure it’s possible.

5

it is a open text file, I was thinking of just writing a small tool than converts the paths in the openclips to local paths, and then back after a artist submitts a shot.

I think this could just happen in flame directly. just like how nuke and resolve have that exact feature.
Flame even has the menu and stuff for it allready it just has to work not only during archive restore.

1 Like
6

Isn’t this what the Path Translation feature is supposed to take care of? Something like internal simlinks…? Not being sarcastic, but I’ve had only intermittent success with Path Translation. Sometimes it re-points, sometimes it doesn’t. When it doesn’t, I’m not immediately clear why not.

I’ve definitely had to batch adjust openclip xmls in emacs to repoint to the correct pathing and I’m totally comfortable doing so when I have to. But given the idiosyncratic nature of everyone’s setup, it seems improbable that one tool will cover all the different possibilities - some babysitting required…

The smoothest experiences I’ve had with openclips are when they’re used on systems with the same pathing - even ones that don’t share storage.

I love this idea though and I think I understand it better after looking up $HIP. I came across this definition in the Houdini subreddit (for the curious):

When you first save your HIP file, Houdini creates a variable called $HIP- all this is is a string value that points to the absolute path on your machine where your hip file is stored. eg) c:/documents/houdini_files/your_project.hip

The power of this is that now you can refer to files using the relative path of $HIP. Let’s say you want to load an image texture, you have it stored next to your hip file in a folder called “img”. In the file path you could just type “$HIP/img/my_image.jpg” and it will correctly find the file. This is faster and easier to read, but ALSO, it stays relative no matter where you move the file, as long as the relative paths are the same. So you can move your project to a different folder, or a different computer, and as long as the relative paths are unbroken, everything will load fine.

Which also included an explanation for $JOB:

$JOB is the exact same idea, except that you can define it yourself when you go “File->Set Project” Whichever folder you choose can now be referenced by the variable $JOB.

Likewise, you can define your own custom variables for whatever folder you like on your machine, using the houdini.env file (Documents/Houdini(x.x)/houdini.env)

Just open it using any text editor and at the bottom of the file add VARIABLE = “path/path” ie) ASSETS = “D:/Dropbox/Assets”

Definitely some food for thought. Nice stuff, @cnoellert! TIL some $HIP! Wouldn’t it be funny if Houdini named their files .hit?

2 Likes
7

afaik the path translation feature is not doing what one would expect.

afaik you need to set it up prior to unarchiving and only then it actually translates paths during the restore. but thats about it

8

…and that’s the Logik behind my reverse user group request. Essentially global, project, batch and user variables, by way of tokens that can be evaluated system-wide.

One application would be a publish. You would set up a global <project_locations> variable that pointed to:

/path/to/projects

…and upon project creation, Flame would automatically assign the <project> variable with the name of the project you’ve just created. Then maybe you create another global variable called <shots> and assign it, in my case to the name:

_04_shows

…which corresponds to where I publish the shows out to in my job structure. With those two changes AND provided that those tokens could be part of an openclip publish you could move the entire project to another location on another machine and provided the other machine had mapped those two variables to their respective new locations, the whole system of an openclip publish would resolve all paths correctly, provided the publish mechanism is updated to allow for tokens at publish and Flame is updated to allow for user definable tokens.

So in the example above on my system, the global <project_locations> variable is set to say →

/Volumes/nas/projects

…and say that a freelancer is using SynologyDrive or something with the project mounted at →

/Users/Freelancer/Documents/nas/projects

Then the idea would be that the freelancer could just update their token for <project_locations> to reflect the new location, all paths revolve correctly and you’re off to the races. The system is based on resolving the tokens at read time, not baking them at write. It’s an important differentiation.

From there, relative paths become almost inconsequential, especially when you consider the you could create a dynamic token that’s called <shot location> which points at →

<project_locations>\<project>\<shot location>\<shot>

…and which resolves it’s location based on the shot number on a per-shot basis set from the token context of batch. Of course it doesn’t mean you couldn’t use relative pathing. One could argue that the most important variable needed for relative pathing to work would be a global <project_locations> that once it was set would enable traversing the project hierarchy with ../ or ./ notation.

$JOB is upgraded version of $HIP, and would have been a better example for what I was out to explain. But $HIP is intrinsic in that it is set on creation or load and therefore allows the magic of relative pathing without user intervention.

4 Likes
9

Feedback requests posted.

2 Likes
10

Hello Chris!

I was expecting we could have discussed your request on the Logik live event but sadly you were not there. It would have been great to bounce workflows with others live since over messages this is not easy. I think we need to discuss the end goals of how should our products better manage content in the future. We should thrive to simplify workflows and not make it more complicated with many different workflow paths. We should discuss that later together in a Zoom call and open it to the ones here who would like to chime in.

2 Likes
11

I would like to see an episode token for my workflow.

1 Like
12

The point is that these tokens are user-definable so you just make a token called <episode> and give it a value.

Think variable and value.

2 Likes
13

Whenever you have time @Slabrie–I’m here all week. I had intended to be there for the meeting but ended up having to supe a shoot last minute.

14

Sadly, my day job keeps me quite busy so we will not discuss this this week. I will need to get back to you later.

1 Like
15

I do too.

16

Ah! The beauty of translating idioms! I do not see any equivalent in French but I will now use it :wink:

1 Like
17

It’s a classic. Follow it up with… “try the veal.” Or localize with “…try the poutine.”

1 Like
18

Yes please.
I have a half dozen camera-centric ones to add into custom tokens.

Also would it be possible to import/export token values thru csv? Would neatly tie in w shotgun, etc.

Not just for tokens but metadata in general.
Thinking like xml from conform.
Perhaps a tool already exists….?
Embedding info into timeline would seem to be less heavy than into each image.

Example: mapping distortion values over lens rotation in timeline was considerably faster than using images for stMaps.
Admittedly I’d guess metadata would be lighter than 32 bit color value, but same idea could apply.

Timelines seem a good place to store streams of metadata.

1 Like