louisvottero/vtool

1. What this repo is

Vetala is a cross-DCC rigging and asset-creation toolkit. The same Python package is meant to run inside Maya, Unreal, or Houdini, and can also be launched from a standalone PySide/Qt environment. The repo is organized around host-specific adapters plus shared pipeline/UI code.

2. Top-level package layout

The main runtime code lives under python/vtool. That package contains shared utilities, UI helpers, logging, USD helpers, and several large feature areas: maya_lib, unreal_lib, houdini_lib, process_manager, script_manager, render_farm, and ramen. This makes the package feel like a platform with several app-like modules rather than a single monolith.

3. Primary user-facing entry points

The README points to two main launch paths: Maya users call vtool.maya_lib.ui.tool_manager(), while Unreal users call vtool.ui.process_manager(). That suggests the UI layer is a front door into different workflows, with Maya being the most mature host integration. There are also standalone .pyw launchers under install/ for process and script manager tools.

4. Host integration boundaries

The repo is explicitly split by runtime host:

- maya_lib contains the richest implementation and likely the main production path.

- unreal_lib and houdini_lib provide host-specific APIs, graph helpers, and UI hooks.

- python/vtool/usd.py and host-specific usd.py modules indicate shared USD-related workflows adapted per host.

This host split is the main architectural boundary: shared UI/workflow code above, app-specific scene manipulation below.

5. Shared infrastructure layer

Common support code is centralized in util.py, util_file.py, util_math.py, data.py, qt.py, qt_ui.py, logger.py, and logging.json. These modules likely provide cross-platform helpers for filesystem work, math, logging, and Qt abstraction so the higher-level tools can stay host-agnostic where possible.

6. Maya subsystem

maya_lib is the largest subsystem and appears to cover the full Maya-facing stack: animation, attributes, curves, deformations, shading, rigs, spaces, corrective workflows, picking, geometry, and expressions. It also has its own UI stack in ui.py, ui_core.py, and ui_lib/ with feature-specific panels like animation, character, rig, corrective, model, and picker tools. This is the clearest sign that Maya is the core production environment.

7. Ramen: rig logic / graph system

python/vtool/ramen looks like a platform-neutral rigging/evaluation layer. It includes eval.py, rig modules for Maya/Houdini/Unreal, and a UI library with node-based interfaces. The presence of rigs_crossplatform.py implies Ramen is meant to describe rig behavior once and adapt execution to different DCCs.

8. Process management subsystem

process_manager is a separate workflow application, with modules for processes, batch execution, UI state/options/templates, settings, maintenance, and view/data/code components. This likely acts as the project/task orchestration layer: configuring jobs, managing templates, and packaging execution for different environments.

9. Render-farm / batch execution

render_farm contains Deadline integration and cache-related jobs such as Alembic and Yeti. This suggests a pipeline boundary where local rigging/scene tools hand off longer-running cache or render work to a farm scheduler. Deadline is the main external service implied by the code layout.

10. Script management

script_manager is a smaller but distinct toolset with a script_view.py and installer launcher. It appears to be a generic utility for browsing/running scripts, separate from the process manager and rigging workflows.

11. Configuration, templates, and assets

The repo carries operational assets inside the package: icon resources, curve data (maya_lib/curve_data/default_curves.data), version metadata, stylesheet files, and install-time customization hooks such as __custom__.py.example. These files indicate the tools are configurable and likely rely on local studio setup for branding, paths, or environment overrides.

12. Platform installation and bootstrapping

The install/ directory holds integration glue rather than application logic: Maya userSetup.py, a Houdini .pypanel, and launcher scripts. That means deployment is host-driven: users wire the package into each DCC’s Python path and startup mechanism, then the package opens its own Qt-based interfaces.

13. Documentation and generated docs

docs/ is a full Sphinx documentation tree with custom manuals for UI tabs, pose/joint-orient tutorials, API docs, and build scripts. This indicates the repo is intended as a maintained tool platform with separate developer/user documentation, not just a code drop.

14. Overall data flow

The main flow is: user launches a Qt UI inside a host DCC or standalone, the UI calls into shared tool logic, that logic routes into the appropriate host adapter (maya_lib, unreal_lib, houdini_lib), and then results are written back to the scene, exported data, or farm jobs. Cross-cutting concerns like logging, file utilities, templates, and Deadline integration support that flow across subsystems.