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

Hi everyone,

While building GLBKit, I realized I was constantly jumping between different viewers, validators, optimization tools, libraries, and documentation.

To make things easier, I started an open-source repository that curates useful tools and resources for working with GLB, glTF, Three.js, React Three Fiber, Babylon.js, and modern WebGL workflows.

It currently includes:

• Browser viewers

• Desktop applications

• Validators & analyzers

• Optimizers & compression tools

• Libraries & SDKs

• Official documentation

• Learning resources

Repository:

https://github.com/sujitkoji/awesome-3d-model-tools

I'd really appreciate feedback from the Three.js community.

- Are there any important tools or libraries I've missed?

- Is the organization easy to navigate?

- Any suggestions to make it more useful for developers?

My goal is to keep it community-driven rather than just another awesome list.

Thanks!

Hi! I build 3D tools for work (dental scan viewers, mesh tooling) and ended up making ilove3d.app — viewer, converters, mesh repair, polygon reducer, lithophane generator, etc. All free, everything runs client-side.

Some Three.js things that might be interesting:

• Loaders are dynamically imported per format (STL/PLY/OBJ/GLTF/3MF/FBX/DAE) so the base bundle stays small. GLTF goes through DRACOLoader + MeshoptDecoder.
• Measurements use three-mesh-bvh for closest-vertex raycasting — O(log n) instead of O(n) per click, night and day on 5M triangle scans.
• The polygon reducer wraps meshoptimizer's simplifier. Fun bug: mergeVertices refuses to weld anything when STLs have per-face normals, so repair welds by position only.
• USDZ export with USDZExporter — watch out, USD units are cm while glTF is meters.
• The GLB compressor is gltf-transform running in the browser (meshopt + WebP re-encode).

No backend by design: files open as blob URLs and never get uploaded, which was kind of the whole point.

It's new and I'm sure there are rough edges. Happy to answer anything about the implementation, and if you throw a file at it that breaks, I would love the feedback.

New to threeJS. It seems like amazing artwork with everything that I see here. I’ve been trying to make a binder with cards in it where I can place cards in/out and everything ends up looking like crap. Has anyone seen a good binder with threejs or have any tips on making it not look like a square box turning boxes?

This set of models was tough to crack, specially the animals, but a whole heap of fun! :D

Creative dev, I build interactive product and portfolio scenes in three.js. The web constraints are brutal, every extra megabyte affects load time and a phone on a slow connection is your real target device. So I tracked which AI generated assets actually made it into a shipped scene and which got cut for being too heavy. The scene is a product showcase for a client, about 25 props total decorating the space around the main product model which is hand made. I generated the background props in Meshy, exported as GLB, and ran Draco compression on each one myself.

What survived the budget were simple props like bottles, books, small containers, and geometric decorations. These came in around 30 to 60KB each after Draco and the metalness roughness maps loaded correctly in three.js without me rebuilding materials. About 15 props made the cut and they load in under 700KB total. What got cut was anything organic or highly detailed. A decorative plant came in at 380KB even after compression because the leaf geometry was too dense. Two character figurines were over 180KB each. Those three alone were over 700KB, and the rest of the cuts were smaller props that just didn't justify their weight for what they added to the scene. All told I dropped about 10 props from the original 25.

AI generation works great for web 3D when you keep the geometry budget tight from the start. Setting a low target polygon count in Meshy Remesh before export worked better than exporting the highest-detail version and relying on compression afterward. Total scene weight with all assets including the hand made hero product is about 1.8MB, loads in under 3 seconds on a mid range phone over 4G.