Hi,
Has anyone thought about how to launch to RV with a proper ENV set. We have JOB/SEQ/SHOT environment variables that could be used to set additional MU_MODULE_PATH and RV_SUPPORT_PATHs. However, I'm not sure how this info would be gleaned from a baked rvlink URL.
Thanks for any ideas!
-Paul
Hey Paul,
You could change the registry key for how the rvlink launches.
if you wrap the rv command in a .sh or .bat that sets the env vars then starts rv.
If i remember correctly the rvlink just contains the version id of the video/image sequence in a hex encoding and rv then uses the api to get the rest of the info.
The other way you could do this is in the config .mu that you need to setup, there is a function called "fieldsCompute" that you can use to add or do work on the path and data gleaned from shotgun via the rvlink , before rv plays the path.
Hope that helps.
Kym
Hi Kym,
Thanks for the response!
Yes, we have already updated the rvlink registry entry to point to a .bat file wrapper. So we can set facility-level env vars. The question is more how to set per-Show, per-Seq, per-Shot env vars. So if we have multiple projects in house, each one could launch RV from Shotgun with a different environment.
My understanding of RV_SUPPORT_PATH is that it can be used to setup different environments with a unique set of packages installed and loaded. This is great, but seems hard to utilize with rvlinks...
This kinda turns into a chicken before the egg scenario... We could write one set of facility packages that determine job/seq/shot environment by parsing filepaths after RV is already loaded. But this usually turns ugly with a whole bunch of "if show == A", do this... etc...
I'll take a look at "fieldsCompute". If I remember correctly, this is a way to map Shotgun fields to meaningful values in RV. While you could grab some values from Shotgun this way, I don't think you can set an Environment, because RV would already be loaded at this point.
Hopefully I'm making sense!
-Paul
Hi guys,
Paul, this is definitely a chicken/egg thing. The point of setting RV_SUPPORT_PATH is definitely to provide different sets of packages to different shows/shots/users/etc. But something needs to be "aware" of the correct values of these variables (show/shot/user) for this run of RV so that other code (usually in a wrapper) can set RV_SUPPORT_PATH correctly.
Maybe you could describe more exactly the workflows you want to support ?
Thanks,
Alan
Ok, here's a basic scenario:
We have .bat file wrappers we use to launch our applications. For example:
wtRV.bat /job:projectA
wtRV.bat /job:projectB
wtRV.bat sets RV_SUPPORT_PATH differently based on the incoming job flags. And let's say ProjectA and ProjectB use different source_setup packages.
When I launch from a command line or in-house tools, the flags can be set properly and everything is cool with the different rules within source_setup for each project.
When I launch from Shotgun, I can adjust rvlink in the registry to point to wtRV.bat, but I can't pass along the job flags... so I lose my show specific source_setup packages.
I was really just asking if anyone had thought about this... either at Shotgun or Tweak or at Studios out there...
The only way I see to get around it, is to:
A.) Make our own Action menu item to replace the default "Play in RV". This would pull in job from the Shotgun records and pass it along as additional arguments to be parsed out.
B.) Change rvlink in the registry to point to a "pre-process" that decodes the bakedURL, queries Shotgun for the filepaths of the sequences, parses the job from the filepath, and THEN builds the command to actually send to wtRV.bat.
I love the simplicity of "Play in RV". It just seems this one gotcha compromises some of the customizable aspects of standalone RV. We are a smaller shop, but I still like to have a setup where I know each project can customize without affecting other projects. How are the bigger companies handling this?
Hi Paul,
I can't speak to how bigger studios are dealing with these issues, but here are some possibilities: