Tools Requests to be implemented

[Lyon-Rosenblatt-Ynput]

Better USD developer / Td and artist tools

Some tools would be great to be available for usage with USD.

Currently, we cannot enable Ayon_Usd inside off, e.g., in the admin console (enabling Usd from inside Python is impossible because Ld_lib_path under Linux and Windows is the same). Because of that, I propose that we add a button Start AyonUsd(better names welcome) that launches a subprocess with Ayon_usd + Ayon_Usd_Resolver ready. This could also include some extra tools available for user convenience.

I think the toolset should be a floating window from which you can start from Tray. The base could be the ayon admin console, with some extra options and a few buttons to start some of the tools we ship.

On top of that, It would be great to have some viewing and debugging tools available in loader, etc.

• [ ] Lanucher AyonUsd Env
• [ ] AyonUsd Window (a window similar to the admin console with some extra features)
• [ ] Usd View
• [ ] usdmanager
• [ ] usd-qt
• [ ] usd-qtpy
• [ ] usdNodeGraph

[BigRoy]

What's problematic with just 'visually' exposing e.g. one of these tools to the user directly in the launcher, or in a DCC - but whenever they want to run it that it actually spins up a subprocess. Why do we need the floating window in-between that lists the tools?

Is it because of how much launch time difference there is?

[Lyon-Rosenblatt-Ynput]

What's problematic with just 'visually' exposing e.g. one of these tools to the user directly in the launcher, or in a DCC - but whenever they want to run it that it actually spins up a subprocess. Why do we need the floating window in-between that lists the tools?

I kinda see 3 parts there. 1: exposing tools to the user in DCC is easy, for eg. Usd_View or usd-qtpy and so on, and it will be very useful. So I would say let's make the startup functions abstract so that they can be standalone and in DCC (if they have the option to pull the Usd lib directly from the DCC, that is)

2: standalone view there was a function in the init that has been designed to alow usage off ayon_usd standalone inside off eg. the admin->console. But adding the usd_libs to the running Python process is impossible(it's possible, but it would be a lot of work and limit us quite a bit), so I would say having a subprocess with nice window. Attaching some extra tools might be a valid alternative if we have to implement a subprocess anyway, and if some people want extra standalone tools, we could do it in one system.

Ps: yes, we can have the tools in the launcher; we could even have something like the admin->console window with ayon_usd preset in there as an "application", the reason why I thought bundling them together might be cool is just that i think it's easy and nice to use just a UI/UX preference of mine. (we could even do both; the baseline of the system should be abstracted in a way that you just call a function and get the setup)

3: standalone background tools I see quite a bit of importance in being able to run, e.g., ayon_usd with ayon_usd_resolver as a standalone both for testing and for Usd-only tools. (i would like to be able to have a function that starts a Python process or subprocess and that has ayon_usd_standalone setup and then be able to run commands/scripts in there)

Is it because of the difference in launch time?

I don't think it would add to the ayon_launcher launch time, but I'm not sure if we need to define the application in the applications addon instead of the ayon_usd addon, so that might be annoying. I also don't think it would add DCC startup time as most of those tools could be lazy loaded, so at startup, we only need to load the function that loads them, not the tool.

That's kinda my thought process for the setup; I hope it makes sense. if you think I'm overlooking something, let me know.

[BigRoy]

2: standalone view there was a function in the init that has been designed to alow usage off ayon_usd standalone inside off eg. the admin->console. But adding the usd_libs to the running Python process is impossible(it's possible, but it would be a lot of work and limit us quite a bit), so I would say having a subprocess with nice window. Attaching some extra tools might be a valid alternative if we have to implement a subprocess anyway, and if some people want extra standalone tools, we could do it in one system.

Ps: yes, we can have the tools in the launcher; we could even have something like the admin->console window with ayon_usd preset in there as an "application", the reason why I thought bundling them together might be cool is just that i think it's easy and nice to use just a UI/UX preference of mine. (we could even do both; the baseline of the system should be abstracted in a way that you just call a function and get the setup)

3: standalone background tools I see quite a bit of importance in being able to run, e.g., ayon_usd with ayon_usd_resolver as a standalone both for testing and for Usd-only tools. (i would like to be able to have a function that starts a Python process or subprocess and that has ayon_usd_standalone setup and then be able to run commands/scripts in there)

I think I understand what you're saying, and I agree. Running ayon_usd with whatever separate tools/dependencies would be great.

What I understood before is that you wanted to from e.g. Ayon Launcher, start a new process that is basically a UI from which you can launch other stuff. My question was merely, why couldn't ayon launcher do that directly. you click "USD view" in loader - it does ayon_usd.launch("usdview") or whatever or exposes a usd_env = ayon_usd.get_usd_environment() and you could e.g. then use that environment dict to run a subprocess call of your own. I wasn't sure why we needed a UI inbetween, and still am not sure I understand.

I don't think it would add to the ayon_launcher launch time, but I'm not sure if we need to define the application in the applications addon instead of the ayon_usd addon, so that might be annoying. I also don't think it would add DCC startup time as most of those tools could be lazy loaded, so at startup, we only need to load the function that loads them, not the tool.

Well, in a lot of cases it seem the tools wouldn't even be loaded into the DCC but maybe run against standalone usd if possible, and thus run through the subprocess.

Anyway, maybe I'm deviating from the issue which asks "what tools do we want?" instead of "how do we run the tools". But that line about the separation just got me confused. I just see:

• We may have tools that absolutely require native/inside the software we use, e.g. asset resolver in Houdini or Maya.
• We may have tools to visualize/debug that are totally fine in a separate process (or even preferred), e.g. usdview
  • Although running usdview against the exact Houdini env, with Houdini's usd libs and plug-ins may also be crucial so you could e.g. also rely on the Arnold Hydra delegate exactly as you've loaded up Houdini. But that's maybe a very different use case and since it relies solely on Houdini's env then - not something that maybe even should be managed by ayon-usd?

[Lyon-Rosenblatt-Ynput]

I think I understand what you're saying, and I agree. It would be great to run ayon_usd with whatever separate tools/dependencies are available.

Nice then we are at the same point here. PS: this entire issue is essentially about running tools in a nice way mostly standalone but there's no reason not to build the startup logic abstract for the tools itself so that we can start from inside what every (ayon_usd, Houdini, end the rest)

What I understood before is that you wanted to from e.g. Ayon Launcher, start a new process that is basically a UI from which you can launch other stuff. My question was merely, why couldn't ayon launcher do that directly. you click "USD view" in loader - it does ayon_usd.launch("usdview") or whatever or exposes a usd_env = ayon_usd.get_usd_environment() and you could e.g. then use that environment dict to run a subprocess call of your own. I wasn't sure why we needed a UI inbetween, and still am not sure I understand.

I should probably expand on the issue above. because yes, I want a UI, and this came from the original function being used in the Ayon->console "ting" and I would still like a cool AyonUsd UI tbh (I just like it when tools have a nice place to live together especially for debugging and td stuff) but your totally right focus should be on building an "engine" with a specific interface that can launch USD tools with what every ENV setup we want (including Ayon_Usd)

Well, in a lot of cases it seem the tools wouldn't even be loaded into the DCC but maybe run against standalone usd if possible, and thus run through the subprocess.

exactly. I would love it if we get standalone Usd tools in a very abstract way so that we can simply start them like a "plugin" and also, if wanted, with our UsdLibs and associated resolver. (for eg debugging, automated editing, and so on)

Anyway, maybe I'm deviating from the issue which asks "what tools do we want?" instead of "how do we run the tools". But that line about the separation just got me confused. I just see:

* We may have tools that absolutely require native/inside the software we use, e.g. asset resolver in Houdini or Maya.

* We may have tools to visualize/debug that are totally fine in a separate process (or even preferred), e.g. usdview

  * Although running usdview against the exact Houdini env, with Houdini's usd libs and plug-ins may also be crucial so you could e.g. also rely on the Arnold Hydra delegate exactly as you've loaded up Houdini. But that's maybe a very different use case and since it relies solely on Houdini's env then - not something that maybe even _should_ be managed by ayon-usd?

I think we could make it so we can manage that because I believe it would be very convenient for both the user and developer if we provide tools to start USD with whatever ENV we want. And we need a nice abstraction in the lib anyway to extend and define in the long run.

By the way, thanks a lot for the input. I will see that I write a ticket handling creation off a startup lib and reduce this ticket to a list of tools we want to have. Because you're right. I mixed running with wanting to have. (then we can go in-depth about what we want and how we want it :smile_cat: ) PS: I'm not sure if the startup lib + protocol (should be minimal) should be in a separate issue or be handled here. Maybe you have some input.