Files
tinyusdz/doc/REFACTOR_TODO.md
Syoyo Fujita 1d290767fd Add C++ MaterialX import support with built-in secure XML parser
MAJOR UPDATE: Complete MaterialX (.mtlx) file loading support in C++

## Key Changes:

### 1. Built-in MaterialX XML Parser (NEW)
Integrated secure, dependency-free parser from sandbox:
- src/mtlx-xml-tokenizer.{hh,cc} - Low-level XML tokenization
- src/mtlx-simple-parser.{hh,cc} - Lightweight DOM builder
- src/mtlx-dom.{hh,cc} - MaterialX-specific document model
- src/mtlx-usd-adapter.hh - pugixml-compatible adapter

**Benefits:**
- No external dependencies (replaces pugixml)
- Security focused: memory limits, bounds checking, XXE protection
- MaterialX optimized
- pugixml-compatible API for easy migration

**Security Features:**
- Max name length: 256 chars
- Max string: 64KB
- Max text: 1MB
- Max nesting: 1000 levels
- Safe entity handling
- No external file access

### 2. OpenPBR Surface Shader Support (NEW)
Added complete MtlxOpenPBRSurface struct to usdMtlx.hh:
- All 8 parameter groups (Base, Specular, Transmission, Coat, etc.)
- 40+ individual parameters
- Proper USD type mappings
- Type trait registration

### 3. MaterialX Import API (ENHANCED)
Updated src/usdMtlx.cc to use built-in parser:
- Replaced all pugi:: with tinyusdz::mtlx::pugi::
- ReadMaterialXFromString() - Load from XML string
- ReadMaterialXFromFile() - Load from file path
- ToPrimSpec() - Convert MaterialX to USD PrimSpec
- LoadMaterialXFromAsset() - USD asset reference support

### 4. Testing Infrastructure
Added comprehensive test suite:
- tests/feat/mtlx/test_mtlx_import.cc - Import test with examples
- Updated Makefile for both import and export tests
- Test with embedded OpenPBR MaterialX XML
- Command-line file loading support

### 5. Documentation
Created C++_MATERIALX_IMPORT.md with:
- Complete API documentation
- Usage examples for all import methods
- OpenPBR parameter reference
- Security features overview
- Migration guide from pugixml
- Test instructions

Updated MATERIALX-SUPPORT-STATUS.md:
- C++ import status changed from  to 
- Built-in parser feature matrix
- Updated "What's Missing" section
- Comparison table updated

## Supported Features:

### Shader Types:
 OpenPBR Surface (open_pbr_surface) - FULL
 Autodesk Standard Surface (standard_surface) - FULL
 USD Preview Surface (UsdPreviewSurface) - FULL

### MaterialX Versions:
 1.36, 1.37, 1.38

### File Formats:
 .mtlx XML files
 String-based XML
 USD asset references

## Files Changed:
- src/mtlx-*.{hh,cc}: 9 new parser files (+3,500 lines)
- src/usdMtlx.{hh,cc}: OpenPBR support, parser integration
- src/value-types.hh: Added TYPE_ID_IMAGING_MTLX_OPENPBRSURFACE
- tests/feat/mtlx/*: New import test and updated Makefile
- C++_MATERIALX_IMPORT.md: 400+ line documentation
- MATERIALX-SUPPORT-STATUS.md: Updated status

## API Example:

```cpp
#include "usdMtlx.hh"

tinyusdz::MtlxModel mtlx;
std::string warn, err;

// Load from file
bool success = tinyusdz::ReadMaterialXFromFile(
    resolver, "material.mtlx", &mtlx, &warn, &err);

// Convert to USD
tinyusdz::PrimSpec ps;
tinyusdz::ToPrimSpec(mtlx, ps, &err);
```

## Testing:

```bash
cd tests/feat/mtlx
make
./test_mtlx_import
./test_mtlx_import path/to/your.mtlx
```

## Breaking Changes:
NONE - Backward compatible via pugixml adapter

## Migration:
Automatic - existing usdMtlx.cc code works without changes

TinyUSDZ now has COMPLETE MaterialX support at all layers:
 C++ Core (Import & Export)
 WASM Binding (Import & Export)
 Three.js Demo (Full Interactive)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-02 02:55:03 +09:00

1.6 KiB

Refactoring Opportunities

This document outlines potential areas for refactoring in the TinyUSDZ codebase.

Code Duplication

  • prim-types.hh and value-types.hh: There is significant code duplication in these files, particularly in the operator overloads for point3h, point3f, and point3d. This could be consolidated using templates.

Large Classes

  • Prim and Stage: These classes have a large number of responsibilities. Consider breaking them down into smaller, more focused classes to improve modularity and maintainability.

Type-Erased value::Value

  • The value::Value class uses type erasure, which can impact performance and code clarity. Explore alternatives such as std::variant (if C++17 is an option) or a more specialized approach to improve performance and type safety.

Python Bindings

  • The Python bindings in python-bindings.cc could be improved by adding more complete and Pythonic wrappers for the C++ classes and functions.

Tydra Module

  • The tydra module appears to be a separate component for rendering. Consider separating it into its own library to improve modularity.

C-style Casts

  • Replace C-style casts with C++-style casts (e.g., static_cast, reinterpret_cast) to improve type safety.

Use of std::vector for Fixed-Size Arrays

  • In cases where std::vector is used for fixed-size arrays, it would be more efficient to use std::array.

Lack of Comments

  • Some parts of the code could benefit from more comments to explain the intent and logic, especially in complex areas.