DEV Community: Alicia lu

Meshy Free to Houdini: What the GLB Actually Contained

Alicia lu — Tue, 20 Oct 2026 05:32:14 +0000

Originally published on Digital Garden by Alicia on 20 October 2026. Codex operated the actual tests and assisted with this article; failed checks and untested limits are retained.

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.

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.

Geometry stage	Points	Triangles	Components
raw	21,781	43,546	13
clean	21,781	43,546	13
reduce	1,508	3,000	13
remesh	2,785	5,554	13

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.

Candidate	Bytes	Median local load to submitted frame
Original download	784,708	33.3 ms
clean, with generated UVs/normals	2,025,332	33.3 ms
reduce, with generated UVs/normals	214,740	16.6 ms
remesh, with generated UVs/normals	391,480	16.6 ms

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.

Meshy, what is included on the free plan and 3D Agent documentation, checked 20 October 2026. Entitlement was also verified by an actual download. ↩
SideFX, Clean SOP and PolyReduce SOP, checked 20 October 2026. ↩
Meshy, ownership of generated models, checked 20 October 2026. The model is distributed with CC BY 4.0 attribution and modification notes. ↩

How I Built a WebGPU 3D Garden with Houdini and Three.js

Alicia lu — Tue, 20 Oct 2026 03:48:52 +0000

Originally published on Digital Garden by Alicia on 19 October 2026. This article was prepared with Codex assistance from actual project tests; the measurements and limitations are stated below.

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.

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 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.

Active backend	Mean FPS	95th percentile frame time	Mean render calls	Mean triangles, including passes
WebGPU	54.66	33.4 ms	67.22	9.49 million
WebGL2 fallback	58.40	16.8 ms	67.24	9.48 million

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.

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.

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.

Reproduce the experiment and understand its limits

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.

Three.js, WebGPURenderer documentation, checked 19 October 2026. ↩