Exporter Reference
Limitations and Known Issues
Review the current exporter boundaries around feature coverage, authored scene data, and optional compression or extension workflows.
General Limitations
- Optional extension output still depends on how the scene is authored and whether the required data exists in supported nodes.
Texture and Compression Limitations
- KTX2 workflows depend on the available texture-conversion toolchain in your environment.
- Draco compression depends on the bundled or discoverable Draco runtime.
- Converted textures can increase export time, especially on larger scenes.
KHR_texture_transformrotation is not supported foraiImagenodes. ForaiImagenodes, rotation is skipped entirely.KHR_texture_transformUV Rotation: UV rotation is exported with pivot compensation forplace2dTexturenodes (Maya rotates around UV center(0.5, 0.5)whileKHR_texture_transformrotates around origin(0, 0), and the exporter adjusts the offset to compensate). However, runtime support forKHR_texture_transformrotation is not working as expected. Other transform properties — repeat (tiling), offset, and scale — are exported correctly and are not affected.
Round-Trip Limitations
- Quad-topology round trip requires compatible Maya-specific metadata in the file.
- Material variants only round-trip when their scene metadata and alternate materials are preserved.
- Texture-transform round trip is most reliable when the importer used Maya
fileandplace2dTexturenodes.
Gaussian Splat Limitations
- Gaussian splat export requires the external
gaussianSplatplug-in and an available export bridge. - If the bridge is unavailable, splat shapes are skipped instead of blocking the rest of the export.
Animation Limitations
- Time Editor export is powerful but more complex than straightforward keyed export, so it should be validated in target runtimes.
- Downstream viewers may differ in how they handle visibility-related extension data.