This system converts Parasolid CAD into production meshes through a persistent Pixyz translation service. It is designed for deterministic throughput at scale, with profile-driven LOD outputs that feed downstream USD assembly authoring for both real-time and offline rendering pipelines.
Overview
Meshing is the conversion boundary between engineering truth and downstream usability. This pipeline treats translation as a production service, not a one-off export, so it can run reliably under batch workloads and constant revision pressure.
- Input: Parasolid geometry extracted from CAD (with STEP as a fallback path when needed).
- Translation: Pixyz is used as the meshing engine via its API, wrapped behind a unified interface.
- Output: deterministic mesh artifacts authored into multiple LODs and prepared for downstream USD assembly ingestion.
The goal is predictable, repeatable translation that scales across large batches without manual babysitting.
Service Architecture
Pixyz is operated as a long-running server that listens for client requests over sockets. A dedicated controller application manages Pixyz lifecycle (startup, shutdown, and configuration) and provides bi-directional communication between Pixyz and the build system.
- Persistent Pixyz session: Pixyz stays alive across a batch, avoiding repeated startup overhead.
- Controller responsibility: job dispatch, state management, error handling, and Pixyz process control.
- Unified meshing interface: Pixyz API operations are exposed through a single contract, not ad hoc scripts.
Why This Split Exists
Deadline is designed to terminate each task’s process tree after completion. If a Deadline task were to launch Pixyz directly, Pixyz would be torn down after each task. That creates unnecessary overhead and reduces throughput when processing large batches.
- Constraint: Deadline tasks are short-lived and their process trees are terminated after execution.
- Failure mode: launching Pixyz per-task results in repeated startup and teardown, wasting time and increasing instability.
- Solution: a persistent service model keeps Pixyz alive while tasks submit work through the controller.
This design turns translation into an operational service that can process many assets efficiently instead of paying a startup cost per work item.
LOD Authoring Strategy
Instead of relying on a single adaptive LOD output, this pipeline generates multiple straight LODs from Pixyz and then mixes them in Houdini using object-oriented bounding box metrics. This supports predefined LOD profiles that can be generated in one pass and tuned for different downstream targets.
- Straight LOD stacks: generate multiple discrete LODs from Pixyz in a controlled, repeatable way.
- Houdini remix: recombine LODs by OOBB-driven heuristics to create predictable profiles.
- Multi-target outputs: enables profiles for real-time interactive applications and offline rendering.
The result is deterministic LOD behavior that can be standardized across product lines rather than tuned by hand per asset.
Cross LOD Properties for Tooling and Selection
LOD changes should not break tooling. In addition to generating multiple LODs, this pipeline preserves cross LOD properties that remain stable as topology changes. These properties become reliable hooks for selection sets, filtering, and downstream automation, regardless of which LOD is active.
- Stable identifiers: author persistent IDs and group tags that map back to the same conceptual regions across all LODs.
- Tool friendly selections: properties are designed to support selection workflows (by region, component class, functional surface) without relying on topology.
- Deterministic transfer: cross LOD properties are propagated from a known source definition so results rebuild the same way every time.
- Downstream leverage: enables consistent material assignment, masking, QA checks, and interactive highlighting across real time and offline targets.
This turns LODs into a single coherent asset family. Downstream tools can target intent level properties instead of fragile per mesh selections.
Ownership
This meshing system is engineered and operated as part of the end-to-end CAD-to-USD pipeline. I built the controller architecture, the Pixyz API interface layer, and the orchestration hooks that allow translation to run reliably under Deadline-driven batch workloads.
- Architecture ownership: designed the service split (PDG/Deadline → controller → Pixyz) to preserve session persistence and throughput.
- API integration: implemented a unified meshing interface around Pixyz to keep translation behavior consistent and maintainable.
- Deterministic outputs: authored an LOD strategy that supports standardized profiles for both real-time and offline consumers.
- Operational reliability: manages lifecycle control, error handling, and batch execution behavior as production requirements.
The outcome is not just meshing. It is controlled translation that can run at scale and feed a consistent downstream USD product archive.