Opening a scene during development

Pipeline Integrations
1

Hi, very often when developing dcc integrations, you work with a specific test scene (whose path you know). You have to perform the cycle “close dcc, open dcc, open workfiles, find the file, open it” many many times, and it takes quite long.

I wonder if there is an easy way to do this in either the tk shell, or through python?

2 Likes
2

Hi @mmoshev, you should be able to launch your DCCs directly from tank and pass any relevant args (like filename):

Executing Commands

Syntax: tank [context] command [args]

  • Context is a location on disk where you want the command to operate.
    It can also be a Shotgun Entity on the form Type id or Type name describing
    the object you want to operate on. If you leave this out, the command
    will use your current working directory as the context.

  • Command is the engine command to execute. If you leave this out then the
    available commands will be listed.

Examples:

Show what commands are available for the current directory:

tank

Show what commands are available for Shot ABC123

tank Shot ABC123

Show what commands are available for Shot ABC123 in project Flash
(In case you have several projects with a Shot ABC123. Note that this
only works when running from a tank studio command)

tank Shot Flash:ABC123

Show a list of all shots in Shotgun containing the phrase ABC

tank Shot ABC

Launch maya for your current path (assuming this command exists):

tank launch_maya

Launch maya for a Shot in Shotgun:

tank Shot ABC123 launch_maya

Launch maya for a Task in Shotgun using an id:

tank Task @234 launch_maya

Launch maya for a folder:

tank /studio/proj_xyz/shots/ABC123 launch_maya

Log out of the current user (no context required):

tank logout

4 Likes
3

Thanks @nico.vandenbosch!

@mmoshev, as Nico pointed out, you can specify a task to launch into on the commandline, so that will save you some browsing in the File Open dialog. If your engine supports it, you could set the launch_at_startup setting on tk-multi-workfiles2 to True, so that you won’t need to manually open the File Open dialog at launch time.

Another option to explore would be reloading things within your DCC session. I know we’ve seen some issues where not everything that you’d expect is being refreshed, but if it works for you, it’ll speed up your iterations quite a bit. You have a couple options:

  • If any of the bundles in your environment has a dev descriptor, you’ll get a Reload and Restart command in the Shotgun menu in your DCC:

01_Concept_Art__Asset_Filet_and_Shotgun_and_Autodesk_Maya_2019__untitled_and_Slack___Francesca_Christopher___Autodesk_Main___30_new_items
01_Concept_Art__Asset_Filet_and_Shotgun_and_Autodesk_Maya_2019__untitled_and_Slack___Francesca_Christopher___Autodesk_Main___30_new_items1392×630 134 KB

  • And even without a dev descriptor, you’ll always have a “Reload Engines and Apps” button on the Work Area Info app:

01_Concept_Art__Asset_Filet_and_Shotgun_and_Shotgun__Your_Current_Work_Area_and_Autodesk_Maya_2019__untitled
01_Concept_Art__Asset_Filet_and_Shotgun_and_Shotgun__Your_Current_Work_Area_and_Autodesk_Maya_2019__untitled2406×1648 541 KB

Hope that helps! Let us know if you have any other questions, and if the those commands aren’t working as expected, I’d love to hear about that, too, so I can escalate it.

3 Likes
4

Thank you both for the suggestions, I will explore both options.

I do use “Reload Engine and Apps” a lot, but it’s not always feasible.
Also sgtk.platform.restart(), which is the main thing that button calls, I guess. It seems to completely reload the configuration, templates, apps, and so on.
This leads me to think that some engine restart hooks could be abused to reload my third party code, too. E.g. only if a dev descriptor is used. Reloading modules in python is a lot of black magic, however.

At some point all our tools will be wrapped in toolkit apps, so restart would indeed work.

2 Likes
5

I ended up using Nico’s suggestion and it works! Thanks again.

Still unclear on where the command launch_nuke11.3 is registered, since grepping in the config did not turn it up. Is the command name generated? Just found it by running tank without arguments…

A bit embarrassed, since I’ve been reading the startup documentation for a while now :slight_smile:

2 Likes
6

Mois, it might be coming from your Software entities in Shotgun? If you have a tk-multi-launchapp instance in tk-shell with use_software_entity set to true, specific DCCs aren’t specified in your config - it gets all that info from Shotgun – hence fruitless grep.

1 Like
7

Ah yes, I forgot. That specific environment did not have software entities configured, and I was confused about the limited list of commands. All is fine now.
Could not get Katana to open a scene directly, othe DCCs have worked so far.

Thanks again!

2 Likes
8

Even better, figured since it is just launching a process, I can do it in emacs!

(defun btl--test-nuke ()
  "Start nuke from toolkit, with a scene."
  (interactive)
  (start-process "test-nuke" "*test-nuke*"
               (concat shotgun-project-path "/proj-name/tank")
               "Task" "@8068" "nuke_11.3v5" "--redacted-scene-path--")
  (switch-to-buffer "*test-nuke*"))

The huge benefit of launching apps like this, is that some, e.g. Nuke and Houdini, do not have proper log files (Nuke has configuration for this, which seems not to work).
Starting in a shell enables one to read the std output of the program, getting a lot more information!

Now I begin to wonder if tk-desktop/launcher can be made to capture all output from a program…

3 Likes