AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-14: Digital Garden by Alicia.

When I'm building digitalgarden.si, an interactive 3D garden, the slow part is rarely sculpting one more flower. Claude Code is what I use on the Houdini side, with hython in the terminal: exports come out with the wrong up-axis, USD layer names don't match, and a batch of assets all need the same attribute changed.

That's where Claude Code for 3D work earns its place. It reads and writes the scripts in your shot folder, runs hython in the terminal, reads the error, fixes the script, and runs it again.

People in the English-speaking Claude Code crowd already make this point: if you treat it like a normal coding chatbot, you're wasting it. The difference comes from the system you build around it: persistent conventions, commands it can run, and output you can check.¹²

It won't click nodes in your viewport for you, and it won't deliver finished shots on its own. You still decide whether the shot looks good. The agent writes the repetitive glue code, gets it running, and fixes it until it passes a minimum check list.¹³

A script partner, not a viewport clicker

Compared with asking a question in a browser chat and pasting the answer into a Wrangle, there are three main differences.

1. It can see your repo. Your existing exporters, naming rules, and past mistakes become context. It doesn't have to guess from zero every time.¹
2. It can run code and read the errors back. The script goes through the terminal, the traceback comes back, and it gets fixed. You don't just get a block of code that looks right.¹
3. CLAUDE.md pins your conventions to every session. Write the axis, units, and Houdini version down once, and you get fewer Maya-flavored hou calls.¹⁴

Houdini users on Reddit are fairly practical about this. With docs for the right version, Claude often writes usable VEX and Python. It still hallucinates, so you need to be able to check node and parameter names. One user tried a Houdini MCP over a weekend and found that most of the time it was faster to ask, then do the work themselves. Their studio's security policy wouldn't allow it anyway.⁵

For most artists, I'd suggest this order: get the no-MCP, terminal-only setup working first. Then decide whether you want live session control at all.

The agent can't move your mouse. What you can reliably hand off is text: VEX drafts, hou scripts, hython / hbatch / husk commands, and written node recipes you wire up yourself.³

In one line: you're the director and the reviewer. Claude Code is a TD assistant that edits scripts, runs commands, and reads logs. It is not an auto-clicker.

What goes in the CLAUDE.md at your repo root

Anthropic's docs describe CLAUDE.md as persistent project instructions the agent reads at the start of every session. Specific and short works better than vague lines like "write high-quality code." It's context, not a sandbox. If a path really must be off-limits, you still need permissions, hooks, or similar mechanisms.⁴

The Retrodeck guide makes a related point. Put your Blender or Houdini version, coordinate system (Y-up or Z-up), units, asset naming, and entry points in the repo root. That's what stops basic failures like Maya-flavored code or assuming centimeters by default.¹

Here's a TEMPLATE. Change the versions and paths for your own machine. It is not a log from a real run.

# CLAUDE.md — Houdini shot / asset pipeline (TEMPLATE)

## Stack (pin versions; don't let the model guess)
- Houdini: 20.5.x (or your actual version)
- Python: the hython that ships with that version
- USD / Solaris: does this project require a layer naming prefix?
- Downstream: Unreal / real-time preview (if any)

## Axis and units (prevents wrong-axis exports)
- Scene up-axis: Y-up (or Z-up — pick one and write it down)
- Units: meters (or centimeters — pick one and write it down)
- Export to Unreal: state whether an extra rotation / scale convention applies
- Never: assume Maya-style transforms by default; if unsure, ask first

## Naming
- Shots: `shots/SH####/`
- Caches: `cache/<asset>/<version>/`
- Suggested USD asset prim: `/World/Assets/<Name>`
- Never ship meaningless names like `geo1` / `null2`

## What the agent may / may not do
- May: edit scripts under `pipeline/` and `shots/*/scripts/`; run `hython` smoke tests on a single asset
- May not: delete caches, touch secrets, submit to the farm without confirmation, edit a `.hip` that has no backup

## How to run
- Smoke test: `hython path/to/script.py`
- One asset first, then the batch
- After every change: print axis check / bbox / whether all material slot names are present

## Minimum human checks
- Do axis and scale look right at a glance?
- Are any materials or attributes missing?
- Was an error swallowed and reported as a fake success?

Make each line something you can verify. "Print the world transform before export" beats "be careful with coordinates." The docs also suggest moving multi-step procedures into skills or path-specific rules, so CLAUDE.md doesn't grow into an encyclopedia.⁴

The Claude Code Houdini loop: write, run hython, read the error, fix

Without MCP, the terminal already covers most of the pipeline glue:

• Write or edit scripts for export, renaming, USD layer checks, and pre-publish validation.
• Run hython script.py, or hython scene.hip, to get an environment with hou loaded.
• Use hbatch for HScript. When you need them, hrender, or husk on exported USD. Check the flags against the docs for your installed version.³

The loop looks like this. Treat it as an EXAMPLE workflow pattern, not a measured timing or a hardware spec from any machine.

1. You describe the goal: read the asset list from the shot folder, export Alembic or USD, and print the world transforms.
2. The agent writes the script in pipeline/, reusing your existing naming functions where it can.
3. You or the agent run hython export_one.py, on one asset first.
4. Read stderr and the exit code: missing node, wrong parm name, path that doesn't exist, license message.
5. Fix it and rerun the same asset. Once that passes, widen it to a batch over the folder.

The Terminal Skills page has a useful reminder. Node type names and internal parameter names change between versions. Read them from the current session or the docs for your version. Don't let the model recite them from memory. Python is good for managing scenes and files; big per-point loops belong in VEX.³

EXAMPLE: fixing an export script with a flipped axis

This is a reusable workflow story pattern. It's made up but common. It is not a claim that this ran on a specific machine yesterday.

• Symptom: In the downstream engine, garden props are lying on their side, or the scale is off by an order of magnitude.
• Common causes: The script hard-codes rotations from another DCC's habits. Units drift between meters and centimeters. CLAUDE.md doesn't state the up-axis, so the model falls back on Maya assumptions.¹
• Fix:
  1. Open the repo-root conventions and confirm the up-axis and units.
  2. Apply the project's conversion once, before export, instead of hand-fixing each asset.
  3. At the end of the script, print the rotation, scale, and bbox.
  4. Compare a single hero asset in the Houdini viewport and downstream.
• Check: The same asset stands upright at the same scale. Only after one asset passes do you let the batch run.

One artist on X said they aren't very familiar with Houdini but used Claude Code to help run a sim and export Alembic caches for an ML Deformer workflow on the Unreal side.⁶ Same direction: scripts and exports. The agent isn't doing the art direction. Opening that export in Unreal is a different check. The Houdini to Unreal USD test measures a composed stage and a baked HDA, including units, materials and instance counts. The simulation cook is separate again. A Houdini ML volume upres log starts from a small Pyro cache, compares pretrained 2× and 3× density, and only then runs a short training pass.

Optional: Houdini MCP and skills, and the risks

In Claude Code, MCP is a channel for external tools. Once a server is connected, the agent can call whatever that server exposes. Configuration has scopes such as local, project, and user, and you can check status with /mcp.⁷

There are already several open-source projects that connect Houdini to MCP, covering things like creating nodes, changing parameters, running Python or HScript, and even grabbing viewport screenshots. Creators on X have shown Claude Code + MCP + Houdini experiments such as camera-path work.⁸⁹

I am not vouching for the security or production readiness of any third-party MCP server. Their architectures differ (local sockets, RPyC, a built-in web server, and so on), and the permission surface is usually large. If it can execute code, it can change your scene. The Reddit thread also has first-hand reports of "slow" and "my company won't allow it."⁵

Before you connect one, use this table to check the impulse:

The skill route packages Houdini command-line and VEX conventions as instructions the agent can read. That's more controllable than remote-controlling the whole desktop, because it mainly changes how the agent writes text. It doesn't hand over full-scene RPC by default. Which skill to install, and whether to trust it, is still on you: check where the files come from. This article doesn't rank vendors.³

High-return tasks: start with these

Pick work that is tedious, repetitive, clearly specified, and easy to catch when it goes wrong. The Retrodeck guide calls this pipeline plumbing, as opposed to "modeling for you."¹

High return:

• VEX / Attribute Wrangle drafts (you paste them into the node and cook them yourself)
• Batch renaming, path rewriting, cache folder cleanup
• FBX / Alembic / USD exporters, plus checks that material slots and key attributes are all there
• USD layer and prim naming validation
• Pre-publish checks: scale, naming, empty materials, a policy for obvious broken geometry (a check script, not automatic retopology)
• Small hython smoke-test scripts, instead of sending the whole shot to the farm on day one

Low return or high risk:

• Asking the agent to "tweak it in the viewport until it feels right"
• Large overwrite-to-disk jobs with no review
• Handing the only copy of a production shot file to an unattended rewrite

Rule of thumb: VEX handles per-element work. Python and hou build networks and manage files. You look at the result.³

Security red lines: paths and secrets the agent stays away from

• Secrets and accounts: API keys, farm credentials, cloud storage tokens. Keep them out of the chat and out of any CLAUDE.md you commit. When they're needed, use local environment variables or your existing secrets manager, and don't let the agent print them.
• Write scope: By default, only pipeline/, scripts/, and clearly marked temp output. Production caches and publish folders need a human to confirm.
• Licenses: hython, hbatch, and import hou take a license. For long-running services, release it the way the docs allow.³
• Untrusted .hip / .hda files: They can carry scripts that run on load. Don't let the agent open files you don't know.³
• Convention isn't enforcement: "Don't delete" in CLAUDE.md is only a reminder. Actual blocking takes tool permissions, hooks, or OS permissions.⁴
• Small before big: Every batch job starts on one file. Talk about unattended runs only once you can undo or roll back from version control.

How this splits with Meshy and ComfyUI

Short version: generation belongs to generation tools; glue belongs to the scripting agent.

• ComfyUI 3D: Text-to-mesh or image-to-mesh, multi-view shape exploration. That's the front half of the pipeline. A ComfyUI 3D workflow test took one TRELLIS.2 draft through remesh, decimation and a GLB check in Blender and Houdini. A generated mesh is not the same as something ready for a game or a real-time garden.
• Meshy and similar generators: Shape iteration on the web or generation side. I won't compare vendors here; the point is just to keep it separate from the scripting agent that comes after. A later Meshy free-to-Houdini cleanup downloaded one Meshy 6 Lite GLB, rejected a cleanup that opened holes, and reduced the accepted mesh to 3,000 triangles before instancing it.
• Claude Code + Houdini: Batch processing after cleanup, exports, USD packaging, naming validation, publish checks. The back half of the pipeline.
• On YouTube, the more common demos are Claude Code + Blender MCP building scenes or filling them with props.¹⁰¹¹ That's live DCC control plus generation. It complements a script loop in your shot folder. Don't judge them by the same metric. Public tests of Gemini 4 Argon for Three.js include a Blender MCP path toward an AI-generated 3D scene, and they still need a human check before anything ships.
• A machine-skill with Codex test built two Three.js pump simulations from that skill. Codex was the host, not Claude Code, and the solvers still needed corrections before the numbers and cutaways agreed. A later Claude Code and Codex wind task gave both tools the same frozen Three.js plant, then checked the unchanged builds on WebGPU and WebGL2.

The garden itself (for example, this interactive 3D garden) makes a good practice ground. Take one plant or prop all the way through script, hython, and opening the result to look at it. The OpenUSD in Three.js note is that kind of check: a headless hython Solaris export, then the browser load. The OpenUSD beginner stage is the smaller file exercise underneath it: references, a payload and a season variant. Then think about batching a full set of seasonal assets. For work in progress, follow @EmberAtelier on X.

FAQ

How is Claude Code for 3D different from asking a chatbot and copying the code?

A browser chat gives you a snippet. Claude Code edits, runs, and reads errors against your actual folder, and CLAUDE.md remembers your team's axis and naming. The more real context it has, the more useful it gets.¹⁴

Without MCP, which Houdini tasks can Claude Code handle from the terminal?

Anything you can write as Python or hou and run with hython, hbatch, or husk: exports, checks, batch renames, smoke-test render scripts, reading cook errors and fixing them. Clicking in the viewport, tuning parameters by feel, and final artistic judgment are still yours. That's the honest scope of a Claude Code Houdini setup.³

How do I stop the agent from writing wrong-axis or Maya-flavored code?

Pin the up-axis and units in CLAUDE.md. Print transforms at the end of export scripts. Compare a single asset downstream first. Explicitly forbid "assume Maya." Read node and parameter names from the session for your version.¹³

What's the minimum a human should check?

Axis and scale. Whether materials and key attributes survived. Whether a file reports a successful exit code but is empty. And open the result and look at it. Assembling a scene without looking at it is a common way agents fail.¹²

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-14: Digital Garden by Alicia.

Gemini 4 Argon is an AI model in Google's Gemini family, released on October 13, 2026. This article collects public community tests of the model generating Three.js scenes, including workflows that drive Blender MCP. It is written for digitalgarden.si, an interactive 3D garden built with Three.js.

First, the ground rules. I didn't test Argon myself. This post collects tests other people published. Every case below names the author and links to the original post, and I only describe what each person actually showed. If a post didn't mention frame rate or failures, I don't guess.

Second, some context. digitalgarden.si is an interactive 3D garden built with Three.js. I didn't build it with Argon. But because I work in Three.js every day, my question is narrow: how far is an AI-generated Three.js scene from something you could ship?

What the official post says

I'm only using Google's own announcement here,¹ and only the parts that touch 3D.

• Google says Argon improves on earlier Gemini models in spatial reasoning, mathematical precision, and "visual coding."
• Googlers use Argon inside Antigravity, with slash commands like /goal and multi-agent loops with custom skills, to prototype 3D visualizations, games, and interactive animations. The output is vanilla code that renders directly in the browser.
• One demo, Desk Racer, turned pictures of a real desk into a playable miniature racing game. Blender MCP modeled and collision-checked the desk objects, room, and track. Nano Banana made the textures. Three.js handled the physics and custom shaders, with car engine audio from Gemini Omni Flash.
• Another demo built a pagoda temple complex in Blender, using multi-agent visual critique loops.
• In a third, Argon wrote Python scripts to procedurally sculpt, rig, animate, and PBR-bake a 3D game, then wired it for the web in Three.js with GLSL shaders and shatter physics.
• A Gothic scene started from a single Nano Banana image, with Argon driving Blender MCP in an autonomous loop.

Note the word Google uses: prototype. That's their framing, not mine. And these are Google's own showcase pieces, not independent tests.

The community cases

Case 1: Margarita slosh, four models side by side (@ann_nnng)

Task. Ann Nguyen (@ann_nnng) tested the same effect, liquid sloshing in a margarita glass, with Argon, Muse Wonder, Claude Opus 5.5, and GPT 6 Astra.²

Result. She reports that all four used Three.js with WebGL. Her verdict was one line: Gemini has "improved so much."

Failure points. None stated. It's one person's visual comparison. The post gives no frame rate, no code, and no detail on how many runs each model got. It's a useful vibe check, not a benchmark.

Case 2: A fluffy pumpkin with no Blender (@thebuggeddev)

Task. The Bugged Dev (@thebuggeddev) had Argon make a fluffy pumpkin plushie without using Blender at all.³

Result. By his description, it's a procedural GLB model with volumetric fur shells, GPU-instanced fur strands, and real-time air-jet physics, built with Three.js and GLSL. You can blow the fur around in real time. In a reply, he explained that Argon generated the meshes mathematically and packed them directly into binary glTF 2.0 with Python.⁴

Failure points. He didn't mention any.

Case 3: A turbofan engine and a Rubik's cube robot (@ai_for_success)

Task. Ashutosh Shrivastava (@ai_for_success) posted two builds. In one, he asked Argon for a high-bypass turbofan jet engine using Blender and Three.js.⁵ In the other, Argon in Antigravity built a whole project: robot arms modeled in Blender, then a 3D simulation in Three.js. He says Gemini then solved the cube through the Interactions API.⁶

Result. Two videos, both following the same route: model in Blender, show it in Three.js.

Failure points. Neither post mentions any.

Case 4: A flying dragon (@ashen_one)

Task. @ashen_one made a flying dragon test and said everything was custom-made, with no premade animations and no video generation.⁷

Result. The mesh came from Tripo 3D. He's specific that he drove Tripo through browser control, not MCP. Then Blender MCP and Argon took it from there. His own take: "not bad for one shot?"

Failure points. None stated, but note what this shows: Argon didn't make the model. The mesh and the motion came from different tools.

Case 5: A storm lighthouse in one HTML file (@YFarmX)

Task. @YFarmX had Argon build a storm-lashed lighthouse in a single HTML file.⁸

Result. Real-time Three.js with no image files. The island, waves, and lightning are all generated in code. By the author's own count, the whole chat used about 87k tokens.

Failure points. None mentioned in the post.

Case 6: A sneaker from primitives (Creative AI News)

Task. The Creative AI News staff gave Argon and Gemini 3.1 Pro the same prompt, once each: a single web page with a 3D sneaker on a round pedestal, soft studio light, slow rotation, and drag to look around. No 3D files allowed, so the shoe had to be built from simple shapes in Three.js.⁹

Result. Argon produced a rounded sole, a tongue, laces, and a heel loop on an orange-trimmed pedestal. It also added a product title nobody asked for. Both pages opened without errors.

Failure points. The toe is boxy and the spin is very slow. The writers said themselves that neither shoe "would pass for a real product render," and called it a first look, not a benchmark.

Recurring problems

Six cases is a small set, but a few patterns show up.

1. Failures are mostly unreported. Of the six, only the one written up by a publication, Creative AI News, lists concrete flaws.⁹ The X posts show the result and stop. That doesn't mean nothing went wrong. It means you can't tell from the post.
2. Close isn't finished. The sneaker test is the clearest look at quality: recognizable, but boxy in places and not product-render grade.⁹
3. Argon didn't always make the assets. The dragon mesh came from Tripo.⁷ Before you judge a demo, work out which step the model actually did.
4. The samples are tiny. Every test here is a single post or a single run per model. Nobody published repeat runs.
5. Setups are hard to reproduce. XiaoHu wrote a step-by-step guide to Google's Desk Racer demo and found that the headless Blender MCP configuration used in that demo wasn't published. The guide uses the community mcp-for-blender add-on instead.¹⁰ If you try to repeat a demo, expect your setup to differ.

The Blender MCP to Three.js asset route

Two routes come up again and again.

• Route A: through Blender. Argon runs Python through Blender MCP, models in Blender, exports GLB, and Three.js loads it. That's how Google describes Desk Racer,¹ and the XiaoHu guide spells out the same split: Blender MCP models through Python scripts and exports GLB props, and Three.js loads, renders, and handles driving physics.¹⁰ Cases 3 and 4 also go through Blender.⁵⁶⁷
• Route B: skip Blender. Argon writes Python that generates glTF directly,⁴ or builds everything in code inside one HTML file.⁸⁹

Here's how I'd choose. If the asset needs to stay editable, or another artist will pick it up later, use Route A. You get a .blend file you can open and fix. If it's a one-off effect or an atmosphere piece, Route B is fine. There's no file to hand off, but there's also less to set up.

Checklist before you start:

• Which Blender MCP implementation, and which port? Google's demo setup wasn't published; the XiaoHu guide's add-on defaults to local port 9876.¹⁰
• Do the exported GLB's units, orientation, and up-axis match your Three.js scene?
• Are colliders built separately, or are you colliding against the render mesh?
• Where do textures come from: Nano Banana, procedural, or hand-painted?

Performance and accessibility: still human work

This part is my own checklist from Three.js projects. It doesn't come from the tests above. None of the cases reported mobile performance or accessibility, so treat these as open items for any AI-generated scene.

Performance:

• Test the frame rate on mid- and low-end phones, not just the author's desktop recording.
• Count draw calls. Merge meshes where you can and use instancing for repeated objects.
• Compress textures (KTX2) and geometry (Draco or Meshopt).
• Dispose geometry, materials, and textures when the page is left or the scene unloads.
• Make post-processing like bloom something you can turn off.

Accessibility:

• Respect prefers-reduced-motion: reduce or stop automatic animation.
• Support keyboard controls, not just mouse dragging.
• Give the canvas a text description, and don't put key information only inside the 3D view.
• Limit how often things flash. The lightning in a storm scene is exactly where this matters.

How it splits with a Claude Code workflow

I wrote earlier about Claude Code for 3D artists and a real Houdini pipeline setup. Looking at these community cases, here's how I'd split the work for now:

• Argon: go from a photo, sketch, or one-line idea to a playable prototype fast, to check whether an idea works. Use it to run Blender MCP for a first pass on assets.
• Claude Code: refactoring inside an existing codebase, pipeline scripts, performance work, and anything that needs long-term maintenance.
• A person: lighting, materials, how interaction feels, the performance budget, and accessibility.

Image-to-mesh is a separate front end from either of those tools. A tested ComfyUI prop workflow still had to remesh, decimate and reopen the GLB in Blender and Houdini before the generated draft counted as a prop. A downloaded Meshy 6 Lite model needed the same kind of Houdini cleanup before Three.js instanced it.

This split is a suggestion based on public material. It is not a head-to-head test of the two tools. A separate machine-skill with Codex test built two Three.js pump simulations; Codex was the host, not Argon, and those pages still needed human corrections. The Claude Code versus Codex wind comparison is a paired run of those two coding tools on one Three.js plant, with WebGPU and WebGL2 checked independently.

Verdict: prototype yes, production not yet

From the public tests, Argon's strength in Three.js is getting from nothing to something you can see and play with, fast. Google itself frames it as a prototyping tool.¹ The one test that listed flaws found a scene that looked close but not finished,⁹ and none of the posts covered performance or accessibility. Those are still on you.

So I'd use it to sketch, not to ship. Take the prototype, then do the boring parts yourself.

If you want a feel for what a browser scene built with Three.js can be, walk around the virtual garden or try Play. Neither was built with Argon.

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-16: Digital Garden by Alicia.

Can a Houdini Solaris stage reach a Three.js scene without a glTF conversion? Yes, for the features in this small test. On October 16, 2026, I exported a purpose-built Solaris stage and loaded its USDA, USDC and USDZ versions with Hugging Face's @huggingface/usd-web-viewer 0.1.1. Textured geometry, 100 point instances, two instanceable references and the selected look variant survived. A MaterialX-only material became grey, and a curve disappeared with a warning.

This browser test is one of the delivery notes in the rendering guide overview.

I make digitalgarden.si, an interactive 3D garden built with Three.js and Houdini-authored plants. This test ran in an independent local Three.js scene using the garden's Three.js version. It did not replace the live garden's GLB assets or exercise its WebGPU/TSL rendering pipeline. The results below describe this fixture and this machine.

The screenshot shows the local test harness, not the production garden. The grey sphere is an observed material fallback, not an unfinished screenshot.

What I tested

The package's published peer range is >=0.162.0 <0.187.0 for Three.js, so the garden's 0.186.1 fits. Version 0.1.1 is MIT licensed. These are properties of the tested package, not a promise about a future release.¹

The fixture is deliberately simple: a UV-mapped quad with a checker texture and flat normal map; two implicit spheres; a colored cube; a cube with two look variants; a 10 × 10 grid of small cube instances; two instanceable references to an external layer; guide, proxy and render-purpose cubes; and a BasisCurves prim. I also authored a USD camera and light to check whether they appeared in the returned group.

The Solaris export that actually ran

I used Python Script LOP → Configure Layer → USD ROP. The node types in this installation were pythonscript, configurelayer and usd_rop. The Python LOP authored the controlled fixture with OpenUSD APIs. Configure Layer explicitly set Z-up and 0.01 meters per unit. The USD ROP used savestyle = flattenalllayers and defaultprim = World.

This is a reproducible headless Solaris test, rather than a manual Material Library or Karma look-development session. The two materials were authored with UsdShade: one UsdPreviewSurface network and one MaterialX-only surface output. I did not test Karma image matching or a production MaterialX library.

There was a useful authoring catch. My first export retained Z-up but came out with metersPerUnit = 1. Adding the explicit Configure Layer node corrected the exported metadata to 0.01. I reopened all three files through OpenUSD and checked the metadata, variant selection, 100 point placements and two native instances before measuring the browser. Merely setting a value in an intermediate LOP was not enough evidence.

The USD ROP wrote USDA and USDC files. I then packaged the USDC with OpenUSD's UsdUtils.CreateNewUsdzPackage, including its external reference and textures. The ROP's layer-flattening option retained the authored references and variant selection; this was not a fully flattened stage. SideFX documents USD ROP as the Solaris stage export node.²

You can download the tested USDZ fixture and inspect the measurements and object diagnostics. The fixture is test geometry made for this article; it contains no production garden plants.

Load USD into an existing Three.js scene

The loader composes USD using Rust compiled to WebAssembly, runs loading in a worker, and returns a Three.js group. The package also offers a ready-made viewer, but I used loadUsd so the test scene owned its renderer, camera and lights.¹

npm install @huggingface/usd-web-viewer@0.1.1 three@0.186.1

For Vite development, exclude the package from dependency pre-bundling so its worker and WASM asset URLs remain usable.¹

export default {
  optimizeDeps: { exclude: ['@huggingface/usd-web-viewer'] }
};

This is the load pattern used in the test, with cleanup included:

import * as THREE from 'three';
import { loadUsd } from '@huggingface/usd-web-viewer';

const placement = new THREE.Group();
scene.add(placement); // scene, camera and lights already exist

const result = await loadUsd('/fixtures/solaris-test.usdz', {
  textures: 'full',
  maxTriangles: 100000,
  maxInstances: 1000
});

placement.add(result.root);
const textures = await result.complete;
console.log(result.info.warnings, result.info.materialKinds, textures);

// When this stage is no longer needed:
// scene.remove(placement);
// result.dispose();

The example adds explicit limits suitable for this small fixture; the recorded measurements used the loader's defaults. complete waits for textures after geometry becomes available. Keep a separate placement group: the returned root already carries the source-unit scale and up-axis rotation. In my test, its scale was [0.01, 0.01, 0.01] and its X rotation was -π/2. Overwriting those transforms would undo the conversion.

What survived, and what did not

All three formats produced the same feature results. The returned diagnostics counted 108 mesh instances, eight geometries, nine materials and 3,182 triangles, with zero missing layers. The 100-copy grid was one actual THREE.InstancedMesh; the diagnostic mesh count should not be read as a draw-call count.

The flat normal map tests whether the normal-map path is loaded, not the quality of detailed normal shading. The reference test checks that both objects survive; it does not establish that every native-instance pattern is GPU-instanced. The variant test checks an authored selection at load time, not a live JavaScript variant switch. Those references and variants were already composed before export. The OpenUSD beginner stage is the smaller Solaris exercise for that composition: five files, a payload and a season variant, with no browser loader involved.

The loader reported:

{
  "materialKinds": { "preview": 1, "displayColor": 7, "fallback": 1 },
  "upAxis": "Z",
  "metersPerUnit": 0.01
}

There were exactly two warning codes: prim-unsupported for /World/UnsupportedCurve and material-fallback for /World/Looks/MaterialXOnly. Their full diagnostic messages are preserved in the linked results JSON. They agree with the package's documented warning categories.³

This is why I would check warnings before judging a USD import by its first frame. The stage loaded successfully, but it did not preserve every authored feature.

Measured load times: small local fixture, not a mobile benchmark

After the first USDC load, I ran five sequential loads of each format. The table shows the median of each measurement. Fetches were local and caches were warm; these numbers are not internet delivery times, mobile results or a ranking of the formats on large scenes.

The first USDC load in the session reported 39.1 ms for info.stats.totalMs, 82.3 ms until loadUsd resolved and 87.2 ms until textures completed. I did not clear the browser's entire cache to establish a controlled cold-start experiment. The five raw samples per format are included in the results file.

totalMs is the loader's own statistic. My surrounding performance.now() measurements include more of the call lifecycle, so I report both. The fetch, parse and compose medians are independent medians and should not be added to reconstruct total time. Likewise, wasmMemoryBytes is not total browser or GPU memory.³

For a real garden asset, the next useful test is much larger: plant texture fidelity, many repeated meshes, actual mobile devices and the existing WebGPU/TSL renderer. A seven-kilobyte USDZ cannot answer those questions. Two composed NVIDIA stages later used this same viewer. That direct OpenUSD load of SimReady assets also recorded where Blender, Houdini and usd2gltf stopped preserving materials.

USD or glTF for the garden?

My practical result is that USD is now worth testing as a direct preview path from Solaris. The external reference, selected variant and instancing cases worked in this fixture. The material and geometry omissions also make the boundary clear.

The live garden continues to use its existing GLB pipeline. Khronos describes glTF as a format for efficient runtime 3D asset delivery; that remains a useful fit for a public browser experience.⁴ I did not run a matched Houdini-to-glTF benchmark, so this article makes no USD-versus-GLB speed or size claim. Exporting the already-loaded browser group to GLB would carry forward the import's losses and would not be a fair source-format comparison.

Three.js also provides its own USDLoader addon for USD, USDA, USDC and USDZ.⁵ I did not benchmark it here. Results for one loader should not be assigned to another. A later Houdini USD and glTF test did use that loader on one authored plant pair, exported as GLB, USDC and USDZ. USDLoader kept a single plant and dropped the wind attributes, so the result is a feature failure rather than a speed ranking.

FAQ

Can Three.js load USD files from Houdini?

In this test, yes: Solaris-generated USDA, USDC and a packaged USDZ loaded through usd-web-viewer 0.1.1. The supplied fixture and results let you check the same narrow case.

Does a successful load mean MaterialX works?

No. My MaterialX-only sphere rendered grey and produced a warning. The UsdPreviewSurface checker panel worked. Test the actual material network you intend to ship. Unreal accepted an embedded MaterialX surface in a separate Houdini to Unreal test after the shader input used the MaterialX name and the mtlx context was selected.

Why do normals disappear in preview mode?

The package's preview mode omits normal maps.³ My full-mode load attached a normalMap; the preview-mode load did not. Request full mode when that map matters.

Does this show that USD will make the phone garden faster?

No. These are desktop localhost measurements of a small diagnostic scene. No iPhone, Android, Safari or production-garden frame-rate claim follows from them.

What would I test next?

One real Houdini plant, its actual textures, a controlled glTF comparison and both garden rendering backends. The Claude Code and Houdini workflow is how I keep these experiments repeatable: run the script, inspect the output, then decide what belongs in production.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-18: Digital Garden by Alicia.

Codex can use machine-skill to build an interactive Three.js machine. My two pump tests also needed corrections before their numbers, cutaways and controls told a consistent story. On October 18, 2026, I used the skill in a Codex desktop conversation on my Windows workstation, built a hand-cranked gear pump and a rain-barrel irrigation rig, and checked the resulting pages in Chromium.

The useful result is an editable explanation: turn the handle, expose a pump chamber, change the water level and inspect the equations. The result does not establish that either pump would perform this way in hardware. The dimensions and operating constants below describe deliberately constructed teaching fixtures.

I make digitalgarden.si, an interactive 3D garden. This experiment ran separately from the live garden. Its renderer, plants and sound were not replaced.

What I actually ran

The original brief suggested Claude Code. I changed the test host to Codex and read the same machine-skill instructions and reference example. I did not run Claude, compare models, or measure a one-prompt success rate.

This was an iterative build in one conversation. The prompts supplied the machines and questions; Codex then authored their geometry and solvers, ran checks and repaired the output. A multi-stage build should not be described as an untouched one-line result.

Using this Claude-oriented skill with Codex

The upstream README explicitly includes Codex among hosts that can read SKILL.md.¹ I cloned that repository into an isolated experiment folder and had Codex read the file directly. I did not test automatic discovery, a slash command or a global installation.

For a project-scoped setup, OpenAI documents .agents/skills as a Codex skill location.² A reproducible placement is:

git clone https://github.com/AirsupHQ/machine-skill.git .agents/skills/machine
git -C .agents/skills/machine checkout e0bd066ac5beaf48512935de2fc0f0e55636853a

Then explicitly ask Codex to read that SKILL.md and build the machine. Claude's /reload-skills instruction is not part of this tested Codex workflow.

The page contains the kit and machine code inline, but imports Three.js and fonts over the network. A single HTML file is convenient to move; it is not a fully offline package. These are purpose-written mathematical models and kinematic animations, without a general contact solver.¹

Test 1: a hand-cranked gear pump

The task I used was:

Use machine-skill with Codex: a hand-cranked gear pump with a 4:1 spur gear reduction, slow it down so I can see the teeth mesh, and say what breaks if I crank it dry.

The input pinion has 20 teeth and the reduction wheel 80. At module 0.005 m, their pitch radii are 0.05 m and 0.20 m, giving a 0.25 m centre distance. The two pump gears have 16 teeth each. The display slows rotation by 1:8 while leaving the reported rpm and flow on the solver's time scale.

At 60 hand-crank rpm, the model produces 15 pump rpm and 0.153 L/min. That value follows the declared displacement of 12 mL/revolution and assumed volumetric efficiency of 0.85:

pump rpm = crank rpm / 4
flow (L/min) = 12 × pump rpm × 0.85 / 1000

I checked inputs of 0, 30, 60 and 120 rpm, the actual animation's inverse rotation ratio and phase relationship, and the modelled centre distance. Those checks passed. The gear helper itself describes its tooth profile as involute-like: seeing teeth pass one another is not proof of a manufactured involute pair or solved tooth contact.

The first dry-running model had a more revealing error. Its friction and cooling assumptions put the equilibrium temperature below the chosen 85 °C failure threshold, even at maximum crank speed. The failure could never occur. The corrected example declares a smaller illustrative seal thermal mass of 0.5 J/K and cooling of 0.02 W/K, alongside 1.6 N m friction. Removing water now gives zero water flow and a computed temperature that crosses the threshold during the simulated run.

Those constants were selected to demonstrate the thermal equation. The 85 °C threshold is an assumption, not a manufacturer's seal rating, and the test does not predict a real pump's time to damage.

Test 2: rain-barrel drip irrigation

The second task was:

Use machine-skill with Codex: a garden drip irrigation rig fed by a small centrifugal pump from a rain barrel; show flow at each emitter and what happens when the barrel runs low.

This fixture uses a centrifugal pump curve intersected with a system curve. The system includes lift from the barrel, a lumped pipe resistance and four equal emitters. At full speed and a 0.50 m water level, the result is approximately 0.276 L/min total, or 4.14 L/h at each emitter.

H_pump = 3 s² - 0.08 Q²
H_system = 0.75 - h + 0.1 Q² + 10.197 (60 Q / 32)²

Here H and h are metres, Q is L/min and s is speed divided by rated speed. Each emitter is assumed to deliver 8 L/h at 1 bar, with square-root dependence on pressure. The constants describe this fixture; they were not fitted to a measured pump curve.

The automated checks compare the two heads at the operating point and verify that four branch flows sum to the total. At water levels of 4 cm or below, the suction input is considered uncovered and calculated water flow becomes zero. Just above that threshold, flow returns. The Expose the intake button sets the water-level input to 2 cm; it does not bypass the solver and force a decorative failure animation. Reset restores the water and temperature state.

Equal pressure at all four emitters is a simplification. This model does not resolve pressure variations along individual hoses, air entrainment, priming or cavitation. Shaft motion is displayed at 1:80.

What needed fixing

The follow-up work had three goals: audit the equations and failure thresholds; isolate X-ray materials and inspect solid sections; then halve the geometry budget while keeping every registered part and repair the mobile framing. The review also caught an easy-to-miss implementation detail: cloning a material alone did not preserve the kit's custom shader callback and shared clipping planes. Both needed to remain attached.

The original studio palette is still fairly clean. It reads as a mechanical explanation rather than a weathered prop from the garden. Weathering, detailed valves and seal geometry would be further art and engineering work.

Measured performance

The upstream screenshot script initially reported about 2 FPS on this Windows setup. A local change to its browser launcher, adding --use-angle=d3d11, restored hardware rendering and roughly 60 FPS. This is an environment correction, not a claimed benefit of reducing triangles.

The lightweight variant reduces curve segments, tooth-flank samples and bevel detail. It retains the tooth counts and the registered part list. Three one-second animation-frame samples per standard page stayed around 60 FPS at the stated viewport, with no page exceptions in those checks. These short, warm desktop samples do not establish sustained phone performance, startup speed or a rendering limit.

The original narrow layout enlarged the model behind its text. I separated the canvas from the control panel and checked 390 px and 320 px desktop-emulated viewports. That is responsive testing, not a physical-phone acceptance result.

Download, recording and embedding

The demo ZIP contains both HTML pages, the generator, reproduction notes and the upstream licence. Extract it and open either page in a WebGL2 browser with network access. When served over localhost, add ?low=1 to select the lightweight version. The test results JSON preserves the geometry, solver, mode and responsive checks.

I also tested the upstream recording command locally with a Windows launcher adaptation. Both delivered clips are 20 seconds, 960 × 600, H.264 at 15 fps, without music. They use seconds 8–28 of the generated film, beginning with the assembled machine; the full 28-second takes were retained locally. Full decode and the recorder's pink-frame scan passed. These are local delivery files, separate from the desktop FPS measurements; their sizes and hashes are in the result data.

A plain same-origin local iframe loaded the irrigation page in a 390 px viewport. The site's current Content Security Policy, however, explicitly blocks frames. A local copy of that policy blocked the same embed as expected; the production policy also restricts the external script and font sources used by these pages. I have not embedded this renderer in the production garden or changed that policy. The downloadable example and screenshots are the published results.

Merging a generated machine into the garden would require deliberate scene, material and solver integration. For comparison, my Houdini-to-Three.js OpenUSD test deals with importing authored assets. The earlier Claude Code for 3D workflow describes another agent setup; it is not the host used here. A later paired Claude Code and Codex task used one frozen plant-wind starter and checked both untouched outputs on WebGPU and the WebGL2 fallback.

Would I use it again?

Yes, for an inspectable mechanism study or an article that needs moving parts and equations readers can examine. The kit gave the two tests a useful common structure. The more valuable part of the exercise was catching mistakes that a good-looking screenshot concealed: an unreachable failure, a solid block where a pump chamber should be, and transparency shared with unrelated parts.

For a production garden prop, I would still author and review the asset for that scene. For engineering analysis, I would start from measured dimensions and validated component data. This test establishes a working Codex-assisted explanation workflow, with its assumptions left visible.

The next img2interior test with Codex applies that review loop to a Blender-authored room: three output contracts, a 95 MB runtime payload, actual cloth/hem checks and a viewer lifecycle repair.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

Start with the pretrained ML Volume Upres nodes, then train a small model only after the data and inference path work. On this workstation, the native billowy-smoke recipe produced valid 2× and 3× density volumes; the native training recipe also exported an ONNX model that could be run again through the same SOP. The interesting failures were mostly about field selection, environment setup and what a short training run can actually prove.

This is a cook log from Houdini 22.0.429 with a commercial license, OpenUSD 26.5, Windows 11, an AMD Ryzen 9 9950X, 64 GB RAM and an NVIDIA RTX 5070 Ti with 16 GB VRAM. The observed driver was 617.42. Training logs selected CUDA with PyTorch 2.9.0+cu130 in a separate recipe-managed Python environment. GPU inference below explicitly used DirectML where stated; selecting Automatic alone is not proof of which provider was chosen.

Left to right: low resolution, pretrained 2×, pretrained 3×. These are the actual density VDBs at frame 12, rendered in Blender 5.2 with the same camera, lights and volume-shader density. This compares the volume output, not Karma/PyroLook renderer parity.

What the node changes

ML Volume Upres applies a trained ONNX model to a native volume or VDB.¹ It increases spatial resolution and sharpens density detail. The upstream simulation still determines the smoke's motion, shape and interaction with sources or colliders. It is not a replacement for the Pyro solver or a guarantee that a coarse simulation has the dynamics of a high-resolution one.

The distinction matters for the Digital Garden pipeline. If I eventually use a volume element in a shot, I still need to art-direct its source, motion, density and lighting. A sharper cached field is one stage of that work. This is also a different job from image-to-mesh. The ComfyUI 3D workflow cleans a generated prop and checks the GLB in Blender and Houdini; it does not upres a smoke cache.

SideFX's documentation also requires DOP-level permissions even though the inference node lives in SOPs. The documented supported license categories include FX, Apprentice, Indie and Education; Houdini Core is excluded.¹ The local run used the licensed native application, not a Python package that merely resembles a volume operation.

Reproduce the pretrained path

The native sidefx::recipe::pyro::billowysmoke recipe created the source, rasterization, Pyro solver, file-cache node, ml_volumeupres_2x, ml_volumeupres_3x and PyroLook nodes. Both ML nodes were present; the 2× branch feeds the default look path. The pretrained model paths resolve through Houdini's shfs: resources rather than an arbitrary downloaded model.

I set the solver's voxel size to 0.15 and cached frames 1–12 before inference. The first frame took about 1.54 s, followed by roughly 0.06–0.30 s per frame in this small fixture. Total low-resolution cache cook/write time was about 2.56 s. These figures include native geometry access and writing the compressed cache, not just solver time.

For each inference result, I connected a File SOP to the same cached frame. This prevents a live simulation recook from being mistaken for ML inference time.

The dimensions are not exact multiples of the low-resolution active bounds. Sparse-grid resampling, padding and pruning can change those bounds. The voxel transform gives a more useful scale check than demanding old_dimension × factor on every active bounding-box dimension.

CPU and GPU inference on the same input

These are single sequential cook-and-write observations, not medians or isolated-kernel benchmarks. The first Automatic run includes model/provider warm-up. Another editor was open, and no allocator-level peak VRAM measurement was recorded. The table supports the narrow observation that DirectML successfully processed these inputs and the larger 3× CPU cook took longer here. It does not establish a universal acceleration ratio.

The node documentation lists Automatic, CPU, CUDA, DirectML on Windows and CoreML on macOS.¹ This test explicitly exercised CPU and DirectML. CUDA was used by training; CUDA inference was not separately benchmarked, and the Automatic inference provider was not independently identified.

At this render size, both pretrained results show sharper folds than the coarse input, with additional small ridges in the 3× result. That is a visual observation about this frame. A short sequence, an alternate source and a render at the actual delivery size are needed before deciding whether the extra cache and cook cost is worthwhile for a shot.

The field-resolution trap

The recipe's ML selection is @name=density. In the default result, temperature stayed at 0.15 voxel size while density became 0.075 for 2×. Velocity started at 0.30 and also stayed unchanged. Merely seeing a detailed density field does not prove that every companion field has been resampled.

I enabled Naive Upsample Other Fields and selected the fields using the actual primitive-group expression:

@name=temperature @name=vel

Temperature then became approximately 0.075 and velocity approximately 0.15. The velocity field remained coarser than density because the operation scales its existing grid; it does not force every field onto the density transform. Flame, which was empty in this smoke fixture and not selected, retained its source transform.

A string such as temperature vel did not select those named primitives in this test. Check the result's field names and voxel transforms, rather than treating a checked parameter as proof that the intended fields changed. If a downstream operation requires identical transforms, explicitly resample to a reference grid and verify it.

A real, deliberately small training run

The native ML Train Volume Upres recipe supplies a training branch and an inference branch.² I used its own Pyro source, cached high-resolution frames at voxel size 0.075, and fed frames 8–12 to the training subnet.

The first end-to-end cook, including creation and population of the separate Python environment, took about 226.7 s. A second partial cook resumed the checkpoint and completed in 22.2 s. That second number is not the total setup-and-training time, and it includes TOP orchestration rather than isolating the GPU training kernel.

The recipe produced an ONNX graph of 20,304 bytes plus 210,816 bytes of external tensor data, alongside its metadata and checkpoint files. Preserve the external .onnx.data file with the graph. The presence of an .onnx filename by itself is not a complete model-delivery check.

The subsequent inference test loaded that exported model into ML Volume Upres and cooked the same cached low-resolution frame. The final recorded CPU and DirectML cook/write observations were about 0.591 s and 0.517 s, with no node errors or warnings. Both produced a valid density volume at approximately 0.075 voxel size.

What the training run does not establish

Four epochs on ten source tiles are a functional smoke test. They demonstrate dataset export, native CUDA training, checkpoint continuation, ONNX export and independent inference. They do not show that the custom model beats the shipped model or generalizes to fire, mist, wind or collision-heavy smoke. The training log remains resumable; I did not label the model converged.

No model-specific blur or seam failure was established in this small run, so there is no invented before/after model-fix story. Before using a trained model for a shot, hold out frames or another simulation, compare against both the pretrained result and a genuine high-resolution solve, inspect temporal stability, and judge it under the final lighting.

For the comparison image I kept one common Blender shader unchanged. I did not perform a dedicated PyroLook/Karma retuning pass. A denser-looking render may need shader-density or exposure changes, but that decision should follow an actual shot comparison; it is not a mandatory numeric compensation derived from the upres factor.

Deliverables and the next useful test

The experiment archive contains the scripts, compact metrics and the small exported model with its dependencies. Full local simulation caches, Python environment and editable scene files remain in the experiment workspace rather than in the public web download.

Start with pretrained inference, get a reliable cache boundary, inspect every field, and only then train. If the source motion is wrong, fix the simulation. If only the visible density detail is too soft, the upres comparison becomes a meaningful next experiment. The Houdini/Unreal test and OpenUSD beginner stage cover downstream scene organization; neither is a claim that this smoke cache was shipped in the live browser garden.

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

OpenUSD becomes easier to understand when one asset appears twice in a scene and changing its source updates both copies. This experiment does exactly that: a cylinder and sphere stand in for a plant, two references place it in a garden, and a stronger shot layer changes its season.

The practical starting point is five small files, not a production scene. Keep geometry in a payload, give the asset an entry layer with a default prim, reference that entry layer into a layout, and put shot-specific choices in a separate override. The downloadable example was opened and checked with Houdini 22.0.429 and its bundled OpenUSD 26.5 on Windows. The fixture is deliberately schematic; it is not one of the production plants in Digital Garden.

The image is a render of the actual USD stage through Houdini's bundled Storm renderer. Headless Solaris loaded the files through Sublayer LOPs. Composition evidence was read with OpenUSD's property-stack API; this is not a screenshot of the interactive Scene Graph Details panel.

The five-file project

The example archive contains the five authored layers, the native Component Builder output, the test script and measured results. Start with this structure:

garden_usd/
  garden.usda
  autumn_shot.usda
  autumn_overrides.usda
  assets/lily/
    lily.usda
    payload.usda

A layer contains opinions: a radius, a color, a reference, a variant selection. A prim is an item at a path such as /garden/lily_01. A stage is the composed result of opening a root layer and resolving those opinions. Composition is the process that makes those files act like one scene.

An entry layer needs a useful root. The plant file sets defaultPrim = "lily", so a reference can bring in the intended asset without spelling out its root path. This follows OpenUSD's referencing workflow.¹ In the layout, the asset root is remapped from /lily to /garden/lily_01; a second reference maps it to /garden/lily_02.

The geometry layer has a 0.3 m cylinder and a small sphere. It uses Y-up coordinates and meters. The entry file carries a payload and the season variants:

#usda 1.0
(
    defaultPrim = "lily"
    metersPerUnit = 1
    upAxis = "Y"
)
def Xform "lily" (
    kind = "component"
    prepend payload = @./payload.usda@
    variants = { string season = "spring" }
    prepend variantSets = "season"
)
{
    # The complete spring/autumn definitions are in the archive.
}

The geometry is gray in payload.usda. A season variant authors a stronger display-color opinion on the petals. The spring selection yields approximately (0.95, 0.95, 0.9); autumn yields (0.8, 0.55, 0.2).

Reference, payload, sublayer and variant: choose by the edit

A reference is not automatically an instance. The two layout prims reuse the same source, but this particular beginner example does not set instanceable = true. That distinction matters when discussing memory or per-instance editing. For measured native and point instancing, see the separate Houdini to Unreal test.

The shot layer lists the override first and the garden second:

subLayers = [
    @./autumn_overrides.usda@,
    @./garden.usda@
]

The override selects autumn for lily_01. Opening garden.usda gives one spring plant and one autumn plant. Opening autumn_shot.usda gives two autumn plants. Both results were asserted in the bundled OpenUSD API and in the stage returned by a Solaris Sublayer LOP.

Find the opinion that actually wins

When a color appears unchanged, do not start by re-exporting everything. Inspect the attribute's property stack:

attr = stage.GetPrimAtPath(
    "/garden/lily_01/geo/petals"
).GetAttribute("primvars:displayColor")
for spec in attr.GetPropertyStack():
    print(spec.layer.identifier, spec.path)

For the autumn shot, the first color opinion came from /lily{season=autumn}geo/petals in lily.usda. The weaker gray opinion came from payload.usda. The shot layer chooses the variant; the selected variant supplies the color. Those are different contributions.

There is a useful trap here: a local attribute value can override a value authored inside a variant. OpenUSD's own variant tutorial explicitly demonstrates clearing the local value before expecting variant colors to win.² I also hit this while preparing the companion Unreal fixture: a radius authored outside the growth variants kept defeating the bud selection. Clearing that local radius made the visible size change work. That was a fixture authoring error, not an Unreal variant limitation.

Unloading a payload does not mean an empty tree

One claim in the original draft did not survive the test. With Usd.Stage.LoadNone, both plant roots remained, but so did /geo and /geo/petals as over prims introduced by the selected variants. The cylinder stem, defined only in the payload, was absent.

Loading just /garden/lily_01 brought back its stem while the other stem stayed absent. The useful test is therefore whether the payload-defined geometry is populated, not whether every descendant path disappears. Inspect IsDefined(), the prim type and payload state before treating a remaining tree item as loaded geometry.

This difference is easy to miss in a Scene Graph Tree. A prim path can exist because a stronger layer contains opinions for it even when the referenced geometry behind that path is unloaded.

The native Solaris Component Builder version

I built a second version with native nodes: two Component Geometry nodes, Component Geometry Variants and Component Output. Each geometry branch contains the same simple stem and sphere, with a different SOP color. The variant names are spring and autumn under the geo set; these are geometry variants carrying color, rather than a separate MaterialX look-development test.

Component Output wrote lily.usd, payload.usdc, geo.usdc and mtl.usdc. Reopening the entry file returned both variant names, with no final node errors or warnings. SideFX describes this node family as a framework for reusable component models with separated geometry, materials, payloads and variants.³

Use forward slashes in Houdini parameter paths. My first Python pass supplied Windows backslashes to an expression-evaluated parameter and produced escape warnings. Switching to Path.as_posix() removed them. The final downloadable Component Builder output is the corrected run.

What the checks establish

Houdini's installation also includes usdview.cmd and usdchecker.exe. This test invoked usdchecker and used Storm for the render. It did not validate the interactive usdview GUI, compress a five-day learning exercise into a claimed learning outcome, or benchmark a large production stage.

For a first exercise, rebuild this folder, change the second reference's placement, add a winter selection, then create a shot that changes only one plant. If that works, you have used the core ideas rather than merely memorized their names. Keep this separate from format support in a receiving application: the Three.js USD viewer test demonstrates why a valid stage can still lose a material or primitive type in a particular viewer. The two-plant USD and glTF export asks that question of Solaris output loaded by Three.js USDLoader. Two composed NVIDIA packages later posed it at a different scale: the SimReady USD notes record which of Blender, Houdini, usd2gltf and direct loading kept materials.

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

A useful ComfyUI 3D workflow needs an acceptance stage after generation. In this test, TRELLIS.2 produced a 1,175,882-triangle mesh from the official example image. Remeshing, decimation, UV unwrapping and texture baking reduced the deliverable to 19,738 triangles in a 4.55 MB textured GLB. Native Blender and Houdini imports then exposed a second problem: an embedded texture that worked in Blender was not directly usable by this Houdini SOP's generated material.

The test ran on ComfyUI 0.37.0, frontend 1.52.7, PyTorch 2.10.0.dev20251209+cu130 and an RTX 5070 Ti with 16 GB VRAM on Windows. The DCC checks used Blender 5.2.0 LTS and Houdini 22.0.429. This was a local TRELLIS.2 run, not a partner-node credit purchase or a comparison with Meshy, Rodin or Hunyuan. The separate Meshy Houdini cleanup follows that other download path: a free Meshy 6 Lite GLB, a rejected cleanup, and a 3,000-triangle instance in the browser. Mesh generation is not the only local model experiment here. ML volume upres for Pyro applies an ONNX model to cached Houdini smoke instead of turning an image into triangles.

The raw shape on the left is shown with neutral clay; the reduced result on the right has the generated and baked PBR material. The camera, lighting and relative display scale are shared. Because the materials differ, this image demonstrates the delivered stages rather than serving as a controlled shading-quality comparison.

Start with the official graph and one input

I used Comfy's published Pixal3D & TRELLIS.2: Image to Model template and its viking_wolf_rune_axe.png input.¹ That keeps the starting asset and graph identifiable. The axe is a workflow fixture, not a production garden asset or an original character design for sale.

The graph was adapted to select TRELLIS.2 and keep the 512-resolution shape stage. The 1024/1536 upsample branch was omitted for this 16 GB test. This matters: the result should not be described as the unmodified highest-resolution template output.

The active generation path was:

1. Load the input and remove its background with BiRefNet.
2. Center/crop the subject and obtain DINOv3 image conditioning.
3. Sample the sparse structure at 12 steps.
4. Decode the structure and sample shape at 20 steps.
5. Decode the raw mesh.
6. Sample the texture stage at 12 steps and decode the material voxels.

All three sampler seeds were fixed to 42. The model was the official trellis_2_int8_convrot.safetensors distribution, with the shape VAE, texture VAE and DINOv3 encoder identified by the template. The exact submitted API prompt and model hashes are included with the test evidence.

Save the raw mesh before improving it

The raw GLB was 20,790,420 bytes. Blender counted 1,175,882 triangles and no UV layer. Houdini read the same primitive count. A default material slot existed, but the raw shape export did not contain the finished baked texture set.

Do not equate the vertex count across importers. Houdini counted 556,025 points in the raw input, while Blender's import with Merge Vertices enabled yielded 554,859 vertices. The triangle count agreed. Importers may weld or split vertices around normals, UV seams and other attributes; report both the importer and its settings when comparing these figures.

The raw asset is useful as a shape/detail source. It is much heavier than the reduced static-prop target, and it still needs UV and texture delivery. That is why a visually successful preview is only the beginning of the acceptance process.

The cleanup chain that actually ran

The exact prompt records all effective inputs, including remaining template values. The requested triangle target is a budget, not a promise of an exact face count. Unwrapping reported 489 charts and an internal atlas of 1039 × 1026 in this run. That is automatic output; it does not establish good artist-authored seam placement.

The first API submission failed at Remesh Mesh because I encoded its dynamic sign_mode input as a nested object. The running ComfyUI API expected the template's flat selector and prefixed child widget fields. Restoring that representation fixed execution. This was an API-prompt construction error, not a failed TRELLIS.2 generation.

The successful cleanup/texture submission reported 34.38 s of execution and reused already cached structure and shape nodes. A preceding failed submission had already generated and saved the raw shape. Do not quote 34.38 s as an end-to-end cold generation benchmark. Model downloading, startup and cached work are different costs; no isolated peak VRAM measurement was captured.

Blender: verify the actual exported GLB

Blender imported the reduced GLB with a UVMap and its embedded material. With Merge Vertices enabled it counted 9,792 vertices and 19,738 triangles. The studio render above is from the imported file, not ComfyUI's preview framebuffer.

That distinction catches problems a node preview can hide: missing image payloads, unsupported material channels, a wrong pivot or an exporter that saved a different result from the displayed mesh. At minimum, reopen the exact exported path, inspect the material's image nodes and rotate the prop under a new light.

The visual result is promising as a static prop draft. The wolf-head ornaments, handle ends and small carved details still contain soft or irregular forms. The automatic UV layout has many charts. I would not call it a finished hero prop, a deformation-ready mesh or clean subdivision topology based on this test.

Houdini: the embedded-texture failure and its fix

Houdini's glTF SOP loaded both meshes without geometry errors. The cleaned GLB exposed point UVs, normals and tangents, but the SOP warned that embedded images could not be used directly as texture filenames for its generated material.

The fix in this experiment was explicit and reproducible: import that same GLB in Blender and export glTF Separate, producing a .gltf, its binary buffer and external image files. Loading the separate .gltf through Houdini's native glTF SOP then returned no import warnings or errors.

The .gltf descriptor alone was only 2,202 bytes. That is not the asset size: its binary buffer and image files are dependencies. Keep the entire folder together. The original textured GLB remains the convenient single-file web deliverable; the external glTF folder solves this specific Houdini material-import boundary.

After unpacking, I used a uniform transform to make the longest dimension 0.60 m and put the lower Y bound on the ground. Clean and Normal SOPs followed. The final geometry bounds were approximately 0.5994 × 0.6000 × 0.1021 m, with 19,721 primitives after cleanup. The change of 17 triangles is a local cleaning result, not a topology-quality score.

This is one reason to keep the generated raw mesh and a separate cleaned branch. A size or cleanup edit should not destroy the higher-detail source needed for later bakes.

What I would accept before placing it in a scene

1. The exported file reopens independently in the target application.
2. Triangle count, attributes and every texture dependency are recorded.
3. The object has a deliberate physical size, orientation and pivot.
4. Base color is inspected for baked lighting, and roughness/metallic behave under new lights.
5. Small details survive the target camera distance and the chosen polygon budget.
6. Collision, LODs and performance are checked in the actual destination if those are required.

This experiment completed generation, mesh post-processing, texturing, native imports, a render and a 60 cm geometry cleanup. It did not insert the axe into the production interactive garden, build collision or LODs, run animation/deformation acceptance, or compare paid partner models. Those claims require different tests.

For scene packaging after cleanup, the OpenUSD starter example demonstrates references and payloads, while the Houdini to Unreal test checks units, materials and native instancing. Generation supplies one part; a stable pipeline makes that part reusable.

Downloads and licensing scope

The workflow evidence archive contains the exact API prompt, compact measured results and model hashes. The original workflow and example input are linked to their official source rather than presented as my own artwork. The local raw/clean GLBs, external-texture folder and editable DCC scenes are retained for inspection.

Comfy's documentation identifies TRELLIS.2 as the local model for this template.¹ The upstream project publishes its license in its repository.² Paid partner services and other model families have separate access conditions and terms; this run does not establish their cost, availability or commercial permissions.

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

For this Houdini to Three.js test, texture compression changed file size far more than geometry compression. The larger catch was semantic: the tested gltfpack outputs lost the custom attributes needed by wind. I measured export, browser loading and repeated placement separately so a small GLB could not silently pass as a usable plant.

The renderer, format and splat notes that build on this export test are collected in the full rendering guide for the interactive 3D garden.

The fixture is an original procedural grape hyacinth built for this experiment, with 6,056 triangles, one material and an intentionally noisy 2048 × 2048 PNG test texture. It is not a production garden asset or a representative survey of plant textures. Codex executed the scripts and browser checks on 19 October 2026.

Start with the native export

Houdini 22.0.429 used the gltf::2.0 ROP. A single quad exported as two triangles without a separate Divide SOP. Ten packed copies exported as ten meshes and ten nodes, totaling 60,560 triangles. Packing inside Houdini did not create EXT_mesh_gpu_instancing in this output. If the website needs an InstancedMesh, create and verify that runtime representation explicitly.

Custom point attributes used the underscore prefix required by the exporter. The raw GLB contained _STIFF and _PHASE alongside position, normal, color and UV attributes.¹ An initial validator failure exposed zero length normals at degenerate leaf endpoints. I fixed the generator’s normal fallback, exported again and validated the final candidates. That repair is part of the tested result; the first export was not accepted.

File size and attribute survival

The native Draco export used Houdini. The other candidates used the official Windows gltfpack 1.3.0 binary or glTF Transform CLI 4.5.1. Sizes are actual file bytes, shown as decimal MB. Every final GLB passed the glTF validator with zero errors; nonblocking unused data and extension warnings are retained in the evidence.

The browser used Three.js 0.186.1, its Draco and Basis decoders, and MeshoptDecoder on WebGPU. Each row used five distinct local HTTP URLs. Timing covered fetch, parse, decode, compile and the first submitted frame. Decoder code and GPU pipelines were warm. These are localhost observations with frame scheduling granularity, not production network, device cold start or GPU completion timings. A separate WebGL2 check also loaded the 2048 KTX2 candidate and reported the same 12 BC7 mip levels and 5,592,432 uploaded bytes.

Draco reduced this texture dominated file by only about 1.6%. KTX2 plus a smaller texture had a much larger effect, but those gltfpack candidates failed the wind attribute requirement. The -kv experiment did not rescue the unknown attributes. The glTF Transform Meshopt candidate retained them, using generic attribute quantization at 12 bits. Attribute presence still does not guarantee sufficient numerical precision for every shader; inspect the decoded values and appearance before release. A later Three.js GLB loading test separated cache, decoding and the first GPU frame on a texture-free plant. Meshopt reduced that file from 319,648 to 130,296 bytes with identical decoded attributes, and the fresh-URL first-frame median fell from 35.7 ms to 17.6 ms. Those twenty rows use a different protocol from this warm, texture-dominated table.

Commands and their limits

The tested gltfpack commands were:

gltfpack -i plant-raw.glb -o plant-pack.glb -cc -ce ext
gltfpack -i plant-raw.glb -o plant-ktx2.glb -cc -ce ext -tc -tj 4
gltfpack -i plant-raw.glb -o plant-1024.glb -cc -ce ext -tc -tj 4 -tl 1024

The tested texture size option was -tl 1024. These commands use EXT_meshopt_compression explicitly and the binary’s built in texture encoder.² I did not install or benchmark a separate toktx conversion. The alternate Meshopt command was:

gltf-transform meshopt plant-raw.glb plant-transform.glb --level high

The vertex color candidate removed the image entirely and encoded phase/stiffness into red/green channels. It is a data transport probe, not an accepted visual replacement: a material that displays those channels as ordinary vertex color will tint the plant. A deliberate vertex color palette can suit stylized plants, but it cannot preserve details that existed only in the texture. A later Houdini versus Geometry Nodes plant export kept three vertex-color groups on one shared material. The first Blender Geometry Nodes file wrote a valid GLB that had lost its green stem and foliage colors; the corrected export kept all three groups.

Uploaded texture data is a separate budget

The 2048 PNG expands to an estimated 22,369,620 bytes for an RGBA8 texture and full mip chain. The actual BC7 KTX2 mip arrays totaled 5,592,432 bytes at 2048 and 1,398,128 bytes at 1024. Those totals describe uploaded mip data. They do not measure total process VRAM, decoder scratch space, staging allocations or driver overhead.

The visual check matters as much as this arithmetic. Downsizing the artificial high frequency texture changes its fine detail; the smaller candidate should not be described as visually identical. Real foliage needs its own close and distant views, especially around alpha edges.

One thousand plants: count the draws

A second test repeated the plant 1,000 times at 1280 × 720, DPR 1, with a 30 second orbit after warmup. All paths used the same simple material settings and stayed close to the display’s 60 Hz ceiling on the RTX 5070 Ti.

The totals include a final output pass, which adds one call and one triangle. In the pinned WebGPU backend, the tested BatchedMesh path loops over draw commands. Its class name did not imply a single GPU draw. Merging reduced calls but duplicates vertex data; instancing shares geometry. The LOD row replaces the whole patch with its authored lower detail model, not a per instance LOD algorithm. The same question, across classic WebGL and the node renderer, is in the nine-path WebGPU and WebGL comparison.

The practical acceptance rule is to check file size, decoded attributes, material appearance and runtime counters together. A later Houdini USD to GLB test made the same distinction on NVIDIA SimReady geometry: optimizing a broken export cleared the reported index errors only by changing the mesh, so the untouched geometry snapshot was the file that passed first. The small reproducible experiment includes the measurements and owned generator. Continue with procedural plants and wind or the complete garden pipeline. Production models were not replaced by these test outputs.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

The interactive garden starts in Houdini and runs in Three.js. Houdini makes the plant geometry and its deformation attributes; the browser places, lights and animates those plants. On 19 October 2026, I tested the current garden code on both WebGPU and WebGL2, then built a separate small plant to check the export pipeline. The useful result is a working authoring boundary, not a claim that switching APIs makes every scene faster.

This note is part of the Three.js 3D garden rendering guide, which groups the renderer, plant, format and splat tests in reading order.

What the browser actually renders

The garden has four seasonal compositions, day and night transitions, shader driven wind, plant interaction and a photography mode. It uses Three.js 0.186.1 and TSL materials. The renderer is WebGPURenderer, which can use its WebGPU backend or its WebGL2 fallback. The active backend is checked after renderer initialization; the constructor name alone cannot establish which one ran.¹

Houdini exports reusable plant assets rather than a giant frozen scene. The browser owns placement, camera movement, screen space detail decisions and interactions. That keeps artistic geometry work in the DCC while allowing the website to respond without a Houdini installation. A stem is authored once and placed many times. Its wind attributes describe how it may deform; they do not contain a frame by frame animation cache.

The production wind system keeps roots fixed and bends a shared stem while preserving coherent flower heads. It also deforms normals. The small downloadable experiment uses a much simpler sine displacement to make attribute loss easy to see. Its shader is a teaching fixture, not the production wind implementation. A later MuTracer WebGPU path tracer test rendered a frozen Houdini plant as a still: vertex colors, three instances and alpha masks survived on WebGPU, and the WebGL attempt lost its context. That image does not convert the animated wind in this garden.

A measured comparison of the current garden

I imported the existing Experience module from source commit 9c25ecc6ab2e into a local measurement harness. Each backend ran the same 30 second partial orbit after a 1.5 second warmup. The canvas was 1920 × 1080 at device pixel ratio 1; the browser viewport was 1280 × 900 so the desktop scene policy stayed active. The spring scene contained 162,420 plant placements.

The machine used an NVIDIA RTX 5070 Ti. The in app browser reported Chromium 155; WebGPU reported NVIDIA Blackwell, and the WebGL2 fallback reported ANGLE over Direct3D 11. Both tabs were visible. Other applications were not closed, and this was one sample per backend.

WebGL2 was faster in this particular run. The display was close to a 60 Hz ceiling, the detail scheduler was active, and the triangle totals vary slightly as detail transitions settle. These measurements do not isolate API overhead or establish a universal winner. They do establish that both backends render the current garden and that this scene does not justify an unconditional “WebGPU is faster” headline.

Both runs reused 36 assets from the browser’s garden cache, with zero model downloads. First frame observations were 1.59 seconds for WebGPU and 10.81 seconds for WebGL2. Those are single initialization observations with different backend pipeline work, not controlled cold load or CDN benchmarks. They should not be used to predict a visitor’s loading time. A later Three.js GLB cache benchmark published twenty controlled rows for one texture-free plant, separating a fresh URL from an immediate cache hit. It does not replace these single garden initialization observations. A later desktop profile counted the garden’s full transfer, including seasons loaded after the first frame, and set the spring scene beside a procedural city built at runtime. Both ran at 1920×1080 on WebGPU; they are different scenes, not a controlled pipeline comparison.

Where the scene budget goes

Instancing shares a plant geometry across many placements. It does not eliminate triangle processing, alpha testing or pixel shading. In the separate 1,000 plant fixture, 6,056 triangles per plant still produced about 6.06 million scene triangles. Reducing the plant to 2,116 triangles brought that to about 2.12 million. Both configurations remained near 60 FPS on this desktop, so the geometry reduction is clearer evidence than a rounded FPS comparison. A later WebGPU and WebGL plant matrix repeated one plant as separate meshes, InstancedMesh and BatchedMesh on three renderer paths, and compared submission cost with the actual draw counters.

The garden’s current desktop policy keeps two decoded seasons resident and uses a bounded 160 MiB model cache on disk. Background preparation pauses around activity and photography. The ordinary scene has a scene pass and bloom; depth of field belongs to photography mode. These are deliberate budgets and lifecycle choices, not benefits supplied automatically by WebGPU.

Reversed depth is enabled only for the actual WebGPU backend in this project. Earlier fallback testing produced a blank post processing result with the reversed path. That is a project compatibility decision, not a general statement that WebGL2 cannot support any reversed depth technique.

Test the boundary before scaling the garden

The companion export test caught a practical failure: native Houdini GLB and the tested glTF Transform Meshopt path preserved _STIFF and _PHASE, while the tested gltfpack paths dropped them. A smaller file that loses the data required by wind is not an accepted replacement. The production garden assets were preserved during this experiment.

The most useful sequence is to validate one plant, reopen its editable Houdini scene, inspect the exported attributes, load the compressed candidate with the real browser decoders, and only then test repeated placements. A renderer screenshot alone cannot prove that deformation data survived compression.

Read the measured details in Houdini glTF optimization, procedural plants and wind attributes, and Gaussian splats in Three.js. The Gaussian article uses a separate synthetic fixture; splats are not part of the production garden. A later Spark versus GaussianSplats3D integration ran that fixture on native Three.js, Spark and GaussianSplats3D, and recorded which encodings actually drew.

Reproduce the experiment and understand its limits

A later free PINOC / JST-2 garden test places an actual million-point SPZ environment beside an owned Houdini plant. It reports native WebGPU, native WebGL2 and Spark results, with a separate renderer-integration failure. That backdrop remains an independent research fixture.

Codex executed the native scripts and browser checks. The compact measurement receipts preserve versions, counts and methods alongside the rendered evidence.

The experiment download contains the original small plant generator, compact results, owned fixtures and independent asset/splat viewers. It excludes the private garden engine and production models. The full garden measurements are supplied as dated results with their method, not as a promise that the private application is included in the download.

No physical phone was tested. Responsive layout checks are not phone GPU tests. I also did not record historical TSL migration hours, measure total driver VRAM, or test every browser version. Those remain unmeasured rather than being filled with estimates. The concrete outcome is a working current garden on both backends, and a set of smaller tests that expose where its asset pipeline can fail.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-20: Digital Garden by Alicia.

The free route worked, with an important boundary: Meshy 3D Agent could not select Meshy 6 Lite, and the Agent's higher-tier generated models were not downloadable on this free account. I used the regular Text to 3D tool with 6 Lite, downloaded a real GLB, and tested the Houdini-to-browser pipeline from that file. This article is a free-workflow test, not a paid Agent export demonstration.

The other plant asset and renderer tests are collected in the garden's Three.js rendering overview.

Codex operated Meshy's web UI, Houdini 22.0.429 and the Three.js acceptance viewer on 20 October 2026. The account was already logged in by its owner. No paid subscription was purchased.

Verify the download before spending credits

Meshy's current free-plan help described 100 monthly credits and 10 monthly downloads limited to Meshy 6 Lite. The Agent model selector offered higher-tier models, but no Lite option; its chat answer also directed the free-download workflow to the regular generator. I checked the actual selector and download controls rather than treating the chat answer as proof.¹

The regular Text to 3D panel allowed Meshy 6 Lite, quoted 10 credits and selected CC BY 4.0. The prompt requested one stylized grape hyacinth: a slender green stem, five narrow leaves and hanging purple-blue bells, with no pot, soil or ground plane. One generation completed and the GLB download counter changed from 10 to 9. The account also received a separate 30-credit daily check-in reward, so its final balance of 120 is not the generation cost.

The page displayed a notice that Text to 3D would be retired on 31 October. That is a dated UI observation, not a promise that this exact free path will still exist afterward. Recheck access and download entitlement before a new batch; do not spend a session generating models that the account cannot export.

What the downloaded file actually contained

The GLB was 784,708 bytes, with 21,781 vertices and 43,546 triangles. Its only mesh attribute was POSITION. It contained no UVs, normals, material images or PBR materials. The requested flower colours therefore did not arrive as a textured deliverable. It was a geometry result, not a ready botanical asset with verified species anatomy.

Houdini's imported and unpacked geometry had 13 connected components, zero boundary edges and zero edges shared by more than two faces. Those checks do not prove there are no self-intersections, that all parts form one connected object, or that it is ready for printing. The website's printable badge is not substituted for those measurements.

The original file was preserved. Derived copies were centered in X/Z, placed at ground height and normalized to 0.6 units tall. The later browser inspection applies a common neutral material, with computed display normals where needed; that material is not a generated Meshy texture.

A failed cleanup made the tolerance problem visible

The first Clean/PolyDoctor chain used defaults after the 0.6-unit normalization. It removed much of the thin geometry: only 23,817 triangles remained, with 11,625 boundary edges and 69 components. I rejected it. A smaller file with more holes is not an accepted cleanup.

The accepted Clean degeneracy tolerance was reduced to 1e-12. Potential overlap/intersection conditions were marked rather than silently repaired. The accepted cleanup preserved all 43,546 triangles and the original closed-edge/component counts. SideFX documents that Clean's degeneracy tolerance is an edge-length measure whose square is compared with area; scale matters.²

PolyReduce then used its actual Output Polygon Count target with finalcount=3000. Merely writing a count while leaving its target on percentage would not activate that target. The remesh branch used target size 0.006 and five iterations. Its loss of some leaf width is visible and consistent with the changed bounds, so it is not called visually identical.

All derived branches received a six-plane UV unwrap and computed normals before native GLB export. That creates inspectable UVs; it is not a hand-authored low-distortion UV layout. There was no source PBR image to rebake, so I did not invent a texture-baking success. The HIP was saved, reopened and cooked again.

Validate the browser deliverable

The source and final GLBs passed glTF validation with zero errors and warnings; informational and buffer-view hints remain in the receipts. Three.js 0.186.1 loaded each candidate through five unique localhost URLs. Timings include parsing, compilation and a submitted frame with warm code/GPU pipelines, not public-network or device-cold time.

Adding UVs and normals makes the full-resolution derived file larger than the position-only download; reduction and attribute creation are different operations. The 3,000-triangle candidate was repeated 1,000 times with explicit InstancedMesh: the receipt records 2 total render calls and 3,000,001 triangles, including the node renderer's output pass. Instancing shares data but does not remove the repeated triangle workload. Both WebGPU and forced WebGL2 fallback were checked.

An independently authored Houdini hyacinth is included as a reference for geometry budget and visible structure, not as botanical ground truth or a blinded aesthetic comparison. The free AI result still needs art direction, material work, appropriate deformation attributes and a scene-specific acceptance check before replacing a production garden asset.

Reproduce it and retain attribution

The asset-test package contains the original free download, derived meshes, Houdini scripts, viewer and results. The Meshy source and its derivatives retain CC BY 4.0 attribution: model created with Meshy by Alicia. The package includes the license link and records the modifications. It does not grant rights to the private garden engine or its production models.³

For a procedural alternative with explicit shape controls and wind data, read the Houdini plant test. For the runtime budget, continue with the nine-path instancing matrix.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-20: Digital Garden by Alicia.

With this plant fixture, instancing reduced draw submission on every tested backend. Switching to WebGPU did not produce a meaningful FPS lead: all nine paths were close to the display's 60 Hz ceiling. The useful distinction was the submitted representation and the work inside renderer.render(), rather than the API name.

For the related asset, format and splat experiments, see the Three.js 3D garden rendering guide.

This test supports the Houdini asset workflow behind Alicia's interactive 3D garden. Codex operated the independent scripts and browser on 20 October 2026. It did not change the production garden or benchmark a physical phone.

What was kept equal

Three.js was pinned to 0.186.1. One owned procedural grape hyacinth supplied 6,056 triangles, repeated 1,000 times: 6,056,000 scene triangles. The same placement matrices, geometry, unlit vertex colours, double-sided material, camera path and bounded root-anchored sine displacement were used throughout. The classic renderer used an equivalent GLSL injection; the node renderer used TSL. This is a small teaching wind, not the garden's production deformation and normal system.

The three renderer paths were classic WebGLRenderer, WebGPURenderer on actual WebGPU, and WebGPURenderer with forceWebGL enabled. Each used separate Mesh objects, InstancedMesh, then BatchedMesh. The active backend was inspected after initialization; a WebGPURenderer constructor alone does not prove WebGPU ran.¹

The canvas was 1280 × 720 at renderer DPR 1, without antialiasing. The browser reported Chromium 155 on Windows and an RTX 5070 Ti. Each accepted cell ran three complete 10-second warm-ups, discarded, followed by five complete 10-second measurements along the same partial orbit. The archived results report the median of each run's summary. The slowest 1% of frame intervals define the 1% low FPS.

Frustum culling was disabled for every object; BatchedMesh per-object culling and sorting were disabled too. That keeps the submitted set equal. It also means this is not a comparison of each class's default visibility policy. Other applications remained open; these are workstation observations rather than isolated maximum-throughput measurements. GPU experiments ran sequentially. Draw representation and counters are clearer evidence than small cross-backend timing differences under background load.

The first full matrix used random Y rotations and 20-second trials. Review caught a parity problem: classic GLSL displaced before instancing, while TSL positionNode ran after the instance/batch transform. The same expression could therefore bend in different world directions. I preserved that matrix as a rejected comparison, removed rotations from all nine paths, and reran the complete matrix with 10-second trials. The chart and archived tables use only this matched-transform rerun. This shorter run does not certify long-duration frame pacing.

Full dataset and 10k/100k runs

The current tables and machine-readable measurements live in the Three.js plant instancing benchmark v1, with 1k, 10k and 100k tests, static and moving cameras, and explicit failed trials. The v1 page reruns 1k using at least five seconds and 300 warm-up frames followed by thirty seconds or 1,800 intervals, with five repeats and alternating backend order. Each sample uses a new visible test document. It does not reuse this article's shorter measurements.

This article and its chart retain the findings of the 20 October nine-path test. Its historical numbers and original protocol remain in the original measurement archive. The two protocols must not be pooled into one performance table.

The node renderer's totals include its final output pass, adding one call and one triangle. Classic WebGL's counters do not contain that extra pass. Neither counter should be relabelled as a direct browser API call count.

The BatchedMesh result is especially useful. In this pinned WebGPU path, the backend loops over the batch's draw commands. Its counter remains at 1,001 calls even though the JavaScript submission can cost much less than traversing 1,000 individual Mesh objects. Classic WebGL used the available multi-draw path and reported one call. A class called BatchedMesh does not guarantee a single draw on every backend.²

InstancedMesh is a clear fit for this repeated identical geometry. BatchedMesh has a different purpose when many geometries share compatible material state; the present one-geometry case does not establish how it behaves in every mixed scene. Merging was not part of this nine-cell matrix.

What the timers do and do not measure

CPU render time surrounds renderer.render(). It includes JavaScript and backend submission work, not completed GPU execution. A separate 30-frame GPU probe used EXT_disjoint_timer_query_webgl2 on classic WebGL and resolveTimestampsAsync on the node backends. Invalid or unavailable samples stay absent in the receipts. Repeated discrete WebGPU probe values are retained as diagnostics, not used to rank small timing differences. The probe is outside the FPS trials and is not total VRAM or end-to-end latency.

Cell setup to first submitted frame was also recorded once per cell, including compilation, after the asset had already loaded. Those values are not device-cold startup or public CDN loading times. A later meshopt GLB loading test times the file itself across twenty WebGPU trials, separating a fresh URL, a cache hit, decoding and the first GPU frame, and it keeps the first-run compilation outlier. JavaScript heap snapshots are process observations without controlled garbage collection, so I do not rank memory efficiency from them.

The display cap hides how much headroom a fast path has. It would be misleading to call 60.00 versus 59.99 FPS a renderer victory, or to extrapolate this desktop result to a phone. This experiment also does not establish a universal instance-count threshold, transparent-foliage overdraw cost or physical-device power consumption. A different workload sits outside this one-plant matrix. The WebGPU performance of two complete scenes profiles slop-newyork and the spring garden at 1080p, where a lower draw-call count did not by itself produce a shorter frame. A still WebGPU plant path tracing test with MuTracer rendered three tinted instances of one Houdini plant. The WebGL attempt lost its context and produced no finished image. Those samples are not rows in this raster matrix.

A separate terrain placement comparison measures the CPU work before rendering: downward rays, BVH, surface sampling and baked Houdini points. Its 70 placement rows are separate from this renderer matrix, and minimum spacing remains a distribution requirement.

Reproduce the actual result

The historical plant matrix archive preserves the pinned 20 October package, owned fixture, harness and all 72 raw trial records. For new measurements, use the v1 harness with updated local tooling. Keep the page visible, run the suite sequentially, and inspect the actual backend and canvas dimensions in each result.

For this garden pipeline, the actionable result is to share repeated geometry, retain wind attributes, and inspect real counters. Continue with export and compression tests, the actual garden integration, or Claude Code and Codex on a smaller wind task.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-20: Digital Garden by Alicia.

The native GLB loaded both plants. The same authored pair, delivered as USDC or USDZ through Three.js USDLoader 0.186.1, loaded only one plant and did not retain the vertex-colour or custom wind attributes. USD retained the authoring concepts in Houdini, but this browser representation failed the pair's feature requirements. That is the main result of this test, not a format-speed victory.

For where this delivery test sits among the other garden experiments, see the rendering guide overview.

Codex ran the native Houdini scripts and browser checks on 20 October 2026. The fixture is an owned procedural grape hyacinth used to study the asset boundary behind digitalgarden.si, Alicia's interactive 3D garden. It is not a production model.

Build a native two-plant fixture

Houdini 22.0.429 generated one 6,056-triangle plant, with normals, UVs, vertex colour and wind attributes. The visible pair places copies at X=0 and X=0.3, for 12,112 triangles. The USD stage contains two seed variants, 11 and 12, and an instanceable internal reference for the second plant. Both variants use 3,838 points and 6,056 triangles per plant, with different procedural leaf shapes.

The USD was authored with pxr under Houdini's hython and composed/read back through a native Solaris Sublayer LOP. It is not claimed to be an automatic Component Builder material conversion. The root layer was exported as USDC; UsdUtils packaged the layer and shared PNG as USDZ. The HIP was saved and reopened, with both variants and the native instance relation verified. OpenUSD reported 0.26.5.

The material probe used UsdPreviewSurface, an sRGB UsdUVTexture and a deliberately noisy 2048 PNG. glTF used Houdini's native principled-material export with the same image. Different exporter mappings can still produce shading differences, so I do not describe the materials as visually identical. MaterialX conversion was not tested.

Two rejected exports mattered

Calling Usd.Stage.Export() flattened the composition and removed the variant set. Exporting the authored root layer preserved it. Flattening can be appropriate for delivery, but it cannot be presented as retaining editable variant structure.

The first packed-copy GLB also contained an unused image entry without a resource URI or buffer view. A downstream tool rejected it. I retained that failure, unpacked the pair before the native glTF ROP, and re-exported. The accepted GLB passed glTF validation with zero errors and warnings; seven buffer-view-target hints remain. The accepted result therefore bakes the two copies into one mesh. That is this exporter path's result, not a limitation imposed by the glTF format.

Packaged bytes and local loading

Three.js 0.186.1 used GLTFLoader or USDLoader in the same classic WebGL viewer, 1280 × 720 at DPR 1. Each format used five distinct loopback URLs. The timer includes fetch, parsing, texture readiness, compilation and a submitted frame, without a GPU completion fence. Code, OS caches and GPU pipelines were warm. USDC's external PNG can be cached, so its timing is a multi-file diagnostic, not directly equivalent to the self-contained GLB/USDZ loads.

The standalone USDC is not a 0.27 MB textured delivery: its external image must be counted. Likewise, a smaller USDZ here does not prove USD is universally smaller than glTF. The two paths encode variants, geometry sharing and custom data differently. The large artificial PNG dominates both packages. More importantly, the loaded USD scene has half the intended triangles, so these timing rows are compatibility diagnostics and cannot be ranked as equal-workload performance.

Inspect the browser objects

The GLB returned 12,112 triangles, UVs, vertex colour, _stiff and _phase. USDC/USDZ returned 6,056 triangles with position, normal and UV only. A texture object was present, but without the authored vertex colour the plant also appeared neutral rather than matching the GLB's colour modulation. A later Houdini plant GLB export from Houdini and Blender Geometry Nodes kept the wind attributes in both accepted files. A Geometry Nodes GLB that lost its foliage colors was rejected even though validation reported no errors. The second instance's absence is a failed rendering requirement, not an optimization. A native USD instance flag does not by itself create Three.js InstancedMesh, and the glTF format's support for an instancing extension does not make this native ROP emit it.

USDComposer's explicit seed selections produced different loaded position hashes in this test. That check uses the pinned parser/composer API and recomposes the stage; it is not a claim that USDLoader supplies a complete interactive variant-switching UI. The separate USDA transform-animation diagnostic exposed 1 clip(s) and numerically changing transforms, but returned 0 mesh objects. It therefore did not pass visible plant-animation acceptance. No skinned or botanical animation export was tested.

Choose the boundary you can validate

The format fixture download includes the owned source generator, portable scripts, accepted files, loader checks and compact results. It also documents the rejected export paths. Bundle costs are measured separately in the receipt; a loader's dependency graph is distinct from asset bytes and from an already-cached application bundle.

For a Houdini authoring pipeline, keep composition and variants where they are needed, then test the specific browser representation that will ship. For repeated identical plants, an explicit runtime instancing step can matter more than the container extension. This test does not cover Quick Look on a physical iPhone, MaterialX, every USD schema, total GPU memory or production network speed. Two NVIDIA packages later followed a different route, USD to GLB in Blender and Houdini, where PreviewSurface textures, a geometry-cache workaround, direct loading and a usd2gltf failure were separate outcomes. Continue with OpenUSD pipeline basics, the earlier USD web-viewer test and measured glTF optimization.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

A procedural plant for the web needs more than an attractive still. It needs repeatable geometry, a stable root, a useful lower detail version and data that survives export. I built an original grape hyacinth fixture in Houdini 22.0.429 and tested it in Three.js 0.186.1 on 19 October 2026. The result is a small working HDA and a browser experiment, with explicit limits around wind, transparency and performance.

This plant fixture is one step in the full rendering guide for the interactive 3D garden.

A small generator with inspectable parameters

The HDA contains a Python SOP that builds a stem, five leaves and eight tiers of five bell shaped flowers. It exposes a seed, LOD, height in meters and stem side count. The tested default is seed 11, height 0.6 meters and eight stem sides. The geometry includes UVs, vertex colors and normals; separate point attributes describe stiffness and wind phase.

One hundred forced seed cooks took 9.38 seconds. These are wall clock measurements of this Python SOP in hython on this workstation. They are not a Houdini Performance Monitor breakdown or a comparison with a compiled SOP implementation. The saved HIP was loaded again for the Gaussian fixture generation, which read the expected plant geometry successfully.

The lower detail plant is authored by reducing generator segments. It is useful for testing a smaller shape, but it is not the production garden’s nested LOD generation and transition system. A distant silhouette can be acceptable even when a close view is visibly coarser. Those acceptance distances belong to each scene and camera.

Bake attributes, then animate in the shader

_STIFF ranges from zero at the base to one toward flexible tips. _PHASE is a stable per plant seed value; seed 11 produces 0.507. In Three.js, the GLTFLoader exposes those attribute names in lowercase. The browser fixture reads _stiff and _phase through TSL.

Its displacement is deliberately simple:

const stiff = attribute('_stiff', 'float');
const phase = attribute('_phase', 'float');
const bend = sin(clock.mul(1.8).add(phase.mul(6.283)))
  .mul(stiff.pow(2)).mul(strength).mul(0.10);
material.positionNode = positionLocal.add(vec3(bend, 0, 0));

Because zero stiffness produces zero displacement, the fixture’s root remains fixed algebraically. This is baked deformation data, not a baked animation. The function offsets points horizontally; it does not preserve stem arc length, solve collisions or correct every shading normal. Calling it a botanical simulation would overstate what was built.

The actual interactive garden uses a more involved shared bend and normal deformation, with coherent flower crowns and per stalk anchors for relevant species. The downloadable shader illustrates the export contract without redistributing that private engine. A copied sine shader should not be mistaken for the whole production animation system.

Attribute survival is an animation test

The native Houdini GLB included _STIFF and _PHASE. So did its Draco export and the tested glTF Transform Meshopt candidate. The gltfpack candidates dropped them, including a run with -kv. That discovery changes which output can be accepted for this shader: a texture optimized file may load successfully while lacking the intended motion data.

In the harness, a missing stiffness attribute falls back to height and a missing phase falls back to a constant. That keeps a comparison visible, but it is not proof of a correct export. A production acceptance check should fail or explicitly flag that fallback. The compression article separates successful decoding from usable deformation attributes.

An earlier native export also failed normal validation at degenerate leaf endpoints. Adding a defined fallback normal corrected the final GLBs. Validation found a problem the distant plant preview did not make obvious. A later Houdini versus Geometry Nodes plant export assembled one controlled plant in both applications. The accepted GLBs corresponded triangle for triangle and kept the wind attributes, after a Geometry Nodes material setup that lost its foliage colors was rejected.

Wind, interaction signals and leaf cards

I tested a 1,000 plant patch at 1280 × 720, DPR 1, on an RTX 5070 Ti in the visible Chromium 155 browser. Each run used 1.5 seconds of warmup and 30 seconds of the same scripted orbit. Wind off and wind on both measured about 59.99 FPS with two total render calls, including the output pass. This ceiling limited observation does not establish the shader’s cost on a phone or at a higher resolution. A later WebGPU versus WebGL plant test kept this plant and separated InstancedMesh, BatchedMesh and one mesh per copy, because a capped frame rate hides the submission difference.

The interaction variant adds a scripted oscillating touch uniform. It also stayed near 59.99 FPS with two calls. It tests a deformation signal without a pointer event, spatial search, collision or input latency measurement. Real garden brushing involves more work and cannot inherit this fixture’s result automatically.

For the alpha test variant, I removed the five solid leaves and added five segmented cards per plant, using an original canvas generated leaf mask and alphaTest = 0.5. This is 5,000 leaf instances in an additional draw: three total calls, 5,936,001 total triangles and 59.99 FPS in the sampled patch. It changes the geometry and shader workload together. It is a practical construction comparison, not a controlled measurement of alpha testing in isolation.

The cards use a hard alpha cutoff rather than blended transparency. Camera angle, double sided rendering, silhouette loss and distant aliasing still need visual inspection. A desktop FPS number does not settle those questions. A later still, MuTracer with a Houdini plant, path-traced double-sided alpha masks and vertex colors on frozen geometry. It does not measure this orbiting patch, and its WebGL run lost the context before a finished image.

For placing those assets, the later uneven-terrain scatter test separates surface attachment from minimum spacing. It uses an independent owned terrain, native Houdini layouts and runtime sampling, including a boundary-ray validator that initially rejected valid points.

Keep the shadow contract explicit

Moving vertices in a color material raises a second question: which positions does the shadow pass use? I captured frozen wind poses with default, explicit rest position and explicit deformed castShadowPositionNode settings. The default and explicit deformed screenshots were identical in the inspected region; forcing rest positions changed 12,014 pixels there. The default worked for this pinned material and renderer. This was not a reproduced default shadow bug.

The production garden’s stylized lighting is a separate implementation. This small directional shadow map test does not certify production shadows or promise correct results for every custom TSL material. Inspect the actual bent silhouette and its ground shadow whenever a deformation changes.

What is included

Codex executed the generator, native export and browser checks; the dated results describe that workstation run.

The experiment package includes the original generator and HDA, compact native and browser results, and a standalone viewer. The large noisy test texture can be regenerated from its seeded script. Editable full HIP files and local capture evidence remain with the project; third party tool binaries and the private garden engine are excluded.

The test proves a seeded Houdini plant can reach the browser with its wind data intact through selected export paths. It does not prove scan quality, biome realism, mobile performance or robust physical bending. It also does not settle code versus Houdini for a finished scene. A later 1080p profile compared this garden with slop-newyork and kept the two pipelines mixed rather than declaring a winner. For the larger context, read the garden pipeline and the separate Gaussian splat compatibility test. That splat fixture is compared again in Spark, GaussianSplats3D and native Three.js.

References

SideFX documents the glTF exporter and custom attribute rules. The browser uses the official Three.js WebGPURenderer. Versions and documentation were checked on 19 October 2026; the download records the exact experiment dependencies.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

Use a USD Stage when you want to retain a composed scene; use Houdini Engine when the deliverable is a procedural tool that should cook and bake inside Unreal. I tested both with independent fixtures: a small referenced flower and a 100-copy scatter. The units, materials and instance counts below are read from native Unreal components, not inferred from a successful file import.

The test used Houdini 22.0.429, its OpenUSD 26.5 build, Unreal Engine 5.8.3 and Unreal's OpenUSD 26.3 build on Windows. The installed Houdini Engine plugin identifies itself as 3.0 - H22.0.429 with version integer 22000429. That local descriptor is the relevant compatibility evidence here; it differs from the plugin-version table in the pre-test draft.

The garden at digitalgarden.si renders in Three.js. These Unreal experiments are separate test assets. They do not migrate the live garden or demonstrate the full Project Titan EVO tool collection.

One fixture per failure

The test archive includes the USD layers, a small packed-scatter HDA and source scripts. The USD stage contains:

• A one-meter cube for units and axis conversion.
• A Preview Surface material and an embedded MaterialX standard surface.
• A separate cube with an unrealMaterial attribute pointing to a native project material.
• A referenced schematic flower with bud and bloom geometry variants.
• A PointInstancer with 100 placements and one prototype.

Houdini opened this stage through a native Sublayer LOP. A separate SOP network packs a simple proxy and copies it onto a 10 × 10 grid. That network becomes the HDA used for the Engine path. The HDA proxy is intentionally simpler than the USD flower: this is a workflow and instance-count comparison, not a matched performance benchmark.

What crosses each boundary

Epic still labels the USD Stage feature Beta in the current 5.8 documentation.¹ Keep that shipping caveat separate from the success of a small editor test. Opening a stage and importing assets are different operations, even when both start from the same file.

Units: the reference cube measured 100 centimeters

The source explicitly declares Y-up and metersPerUnit = 1. In Unreal, the one-meter cube had half-extents (50, 50, 50) cm and its center was at Z = 50 cm. Its source X position of −1.5 m became −150 cm. The source vertical Y direction became Unreal's vertical Z direction.

That is a stronger acceptance check than reading the source metadata alone. Metadata describes how values should be interpreted; it does not repair geometry authored at the wrong scale. Put a real reference object in your fixture and measure the receiving component.

component = usd_actor.get_generated_component("/World/MeterCube")
origin, half_extent, radius = unreal.SystemLibrary.get_component_bounds(component)
# Expected half_extent for a 1 m cube: 50 cm on each axis.

Materials: render context and schema both matter

My first MaterialX definition used a Preview Surface input name: roughness. Interchange correctly rejected it because a MaterialX standard surface expects specular_roughness. After correcting that authored shader input, the same import finished with zero errors. This was a fixture bug. It is not evidence that Unreal cannot import MaterialX.

The context test is also narrower than a full material-match test. It checks native material creation and assignment for an embedded, constant-color standard surface. It does not establish Karma-to-Unreal pixel parity, external .mtlx reference behavior, every texture channel, displacement or a production shader library. Keep a Preview Surface fallback when that is the receiving application's more portable path.

For a native project override, the exact asset path must exist in the receiving project. The test created a green native material in its own Content folder before loading the USD cube. A string that happens to look like a material path is not sufficient evidence of a successful binding.

Count the instance component, not the scene root

The PointInstancer's generated root was a plain SceneComponent. Its descendant Prototype_0 was an InstancedStaticMeshComponent with 100 instances. Looking only at the root, or only at the actors returned by a commandlet's editor actor list, initially hid that result.

root = usd_actor.get_generated_component("/World/Scatter")
for component in root.get_children_components(True):
    if hasattr(component, "get_instance_count"):
        print(component.get_class().get_name(), component.get_instance_count())

The installed version produced ISM, not HISM, for this fixture. Do not turn the documentation's list of supported representations into a promise about the specific class your scene will create. Count it after import and inspect the prototype's actual material assignment.

The HDA path also produced one InstancedStaticMeshComponent containing 100 packed copies. The native material override was authored before packing. This test does not establish arbitrary per-point color propagation across every packing/export combination; a color attribute and a material assignment are different contracts.

A variant failure that was really a composition failure

The first bud selection did nothing. The source sphere already had a local radius opinion outside the growth variants. That stronger opinion defeated the variant-authored radii.

Clearing the local radius before authoring the variants fixed it. In Unreal, the generated flower's X/Y half-extent changed from 12 cm for bloom to 5 cm for bud. Reloading the source root layer restored the on-disk bloom selection and the 12 cm extent. An actor-level translation of 33 cm survived that reload.

This test authored the temporary variant opinion through the native OpenUSD Python API in the Unreal process. It did not prove that a particular USD Stage panel edit is saved into a persistent override layer. If the requirement is to keep an Unreal-authored variant selection across reloads, explicitly choose an edit target, save that layer and reopen it. The beginner stage exercise explains the opinion stack behind this failure.

Cook and bake the HDA

The Engine plugin imported the test HDA, started a matching Houdini session, instantiated it and completed synchronous processing. The cooked actor contained 100 instances. bake_all_outputs() returned true and produced baked output actors.

SideFX's public API documents session management, asset wrappers, synchronous processing and baking.² The installed API still supports instantiate_asset, but marks it deprecated in favor of instantiate. Record that distinction if you adapt this fixture; do not copy a tutorial's method names without checking your installed build.

The bake demonstrates that this small tool can produce native output. It is not a packaged-game test or evidence that a shipped game should cook HDAs at runtime. Reopen and inspect the baked assets without depending on a live Houdini session before accepting that delivery contract.

A checklist that catches more than a successful import

1. Record the Houdini build, receiving UE patch, plugin descriptor and both USD versions.
2. Measure a known object in receiving units and confirm the vertical direction.
3. Test Preview Surface, MaterialX and native overrides separately.
4. Correct shader-schema errors before blaming a render context.
5. Inspect descendant instance components and assert the actual count.
6. Change a variant and measure a geometric consequence.
7. Reload the file and record which source and actor edits survive.
8. Import native assets separately from opening a live stage.
9. Cook and bake an HDA, then inspect the baked deliverable.

All substantive import, component and bake results were obtained in isolated test projects. The production demo project and the live garden's models were not changed. This is an editor pipeline test on one workstation, not a production certification. For the browser destination, the OpenUSD in Three.js experiment records a different set of material and primitive limitations.

References

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-19: Digital Garden by Alicia.

Native Three.js Gaussian splats worked on both WebGPU and WebGL2 in this test, including direct SPZ v4 loading with SPZLoader. Spark 2.3.1 worked with WebGLRenderer, but the tested integration failed with WebGPURenderer. The same real SPZ v4 file failed Spark’s reader with an “Invalid gzip header” error.

For how this splat study relates to the mesh plant notes, see the garden's Three.js rendering overview.

Correction, 20 October 2026: the original article incorrectly stated that the pinned Three.js 0.186.1 package had no SPZLoader. It does include that loader. I have now directly loaded and rendered the original SPZ v4 fixture on native WebGPU and WebGL2. The download viewer and receipts below include this correction; the original 19 October PLY measurements retain their original scope and date.

These findings come from an owned synthetic fixture, tested on 19 October 2026. It contains 12,014 Gaussian points derived from the procedural plant in the previous article, including 500 intentionally placed outliers. It is not a trained capture or a photogrammetry quality benchmark. Its higher spherical harmonic coefficients are all zero, so the results do not validate view dependent appearance.

Pin the renderer and the data

The native path used Three.js 0.186.1 with its GaussianSplat mesh and PLY loader under WebGPURenderer. The fallback used the same renderer with the WebGL backend forced. The Spark path used Spark 2.3.1 with WebGLRenderer, matching its documented setup.¹ All tests ran in a visible Chromium 155 in app browser on an NVIDIA RTX 5070 Ti, at 1280 × 720 and DPR 1.

The PLY generator emitted position, color, opacity, scale, rotation and the expected spherical harmonic fields. The underlying plant produced 11,514 jittered points; the separate 500 red outliers made crop failures easy to detect. Encoding a repeated synthetic shape is much easier than compressing a complex real capture, so this dataset must not be used to advertise a general compression ratio.

What loaded, and what failed

The Spark WebGPU failure was this.renderer.getContext(...).getExtension is not a function. It is evidence about this integration and version, not proof that every future Spark path or adapter must fail. The working WebGLRenderer route remains useful.

Three.js 0.186.1 includes SPZLoader alongside the PLY, SPLAT and KSPLAT loaders. For v4, parsing can be asynchronous; loadAsync handles that path.² The earlier SPZ-to-PLY conversion worked, but it is not required to use this file with the native renderer.

import { SPZLoader } from 'three/addons/loaders/SPZLoader.js';
import { GaussianSplat } from 'three/addons/objects/GaussianSplat.js';

const geometry = await new SPZLoader().loadAsync('fixture-v4.spz');
const splat = new GaussianSplat(geometry);
// Align this converted fixture with its original Y-up PLY scene.
splat.rotation.x = Math.PI;
scene.add(splat);

The Rx180 alignment above is specific to this file’s conversion and our reference scene, not a universal SPZ requirement. After that transform, corresponding decoded centers differed from the original PLY by at most 0.0001221 scene units per component. Both visible browser backends rendered 12,014 points at a 1280 × 720 canvas and renderer pixel ratio 1. Five local load checks per backend passed; this follow-up did not rerun the FPS benchmark or validate nonzero SH appearance.

SPZ v4 is not the old gzip container

I uploaded the owned PLY into Niantic’s official browser utility, downloaded SPZ, and inspected the result. It had an NGSP header, version 4, 12,014 points and 55,323 bytes. Reopening it in the utility showed six streams. The utility then decoded it back to PLY for the native renderer test. No external scan was uploaded or republished.

The official format documentation describes v4’s plain header and Zstandard streams, while earlier versions used gzip.³ That explains why a reader expecting the older container can reject a valid v4 file before rendering starts. It does not mean the SPZ download was corrupt. The exact utility build commit was not exposed in its UI; the record keeps the test date, downloaded file hash and inspected header instead of inventing one.

The unusually small SPZ is a property of this simple synthetic dataset with zero higher SH coefficients. Real captures need separate file size, decoder time and appearance measurements.

Crop in Houdini, then reopen

I used the public GSOPs 3.0.0 HDAs, pinned to commit 46f1756c65d4, in an isolated Houdini 22.0.429 subprocess. Loading only the apparent import/crop/export HDAs initially left missing dependencies. Loading the public dependency set resolved that problem without changing the user’s global Houdini package configuration.

The crop box removed the 500 known outliers. The exported PLY was then imported again: 12,014 input points → 11,514 cropped points → 11,514 reopened points, with no node errors. Some no matching group/attribute export warnings remained and are recorded. This proves the known count crop and round trip, not arbitrary scan cleanup or attribute equivalence for nonzero SH data.⁴

GSOPs is a third party tool with its own license. The download links its official source and pinned version; it does not redistribute the plugin. An external sample marked noncommercial was considered and rejected for this publication. All published splat imagery instead comes from the owned fixture.

Performance and compositing boundaries

Each primary renderer ran a 10 second static view after one second of warmup. All three working paths measured about 59.99 FPS, with 95th percentile frame intervals of 16.7–16.8 ms. Native totals were four render calls and Spark totals were three. At only 12,014 points and a 60 Hz display ceiling, this is a compatibility check, not a large scene throughput ranking.

Five warm local load trials had medians of 116.7 ms for native WebGPU PLY, 76.9 ms for native WebGL2 PLY and 16.7 ms for Spark WebGL PLY. Each includes fetch, parsing, initialization and the first submitted frame. Their pipelines and decoder paths differ; these values do not isolate decoder speed or predict CDN loading.

I also placed opaque red and green mesh references before and behind the splats, then introduced a translucent pink plane. The working paths rendered the opaque controls, but the translucent views differed in brightness and opacity. They did not achieve pixel parity. A scene with layered petals, glass or overlapping translucent materials needs a dedicated sorting and art direction acceptance pass. “It loads” is a much narrower claim than “it composites correctly for every asset.”

Use the test as a compatibility receipt

Codex executed the native scripts, official utility workflow and browser checks. The supplied receipts distinguish a successful render, a known setup error and a load only check.

The experiment download includes owned Gaussian fixtures, generation code, compact receipts and a standalone viewer, updated 20 October. It includes the actual SPZ v4 file, the corrected native loader path and the recorded Spark container failure. The machine-readable results preserve the original measurements and add a separately dated correction. No training run, real capture reconstruction, large splat scene or physical phone was tested. A later Spark and GaussianSplats3D comparison loads this same fixture through native Three.js, Spark and GaussianSplats3D, including KSPLAT and direct SPZ v4, and keeps the combinations that failed to draw.

For mesh plants, start with Houdini procedural geometry and wind and glTF compression. The main garden article explains where those meshes fit. The current production garden remains a mesh based scene; this splat study does not silently replace it.

For a trained sample rather than this synthetic flower, Spirula Studio to Three.js uses the official Mip-NeRF 360 Garden images with supplied camera poses, Vulkan training, a PLY checkpoint and Spark. It documents 100,000 splats and is not a phone capture. For an actual generated environment rather than this synthetic flower, the free PINOC / JST-2 SPZ test uses a million-point garden export. It records native and Spark 2.4.0 loading, opaque plant occlusion and the WebGPURenderer combination that failed. Different input files and package versions are kept separate.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-20: Digital Garden by Alicia.

Claude Code and Codex both completed this small Three.js task and produced builds that passed. Independent browser checks then loaded both unchanged outputs on WebGPU and WebGL2 fallback. This is one paired workflow case study, not evidence that either tool is generally better at 3D work.

For the renderer and asset tests this wind task builds on, see the garden's Three.js rendering overview.

The production garden already has wind. I used a separate frozen starter so that this test would not pretend to add a feature that was already present, expose the private application, or depend on unrelated project history. Codex operated the test and subsequent acceptance checks on 20 October 2026.

The same starter and request

Both tools received the same source files, fixture hashes, pinned Three.js 0.186.1 and Vite 8.3.1 dependencies, AGENTS.md and task prompt. CLAUDE.md contained an AGENTS.md reference. Each started a new noninteractive session with an isolated copy of the frozen repository.

Task A was a bounded sinusoidal X bend driven by the exported _stiff and _phase vertex attributes. Roots with stiffness zero had to stay fixed; maximum displacement at wind=1 had to stay within 0.10 units. The existing Wind slider had to update a GPU uniform, with one InstancedMesh per source primitive and no per-frame matrix rewrites. Task B was a deliberately incorrect albedo texture colour space: fix the colour texture without treating geometry data as sRGB.

The fixture contains 16 instances of an owned 6,056-triangle procedural plant. Its matrices are translations, not arbitrary scaling or rotated parents. The root/bound argument in this article therefore applies to that controlled transform setup. It does not validate a general production wind solver.

Which tools actually ran

The first Codex invocation used the desktop's gpt-6.1-sol default and was rejected before editing because that model was unsupported by this CLI account route. I retained the failure and used a model listed by the CLI's local catalogue. This was a setup correction, not an extra coding attempt on a failed solution. The successful task used the original unchanged starter.¹

The environments and permission profiles differ. Claude used the VPS's existing configuration and encountered command permission denials while inspecting the GLB. It worked around them with shell utilities, and its report disclosed an inspection script written in a temporary directory outside the intended fixture. That is a scope failure worth retaining: a written instruction is not filesystem confinement. Codex used its Windows workspace-write mode. I did not normalize these into an artificial security or speed score.²

What the patches changed

Claude added a sine expression with clamped wind and stiffness, a slider input listener, and the sRGB albedo setting. Codex used the same basic bounded multiplication but relied on the verified fixture's stiffness range and the slider's 0–1 range. Both used phase as radians. The prompt left frequency open, so their selected frequencies differ slightly.

For the actual input domain, sin is bounded by one and both wind/stiffness factors lie between zero and one. Multiplying by 0.10 establishes the maximum X offset; multiplying by zero establishes the fixed root. This is source and data reasoning, not GPU vertex readback. Only Claude's additional clamps defend against a later out-of-range input; Codex's code needs its stated input contract to remain true.

Both outputs changed the albedo to THREE.SRGBColorSpace. The fixture assets, camera, placements, dependency versions and protected instruction files remained unchanged. The paired-task download includes the exact prompt, starter hashes and unmodified source outputs. The public package excludes authentication data, private configuration and raw model transcripts.

Independent browser acceptance

Neither tool claimed to have verified the browser. Both ran npm run build and disclosed that visual testing remained outstanding. I then appended an independent QA wrapper to copies of their unchanged source. The wrapper displays the active backend, uniform value, instance count and texture colour space, and records three 10-second static-camera observations. Its additions are separated from the saved agent patches.

The browser checks used a 960 × 640 canvas at DPR 1. Both outputs loaded on both backends, retained one InstancedMesh with 16 instances, and reported the albedo as sRGB. Moving the slider to 0 and 1 updated the displayed shared uniform; the rendered plants stopped and swayed as expected. Screenshots and DOM receipts are retained. This verifies the fixture's interactive behavior, not production normals, physically preserved stem length or every device.

The observations stayed near the display ceiling, so no FPS winner is inferred. Wall time and token telemetry are retained in the compact evidence, but the accounts, model families, OS, caching and permission delays differ. Subscription telemetry is not an invoice and is not used to estimate comparative cash cost.

What I would carry into a real garden change

The useful common behavior was editing a small explicit task, preserving the asset contract, building, and stating validation limits. The additional operator step was essential: a passing build did not verify WebGPU compilation, the fallback, visible motion or the UI.

For a real change, freeze the task and inputs, record the actual model and execution route, review the diff, and independently test each required backend. This paired run does not test Houdini automation, a large migration, long-term maintenance or general model intelligence. Continue with the full plant submission matrix or the Houdini-oriented Claude Code setup.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-20: Digital Garden by Alicia.

A Gaussian splat viewer must be tested with the renderer and file encoding it will actually use. In this integration test, I compared Spark 2.3.1, GaussianSplats3D 0.4.7 and native Three.js 0.186.1 on the same owned synthetic fixture. The measurements separate successful rendering paths from setup and format failures; they do not rank capture quality.

This integration test is grouped with the other renderer experiments in the garden's Three.js rendering overview.

Codex ran the conversions and browser checks on 20 October 2026. Splats remain a research fixture alongside Alicia's interactive garden, not a production garden feature.

A known input rather than an unknown capture

The fixture contains 12,014 synthetic splats and known outliers. Higher spherical-harmonic coefficients are zero; the KSPLAT conversion explicitly used degree zero. The PLY is 2,981,073 bytes. GaussianSplats3D's public parser and compression-level-1 SplatBufferGenerator produced a 294,024-byte KSPLAT and retained 12,014 splats. The independently converted SPZ v4 fixture is 55,323 bytes.

These are different encodings and compression choices. Their byte counts are not an objective image-quality ranking, and this tiny generated flower does not represent a room scan, reflective object, noisy phone capture or full SH scene. No scanning, training or reconstruction quality is claimed.

All paths used one deduplicated Three.js 0.186.1 installation, the same camera, opaque Houdini plant, orange depth reference, canvas and DPR. Native paths used WebGPURenderer on WebGPU or forced WebGL2. Spark and GaussianSplats3D used classic WebGLRenderer. The accepted GaussianSplats3D DropInViewer path used CPU floating-point sorting and shared-memory workers; the local server supplied COOP/COEP headers.¹

Record which combinations actually load

Each listed file used up to five unique loopback URLs; a failure stops that format's attempts and is retained. Successful load timings include readiness, compilation and a submitted frame. They are warm local observations rather than public CDN throughput or completed GPU timing.

Spark's WebGPURenderer compatibility was checked separately and its failure is retained. That is an observed result of these versions and this renderer integration, not a statement that future Spark versions cannot support WebGPU. Spark's documented quick-start path and renderer design should be read for the tested version.²

The first GaussianSplats3D GPU/integer-sort configuration decoded the expected count but never submitted a visible splat draw. The screenshot contained only the mesh references, and the triangle counter confirmed that absence. I rejected its empty-scene FPS, added a rendering-contribution guard, initialized the DropInViewer with the host renderer before loading, and checked a CPU floating-point-sort branch. Only that branch's visible rerun is included below. This is a compatibility finding for the tested integration, not a claim that the library's GPU sorting is always broken.

Native Three.js 0.186.1 does include SPZLoader. An older assertion that native SPZ loading was absent was wrong and was corrected before this comparison. The SPZ path uses that loader explicitly. This converted Y-up fixture needed an X-axis half-turn to align with its PLY reference; that correction is specific to this file, not a universal SPZ rule.

File-format support alone does not ensure that every encoding works: SPZ versions, compression headers and library versions matter. A failed v4 file load is not turned into a successful PLY result under the same label.

Update, 21 October: a different, million-point SPZ v4 export from free PINOC loaded successfully with Spark 2.4.0 and native Three.js in the JST-2 garden integration test. Both the input and Spark version changed, so that result does not establish which change explains the earlier failure. Spark with WebGPURenderer still failed in the newer test. A later Spirula Studio and Spark test also used Spark 2.4.0, this time on a Vulkan-trained official Garden PLY and the SPZ converted from it. That sample is not this synthetic fixture.

Orbit observations after compatibility

The browser reported Chromium 155 on Windows and an RTX 5070 Ti. Each successful path ran one discarded 20-second warm-up and three measured 20-second half-orbits at 1280 × 720, DPR 1, without antialiasing. This bounded integration protocol replaces the broader unexecuted draft benchmark plan; no three-warm-up/five-run performance claim is made here. Trials ran sequentially after the plant matrix, with visibility guards.

The scene is small and display capped. These figures cannot establish a universal fastest renderer. Gaussian sorting may involve asynchronous worker work outside the measured renderer.render() call; CPU submission time is not total application CPU cost. JavaScript heap is not total VRAM, and there is no controlled memory ranking.

Test depth and transparency separately

The viewer supplies three fixed inspection states: an opaque plant/bar in front, the splats in front, and a translucent petal. Screenshots retain the same references and view. Opaque depth occlusion and mixed transparent compositing are different acceptance questions; a plausible opaque screenshot does not prove globally correct sorting with arbitrary transparent objects. The flower appeared darker under Spark and GaussianSplats3D's tested defaults than under the native path. I did not normalize that into a pixel-quality score or claim colour-management parity.

The fast half-orbit helps expose transient sorting changes, but the saved screenshots are representative frames, not proof that every intermediate ordering is perfect. This test does not certify a general transparency solution or high-motion capture scene. The small fixture and its simple degree-zero colours limit what can be concluded.

Carry a verified integration into the project

The splat comparison download contains the pinned package, known-count fixtures, KSPLAT converter, independent viewer and detailed success/failure receipts. Bundle-export gzip sizes are recorded separately from asset sizes and actual network transfer. Dependencies are installed from their official packages and retain their licenses; no external capture sample is redistributed.

For this garden's current node-renderer stack, native loading is worth testing first because it shares that renderer. Classic-WebGL libraries remain separate viable integration paths where their versions and formats pass. The correct choice follows the required format, renderer, sorting behavior and scene budget. Continue with the earlier Gaussian asset workflow or the plant submission measurements.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-21: Digital Garden by Alicia.

A garden exported from Viggle's free PINOC interface loaded as SPZ v4 in native Three.js 0.186.1 on WebGPU and its WebGL2 fallback, and in Spark 2.4.0 with classic WebGLRenderer. Spark did not initialize with WebGPURenderer in this test. The exported scene contains 1,048,576 Gaussian splats and occupies 17,575,822 bytes. These are measurements from one generated scene, not a claim about every JST-2 output.

Codex operated the browser and ran the local tests for Alicia on 21 October 2026. This is a research fixture beside the interactive garden, not a new feature in the production garden. No paid API, subscription or purchased credits were used.

The earlier synthetic splat tests and the mesh plant notes are collected in the Three.js 3D garden rendering guide.

What the free PINOC session actually produced

Viggle presents JST-2 as a world model, and PINOC is its browser interface.¹ I used this prompt:

Make an environment: a compact peaceful botanical garden at eye level, with a curving narrow pale gravel path through dense blue grape hyacinths, pink tulips, green leaves and soft grass. Low flower beds in the foreground, a small weathered stone border, distant leafy trees. Soft overcast daylight, natural botanical colors, realistic spatial depth, no people, no text or logos. Keep an open patch beside the path for adding a separate 3D plant mesh.

The free balance went from 60 to 43 credits: five for the initial generation and three each for four automatic filling passes. The agent kept trying to repair gaps, so I stopped that sequence after the fourth pass. This is the observed cost of this session, including those passes; it is not a quote for all future accounts or a one-pass generation cost. The changing interface quality scores did not establish that every hole had been removed.

The downloaded file was a .spz, not a mesh with editable faces. Its header identified SPZ version 4, 1,048,576 points, spherical-harmonic degree zero and 12 fractional bits. Its SHA-256 is c0dfc6a38528e1324cb891b670a67d3e9dd7b1e7249e9375759e95a965a0d421.

I did not measure the vendor's model inference time. The interactive session includes prompting, queueing, automatic repairs, viewing and export; it cannot validate a one-second model-generation claim. No PLY or character .vsplat result is included in this experiment. A later Spirula Studio PLY to SPZ test started from the official Mip-NeRF 360 Garden sample: Spirula Studio trained it on Vulkan, wrote a PLY, and Spark converted that PLY. It does not replace this generated PINOC file.

Three working renderer paths and one recorded failure

The independent viewer combines that export with one owned Houdini grape-hyacinth mesh, containing 6,056 triangles. The mesh uses an opaque magenta inspection material, so it is easy to distinguish from generated flowers. Both libraries resolve to the same Three.js installation.

The native branch uses SPZLoader and GaussianSplat from the installed Three.js add-ons.² For this PINOC export, zero rotation aligned the scene with the camera; the half-turn used for my earlier synthetic fixture was unnecessary. Coordinate corrections must follow the actual file, not the extension alone.

import { WebGPURenderer } from 'three/webgpu';
import { SPZLoader } from 'three/addons/loaders/SPZLoader.js';
import { GaussianSplat } from 'three/addons/objects/GaussianSplat.js';

const renderer = new WebGPURenderer({ forceWebGL: false });
await renderer.init();
const geometry = await new SPZLoader().loadAsync('/scene.spz');
scene.add(new GaussianSplat(geometry));
await renderer.compileAsync(scene, camera);
renderer.render(scene, camera);

For Spark, await splat.initialized alone was insufficient to prove that the first submitted frame contained splats. An initial frame reported only the mesh's 6,056 triangles. I corrected readiness to await spark.update({ scene, camera }) after attaching the splat and updating scene matrices, then confirmed 2,103,208 submitted triangles. That guard prevents an empty-scene frame from looking like a fast successful load.³

const spark = new SparkRenderer({ renderer }); // classic WebGLRenderer
scene.add(spark);
const splat = new SplatMesh({ url: '/scene.spz', lod: false });
await splat.initialized;
scene.add(splat);
scene.updateMatrixWorld(true);
await spark.update({ scene, camera });
renderer.render(scene, camera);

With WebGPURenderer, Spark's constructor instead threw TypeError: this.renderer.getContext(...).getExtension is not a function. This is a version-specific integration failure, not a prediction about future Spark support. The earlier Spark, GaussianSplats3D and native comparison used Spark 2.3.1 and a different synthetic SPZ; its format failure does not override this successful 2.4.0 PINOC-file test.

Local timings, with the display ceiling kept visible

The desktop browser reported Chromium 155 on Windows and an NVIDIA RTX 5070 Ti. The canvas was 1280 × 720 at renderer DPR 1, with antialiasing disabled. Each working path used five unique loopback URLs for load measurements, one discarded five-second warm-up and three visible 30-second camera-path trials. The renderer stayed initialized between loads. These are warm local asset loads, not cold-device startup or public CDN download times.

Load time includes decoding/readiness, compilation where available, sorting readiness for Spark, and submitted frames. It does not wait for a GPU-completion timestamp. CPU render-call duration excludes asynchronous worker work and is not total application CPU cost. The 1% low is the reciprocal of the mean of the slowest one percent of frame intervals; table values are medians across the three trials.

All three paths reached this setup's roughly 60 Hz presentation ceiling. That establishes smooth operation in this bounded test, not equal maximum throughput or a universal fastest renderer. The workstation was not a dedicated thermal or power-controlled laboratory. No physical iPhone, Android phone, mobile memory limit or mobile FPS was measured.

Check mesh occlusion before calling it a mixed scene

Three fixed states put the opaque plant in front, behind and through the splat scene. In the inspected frames, the foreground plant remained visible, the rear plant was hidden, and the enlarged intersecting plant showed partial occlusion. This is a useful opaque-depth check; it does not prove globally correct ordering for translucent petals or every view in a large scene.

Spark and native Three.js produced visibly different brightness under their tested defaults. I did not normalize their colour pipelines or score one as higher quality. These representative views do not certify complete geometry from every camera position. It is a captured-looking spatial backdrop, not a replacement for individually authored, deformable flower meshes.

Reproduce the integration without redistributing the generated world

The test package contains the pinned viewer, owned mesh fixture, prompt, header metadata and all accepted load/frame receipts, including the WebGPU failure. Supply your own exported file as public/pinoc-garden.spz; the vendor-generated world is not included. Screenshots document the tested result. Dependencies and the owned fixture have their own notices in the archive.

For this garden, I would test a generated splat as a bounded background around a small authored interaction area. Editable plants, wind, per-flower interaction and reusable geometry remain mesh work. Native loading fits the current node-renderer stack; Spark is a separate classic-WebGL integration when the required format and renderer pass together. Continue with the Gaussian asset workflow or the Houdini-to-Three.js garden pipeline.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-21: Digital Garden by Alicia.

This guide collects the notes behind the interactive 3D garden at digitalgarden.si. The hands-on notes record experiments with pinned versions, owned fixtures and explicit limits. The Gemini note is a separate community case summary. Read them in the order below if you are building a plant scene in Three.js, or jump to the question you have now.

The notes and the open benchmark dataset come from one desktop setup; they are case studies, not general performance claims. Where a result depends on a fixture, a renderer path or a file encoding, the linked page says so.

Renderer and performance

Start with how the interactive 3D garden is built. It follows the production garden from Houdini assets to Three.js, with the current code tested on both WebGPU and its WebGL2 fallback, and explains where the scene budget goes.

When the question is which renderer and submission path to choose for plants, read the controlled 1,000 plant fixture next. It separates the submitted representation, such as separate meshes, InstancedMesh or BatchedMesh, from the API name, and compares CPU render time with the actual draw counters. The first note is a project record; the second is a controlled measurement.

For larger scenes, the open plant instancing data at 1k, 10k and 100k is a separate v1 dataset: 240 attempts across 48 cells, three renderer paths, static and moving cameras, and per-run CSV and JSON downloads. It uses a longer protocol than the 1,000 plant note, so the two sets of numbers are not pooled. No physical phone was measured.

Plant assets: procedural, optimized and instanced

For scattering objects on uneven terrain without floating or clumping, a separate 70-trial fixture compares plain and BVH rays, weighted surface sampling, hard spacing and native Houdini layouts. Placement accuracy, distribution and render pacing are kept separate.

A plant for the web needs repeatable geometry and data that survives export. The note on authoring wind-ready plant geometry builds a small seeded Houdini plant with two levels of detail, custom wind attributes and alpha tested leaf cards.

Compressing and instancing plant GLBs measures Draco, Meshopt and KTX2 on that kind of asset, and checks whether the attributes needed by wind survive compression before repeating the plant a thousand times.

Generated meshes need the same scrutiny. Making a generated mesh safe to instance takes a real Meshy 6 Lite download through topology checks and a Houdini reduction before it is placed in the browser.

Delivery formats: glTF and OpenUSD

For choosing glTF or USD for browser delivery, the same two-plant pair was exported from Houdini as GLB, USDC and USDZ, then loaded in Three.js. The note records which representation kept both plants, their colors and their wind data.

Loading a Solaris stage in the browser tests a Houdini Solaris scene in a USD web viewer, with materials, instances, variants, units and warnings. If USD composition is new to you, the first OpenUSD stage for artists explains references, payloads and variants with downloadable files.

Follow-up delivery checks

Three follow-up tests cover different parts of the pipeline. MuTracer with a Houdini plant checks colors, alpha, instances, denoising downloads and fixed-sample convergence. GLB cache and first-frame measurements publish twenty controlled loading rows. Houdini and Geometry Nodes plant export compares editable native files, triangle correspondence and retained wind attributes, including two rejected export cases.

Gaussian splats

Splats are not part of the production garden. To see where splats fit next to mesh plants, read the native Three.js test with an owned synthetic fixture, opaque mesh references and the SPZ v4 correction.

Choosing a splat library for Three.js then loads that same fixture through three integrations and records which renderer and encoding combinations actually drew.

For a generated million-point garden in Three.js, a free PINOC / JST-2 export in SPZ v4 is placed beside an opaque Houdini plant. It loaded in native Three.js on WebGPU and its WebGL2 fallback, and in Spark 2.4.0 with the classic renderer; Spark with WebGPURenderer failed to initialize. That input file and those package versions differ from the synthetic fixture above.

Coding agents for rendering code

Handing a shader task to a coding agent gives two coding tools the same Three.js plant wind and color-space task, keeps their outputs unchanged, and checks them independently on WebGPU and WebGL2. For further agent experiments, see the machine-skill pump simulations with Codex and the community tests of Gemini 4 Argon.

How to use these notes

The slop-newyork and garden profile compares full download budgets and three 1080p observations of two different WebGPU scenes. The SimReady USD-to-GLB test follows two NVIDIA assets through Blender, Houdini, usd2gltf and direct USD loading, including the failed paths and material-preservation limits.

The img2interior room test with Codex follows a single synthetic reference through Blender authoring, PBR/runtime delivery, a static portable GLB and actual garden import. It records Windows fixes and the difference between a 2.67 MB model and its 95.10 MB required runtime payload.

The Spirula Studio to Spark sample test adds a measured training-to-browser handoff: the official Mip-NeRF 360 Garden sample, supplied camera poses, Vulkan training, PLY export and SPZ conversion. It documents 100,000 splats and a mixed WebGL render while keeping phone capture, fresh SfM and mobile performance outside the tested scope.

Each note links its downloadable fixtures and machine-readable results where they exist. Rerun the experiment on your own hardware before relying on a number, and treat a screenshot as evidence of one renderer path, not of every device. Then walk through the garden to see the production scene these tests support.

Read the original article, supporting data and updates.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article.

Originally published by Alicia on 2026-10-22: Digital Garden by Alicia.

img2interior worked in this iterative Codex test, with local Windows fixes and a viewer lifecycle repair. It produced an editable Blender scene, a runtime GLB with a Three.js viewer, and a separate portable GLB. The room is a simplified interpretation of one synthetic reference, with no measured reconstruction claim.

The largest practical finding was the payload. The runtime GLB was 2.67 MB, but its required lightmaps and reflection probe brought the declared total to 95.10 MB. The standalone portable file was 8.80 MB. The full desktop workflow passed after review and repair; no physical phone was tested.

This is an actual render from a fresh process opening the final master. The geometric artwork, uniform stone, simplified upholstery and schematic trees show where the reconstruction stops.

Inspect the static portable model, download the editable study, or read the machine-readable desktop results. The online preview is a separate static consumer; it does not reproduce the full PBR viewer's cloth simulation.

One synthetic reference, a new scene builder

The user selected the project's public synthetic living-room reference: 2752×1536 pixels, with full-height glazing, an ivory sofa, a pale round table, a dark chair and a walnut cabinet. It was not a greenhouse photograph. The reference remains linked at its source and is not redistributed in the download.

img2interior is an agent workflow for authoring a Blender scene, rather than a pretrained image-to-mesh model. In the current Codex desktop conversation, I wrote a scene-specific Python builder using the package's reusable geometry helpers. I did not call its bundled Oak/Linen room recipe or run Claude Code.

The room has actual shell and furniture geometry, glazing, curtains, UV-mapped surfaces and authored lighting: 131 meshes, 46,544 triangles and 12 semantic components. I estimated dimensions in metres, using a roughly 3.1-metre sofa as an anchor. Hidden construction and the camera remain authored assumptions. Native authoring uses Z-up; the glTF exports use Y-up.

This was not a fresh-session, unchanged-prompt benchmark. I preserved failed renders, changed the builder and checked the results. The earlier Codex machine-skill test follows the same distinction between using a skill and accepting its first output.

Setup and the Windows interventions

The test used img2interior 0.3.1, img2 CLI 0.4.0, Python 3.11.14, bpy 4.3.0 and NumPy 1.26.4. The workstation ran Windows 11, a Ryzen 9 9950X and an RTX 5070 Ti. The observed browser was Chromium 155 through ANGLE D3D11. Codex ran in the current desktop conversation; the CLI version readback was 0.144.1.

I registered the package in an isolated harness home and host fixture. Doctor returned zero failures and zero warnings; sync returned zero drift. That verifies the isolated fixture. It does not establish that a newly restarted user Codex host discovered the installed skill.

Three Windows issues needed attention:

• An inherited OCIO setting pointed Blender at an incompatible studio configuration. Clearing OCIO only in the authoring child process fixed preflight while preserving the workstation setting.
• The exporter wrote a backslash in the source-image URL. The viewer rejected it. A local Path.as_posix() change fixed that field, with the original retained for rollback.
• Python 3.12 reported different path-stat and file-stat ctime values, triggering the file-change audit. Running the unchanged checks with Python 3.11 passed. The delivery contract also needed an equivalent relative root because its drive path was classified as a URL.

The downloadable study contains the builder, inputs, generated linen maps, packed master, portable model, applicable notices and the viewer lifecycle patch. Install the pinned official toolkit separately to rebuild. The archive excludes the reference image, environments, production garden plants and the large runtime sidecars.

Render, reject, repair, then bake

The first native render took 5.44 seconds. I rejected it: the camera was too close, and the table and chair were clipped. Two repair rounds adjusted the framing, hidden front-room extent and furniture proportions. I inspected source, lateral, reverse and textile views before final baking.

Five full/ambient bake groups took 193.17 seconds, using a base resolution of 1024 and 2048 for textiles and outdoor geometry, 32 samples and OpenImageDenoise. A 1024×512 reflection probe took another 6.61 seconds. These are measured stages, not a complete setup or generation stopwatch.

The UV/color/coordinate round trip reported zero error. A separate matched 256×192 browser calibration fixture had a mean absolute RGB difference of 0.003818 on a 0–1 scale against the native expected render. That checks lightmap transport, not resemblance to the source sofa.

Three deliverables with different contracts

These are decimal MB and file-byte totals, not a measured cold network transfer. The online static preview loads the unchanged portable GLB only after an explicit button press. It does not load the 95 MB runtime set.

Fresh Blender processes reopened the master and independently imported the portable model, then rendered each. Both final GLBs passed the Khronos validator with zero errors and zero warnings. The full viewer's actual downloads matched the final master and portable file hashes.

The portable model embeds five static images and uses unlit materials for its baked appearance. Close surface detail is softer than the native/runtime PBR version. It does not carry the current browser fabric finish, live curtain state or dynamic relighting. The GLB export notes cover a separate optimization workflow; I did not run that pass here or invent before-and-after numbers.

Loading it in the actual Digital Garden renderer

I loaded the portable GLB through the existing Digital Garden Experience and real plant assets, using a local test entry, an inspection camera and derived placement. The garden used Three.js 0.186.1; the original PBR room viewer used 0.180.0. The room imported at scale 1, upright, without an extra rotation.

Both garden paths hit the display's roughly 60 Hz ceiling. This does not show which backend is faster. The sampled garden view reported 175 draw calls and about 12.15 million rendered triangles, including rendering passes. For a controlled submission comparison, use the separate plant instancing benchmark.

The import exposed a placement problem: existing plants intersected the room. I preserved the scatter. A production installation needs a reserved footprint. The live garden has not been changed to include this experimental room. Its portable baked light also cannot follow the garden's sun.

Cloth, hems and the lifecycle bug

The desktop follow-up tested low, middle and high fabric points and the lower hem on both panels: eight bidirectional drag/release cases, plus two pinned upper-hem checks. The ray-hit data actually identified part=hem; cloth hits were not relabelled as hem results. The far lower hem was initially obscured by the sofa, so I navigated into a clear viewing position instead of weakening occlusion checks.

The saved hem-grab capture shows the full cloth viewer during the test. The online portable preview has static curtains.

A separate vertical pull kept rail coverage at zero while moving the middle probe 76.37 mm, a higher probe 5.09 mm, and the pinned top 0 mm. The maximum observed movable held-point error was 3.86 mm, below the stated 5 mm test threshold. Camera transforms/projection and UV0/UV1 fingerprints stayed unchanged. Rendered world vertices matched the solver within Float32 precision.

Native pointer-capture loss, release outside the canvas, trusted browser blur, Source-mode changes, real offscreen pause, wind-off sleep, page exit and return all passed. Real navigation produced pagehide and hidden events and removed the old canvas. Isolated hidden-pause used a restored temporary getter/event because inactive tabs in the in-app browser stayed visible. Extra-touch/cancellation handlers used DOM PointerEvents. Neither simulation is physical-phone evidence.

The tests found a real lifecycle bug: a late context-loss event on a detached old canvas could put its replacement viewer into an error state. I removed the old keyboard/context listeners during disposal and guarded the context handler by session ownership. Dispatching the same old-canvas events after repair left the new viewer ready and its camera unchanged.

Actual WebGL loss, a blocked manifest request and a blocked atlas request each recovered through Retry load. The eight review stages and all three blocking gates passed after repair. The gates check ordering and bytes; the browser observations establish the scoped behavior.

What I would use it for

The editable project is useful as a starting point for an approximate room, especially when I want a builder and Blender scene to continue editing. Review and repair remain part of the work. The geometric artwork, upholstery, wood, stone, outdoor trees and lighting are visibly simplified.

Before using this room as a production garden asset, I would improve the reconstruction, reserve its footprint, reduce the runtime payload and complete real-device checks. The 390×844 layout emulation had no horizontal overflow, but no physical phone was connected. There is also no complete setup timer or per-run token/cost baseline.

Does img2interior work with Codex?

It did in this Windows test, using a new builder, render iterations, local compatibility changes and a viewer repair. This does not establish untouched first-pass reliability across other images or fresh host installations.

Which GLB should I put in another Three.js scene?

The portable file is the self-contained static-appearance export. The runtime GLB requires its declared lightmaps, probe and viewer integration. The packed Blender master is the editing source.

Is it open source?

The tested package is source-available under the img2 Interior Free Use, Restricted Commercialization License 1.0, not an OSI open-source license. Read its output/runtime and third-party terms for your use. This test does not relicense the reference image or toolkit.

Related: Three.js garden rendering guide, Codex machine-skill test and the official img2interior project.

Read the original article, supporting data and updates.