Integrations¶

fxquinox ships a desktop app and DCC integrations for Houdini and Nuke. Like every other surface, they are clients of the API built on the Python SDK - they hold no privileged access and no logic that isn't also available to you.

The publish/load contract¶

All adapters share one host-agnostic core (fxqintegrations.core) so the contract is identical everywhere and testable without any DCC installed:

• publish_scene(...) - publish DCC output as a Product → Version → Representation chain, optionally declaring the input versions it consumed (the lineage DAG). It is a thin wrapper over the SDK's publish().
• resolve_for_load(version_id, rep_name=None) - return the file entries to load for a version's representation, so a host can bring it back in.

A DCC adapter's only job is to gather scene data in the host (the ROP path, the Write node, the frame range) and delegate to this core. That keeps host-specific code thin and the publish behaviour consistent across Houdini, Nuke and anything you add.

Loading shares the same idea: each adapter registers a universal loader for the product types it understands, and the core resolves a version's files and hands them to the host. The path each file lands at comes from the project's anatomy, resolved on the server. The concepts behind that contract — anatomy and path resolution, the universal loader, scene inventory, the render farm and multi-site sync — are in Pipeline APIs.