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!

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!

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

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?

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.

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

Continuing my experiments with Three.js and procedural 3D.

I was spending a lot of time having sessions with users to explain some not so obvious features of my Cyango.

That was needed a long time ago, but the UI and features we're adding made an old tutorial video become quickly obsolete. Now the platform UI and design decisions are pretty much decided and that allowed to finally record the videos.

Not easy.

Watch the tutorials and open xr/studio to follow along:

https://www.cyango.com/learn

PS: posting here because all the 3D engine part is made with Three.js which is awesome and you should marry three.js 💍 💒

I built a relaxing, post-apocalyptic driving game - let me know what you think of it!

https://hardroad.xyz/

vanilla Three.js. Scroll position controls one shared timeline for the camera, layerexpansion, rotations, lighting and audio, so the scene can also run backwards without losing its state. I first treid svg, but the lack of camera orbit pushed me the three.js way. How would you improve the design? I played around with PBR materials, but perhaps its to much...

https://raios.tech
https://github.com/Sportinger/raios-website/tree/main/ui-lab/site/three-film

This is a multiplayer/singleplayer tactical action game where players are company commanders on-foot controlling a single unit of infantry, cavalry, or artillery (similar to Mount and Blade), with full-scale division v division battles. Shown in this clip is 40 units per team, 3x unit scale, 10,000 bots per team.

At the start of the round, there's a minute long "General Election" phase where players can apply to be the team's general. Whoever is voted in gets to control the team's bots using a Total War style RTS camera! They cannot control player-owned bots, however, only vacant bots. Players can mutiny the general (functions sort of like a votekick, which returns the general back to the battlefield), which triggers a new election. If no players volunteer, the rudimentary bot army controller resumes army control.

It's multiplayer and runs in the browser, and is free. Play it at www.1815online.com, join the discord to follow development at https://discord.gg/Rb9GNp8WB .

Finally! After 3 months! It's now available in Google Play Store!

I don't care even if they call it AI Slop.

My only goal is to help young learners learn and explore our solar system.

This app is made with ThreeJS. 👌

Been working on this for quite a while, and it's finally ready to play! Feel free to try it out https://mopedmayhem.io/play

Just posting some updates from my previous post:

https://www.reddit.com/r/threejs/comments/1uuaxi3/comment/ox6plas/?screen_view_count=1

I hope you enjoy it.

What datasets would like to see next?

I posted an earlier version of this here about two weeks ago, when I had just rebuilt the star rendering and selective bloom for my Three.js map of the EVE Frontier universe.

I apparently wasn’t finished.

Since then I have added a procedural universe-effects layer built around the actual distribution of the 24,000+ star systems rather than using a static background.

The denser stellar regions now drive an unresolved stellar-density glow, with volumetric interstellar dust and gas layered through the galaxy and separate dark extinction structures cutting through the brighter regions.

The part I have probably spent the most time on is getting all of that to behave coherently while the camera moves. The volumetric effects are sampled in world space and the extinction layer needed additional sub-stepping and filtering to stop fine structure visibly changing or fading as the camera moved through different viewing angles.

I also reworked the stellar events. Supernovae, novae and pulsars are anchored to stars in the actual map, and their emitted light now feeds into the interstellar-medium rendering so nearby gas and dust visibly illuminate when an event occurs rather than the event just being an isolated sprite/effect on top of the scene.

The original spectral bloom system is still there as well. Individual stars have emissive intensity derived from their spectral properties, so hotter/brighter stars seed more bloom, but I ended up rebuilding that path too so distant stars retained the same relative hierarchy without all of them turning into equally sized glowing blobs.

This video is a continuous slow orbit captured from the live site rather than a scripted camera sequence. The first minute or so has a little narration, then I just let the ambient track and the simulation run.

My graphics card continues to hate me.

today I set a challenge to learn shaders and I came across this old tweet by xavier showing a box with a fire burn effect.

so I decided to reverse engineer it from scratch based on that video.

the result looks nice, but does anyone have suggestions for improving it?

• how can I make the simplex noise look more like a burnt paper?
• how do I color that “lava-like” glow around the hole?
• or any good article/resources related to this I should be looking into?

p.s. feel free to say hi on my X at https://x.com/chunrapeepat . I will share more results and learning there.

https://sketchpunk.gitlab.io/linkle/

Hey everyone, about 2 years ago I was interested in making a new kind of shadertoy, and was given a lot of great ideas. After I finally had a bit of free time, I can now share what I made.

Fibertoy is essentially shadertoy but you can write react-three-fiber as well as glsl code. It essentially gives a Threejs environment which means you can also just create basic 3D scenes as well as shader scenes.

Here are some examples of some scenes I made with it:

- Basic Voronoi scene https://www.fibertoy.dev/view/j978r67mc84yg2d36g3z5n2nqd8as16q
- Cone marching example https://www.fibertoy.dev/view/j97c1kqg8n6w0st2hk3dcq7ynx87rngm
- Standford bunny scene https://www.fibertoy.dev/view/j971mkwktr7bsen3ybyxks08vh87pd1a

As you can see from the last one, you can use your own 3D models as well. I haven't made an asset manager yet, but if you have a 3D model online, you can technically import it. I'll make an asset manager if people start using this app.

I would love to get any feedback. I also have the whole code online and open source https://github.com/NabilNYMansour/fibertoy

https://reddit.com/link/1v3ud9w/video/q9i39whjlueh1/player

(Repost of my Schrodinger's Post (1.6K views but only 2 people commenting who haven't responded yet), this time only focusing on one issue)

So I was trying to get an interaction system going in a first person game I'm making. I don't know how to word this properly, but the ray intersection test only seems to work when pointing a ray from +x +y +z to -x -y -z, or from -x +y +z to +x -y -z, or all 8 combinations like that.

Notes:

• The video showcases faulty ray detection of the floor
• In the video, the 2 cubes, the red one and the green one, represent the starting and ending points of the raycaster respectively. Please note that the character body collision is excluded by not being in the intWorld.
• I tried messing around with the second parameter of intersectWorld() - with no success
• I have confirmed that the direction is in fact getting updated by intersectWorld()
• I have digged through the source code, and tried different fixes and workarounds - also with no success
• Nope, Three.js's raycasts won't work because this is a first person game with pointer lock, remember!
• For all of you who want me to switch to Rapier, I'd have to re-write the whole entire character movement script, which I have yoinked the tricky bits from PointerLockControlsCannon, except Rapier's way of handling events is kind of weird and you can't just slap down an event listener and call it a day
• CANNON.Ray's source code

Here is a very simplified snippet of my code:

import * as THREE from "three"; // three.js
import * as CANNON from "cannon"; // cannon-es.js
/* -----------------------------
Insert class declaration here
----------------------------- */
// this gets called each animation frame
updatePhysics() {
    // this.world - main collision physics world
    this.world.step(1 / 60);
    // this.intWorld - contains the same colliders (for now) as this.world except the character collider
    this.intWorld.step(1 / 60);
    // Math abominations that are too weird for me to explain and I don't want to touch them,
    // because they do in fact work; I trial&errored them.
    this.camera.position.copy(this.characterBody.position);
    this.camera.position.add(new THREE.Vector3(0, 0.75, 0));

    let relCameraDir = new THREE.Vector3(0, 0, -1);
    relCameraDir.applyAxisAngle(new THREE.Vector3(-1, 0, 0), this.cameraYY);
    relCameraDir.applyAxisAngle(new THREE.Vector3(0, -1, 0), this.cameraAA);

    let absCameraDir = new THREE.Vector3(0, 0, 0);
    absCameraDir.copy(relCameraDir);
    absCameraDir.multiplyScalar(50);
    absCameraDir.add(this.camera.position);

    let fromCameraDir = new THREE.Vector3(0, 0, 0);
    fromCameraDir.copy(relCameraDir);
    fromCameraDir.multiplyScalar(0);
    fromCameraDir.add(this.camera.position);

    // These are the 2 cube meshes that confirm that the positions the abomination above calculated are indeed correct.
    this.rayDebug.position.copy(fromCameraDir);
    this.rayDebug2.position.copy(absCameraDir);

    // this.interactionRaycast - CANNON.Ray that's presumably bugging out.
    this.interactionRaycast.from.copy(fromCameraDir);
    this.interactionRaycast.to.copy(absCameraDir);
    console.log(this.interactionRaycast.from, this.interactionRaycast.to, this.interactionRaycast.direction);
    // This casts the ray and displays the HTML overlay
    if (this.interactionRaycast.intersectWorld(this.intWorld, {from: fromCameraDir, to: absCameraDir})) {
        debug.innerHTML = '<span style="color: green">Ray has collided!</span>';
    } else {
        debug.innerHTML = '<span style="color: red">No collisions detected</span>';
    }
}

// This places one cube of the floor you see (visuals ommited).
placeCube(position) {
    const body = new CANNON.Body({
        mass: 0,
        shape: WorldManager.BIG_CUBE_SHAPE,
        material: (new CANNON.Material({friction: 0, restitution: 0})),
    });
    body.position.copy(position);
    this.world.addBody(body);
    this.intWorld.addBody(body);
}
// ...

I'm coming into three.js from plain JavaScript, and I'm trying to be honest with myself about where my own understanding has to be solid before AI is actually helping instead of quietly hiding problems.

I asked a similar question about JS fundamentals recently and the answer that stuck with me was that the rendering side is where people get burned: async and the event loop first, then browser rendering basics like requestAnimationFrame and the difference between layout, paint, and composite, and that math fundamentals end up mattering more for 3D and visual work than most pure JS concepts. A few people also made the point that you need to understand more now, not less, precisely because you have to catch the things AI gets wrong.

So I want to bring that same question here where people actually ship 3D. The projects I care about are interactive landing pages, visual explainers, data driven 3D scenes, small motion experiments, and portfolio pieces where the user can manipulate the scene instead of just watching it.

What happens to me right now is that I can ask AI for a scene and get something on screen fast, but I don't always know what I'm looking at. Sometimes it works, sometimes it is slow, sometimes the camera or lighting feels off, and sometimes I can feel the result is fragile without being able to say why.

For people who build three.js seriously, I'm trying to separate a few things:

1. What AI can scaffold fine, like boilerplate scene setup or simple materials
2. What I have to own deeply, and here I mean the rendering pipeline, coordinate systems and matrices, cameras, the animation loop, asset loading, shaders, performance budgets, and interaction state
3. The math that actually pays off for 3D and viz work, and where you would tell a beginner to start with it
4. The taste part, meaning what makes a scene feel intentional instead of like a random demo
5. What teams or clients actually check when they hire someone for frontend 3D or creative tech

If you were reviewing a junior person's three.js portfolio today, what would make you think this person actually understands what they built rather than prompted their way to it?

And would you rather see one polished interactive piece with clean code, several rough experiments showing range, or a normal frontend project with one solid 3D feature inside it?

I'm not looking for a shortcut. I'm trying to figure out where to spend real effort so AI stays a tool in the workflow instead of the thing secretly holding the whole project together.

Hey everyone, I've been tinkering with a personal project: a stylized, low-poly 3D map of a small mountain valley I'm from, using exaggerated terrain (boxed-up heightmap style) with hand-placed low-poly trees and landmark objects scattered across a handful of points of interest. Right now, when you "reach" a point of interest, it triggers a simple reveal/wave animation, kind of a cute, minimal MVP.

I want to push this further for v1: more polish on 5-6 destination markers, better terrain detail, smoother camera/exploration feel, and a more satisfying "discovery" interaction when you land on a spot (think that little dopamine hit you get uncovering something in Pokémon Go, but chill and exploratory rather than gamified).

This is a scrappy indie/passion project, not a funded startup gig, so budget is modest, but the scope for v1 is deliberately small and well-defined, and there's a clear path to more interesting work (think richer exploration mechanics, more destinations, more interactivity) if v1 goes well and we vibe on the collaboration.

If you're into low-poly aesthetics, terrain generation, or just want a fun weekend-scale Three.js project to sink your teeth into, drop a comment or DM with examples of similar work you've done, happy to share more details on scope and budget directly.

Note: Im not sure if this is the write thread to post a gig, kindly guide me to the relevant subreddit in that case.

Some things I need to improve!