Play in RV: Launch with an ENV set

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!


5 条评论

  • 0
    Kym Watts

    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.


  • 0
    Paul Hudson

    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!


  • 0
    Alan Trombla

    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 ?



  • 0
    Paul Hudson

    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?  

  • 0
    Alan Trombla

    Hi Paul,

    I can't speak to how bigger studios are dealing with these issues, but here are some possibilities:

    • Assuming that whenever you load a Version from the Shotgun project "ProjectA" you want to start RV with the ProjectA bat file settings, you could write a script that takes a rvlink URL on the command line, looks for a Version ID in it, uses the shotgun API to find the corresponding Project, and then launches RV through the appropriate bat file (passing on the URL of course). Then this script becomes the rvlink protocol handler.
    • If the user really needs to choose the project at runtime, the rvlink protocol handler could be a small app that puts up a dialog asking the user to select a project, then running rv with the appropriate bat file. I have no idea if that's easy to implement in the windows scripting world.
    • You could move away from the rvlink connection entirely, and use drag and drop for most Shotgun interaction (URLs of type Version, Shot, Asset, Playlist, and User can be dragged from a browser and dropped on RV to load the appropriate media). That way the user makes the "which project" decision when they start RV.
    Hope that helps,