DEV Community: Alicia lu

What broke when I carried bubble shapes through FLIP particles

Alicia lu — Sat, 14 Nov 2026 05:58:54 +0000

Read the complete experiment, code and evidence on Digital Garden. This is a short companion note; the original article contains the full method and measurements.

A bubble-shaped particle selection seemed like a manageable exercise after studying Entagma's viscous-fluid tutorial. I built a separate 48-frame pour in Houdini 22.0.429 and compared five ways to carry its distance attribute through the cache.

Three checks changed the implementation:

On frames with no new centers, my distance-node configuration returned -1. Without a guard, the next threshold test selected the whole fluid.
Stable IDs preserved identity when point order changed. Neighbor repair needed its own second Wrangle to read the completed inheritance result.
Surfaced cavity shapes needed clipping against an inset liquid SDF. The containment checks covered 53 frame/radius outputs.

The limits are useful too. This is cached-material post-processing, not a second air-phase simulation. The larger-radius final mesh retained two local face-direction exceptions; the tests do not establish production-ready glass rendering or continuous collision freedom. The explicit CUDA probe fell back to CPU, so formal neural surfacing used DirectML.

The original write-up includes all five comparisons, the two-pass VEX, discrete mesh checks, an actual Solver SOP comparison, figures, CSV and a small source package. Codex executed the Houdini tests and assisted with numerical checks and writing.

Continue with the full Houdini FLIP bubble study on the original website.

Idol to Three.js: notes from a local garden-object experiment

Alicia lu — Sat, 14 Nov 2026 04:19:15 +0000

This is a short companion to my original Idol desktop study on Digital Garden, published on 13 November 2026. The complete measurements, code, figures and reproduction files are available there.

I wanted to know whether an object generated from one owned garden image could survive a local browser loader. The practical check was not just whether Idol generated a PLY, but whether the file displayed with the expected orientation and color in Three.js and Spark.

A few observations

The study ran on an RTX 5070 Ti with Windows as the host and CUDA through WSL2. Fourteen generation jobs completed using two owned Blender renders: a potted plant and a watering can. Each condition was one observation at seed 42, so this is a small desktop experiment rather than a broad model benchmark.

At the default 50-step, 262,144-Gaussian setting, the first pipeline call with new compile caches took 47.68 seconds. The same input in the same process then took 29.52 seconds. Initial model loading and disk saving were recorded separately. The resulting uncompressed PLY was 17,826,208 bytes.

The browser integration mattered

The isolated viewer used Three.js 0.186.1 and Spark 2.3.1. The exported basis initially placed the plant upside down; an X rotation of pi corrected its placement. The native Three.js path also needed explicit SH0 sRGB decoding into the linear working space. These were viewer adaptations, and the generated PLY files were kept unchanged.

Nineteen final browser loads completed across WebGPU, the WebGL2 fallback and Spark, including the million-point file. Timing ended at the first submitted draw. It does not measure the first visible pixel or establish a renderer-speed ranking; Spark's worker may still be preparing visible data after submission.

Windows adapter counters included shared memory and unrelated desktop activity, so completion is not proof of zero memory spill. Physical iPhone Safari, public-network 3D delivery and production-garden placement remain untested.

Read the full original

The full Digital Garden article contains all five tables, four original figures, the encoder-source checks, native API examples, exact memory distinctions and an 18.7 MB reproduction bundle with raw records and two representative PLY exports. The article also explains the setup failures and limits behind these observations.

Alicia — 3D technical artist, TA and independent developer. Codex assisted the tests, numerical checks and writing. Owned text and figures retain CC BY 4.0; the linked bundle carries its own code and upstream notices.

Blender 5.3 Gaussian Splats: Import, Crop and Export Tested

Alicia lu — Thu, 12 Nov 2026 03:54:37 +0000

Originally published by Alicia on 12 November 2026 at Digital Garden. Alicia is a 3D technical artist (TA) and independent developer. Codex assisted with the desktop tests, numerical checks and writing.

Blender 5.3.0 imported the same 12,000-splat plant through PLY, SPZ, glTF and USD. A Geometry Nodes crop preserved its surviving attributes. None of the native exports tested here returned a complete web-readable splat. File creation, point preservation and splat preservation were three different results.

Codex ran this desktop study under Alicia's direction on 12 November 2026. Alicia is a 3D technical artist (TA) and independent developer. The fixture is the owned procedural plant from our Houdini 22 GSplats study, trained previously from 24 Karma views for 1,200 steps. It is a synthetic plant fit, not a photographic scan, a newly trained Blender model or the live Digital Garden scene.

What Blender officially promises

The 5.3 rendering notes explicitly say: “There is currently no export support.” They describe native PLY/SPZ import, a Gaussian-splat point-cloud type, and limitations around color and applying transforms. The pipeline and I/O notes separately document glTF/USD splat import and generic point-cloud improvements. Generic point-cloud export is not a promise to preserve a Gaussian-splat field.

The Blender developer article explains the different rendering approaches and rudimentary relighting. We checked these claims against the installed release, rather than treating release footage or a successful export notification as a round trip.

Machine, source and measurement boundary

Item	Recorded setup
Blender	5.3.0 Release, build `02f0899d78e3`, built 10 November 2026
Workstation	Windows 11, Ryzen 9 9950X, RTX 5070 Ti, driver 621.14
GPU memory	Adapter reports 16,303 MiB total; one pre-test snapshot used 2,607 MiB; no per-import allocation or VRAM peak measurement
Native images	800 × 600, fixed orthographic camera; source/crop share a camera; transform pair uses a separate shared camera
Native color setup	Process-scoped ACES 2.0 OCIO config, sRGB display, Un-tone-mapped view, no look, exposure 0, gamma 1
Browser lab	Desktop Chrome 157, headed, 800 × 600 canvas, DPR 1; Three.js 0.186.1; Spark 2.3.1
Source properties	12,000 splats; degree-three SH storage, with degree-one training active in the historical fit

The original PLY is 3,121,605 bytes, its lossy SPZ v3 derivative 235,748 bytes, and the native USD 3,121,407 bytes. Their hashes accompany the evidence. A local glTF repack uses the same PLY records, linear scale, normalized opacity, xyzw quaternions and the KHR_gaussian_splatting attribute schema, including kernel: ellipse and colorSpace: srgb_rec709_display. That repack tests import; it is not a Blender export.

The historical Karma color pipeline and Blender's documented sRGB assumption differ. The glTF color-space field is an explicit structural-test declaration; no original Karma-to-sRGB conversion was validated. These pictures establish visible output and structural behavior, not colorimetric equivalence across native and browser renderers.

Four imports, one source

All four paths created POINTCLOUD objects with type GAUSSIAN_SPLAT, 12,000 points, scale, quaternion rotation, four-component radiance:base, and 15 radiance:sh_N vectors.

Input	Single operator duration	Orientation used for this source	Other observation
Standard 3DGS PLY	2.79 ms	Imported identity; rotate object X +90° for Blender Z-up inspection	Additional source normals/albedo scalar attributes retained
SPZ v3	4.13 ms	Importer already changed this file's coordinates to Z-up	Anti-aliasing support warning in the native log
USD particle field	33.44 ms	Importer supplied X +90° object rotation	Native splat type detected
glTF repack	43.55 ms	Importer converted glTF Y-up data	Native splat type detected

These are one operator call each in already running background processes. They exclude process startup, interface painting and viewport readiness. They are diagnostics, not a format speed ranking. SPZ versions other than this v3 derivative were not tested. An axis correction for this writer is not a universal SPZ rule.

Cropping works; inspect evaluated geometry

On a duplicate of the PLY object, a Geometry Nodes group connects Position → Separate XYZ → Compare (X > 0) → Delete Geometry, on the point domain. It retains X ≤ 0 in source coordinates. A source_id integer attribute lets the test match each survivor back to its exact input record.

Crop check	Result
Base datablock points	12,000
Evaluated modifier output	5,906
Surviving source IDs match the intended selection	Yes
Maximum absolute difference, surviving position/scale/quaternion/base radiance	0
Maximum absolute difference, all 15 stored SH vectors	0
Fresh-process `.blend` reopen	Base 12,000 / evaluated 5,906

Reading only object.data would incorrectly report that the modifier had done nothing. The tested code obtains object.evaluated_get(depsgraph).data before checking counts and attributes. Edit Mode deletion and more complex cleanup were not measured.

Applying transforms changed the appearance

A separate duplicate had X +90° and Z +90° object rotations plus uniform scale 2. Before and after applying rotation and scale, the same camera viewed the same intended world-space arrangement.

World-space point centers agreed within 5.95 × 10⁻⁸ after application. However, the scale and quaternion rotation attribute arrays did not change at all. The first three SH vectors contained nonzero values before the operation and also remained unchanged. Point centers moved into the datablock while the stored splat shape and directional radiance did not follow the object transform.

The paired renders visibly fragment after application. This reproduces the documented transform limitation for this fixture. Keep object transforms unapplied in this workflow; a general transformed-splat exporter would need to handle covariance and SH rotation correctly. Our reference crop writer does neither because it deliberately preserves the original coordinate system.

Rendering and a bounded relighting probe

Image operation	Settings	One wall-clock duration
Original, Workbench	Flat lighting	0.83 s
Original, EEVEE	128 samples	3.42 s
Original, Cycles	OptiX GPU, 64 samples, denoising off	0.87 s
Cropped, Cycles	Same 64 samples and source camera	0.29 s
Diffuse probe, EEVEE	Gray Diffuse BSDF plus point light, 128 samples	0.47 s
Diffuse probe, Cycles	Same material/light, 64 samples	0.46 s

These sequential single renders include different startup/cache costs and different rendering work. They do not establish an engine ranking or viewport FPS. The diffuse probe was a deliberately gray material replacement. It produced a lit grayscale plant, rather than recovering the learned plant's albedo. A retained copy and both probe images are in the package; baked illumination removal was not tested.

Export matrix: success messages are insufficient

Only the cropped object was selected. Generic attribute export was enabled where available. Every written artifact was independently reopened in a fresh empty Blender scene.

Native export	Bytes written	Reopen result	Complete splat preserved?
PLY, evaluated modifier enabled	156	Header says `element vertex 0`; native reimport fails	No
GLB, default `export_apply=false`	144,664	12,000 ordinary mesh vertices; crop and splat attributes absent	No
GLB, `export_apply=true`	No output	Raises `Object does not have geometry data`	No
GLB, modifier baked first, `export_apply=false`	71,540	5,906 ordinary mesh vertices; splat attributes absent	No
USD	2,666,502	5,906-point `POINTS` cloud; scale, rotation and SH retained; base radiance missing	No
Alembic	736,250	5,906-point `POINTS` cloud; scale and renamed SH retained; rotation and base radiance missing	No
SPZ	Not available	No native SPZ export operator found	Not tested through a native exporter

The USD and Alembic logs explicitly warn about unsupported radiance:base. Their ordinary point-cloud type and missing data prevent calling this a splat round trip. Simply changing the point-cloud type back cannot recover a missing base radiance/opacity vector. The GLB default also illustrates why counting bytes or relying on a saved filename can conceal a modifier-evaluation problem.

Actual browser return path

The local lab ran eight functional browser starts, one per backend/file pair. Native Three.js selected WebGPU; Spark used WebGLRenderer. Each successful case settled for 45 frames before capture. There is no FPS benchmark here. Three's native SPZ path needed an X = π object rotation for this particular file; Spark used its own decoded convention.

File	Native Three.js GaussianSplat	Spark 2.3.1
Original PLY	Visible, 12,000 splats	Visible, 12,000 splats
Original SPZ v3	Visible, 12,000 splats	Visible, 12,000 splats
Reference source-record crop PLY	Visible, 5,906 splats	Visible, 5,906 splats
Blender's native crop PLY	Rejected: required splat properties missing	Rejected: `scale_0` missing

The reference crop is a separate diagnostic writer: it copies the original PLY records selected by the same source-X rule. The count and IDs match the evaluated Blender crop. It is not a native Blender export, a general exporter for edited attributes, or evidence that transformed SH were handled correctly. It proves the viewer accepts a complete cropped splat when the original schema and records survive.

The native Three.js image is visibly sparser than the Spark image. We retain that difference rather than claiming matched image quality. These two functional captures do not explain every renderer difference; our renderer comparison treats renderer behavior separately. glTF, USD and Alembic were not forced through PLY/SPZ-only loader entries. The exported GLBs have no Gaussian-splat extension, and these native/Spark lab paths supply no equivalent USD/Alembic splat import.

Practical workflow and reproduction

Use native Blender import to inspect, combine and crop a splat, then preserve the .blend as the editable result. Before selecting a delivery tool, ask whether it preserves the evaluated count, radiance/opacity, scale, rotation, SH convention and coordinate system. Reopen the artifact and test it in the intended viewer. A third-party exporter is a separate pipeline with its own version, license and limitations; no PlayCanvas account upload was performed here.

For a working web deliverable today, keep the source standard PLY/SPZ or use a separately verified export/conversion path such as our bounded Houdini attribute round trip. Compression and viewer choice remain separate decisions; see the PLY, SPZ and SOG study.

The machine-readable summary and reproduction package include owned inputs, the editable compressed .blend, scripts, raw attribute arrays, native artifacts, screenshots and browser receipts. Source code is MIT; owned fixture data, text and captures are CC BY 4.0, Alicia / digitalgarden.si. Blender and browser/dependency binaries, user settings, account data and full copied vendor pages are excluded. Dependencies retain their upstream licenses.

The first browser harness incorrectly attempted a WebGL finish() call on the native WebGPU canvas context. An initial glTF repack also copied nonunit source quaternions; that invalid diagnostic input was excluded, then normalized and reimported for the reported glTF result. The maximum float32 unit-norm error was 1.79 × 10⁻⁷. Pilot receipts remain separate from the corrected results. Public HTTPS hosting, iPhone Safari, large photographic scans, native SPZ v4, generic edited-attribute export and viewport FPS remain untested. Codex assisted execution, numerical checks and writing.

Questions

Does Blender 5.3 support Gaussian splatting without an add-on?

Yes. This Blender 5.3.0 desktop test imported the same owned 12,000-splat fixture through PLY, SPZ v3, glTF and USD as GAUSSIAN_SPLAT point clouds. It did not train a new splat from photos.

Can I crop Gaussian splats in Blender 5.3?

Yes in this fixture. A Geometry Nodes Delete Geometry selection removed positive-X points, leaving 5,906 evaluated splats. Surviving position, scale, rotation, base radiance and all 15 stored SH vectors matched their source records exactly.

Can Blender 5.3 export a standard Gaussian-splat PLY?

The official release notes say there is currently no export support. Our native PLY exporter returned FINISHED but wrote a 156-byte file with zero vertices. This is one tested build and fixture, not a claim about every add-on.

Does a successful GLB export preserve Gaussian splats?

No in this test. The default export retained 12,000 ordinary vertices without the crop or splat attributes. Baking the crop first retained 5,906 ordinary vertices, still without splat attributes. The export_apply option raised a geometry error.

Can Blender relight a splat like a scanned material?

Only rudimentary relighting is documented. A gray Diffuse BSDF and point light produced a lit grayscale result here. That did not recover albedo or remove baked illumination from the learned radiance.

Three.js vs Unreal Engine for Web 3D: Which Should You Ship in the Browser?

Alicia lu — Wed, 11 Nov 2026 03:50:46 +0000

Originally published by Alicia Lu on 11 November 2026 at Digital Garden. Alicia is a 3D technical artist (TA) and independent developer. Codex assisted with implementation, measurement and drafting.

Start with Three.js for a web-authored viewer or interactive page. Consider Unreal's experimental Wasm target when keeping an existing Unreal project is worth the larger client and Preview restrictions. Consider Pixel Streaming when the Unreal application should run on a server. That is a product decision, rather than a universal performance ranking.

This desktop study was run on 11 November 2026 by Codex under Alicia's direction. Alicia is a 3D technical artist (TA) and independent developer. It adds 48 measured Chrome page loads (24 fresh-context visits and 24 same-context reloads) to the previous Unreal Wasm build test, with matched hosting software, Brotli compression and explicit cache policies. Public HTTPS hosting and iPhone Safari remain outside this desktop study. Local bandwidth shaping is not a measurement of a public network.

Three browser delivery paths

Path	Where the 3D application runs	What the browser receives	Decision to make
Three.js web client	On the visitor's device	JavaScript and scene assets	Can the experience be authored and maintained as a website?
UE 5.9 Preview Wasm client	On the visitor's device	A packaged engine client, WebAssembly and content	Is preserving the Unreal project worth the client download and experimental target?
Unreal Pixel Streaming	On a desktop or server running Unreal	WebRTC frames and audio, with input returned to the application	Is a streamed session acceptable, and can the service operate it?

This three-path frame is our decision aid. Epic documents the experimental Wasm target in the 5.9 release notes and describes Pixel Streaming as remotely rendered frames and audio delivered over WebRTC. Pixel Streaming latency, server costs and concurrent sessions were not measured in this study.

The MegaJam Preview announcement calls the browser target experimental, identifies WebAssembly, WebGPU and the mobile renderer, and recommends Chrome. Its source-build/C++ guidance should be read alongside the known issues. Our earlier Windows Launcher result is evidence for one installed build, not a guarantee for every platform or project. Existing production projects were preserved separately.

What the desktop test actually compares

The machine was Windows with an NVIDIA RTX 5070 Ti; the browser was Chrome 157.0.8103.50, headless, at 1280 × 720 and device pixel ratio 1. The Unreal package was UE 5.9.0 MegaJam Preview CL 60351404, Shipping, using the forward WebGPU tier. The Three.js control used 0.186.1, reported revision 186, and actually selected its WebGPU backend.

Both fixtures have a floor, two upright boxes, a rotating center cube and a fixed camera. The original fixture sources and UE Shipping package were reused unchanged. Materials, lighting, shaders and engine behavior differ. The screenshots show that difference; this is not matched visual quality or a garden-scale scene.

Each stack ran three fresh browser contexts, each followed by a reload in the same context, for each of two network profiles and two cache policies: 48 measured page loads in total, using two Playwright browser launches overall, one per cache-policy dataset. Stack order alternated between pairs. Fresh-context means fresh browser storage, not a reboot, a cold GPU driver or a reset of every browser-process and OS cache.

Both stacks used Epic's packaged local server, loopback HTTP, the same isolation headers and Brotli siblings. The second profile used its server-side 50 Mbit/s shared-bandwidth and 40 ms response-delay setting. Server-side shaping also covers the UE service worker's fetches; the profile still does not reproduce a VPS, TLS, DNS, routing or a mobile radio.

For the primary table, versioned assets used the server's immutable-cache option and entry documents retained its no-cache policy. This is appropriate only for fixed, versioned test artifacts; a production site must change asset URLs when their content changes.

Desktop startup and transfer results

Every cell in the primary startup table below is the median of three runs. Times are milliseconds from navigation start. Response-body bytes were summed from the server ledger after 120 sampled post-ready animation intervals and an observed zero-in-flight response count, before screenshots. They exclude HTTP headers, TLS and transport overhead. These are bytes for that observation window, not a folder size and not a count stopped at READY.

The common hook records the first successful GPU queue submission after a configured canvas acquires a texture. It provides one instrumented API boundary across stacks; it does not establish GPU completion, display scanout or that the first submission contains the final scene. The separate readiness column ends at UE's page READY event or the Three.js control's first rendered submission. Those readiness signals do different work.

Stack	Network profile	Visit	First canvas submission, ms	Stack readiness, ms	Completed response bodies, B
Three.js r186	Unshaped loopback	Fresh context	199.07	199.08	533,231
Three.js r186	Unshaped loopback	Same-context reload	95.13	95.14	124
Three.js r186	Local 50 Mbit/s + 40 ms	Fresh context	483.83	483.84	533,231
Three.js r186	Local 50 Mbit/s + 40 ms	Same-context reload	114.26	114.27	124
UE 5.9 Wasm	Unshaped loopback	Fresh context	2043.05	2049.62	50,111,928
UE 5.9 Wasm	Unshaped loopback	Same-context reload	1688.59	1701.52	40,838
UE 5.9 Wasm	Local 50 Mbit/s + 40 ms	Fresh context	15493.15	15507.72	57,537,511
UE 5.9 Wasm	Local 50 Mbit/s + 40 ms	Same-context reload	1607.65	1612.54	40,838

The small Three.js control had the smaller transfer and earlier submission in these conditions. That observation supports a lightweight web-client option for this fixture. It does not give a speedup ratio for equally rendered scenes, predict the full garden, or settle the cost of porting an existing Unreal project.

The UE cold transfer changed with the shaped profile even though the package was identical. On unshaped loopback it was 50,111,928 B. On the shaped profile it was 57,537,511 B. The shaped cold ledgers record 14 Range responses totaling 7,425,583 B alongside whole-file prefetch responses; the unshaped cold ledgers record no Range responses. Count the actual requests when estimating network cost. A Brotli file's size alone misses this observed overlap.

The earlier build article reports its own before-READY byte count and an uncompressed Three.js control. Those historical figures remain unchanged. This table uses a different, explicitly defined observation window and compressed control, so it should not silently replace the earlier numbers.

Cache policy is part of the comparison

The server's default policy is no-cache and it provides no validators for these responses. In the default-policy control, the Three.js files were fetched again on reload. UE also used its own service-worker content cache. Enabling the same immutable option on both servers changed the warm byte totals:

Stack	Server policy	Reload response bodies, B	Reload readiness, ms
Three.js	Default no-cache, no validators	533,231	116.46
Three.js	Versioned assets immutable	124	95.14
UE Wasm	Default no-cache, no validators	109,591	1506.18
UE Wasm	Versioned assets immutable	40,838	1701.52

These rows use unshaped loopback and medians of three reloads. The default-policy control did not persist its in-flight response counter; its transfer column is the ledger total recorded at collection. They show why “warm” needs a definition. The difference between the two server policies is a deployment result for these files, not a built-in advantage or defect of a JavaScript library. The UE warm page still initialized the engine; caching did not make startup free.

Across all 48 measured page loads the fixtures rendered moving pixels at the expected canvas size, and the page-error collector recorded zero JavaScript page exceptions. The runs sampled 5,760 post-ready requestAnimationFrame intervals in total. The raw evidence retains four console resource notices from missing favicon requests. Those notices are not silently relabeled as clean network logs. Animation-frame spacing on this tiny, refresh-limited fixture is not a maximum-throughput benchmark.

What the memory readings do and do not say

The 11 November runner attempted a Wasm linear-memory sample every 100 ms, but its hook did not obtain a memory handle in any of the 24 UE page loads. Those raw fields are null. They mean not measured, not zero memory usage. The startup and transfer results do not supply a new Wasm-memory measurement.

The separately published 10 November test recorded a sampled peak of 536,870,912 B, or 512 MiB. That historical result belongs to that test. It is a linear-memory allocation, not total browser RAM, not all transient allocations and not GPU VRAM; it is not presented as a newly observed peak for these 24 page loads.

The data includes Chrome's sampled JavaScript heap counters for both stacks. They cover another memory category and are not comparable to the Wasm allocation as a total-memory ranking. No total-memory or VRAM ranking is presented. A larger scene needs its own resource and memory study.

Which path should a project choose?

For an experience built around a web page, Three.js keeps the scene in the front-end code and allows assets to be chosen and loaded at the feature level. Digital Garden already uses that structure: the website shell is separate from the playable Three.js garden. The Houdini-to-Three.js garden article describes that pipeline. This study's four-box scene is a separate fixture.

For an existing Unreal level, reusing the editor, code and assets may matter more than the initial download. Test the particular features the project relies on in the experimental target, then measure that package on the intended host and client devices. A successful box scene does not validate an arbitrary Blueprint project, large level, deferred rendering path or mobile browser.

For a project that should remain on a server, assess Pixel Streaming as a service architecture. Its browser client receives a stream rather than downloading the Wasm engine package, but a machine still has to run the Unreal application for the session. Streaming quality, network latency, input behavior and service capacity require separate tests. This article supplies no invented prices or session counts.

Three.js's WebGPURenderer documentation describes a WebGL 2 fallback when WebGPU is unavailable. All measured control runs here selected WebGPU; fallback behavior and Safari were not tested. An engine's renderer being called “mobile” does not prove it works on an iPhone. Unity, Babylon.js and PlayCanvas were not measured either.

Evidence and reproduction

The desktop summary and reproduction package contain both 24-run datasets, the harness, authored fixture sources, request ledgers, screenshots and the measurement definitions. The package excludes Unreal Engine binaries, engine scripts and the generated UE runtime; reproduce that side using a licensed engine installation and the build steps linked from the earlier article. The portable runner requires explicit paths to the existing Shipping package, Epic server and Python.

The first setup attempt encountered Windows' inactive Python alias before a server or measured trial started. It is retained separately as a setup failure. The completed datasets use the installed engine's Python and report no measured-run failures. This distinction matters when counting the 48 measured page loads.

The Three.js r186 license and Epic's Unreal Engine terms remain the authoritative license references. No royalty or seat interpretation is made here.

Author: Alicia, 3D technical artist (TA) and independent developer. Codex assisted with desktop execution, instrumentation, data checks and this manuscript. Public-host HTTPS, iPhone Safari, Pixel Streaming and larger-scene validation remain untested.

Questions

Can Unreal Engine run in a browser without Pixel Streaming?

Experimentally, yes. Unreal Engine 5.9 Preview adds a WebAssembly target with WebGPU rendering. Our specific Windows Launcher Shipping fixture rendered locally in Chrome. Public hosting and iPhone Safari remain untested here.

Are these Three.js and Unreal timings a visual performance ranking?

No. The layout matches but the materials, shaders, runtimes and readiness signals differ. The shared submission hook records a CPU-side WebGPU queue submission, not visible display time or equal rendering work.

Does a warm Unreal Wasm page still initialize the engine?

Yes in this fixture. Cached resources reduced response-body transfers, but each measured reload still initialized the engine. A warm download is not a zero-cost startup.

Does Unreal Wasm work in iPhone Safari?

This study has no iPhone Safari result. Desktop Chrome, a mobile renderer name, and local network shaping do not establish iPhone compatibility.

Three.js Exploded View: Explode a Real Multi-Part GLB (and What It Costs in Draw Calls)

Alicia lu — Mon, 09 Nov 2026 02:52:29 +0000

Originally published by Alicia Lu on 9 November 2026 at Digital Garden. Alicia is a 3D technical artist, TA and independent developer. Codex assisted with implementation, measurement and drafting.

A Three.js exploded view moves a GLB assembly apart by changing its part transforms. For this test, Codex built and exported a potted flower in Houdini 22.0.429 and ran it on Alicia’s RTX 5070 Ti desktop. The fixture has five assemblies: pot, soil, stalk, leaves and bloom.

The short answer. Give each movable part a name and a pivot, then save its rest position. The merged, 10-, 50- and 200-part GLBs all contain 30,848 triangles. They took 1, 10, 50 and 200 model draws on both backends. The raw renderer counts were 2, 11, 51 and 201 because an empty scene recorded one draw. From merged to 200 parts, WebGPU load to first GPU completion went from 89.7 to 116.2 ms. Point picking went in the other direction because the split created tighter bounds.

Export the parts and pivots from Houdini

The native scene uses a Geometry Stash SOP inside each OBJ mesh. Each part has a pivot at its local bounds center and is parented under a named assembly null. The merged control stores the same colored geometry under one mesh at the origin. The 10- and 50-part layouts group the same 200 source components in fewer meshes. The glTF 2.0 ROP exports the OBJ hierarchy, with one mesh primitive per part. A node extras dictionary stores the assembly name and component count. Three.js read both back from userData. SideFX glTF 2.0 ROP

All four native exports passed the glTF validator with zero errors and warnings. A separate audit matched every oriented triangle against the merged control and compared its world-space corners, normals and vertex colors. The largest component difference was 2.46 × 10⁻⁷. The saved HIP reopened with all four layouts and their geometry intact.

Flat traverse and a two-stage hierarchy

Flat explode moves each part away from the model center. The hierarchy path first moves the five parents apart. At slider value 0.5, the children still have their rest positions inside those groups. The second half moves each child away from its own group center. The two modes use different offsets to illustrate how they open. The flat view spreads parts along the plant’s overall shape, while the hierarchy view opens the five assemblies in stages.

Both methods compute positions from stored rest values. The test model sits under a rotated, nonuniformly scaled parent. To apply a displacement in world units, convert two points to the parent’s local space and subtract them. The resulting vector length accounts for parent scale. Three.js Object3D

function localOffset(node, point, worldOffset) {
  const start = node.parent.worldToLocal(point.clone());
  return node.parent.worldToLocal(point.clone().add(worldOffset)).sub(start);
}

// Hierarchy path after the local offsets have been prepared.
const groupT = Math.min(1, t * 2);
const partT = Math.max(0, t * 2 - 1);
for (const group of groups) {
  group.node.position.copy(group.rest).addScaledVector(group.delta, groupT);
}
for (const part of parts) {
  part.node.position.copy(part.rest).addScaledVector(part.child, partT);
}

Across 24 parted contexts, 960 out-and-back cycles returned to rest with zero measured drift. The largest world-position error in the displacement checks was 1.33 × 10⁻¹⁵ scene units. The two GIFs share a wider camera so the plant stays in frame at full separation. The timing runs use their own fixed camera.

Draw calls and first completion

Chrome and Three.js 0.186.1 ran at 1280 × 720, device pixel ratio 1. The WebGL2 path uses the WebGPU renderer’s WebGL backend on ANGLE/D3D11. Both selected NVIDIA hardware. Four fresh contexts per layout and backend loaded each GLB from localhost with cache disabled. Contexts shared a Chrome process and did not clear driver or OS caches.

These are medians in milliseconds. Asset-to-completion starts after renderer initialization and includes loading, scene setup, awaited compile and the first render with its work wait. WebGPU used the queue completion promise and WebGL2 used gl.finish(). This measures submitted work completion before display presentation.

Layout	Backend	Raw draws	GLB MiB	Fetch ms	Parse ms	Compile ms	First render + wait ms	Asset to completion ms
Merged	WebGPU	2	0.965	5.6	2.4	60.9	20.7	89.7
10 parts	WebGPU	11	0.977	5.2	3.4	61.5	20.7	91.5
50 parts	WebGPU	51	1.027	5.2	4.9	64.6	21.0	96.4
200 parts	WebGPU	201	1.215	5.9	9.8	71.2	30.0	116.2
Merged	WebGL2	2	0.965	6.2	2.4	24.2	7.6	43.4
10 parts	WebGL2	11	0.977	6.0	3.2	27.0	8.5	47.3
50 parts	WebGL2	51	1.027	6.3	5.1	36.8	10.0	58.0
200 parts	WebGL2	201	1.215	6.4	9.2	29.7	13.4	59.1

The 200-part asset cost about 26.6 ms more than the merged WebGPU median. The WebGL2 50-part runs ranged from 46.4 to 78.1 ms, which is wider than the difference between the 50- and 200-part medians. The file size, number of nodes and buffer layout all change with the split. The separate columns are medians from four runs and do not necessarily add up.

The harness reads renderer.info.render.drawCalls. Early pilots caught the empty-scene draw and a second issue: back-to-back render calls could accumulate statistics. The formal harness resets counters before each render and measures the empty scene after first completion. Three.js Info

200-part mode	Raw draws	WebGPU CPU submit ms	WebGL2 CPU submit ms	WebGPU / WebGL2 p95 rAF ms
Assembled	201	0.8	0.6	16.8 / 16.7
Flat	201	1.1	0.9	16.8 / 16.8
Hierarchy	201	1.0	0.9	16.8 / 16.8

CPU submit is elapsed time around the render call and counter reset. It excludes the per-frame transform update and GPU wait. Warm rAF intervals stayed near the refresh cadence. The assembly uses one opaque vertex-color material, no shadows and disabled frustum culling, so moving parts does not change the draw count.

Picking got cheaper as the mesh count rose

The harness times setFromCamera and intersectObjects on the same 49 rays. Each context ran 12 timed sweeps after three warm-up sweeps. Every sweep had 12 hits. The per-ray times are CPU measurements grouped by the renderer in use in that context. Picking uses an explicit mesh list and reuses its result array. Three.js Raycaster

Layout	WebGPU µs/ray	WebGL2 µs/ray	Meshes reaching triangle loop per sweep	Triangle loop entries per sweep
Merged	1,373.5	676.5	41	1,264,768
10 parts	234.7	117.3	59	208,192
50 parts	106.1	55.1	105	78,104
200 parts	65.3	30.6	130	37,952

An untimed CPU control counted entries after the built-in bounding tests in the same Three.js version. From 10 to 200 meshes, more candidates passed the bounds checks but many fewer triangles reached the inner loop. All 49 hit-or-miss outcomes matched. The largest difference in the nearest hit distance was below 0.000002 scene units. The result depends on the asset’s bounds and the ray distribution. Three.js r186 mesh raycasting source

Click to fade or hide

The live viewer picks on pointer release and ignores drags longer than five pixels. Fade assigns unselected meshes a shared translucent material at opacity 0.17. The selected mesh retains the opaque material. Hide makes the other meshes invisible and filters them out of the next pick. The camera stays fixed for the comparison.

Layout	Fade / hide raw draws	WebGPU fade / hide CPU submit ms	WebGL2 fade / hide CPU submit ms	Model triangles when hidden
10 parts	11 / 2	0.2 / 0.2	0.2 / 0.2	2,176
50 parts	51 / 2	0.4 / 0.2	0.3 / 0.1	2,176
200 parts	201 / 2	0.6 / 0.2	0.6 / 0.2	1,152

Fade kept the whole shape visible. Hide left one model draw plus the empty-scene draw. The hidden triangle count depends on the chosen part, whose grouping changes with the layout. The table shows warmed CPU submit medians. Transition completion samples are in the raw data. Some WebGL2 samples hit the timer floor, so they cannot support a more precise latency claim.

A separate browser interaction test moved the slider, changed the rendered canvas, picked a part, toggled hide and fade, and reset. A 300 ms idle window after each timed sequence logged zero further render calls in all 32 contexts. This counts submitted frames. GPU utilization and power were outside the test.

Reproduce the experiment

The bundle includes four native GLBs, the Houdini scene and generator, browser viewer, raw trials, chart sources, GIFs and the picking control. The formal set contains 32 contexts, 7,680 rAF intervals and 18,816 timed ray evaluations, including 14,112 on the three parted layouts. Pilot failures are separate from the formal data. Download the reproduction bundle or inspect the summary CSV.

The results cover one desktop, one browser version, one camera for timing and an untextured authored model. Mobile devices, production asset loading and batched alternatives are outside the measured scope. Related studies cover GLB loading and first frame and the forest draw budget with different fixtures.

By Alicia, a 3D technical artist, TA and independent developer. Codex assisted with implementation, measurement and drafting.

Questions

Can one merged GLB mesh explode?

A merged mesh has one object transform. Independent movement requires separate logical parts, such as separately transformed meshes or an explicit per-part representation. This study measured separate native GLB meshes.

Does every named part always add one draw?

Each mesh added one model draw in this one-primitive, one-material test. Extra materials, passes and batching change the count. The raw counter also recorded one draw in an empty scene.

Should click-to-isolate fade or hide other parts?

Fade keeps the surrounding assembly visible and retained all model draws here. Hide left one model draw for the selected mesh. Choose based on whether the rest of the assembly helps the reader.

Brush vs Spirula Studio on Windows with the Same Posed Garden

Alicia lu — Thu, 05 Nov 2026 03:37:44 +0000

Originally published by Alicia Lu on 5 November 2026 at Digital Garden. Alicia is a 3D technical artist, TA and independent developer. Codex assisted with this study.

I trained a synthetic garden in Brush 0.3.0 and Spirula Studio 2026.10.16 on one Windows RTX 5070 Ti. Both exported a Gaussian PLY at 600 and 6,000 steps. At 6,000 steps, the saved RGB images averaged 21.48 dB PSNR for Brush and 38.17 dB for Spirula on the same seven held-out views. This result covers the chosen budgets, settings and scene.

The shared input and training limits

The 44 posed RGB images and camera intrinsics come from the Houdini procedural splatting study. Each image is 192 × 192. I used views 1–36 for training and held out 37–44. Both trainers used SH0 and a 12,000-splat cap, with their own random initialization and optimization settings. Brush used wgpu on Vulkan and seed 381. Spirula used its Vulkan release, 3dgs preset, and explicit random initialization. The GPU driver was NVIDIA 617.42. This experiment starts with known camera poses.

Brush received separate Nerfstudio train and test manifests. Spirula needed a single transforms.json. I copied the identical PNGs, added train and eval prefixes for its filename split, and kept the original camera matrices and intrinsics. An initial Spirula probe using only the split manifests reported that transforms.json was missing. The derived dataset fixed the packaging issue. Spirula dataset implementation.

Four exports and one independent comparison

Trainer	Steps	Process wall time (s)	Exported splats	PLY bytes	Mean RGB PSNR (dB, seven views)
Brush	600	6.121	11,680	654,515	13.99
Brush	6,000	18.370	12,000	672,435	21.48
Spirula	600	1.490	1,200	82,014	28.21
Spirula	6,000	12.320	11,992	815,871	38.17

I matched the saved Spirula reference PNGs to the original input by exact decoded pixels. The 600-step output repeated view 37 and omitted view 39. The two renderings of view 37 were identical. Both Brush runs and the 6,000-step Spirula run provided all eight views. I kept views 37, 38, 40, 41, 42, 43 and 44 for every row. I independently measured full-frame PSNR in 8-bit RGB, then averaged the seven image-level dB values. The table uses those recalculated values. The application logs keep their own evaluation values.

The PLY count comes from each exported header. Spirula reported 12,000 active points at the end of the longer run and wrote 11,992 points. Process timing includes startup, import, training, evaluation and export. One run per configuration and the different initialization, growth and settings limit conclusions about speed or trainer quality. I kept whole-board memory samples separate from any per-process VRAM claim.

Fixing the Brush image-header failure

The first two Brush attempts failed with early eof, using both a directory and ZIP. Brush 0.3.0 reads at least 16,387 bytes during its image-header probe. Two otherwise valid compressed PNGs were shorter. I regenerated all 44 PNGs with compression level zero and verified that every decoded RGB pixel matched the earlier files. The reproduced dataset includes the larger lossless PNGs. Brush 0.3.0 loader.

Both used freely available Windows builds from their official releases. The test covers posed synthetic inputs and exported PLYs. It leaves real photos, SfM and other trainers for separate runs. Brush releases, Spirula Studio release.

Alicia is a 3D technical artist, TA and independent developer. Codex assisted with the dataset adapters, measurement and editing.

Related studies

Data and reproduction

Gaussian Splat Viewers on Desktop: PLY, SOG and SPZ

Alicia lu — Thu, 05 Nov 2026 03:36:43 +0000

Originally published by Alicia Lu on 5 November 2026 at Digital Garden. Alicia is a 3D technical artist, TA and independent developer. Codex assisted with this study.

I used one 4,096-splat synthetic garden to check three ways to view Gaussian splats locally in Chrome. SuperSplat's generated HTML and antimatter15/splat both rendered the garden. A pinned PlayCanvas Model Viewer debug build rendered original PLY, compressed PLY and bundled SOG. The same viewer did not load SPZ v3 or v4 through its local file input. Its release build hit a worker error before displaying the three supported files.

Three desktop paths

Viewer path	Local input actually tried	Desktop result
SuperSplat Viewer standalone	SOG embedded by splat-transform 3.10.3	Visible garden in a 960 × 720 canvas
antimatter15/splat at ba182b51b7c2	Original PLY by absolute same-origin URL	Visible garden and a WebGL instanced draw with 4,096 instances
PlayCanvas Model Viewer 5.10.0, debug WebGL2	PLY, compressed PLY and bundled SOG	All three rendered and each decoded resource held 4,096 splats
PlayCanvas Model Viewer 5.10.0, debug WebGL2	SPZ v3 and SPZ v4	Both left the load screen visible with no decoded splat resource

The screenshots use the viewers' own camera and UI. I checked file loading and actual drawing. The format comparison uses one renderer and matched cameras for its separate image-error and startup measurements.

Replaying local files

For SuperSplat Viewer, this command generates a standalone HTML page that embeds the SOG data. My generated file was 3,892,390 bytes including the viewer.

npx splat-transform -g cpu garden.ply garden.html

For antimatter15/splat, serve the upstream HTML and JavaScript from a static server and set the url query parameter to an absolute same-origin PLY URL. A relative value resolves against the viewer's default asset host. My initial relative-URL probe attempted to reach that host, which the harness blocked. The final replay issued only local GET requests.

The PlayCanvas test used the open-source Model Viewer at commit 34df5967df32 with PlayCanvas Engine 2.19.7. I built the release and debug targets from the same source and lockfile. The release build hit a ReferenceError in its blob worker on WebGL2 and WebGPU. The error also appeared after the panel reported 4,096 primitives for PLY. The rendered garden was absent, so those runs did not pass. The upstream debug build ran the three supported formats on WebGL2. Its compressed PLY and SOG scene panels showed zero primitives even when the garden was visibly rendered. I checked the decoded resource count for those rows. This describes the pinned local builds. The hosted viewer and the engine's separate SPZ parser have their own paths. Model Viewer source, Model Viewer formats, PlayCanvas Engine SPZ parser.

What the desktop check covers

The successful local replays required no login and made only local GET requests in the isolated test. The network evidence covers these specific self-hosted paths, with any nonlocal traffic blocked by the harness. It says nothing about upload and account behavior on third-party hosted services. The rendered screenshots and source file receipts are included. Physical iPhone and Quest 3 operation, immersive modes and hosted service policies remain separate tests. SuperSplat Viewer, antimatter15/splat.

Alicia is a 3D technical artist, TA and independent developer. Codex assisted with the test harness, evidence checks and editing.

Related studies

Data and reproduction

Houdini GLB to USDZ with Blender, Three.js and Three-Live

Alicia lu — Thu, 05 Nov 2026 03:36:30 +0000

Originally published by Alicia Lu on 5 November 2026 at Digital Garden. Alicia is a 3D technical artist, TA and independent developer. Codex assisted with this study.

I converted the same textured Houdini plant with Three.js r187, Three-Live 1.2.3 and Blender 5.2 LTS. All three exports reopened in Houdini with 1,056 triangles. Blender preserved the original world bounds, two textures and the double-sided leaves. Three.js preserved the bounds and textures. Three-Live produced the smallest package, with a shifted bounding box and no linked textures.

One input and three export paths

The 947,652-byte input is the owned 512-pixel GLB from the Copernicus bake study. It has 628 vertices, 1,056 triangles, a normal map, a packed occlusion-roughness-metallic map and a double-sided material.

Three.js r187. In Chrome 156 on an RTX 5070 Ti, I loaded the GLB with GLTFLoader and ran USDZExporter with maxTextureSize 1024. I exported three times per Quick Look option.
Three-Live 1.2.3. The verified Windows x64 CLI read the same GLB and exported USDZ directly.
Blender 5.2.0 LTS. A factory-startup background session imported the same GLB and exported a Y-up, meter-scale USDZ with USD Preview Surface. A fresh Blender scene then imported the USDZ, recovering 628 vertices, 1,056 faces and two packed images.

three-live-cli.exe convert input/houdini-plant.glb -f usdz -o evidence/plant-three-live.usdz
blender --background --factory-startup --python-exit-code 2 --python export_blender.py

const { scene } = await new GLTFLoader().loadAsync('/input/houdini-plant.glb');
const bytes = await new USDZExporter().parseAsync(scene, {
  quickLookCompatible: true,
  maxTextureSize: 1024
});

What survived when I reopened the packages

Path	USDZ bytes	Stored ZIP members	Resolved image files	Points / triangles	Double-sided	World Y range (m)
Three-Live 1.2.3	66,910	1	0	628 / 1,056	false	−0.9923 to 1.1887
Three.js r187, option off	364,858	4	2	628 / 1,056	false	0.0000 to 2.0287
Three.js r187, option on	364,858	4	2	628 / 1,056	false	0.0000 to 2.0287
Blender 5.2 LTS, Y up	957,384	3	2	628 / 1,056	true	0.0000 to 2.0287

Houdini 22.0.429's OpenUSD 0.26.5 reopened all four packages. All entries passed CRC, store-method and 64-byte alignment checks. Each stage declared Y up and one meter per unit. Three.js and Blender preserved the GLB world bounds to within 0.000001 m per component. The Three-Live file had one USDA layer and a bound UsdPreviewSurface with no linked texture files.

The Blender package used a binary USDC layer and two PNG textures. Its normal PNG accounts for most of its 957,384 bytes. The result supports a desktop handoff where the leaf backs and floor position matter. The smaller Three.js result is another candidate when the mesh's single-sided export is acceptable for the intended camera.

What the Quick Look option changed on this plant

All six Three.js exports were byte-identical, across both settings. The exporter warned about the double-sided input in each run. Every Three.js USD mesh reopened with doubleSided false. The result is specific to this asset and exporter build.

The included device checklist links the saved USDZ files. A physical iPhone can then check texture appearance, back-facing leaves, initial scale and placement. This release reports the desktop export and reopen. Apple documents the device playback path separately. Apple Quick Look, Three.js USDZExporter, Three-Live 1.2.3, Blender USD manual.

Alicia is a 3D technical artist, TA and independent developer. Codex assisted with the test harness, evidence checks and editing.

Related studies

Data and reproduction

SPZ vs SOG vs PLY: Five Exports of One Gaussian Splat Garden

Alicia lu — Thu, 05 Nov 2026 03:35:22 +0000

Originally published by Alicia Lu on 5 November 2026 at Digital Garden. Alicia is a 3D technical artist, TA and independent developer. Codex assisted with this study.

On one 4,096-splat garden, SPZ v4 was the smallest file at 62,011 bytes, down from 278,942 bytes for the original PLY. Compressed PLY had the smallest image error in the three tested Spark views. SOG landed between compressed PLY and SPZ on that image comparison. The best pick depends on the viewer's supported formats and whether the delivery server applies additional compression.

One source, one renderer

I started with an owned synthetic scene fitted from Karma renders in the Houdini procedural splatting study. The source has 4,096 splats and SH degree 0. I encoded the exact same PLY with splat-transform 3.10.3, then loaded every result through Spark 2.4.0 and Three.js r187. The browser was Chrome 156.0.8078.80 with WebGL on an RTX 5070 Ti.

npx splat-transform garden.ply garden.compressed.ply
npx splat-transform --spz-version 3 garden.ply garden-v3.spz
npx splat-transform --spz-version 4 garden.ply garden.spz
npx splat-transform -g cpu garden.ply garden.sog

Size, first submission and image difference

File	Raw bytes	Brotli q11 bytes	First submit median (ms)	Full-frame RGB PSNR vs PLY (dB, three views)
PLY	278,942	212,282	143.6	reference
Compressed PLY	67,344	66,656	147.8	54.37 / 53.42 / 54.18
SPZ v3	68,140	68,145	164.1	49.38 / 48.73 / 49.35
SPZ v4	62,011	62,015	150.7	49.38 / 48.73 / 49.35
Bundled SOG	69,537	63,049	144.3	50.19 / 49.62 / 50.10

Each median covers three fresh browser contexts on loopback, with an uncached asset request. Timing runs from navigation's performance origin until the first renderer.render() and blocking gl.finish(). The early submission includes module setup and shader work. One raw PLY sample took 414.1 ms, while the other two took 132.6 and 143.6 ms. These three-sample results describe the startup runs and are too sparse for a speed ranking. Brotli measurements are offline byte counts, with no network latency or server configuration in the comparison.

After the scene settled, I rendered three fixed views at 768 × 768. The table compares their full 8-bit RGB images, including the background. It measures encoding differences under this renderer. The two SPZ versions gave identical RGB captures in all three views, with different on-disk sizes. Full-frame PSNR can hide small changes around leaves and other thin edges.

Where each result applies

Keep a full PLY master for editing and repeat exports. Check the actual splat schema when receiving a PLY from another tool.
SPZ v4 saved about 78% against the source PLY in this test. This file uses Zstandard. SPZ v3 uses gzip and remains an option when a viewer needs that version.
SOG bundles quantized WebP attribute images and metadata. It shrank by another 6,488 bytes under offline Brotli q11 here. Streamed SOG and remote range loading remain outside this comparison.
A separate 124-splat synthetic SH3 control encoded and decoded as SPZ v4 and SOG, retaining three SH bands in splat-transform's readback. That is a structural check on a different asset. The main five-format timing and visual comparisons are SH0.

The test did not measure per-process GPU memory, CDN performance, large captures or mobile devices. Supported formats depend on both the reader and the format version. For example, PlayCanvas documents its SPZ parser separately from the Model Viewer drag-and-drop list. Niantic SPZ, PlayCanvas SOG, PlayCanvas Model Viewer.

Alicia is a 3D technical artist, TA and independent developer. Codex assisted with the harness, evidence checks and editing.

Related studies

Data and reproduction

A Mountain River in Unreal PCG: Testing a Houdini Erosion Mask

Alicia lu — Wed, 04 Nov 2026 03:58:03 +0000

Originally published by Alicia on 4 November 2026 at Digital Garden. Codex assisted with implementation, testing and writing.

Houdini's native erosion changed a 1,008 m valley and produced a flow layer. I exported binary placement masks, brought them into Unreal 5.8.4 and ran the same native PCG grid with three controls. Of 3,844 unmasked candidates, 134 were inside the authored river corridor. A channel-only mask and a channel-plus-flow mask both reduced that number to zero. Flow removed three additional candidates near the channel for this grid and threshold.

Construct the slope, then measure erosion

I built a 512 × 512 Houdini HeightField on a 1,008 m square, at 1.96875 m voxel spacing. A deterministic procedural surface contains a downward slope, a sinuous channel corridor and noisy valley sides. HeightField Erode 3.0 froze at frame 9. A forced cook of the erosion node took 0.871 s on this machine. Across the tile, the eroded elevation ranged from 0.84 to 185.17 m. Relative to the authored surface, height changes ranged from −28.35 to +10.77 m.

The channel is defined by the authored centerline and an 18 m half-width. The combined exclusion also removes pixels within 60 m of that centerline when normalized native flow exceeds 0.45. Positive flow was divided by its 98th percentile, 7.3656 in the exported layer's units, and clipped. The channel excludes 9,378 of 262,144 source pixels. Adding the flow rule excludes 133 more. This makes the extra contribution measurable without treating the flow layer as an independent water simulation. SideFX HeightField Erode reference.

Houdini's voxel index order put its world Z in the fast axis. I reordered the native data before writing a PNG with X along columns and Z along rows. The PNG alpha carries the allowed mask. The graph reads that channel with bilinear filtering and a 0.5 threshold. The additional 505 × 505, 16-bit heightmap is a center crop intended for future Landscape import. I decoded it independently against the source heights and measured a maximum quantization error of 3.922 mm.

Native PCG on the same grid

The isolated Unreal map used 62 × 62 points at 16 m spacing. The graph was Create Points Grid → Sample Texture → Density Filter. The Get Texture Data node uses a 100,800 cm texture footprint. The Houdini XZ plane maps to Unreal XY. The mask textures were imported with sRGB disabled, no mipmaps and uncompressed data settings. All three graph variants used the same editor scene and grid.

Control	Candidate output points	Within authored corridor
All allowed	3,844	134
Channel exclusion	3,708	0
Channel and flow exclusion	3,705	0

Each case was forced three times after reopening the saved Unreal map, and each case returned the same coordinates across its three runs. The independent comparison used the actual baseline XY positions and reconstructed sampling from the saved mask. A nearest-texel check differed at two channel-only points and three combined-mask points. The bilinear check matched all retained XY positions. The extra two channel-only removals outside the analytic corridor come from sampling the raster boundary with a threshold.

The first baseline reached the editor's generation event in 424.2 ms. All eight later requests completed in 14.9–18.0 ms in the same editor session. They may reuse compiled graph work and cached data. These are request-to-event latencies, with no claim about packaged runtime, mesh rendering or per-node CPU time. Earlier null-renderer launches timed out; the successful run used offscreen D3D11. Epic PCG node reference.

Scope

This is an Unreal editor test of placement eligibility. Native PCG returned point coordinates on a plane at Z = 0. It did not import a Landscape, project points onto terrain, spawn production foliage, render water or run a packaged game. The exported heightmap and separate wetness mask are available for that follow-up. In this fixture, the channel mask alone was sufficient for excluding all tested in-channel points. The flow layer changed a narrow part of the surrounding placement budget.

Reproduction archive and data. Codex implemented the fixture, ran and audited the native tests, and drafted the article.

Related study: Digital Garden field note.

Raw measurement files

Procedural Gaussian Splatting in Houdini: Six Fits Without Photos

Alicia lu — Wed, 04 Nov 2026 03:58:02 +0000

Originally published by Alicia on 4 November 2026 at Digital Garden. Codex assisted with implementation, testing and writing.

I rendered a small procedural valley in Houdini and trained six Gaussian splats on the resulting synthetic images. With the same 4,096 splats and 600 training steps, going from 12 to 24 training views improved held-out quality for both seeds. Going from 24 to 36 gave little extra full-frame PSNR and slightly lower foreground PSNR in both runs. This is a result for one 192 × 192 scene and one fixed-capacity trainer.

Make a scene and keep the cameras honest

The test scene is a small valley diorama with a pool, rocks and eight trees. A Houdini 22.0.429 hython script built a USD stage from procedural primitives, set materials and lights, and saved a HIP with a relative reference to the source USD. Karma CPU produced 44 RGBA EXRs at 192 × 192, with 12 samples per pixel and motion blur disabled.

Training used the first 12 cameras, then a nested 24-camera set, then all 36 training cameras. The extra eight cameras use offset azimuths and alternating elevations. They were used only to render ground truth and score the finished fits. Initialization sampled random centers in a broad scene-sized box. The fitter received no geometry points, depth, or pixels from the eight held-out views. The scene's approximate dimensions and camera aim were authored and shared across the trial.

The renderer output was composited over a fixed background in render-linear RGB, then clipped and passed through a fixed gamma curve. It defines the training target for these numbers. It is separate from the native Karma viewer's display transform.

Six GPU fits at fixed capacity

Training views	Seed	Full-frame PSNR (dB)	Foreground PSNR (dB)	SSIM	Fit wall time (s)
12	381	32.55	28.92	0.92114	13.039
24	381	35.80	33.26	0.94525	1.663
36	381	35.97	33.21	0.94670	1.717
12	719	32.18	28.51	0.91714	1.337
24	719	35.71	33.18	0.94457	1.443
36	719	35.82	33.11	0.94539	1.596

The workstation ran Torch 2.9.1+cu128 and gsplat 1.5.3 on an RTX 5070 Ti. Each fit optimized positions, scales, rotations, opacity and a view-independent RGB value, with no point splitting or pruning. Loss gave equal weight to full-frame and alpha-masked absolute error. Metrics are means of eight per-image scores. Foreground scores exclude target pixels with alpha at or below 0.5. SSIM uses a Gaussian 11 × 11 window.

The first fit had a much larger wall time than subsequent fits. Those times include initial work in the shared Python process and do not isolate a camera-count speed effect. Peak Torch allocations were 22.45–22.46 MiB and peak Torch reservations 26 MiB for this tiny scene, including cached target tensors. They do not report total driver or GPU residency. The 12-step pilot is separate from the six fits.

Browser delivery and collision

I preselected the 36-view, seed-381 output for delivery. The binary PLY is 278,942 bytes and the SPZ v3 is 64,915 bytes, 76.7% smaller. Both decoded as 4,096 splats and reopened in Spark 2.4.0 on NVIDIA WebGL2. Browser screenshots retain visible blur and residual floaters. The numeric quality table describes the trainer's renders at 192 × 192. It does not score the browser's differently sized render or the format conversion.

The invisible Three.js proxy reproduces the base slab of the authored USD using a 2.64 × 0.26 × 2.26 metre box. Three downward rays inside its footprint hit the top at y = 0 within 4.77 × 10⁻⁹ m. Two outside rays missed. Both PLY and SPZ runs gave the same result because the rays tested the separate mesh. The test covers the slab only, with no physics solver, full collision mesh or relighting claim.

The previous Houdini native export study covers GSplat SOP and format transport. This study instead varies synthetic views and separates visual display from collision. Spark SplatMesh reference.

Reproduction archive and raw evidence. Codex implemented and ran the experiment and drafted the article.

Related study: Digital Garden field note.

Raw measurement files

training.json

Three.js Gaussian Splats: Gaussian-Splat-Lite, Spark and Radix on One Desktop

Alicia lu — Wed, 04 Nov 2026 03:57:57 +0000

Originally published by Alicia on 4 November 2026 at Digital Garden. Codex assisted with implementation, testing and writing.

I compared Gaussian-Splat-Lite 1.6.2, Spark 2.4.0 and Radix 0.0.1 using the same fixed SPZ file at each size, with five hardware-backed paths on an RTX 5070 Ti. Spark on r187 reached the first submitted-work wait sooner than the other paths at both sizes. The warm camera orbit paced near 60 Hz in every group. That cadence cannot rank GPU throughput.

What was actually shared

The two SPZ v3 files contained 500,000 and 2,000,000 view-independent splats from the same seeded, synthetic flower-bed generator. File sizes were 6,443,429 and 25,759,887 bytes. Every path decoded the expected count and rendered the same opaque cube, camera, 1280 × 720 output and orbit. This is an owned stress fixture, separate from a photographic scan and the live garden.

I used Three.js 0.187.0 for Gaussian-Splat-Lite and the main Spark run. The first Radix pilot on r187 hit Three.js's compute dispatch size error. Radix 0.0.1 then ran with its compatible 0.186.1 setup. An extra Spark 2.4.0 path also ran on 0.186.1. The derived local bundles for the two r186 paths only redirect Three.js imports to the pinned alias and remove source-map references. The compatibility failure is preserved. Gaussian-Splat-Lite repository · Spark · Radix.

Setup and frame pacing

The clean repeat ran 30 fresh contexts in one Chrome 156.0.8078.80 process, with three contexts per size and path and rotating order. WebGPU reported NVIDIA Blackwell, and WebGL2 reported the RTX 5070 Ti through ANGLE D3D11. Antialiasing was disabled and the pixel ratio was 1. Each run included 45 warm-up frames, then 120 recorded requestAnimationFrame intervals during the orbit. The earlier run had an unclassified 404 console entry in one context and overlapped the start of the Unreal task. It stays separate from the clean repeat.

Startup measures module execution after the common dynamic Three.js import through the first render call and completion wait for submitted work. It includes backend setup and renderer-specific imports and loading. It stops at WebGPU queue completion or WebGL finish. Any asynchronous sort can still be pending. The later capture and full warmed orbit verify the decoded scene separately.

Renderer path	Three.js	0.5M first wait (ms)	2M first wait (ms)	0.5M warm p95 (ms)	2M warm p95 (ms)
Gaussian-Splat-Lite WebGPU	0.187.0	351.2	847.4	16.7	16.8
Gaussian-Splat-Lite WebGL2 backend	0.187.0	250.0	648.9	16.8	16.8
Spark WebGL2	0.187.0	227.7	475.3	16.8	16.8
Radix WebGPU	0.186.1	767.1	1,106.2	16.7	16.7
Spark WebGL2 control	0.186.1	254.3	515.7	16.8	16.8

The cells report the median of three run-level measurements. All ten groups had a 16.7 ms median and 16.8 ms p99, rounded to one decimal. The only intervals above 25 ms were two in the 500,000-splat Gaussian-Splat-Lite WebGL2 group. At that size its first-wait values also ranged from 246.8 to 572.8 ms. Fresh contexts do not clear the browser process, GPU driver or server transform caches. The startup table is a local observation, not a cold network benchmark.

Scope and what I would test next

These are renderer paths as configured, with different sort and upload implementations. No measured GPU timestamps, total VRAM, sort latency or pixel-accuracy ranking is inferred from rAF. All runs used fully loaded SPZ, so the table says nothing about paged RAD, SOG or LCC2 streaming. The raw renderer counters and per-frame intervals are in the archive.

Reproduction archive with deterministic fixture generator and raw evidence. The earlier Spark and Radix study used a separate protocol and remains a separate result. Codex implemented the harness, ran the tests and drafted this article.

Related study: Digital Garden field note.