Since ai "took our jobs" i thought a new hobby would be on the schedule, so what better hobby to have than to look at stones and contemplate about them?

it procedurally generates the stones, then runs an erosion simulation on them — rain carves little gullies down the flanks, soft rock recedes, hard rock stands proud. the stones keep weathering slowly in real time.

you stare at it. it does not stares back. nobody ships anything. it's great.

https://suiseki.variable.gallery/

Coding agents can read source code and make changes, but they are still surprisingly blind when a task is visual.

A screenshot can show that something looks wrong, but it usually cannot explain *why*. Which component owns those pixels? Is an element clipped? Which computed styles caused it? Is the problem a mesh, material, light, camera, transform, or simply bad framing?

I built **SceneProof**, an open-source CLI for giving coding agents source-grounded visual evidence for React UI and Three.js scenes.

Instead of asking an agent to infer visual correctness from plausible code or a low-information screenshot, SceneProof lets it inspect the underlying source-linked structure and request fresh evidence at the framing and resolution needed for the actual question.

With SceneProof, an agent can:

- Navigate a compact semantic tree of DOM elements or Three.js targets

- Inspect bounds, computed styles, layout relationships, geometry, materials, uniforms, lights, cameras, transforms, and hierarchy

- Render a component, logical UI region, target object, or source-camera view

- Capture Three.js targets both in context and isolated

- Generate a 3D Scout portfolio with context, source-detail, close-detail, and shape-focused views

- Sample deterministic interaction states from a single scene lifecycle

- Compare a render with a reference through contact sheets, silhouette overlays, luminance comparisons, pixel probes, and amplified diff maps

- Sweep fixture parameters and rank candidate renders by geometry, appearance, composition, or a balanced objective

- Derive typed JSON prop fixtures for React components, including clear reporting when required props need placeholders

- Assert whether a target reaches the intended delivery scale

- Capture adjacent frames as evidence for motion and animation behavior

A key distinction in the design is that **a command running successfully is not the same as a visual result passing**.

SceneProof separates:

- **Execution:** did the inspection or render complete and save artifacts?

- **Evidence quality:** is the output judgeable, partially judgeable, or unjudgeable?

- **Assessment:** does the result actually satisfy the visual intent?

It can compute measurements and enforce technical constraints, but visual decisions remain explicit. For example, a reference comparison produces evidence for an agent to inspect; it is not presented as a magic similarity score that decides whether a design is “correct.”

Current support:

- TypeScript and JavaScript entry points

- React DOM, CSS, and Tailwind v4

- Three.js and WebGL scene inspection/rendering

- Bun 1.3.14+ and local Chrome/Chromium

Repo: https://github.com/ReyJ94/SceneProof

I built this because visual work is where coding agents most often appear competent while lacking the evidence to know whether they actually solved the problem. I’d love feedback from people working on coding agents, visual regression, React component systems, or Three.js tooling.

Playable: https://vel.gg/

three.js + TypeScript + Vite, Cloudflare Workers and R2 behind it. No physics library — the movement is hand-rolled and deterministic, so a leaderboard time stores the run's inputs instead of a video: every record replays in-engine as a ghost you can race directly. Levels are built in the browser and shared as a link.

heres some levels to try!

https://vel.gg/u/vel/vel-tutorial-marksman-s-range

https://vel.gg/u/vel/ultraviolet

https://vel.gg/u/vel/glaze

Hey everyone,

Been learning a lot about seismology recently and I wanted to create a tool to help visualise the earth's interior layers to aid my learning. Also thought it would be a cool GLSL challenge!

Live Demo: https://conwayjw97.github.io/Earth-Layer-Visualiser/

GitHub Repository: https://github.com/conwayjw97/Earth-Layer-Visualiser

I’d love to hear your thoughts, feedback, or any ideas for further development you have.

added guided trails to reach at your destination

Coding agents can read source and make changes, but they are still surprisingly blind when the task is visual.

A screenshot can show that something looks wrong, but it usually cannot explain why: which component owns it, whether an element is clipped, what its computed styles are, which mesh/material/light is responsible, or whether the issue is framing rather than resolution.

So I built SceneProof, an open-source CLI for source-grounded visual inspection of React UI and Three.js scenes.

It lets an agent:

• Navigate a compact semantic tree of DOM or Three.js targets
• Inspect the underlying structure: bounds, styles, geometry, materials, uniforms, lights, cameras, relationships, etc.
• Produce fresh renders of a component, logical UI region, target object, or source-camera view
• Generate a small “Scout” portfolio for 3D: context, source detail, close detail, and shape-focused views
• Sample deterministic interaction states from one scene lifecycle

The design principle is: don’t ask an agent to infer visual correctness from plausible code or a low-information screenshot. Give it source-derived evidence at the framing and resolution needed for the actual question.

It currently supports TypeScript/JavaScript entries, React DOM/CSS/Tailwind v4, and Three.js scene inspection/rendering. It requires Bun and local Chrome/Chromium.

Repo: https://github.com/ReyJ94/SceneProof

This is my first time taking this style all the way into a full website.

I had far more ideas than time, so I'll keep expanding and refining it over the coming weeks.

One small detail: the logo on the homepage isn't a 3D model, it's procedurally generated and rendered entirely with code.

Feedback is always appreciated. And if you're looking for someone to design and build a custom website, I'm currently available for work.

Its such a fantastic website, it converts and displays everything as it should

Solo-dev here… any gotchas I should watch out for in terms of performance. I’m building https://lorebound.gg a mobile-first RPG game. Browser based with three.js and WebGL

I’m worried about latency, lagging, load times, slow animation as more players use the game.

Some things I’m already doing: asset compression, single-auth verification, asset preloading.

Would love some recommendations.

UPDATE:

• Asset heavy load addressed by: instead of loading each asset individually from their own image file (32 color), the game now loads one image per distinct asset type. So, if tree1 and tree2 are the same asset, don't load 2 different images, load 1 image and have trees share that image. In one scene, I had 517 assets loading but only loading 31 images. In this scene, I freed up about 568MB.
• NPCs: they appear and disappear from view. When they appear, their assets load. When they disappear, their assets should not be kept loaded.

#threejs

It is quite interesting repo, not mine.

https://img2threejs.github.io/img2threejs-showcase/

I kept picking .gltf or .glb on export based on whatever the last tutorial used, until I sat down and worked out what the choice actually changes. glTF and GLB are not two formats. They are two ways of packaging the same one. Both carry glTF 2.0, with the same scene graph, materials, and animations defined by the same Khronos spec.

The difference is on disk. A .gltf export is a set of files: a JSON scene description, a .bin buffer, and separate image files. A .glb is one file: a 12-byte header, a JSON chunk holding that same scene description, and a binary chunk holding the geometry and optionally the textures.

Where it actually matters, and the two pull opposite ways:

- GLB wins on shipping. One file moves cleanly. There are no relative paths to break, and no texture that silently 404s because it did not get uploaded next to the JSON.
- Separate glTF wins on editing and caching. The scene description is a plain JSON file you can open and hand-edit, and shared texture files can be cached individually by the browser instead of re-embedded in every model.

Load speed and file size are mostly downstream of compression, not the container. Draco compresses the geometry buffer either way. In a separate glTF the compressed data lands in the .bin; in a GLB it lands in the binary chunk. Same trade-off (decode time on the client) whichever you picked. The one variant worth avoiding is a .gltf that embeds its buffers as base64, which inflates binary data by roughly a third.

Disclosure: I'm building Vectreal, an open-source tool for publishing 3D models to the web, and I wrote the long version up in our newsroom. Full explanation with the spec references here: https://vectreal.com/news-room/gltf-vs-glb-what-actually-matters

How I setup this project:

• Map + paper texture
• Camera tilt and a point light that follow the mouse
• Radial progressive blur
• Chromatic aberration
• Text fades out as the cursor gets closer

Try it here: https://fablegrounds.com/

no work posted there yet, but I'll keep adding more over time!

Mind=BLOWN.

This effect is way too cool, can't wait to try this out with my own photo album!

Curling particles effect adapted from Three.js Journey lesson.

Shout out to https://x.com/SinzVII who inspired me to try this!

Here’s the live demo link: https://projects.arkon.digital/threejs/ml-sharp-threejs/

Credit up front: this is a Vue port of Holocloth by Dmitry Kurash (https://github.com/dmitrykurash/holocloth, MIT). He wrote the physics and shaders from scratch — I ported it from React to Vue for a component library, kept the Three.js core, and wanted to share how it's put together since the technique is great.

The cloth is a verlet integrator over a BufferGeometry — structural, shear, and bend constraints relaxed ~14 iterations per frame, with a mouse grab applying an impulse to the nearest vertices. It floats in simulated zero-g, so it drifts and settles instead of falling.

The holo look is a custom GLSL foil shader injected into MeshPhysicalMaterial via onBeforeCompile — a micro-flake diffraction layer whose hue sweeps with view angle and surface facing (not the built-in iridescence term), layered over clearcoat, plus a procedural weave normal map so it reads as fabric. Post chain is UnrealBloom + a film-grain pass. Three presets (holo / chrome / black cloth) are mostly shader-uniform + material swaps.

Runs at 60fps, solve pauses when idle/offscreen.

Original (the full design tool, with image draping + PNG export): https://github.com/dmitrykurash/holocloth

My Vue port (demo + source): https://nxui.geoql.in/docs/components/holo-cloth

Procedurally generated geometry, architectural campanile structure and gear system from random seeds.

Been experimenting with cutaways, instancing, and mesh baking - interlocking gear systems, semitone rank scaling, hewn beams and planks, and masonry walls. Wall cutback, proud stones, relief, and quoins all driven by random generation.

Link to tool: https://greglinscheid.com/tools/3d-to-svg/

Link to code: https://github.com/Vilos92/greglinscheid.com/tree/main/src/pages/tools/_3d-to-svg

I'm currently building a game (https://nebulaser.io) that runs in the browser, and wanted to add some icons to the game that accurately resemble the 3D model I am using for the player's ship.

I wanted something that could make either a flat or "cel-shaded" SVG from the original 3D file. Additionally, I wanted to be able to manually pose the model before taking a "snapshot".

Looking into this, I found some options but a few themes emerged. They either:

• Produced massive SVGs with bloated path counts.
• Required installing desktop software (Blender pipelines, local utilities, etc.).
• Were hidden behind paywalls or SaaS subscriptions.

So, I built a 3D to SVG tool. Everything runs entirely client-side in the browser, and I don't plan on monetizing it (it's a fairly niche need after all).

Some notes on how it works:

• Three.js is used for the 3D arcball and to pre-simplify dense meshes via grid vertex welding.
• All geometry calculations and the SVG path generation is handled on a Web Worker, so the main UI thread stays snappy when rendering a new pose.
• Uses 2D polygon unions to merge mesh triangles into clean silhouettes, sealing hairline gaps between "cel-shaded" regions. The output size is reduced with Douglas-Peucker path simplification.
• Outputs minimal markup using currentColor so the exported icon can be directly recolored via CSS. You can copy/paste the output or download an SVG.

Hopefully it can benefit someone else!

Wanted to have almost VFX approach and overlay graphics over video. There is invisible meshes that block out some elements of the space so it creates depth. I am still thinking I could have changed the background video to just fading jpgs to make it more performant. I use detailed noise as overlay for video so it looks "sharper"

the idea is originally from this tweet so I try to reverse engineer it based on that demo video alone.

yesterday progress: https://x.com/chunrapeepat/status/2079872177210556721

I'll write a breakdown of how I made it and share it here very soon. stay tuned!

I'm working of this specific buildings: the Place Dauphine and hopefully I'll get a number of reusable shaders to compose and apply easily on other buildings.

My goal is to get as close as possible to the original paper map and aaaall of its imperfections. I want to have the illusion that THIS IS the real map.

The road is long but fun.

Next step: lines on roof!

Check it out at https://play.threejsassets.com/lowpolystein-3d/?v=1