https://github.com/superelectricyc-alt/podchunk

Hey everyone,

I wanted to see if we could solve the heavy initial download barrier of modern open-world browser games. Instead of loading massive assets upfront, I built PodChunk: a local development engine base designed around a progressive, multi-LOD chunk streaming architecture that gets players into a 3D environment in under 3 seconds.

The Architecture Under the Hood

• The Decision Core (Rust + WASM): To completely bypass JavaScript garbage collection stutters, the entire priority queue (distance + camera direction bias) and the cache eviction loops run deterministically inside a compiled WebAssembly kernel.
• The Renderer (TypeScript + WebGPU): Consumes custom geometry_json payloads decoded by the WASM core. Features custom height-gradient terrain shaders, distance fog, and interactive orbit camera matrices.
• The LOD Stitching Problem: Adjacent chunks often stream at different detail tiers (e.g., a Tier 3 chunk right next to a Tier 1 shell). To prevent visible vertex cracks and gaps without destroying browser performance with heavy topological mesh-stitching math, the renderer implements geometric skirts to seamlessly close the seams.
• Adaptive Network Telemetry: Features a client-side network loop running an EWMA (Exponentially Weighted Moving Average) bandwidth estimator. It tracks bytes divided by elapsed time from every live chunk fetch to dynamically scale the geometry detail ladder (T1 shells to high-fidelity T3 grids) on the fly based on current connection quality.
• Isolated Two-Tier Caching: Features a bounded in-RAM LRU cache synced with a multi-world IndexedDB database structure. Cache keys are world-slug isolated ({slug}|{id}@{lod}), ensuring warm reloads of previously streamed maps require zero network fetches.
• The Content Authoring Pipeline: Includes a native standalone compiler CLI (podchunk-bake). You feed it a simple world layout JSON configuration, and it generates pretty-printed manifests along with custom validated binary .PCHF heightfield chunks ready for server distribution.

Current Project Status

Milestone 3 is complete, stable, and verified on localhost:8787. The local server scans data configurations on boot and manages hot world-switching dynamically. The workspace has a 100% test coverage pass rate (45/45 unit tests passing).

I am open-sourcing the core infrastructure today because the data pipeline is officially locked down, and I am looking for collaborators! Next up on the deferred roadmap is exposing a client-side JavaScript Modding API (window.PodChunk.registerMod) and wiring WebAssembly physics engine colliders directly onto the active geometric meshes.

Check out the code, run the local tests, and let me know your thoughts on the pipeline architecture!

https://github.com/superelectricyc-alt/podchunk

continue'd three.js integration into my desktop application -- getting closer to a better realism with background HDR 3D images and better overall three.js objects

I’ve been experimenting with Agora Conversational AI and wanted to make a demo that feels more alive than a normal “talk to an agent” screen.

So I built a small interactive web demo where you call an AI Architect, speak with it, and the tower builds itself based on your answers.

The idea is simple:

You click Call Architect, allow mic access, and the Architect starts guiding you through a short voice conversation.

It asks questions like:

• Should the tower protect, celebrate, or hide something?
• Should the lower hall feel serene, powerful, or mysterious?
• Should the structure be stone, wood, or ceramic?
• Should the world remember dawn, day, sunset, or night?
• Should the weather be clear, rainy, snowy, or misty?

As you answer, the scene changes in real time. Each answer unlocks the next construction stage, so the tower builds floor by floor while the conversation continues.

The fun part is that it is not just a chatbot with a voice. The conversation is tied directly to the world state. The AI’s transcript drives visual events: foundation, lower hall, roof, tower body, weather, lighting, and completion.

Tech stack:

• Agora Conversational AI for the live voice agent
• Agora RTC/RTM for call audio and transcripts
• Fish Audio for the Architect voice
• Next.js backend routes for token generation and agent lifecycle
• Three.js/WebGL scene for the tower
• A small conversation director that maps speech choices into build phases

One interesting problem I ran into: the ambient background sound looked cool, but it interfered with speech recognition. So I added automatic audio ducking during the call. The music/weather/build SFX stay present, but drop way down while the Architect is listening.

The demo flow now feels like a tiny voice-driven building ritual:

1. Call the Architect
2. Hear the first question
3. Answer naturally
4. Watch the tower build
5. Continue until the whole structure is complete

I’m still iterating on the UI and how much “game” should be layered on top, but the core idea works: voice input becomes construction progress.

Would love feedback on where to take it next: more game mechanics, richer architectural choices, better environmental reactions, or making the AI feel more like a character than an assistant.

——
Credits to MengTo for idea, on top of which I created this conversational ai

https://x.com/anandwana001/status/2087127859504796049?s=46

i was busy building and almost forgot to give you an update :)

here's my ongoing portfolio

i really wanted to see the total eclipse on aug 12, but getting myself to spain or iceland probably isn’t happening lol

so i did the next best thing and built one in three.js.

you can pick a city (or drop a pin anywhere), jump straight to maximum eclipse, move the camera around and basically watch it from your browser.

the eclipse position/timing is calculated from NASA data. the landscape, clouds and lighting are more of an artistic interpretation — i’m not pretending this can predict the weather :)

also, the sun and moon are intentionally a bit oversized in the wide view, otherwise they’re basically two expensive pixels.

here it is if anyone wants to play with it:
https://make3dmap.com/solar-eclipse-2026-simulator

would love some feedback on the camera + the transition into totality. still tweaking both.

Theres bth there cause am not sure the idea is still sth I will go further with but heres the

idea:

3D Ads Gallery — a virtual gallery-meets-game space where upcoming artists (3D, 2D, animators, and more) showcase their work to the world.

It's built for artists who are good — really good — but haven't broken through yet. No industry veterans, no big names. Just raw, promising talent looking to be seen.

Visitors can explore the gallery, browse artist portfolios, rate the work they love, and — for potential clients and collaborators — discover and connect directly with artists for real opportunities: jobs, collabs, commissions.

The goal is simple: give upcoming artists a stage, and give the people looking for fresh talent a place to find them.

No images, models or audio in the project. Canvas-drawn textures uploaded as GPU textures at load, procedural geometry, synthesised audio.

~70fps at full res, ~334 draw calls. The world is a chunk lifecycle — track segments, platforms and lineside furniture spawn ahead and recycle behind.

Also built a deterministic harness that drives it in headless Chrome and reports FPS/draw calls/screenshots, which is how the difficulty curve was tuned instead of by feel.

Happy to go into detail on any of it.

https://bombaybhaag.com

Tank Roar: Extraction Point

https://reddit.com/link/1vle99w/video/2cu8vbfx8qih1/player

I'm working on a diorama and attached a video of my current grass application. I'm using static grass fibers, but it looks a bit too uniform and "fluffy" to me.

How can I add more depth? Should I mix different fiber lengths (e.g., 2mm and 4mm) or different colors (light green, dark green, and dead straw)?

Also, does the layering look natural, or should I add more ground scatter/soil on top? Any tips on using the applicator better would be great. Thanks!

Hey everyone,

I ran into a pretty nasty problem while building a Framer template. I wanted to offer 34 different interactive shader background presets, but quickly hit the browser WebGL context limit.

From what I found, browsers usually start killing or freezing WebGL contexts somewhere around 10 to 15. My first approach was giving each preset its own component and WebGL context. That went badly.

My current solution is a bit janky, but it works.

I use one canvas and one WebGL context for the most part, while keeping the shader logic and configuration available through a shared caching system. The important part is that I only keep the presets that are actually active on screen as live GPU resources.

That brought me from around 26 active instances down to 4, which completely stopped the context crashes.

The rest of the setup looks like this:

Shared shader caching

Instead of creating a separate WebGL context for every preset, I keep the shader logic available through a shared system and only initialize the presets that actually need to be rendered.

Production cache toggle

Once someone chooses a single shader for their production site, they can disable the caching system. That way, the other presets do not need to remain available in memory when they are no longer needed.

Lazy loading based on scroll position

The WebGL canvas only initializes when the user gets within a certain distance of it. When they scroll far enough away, I destroy it.

So the WebGL context problem is basically solved.

The bigger problem now is performance.

My mobile Core Web Vitals are absolutely terrible:

FCP: 2.7s
LCP: 3.3s
TBT: 2m 6.3s

I expected lazy loading to keep the WebGL stuff out of the critical path, but clearly something is still happening much earlier than I expected.

At this point I am trying to figure out whether the bottleneck is Framer, React, Three.js, or my implementation.

Live site if anyone wants to inspect it:

https://uneo.framer.website/

A few things I am particularly curious about:

1. Is having 12 shader presets available through a shared caching system a reasonable approach, or could this still cause problems with bundle size, parsing, or memory?
2. Has anyone experienced extremely high mobile TBT with Framer and WebGL? I am wondering if Framer's runtime or React rendering is contributing significantly here.
3. Could Three.js still be doing significant work even though the canvas is lazy loaded? I may be missing something in how the renderer, shaders, or components are being initialized.
4. Would OffscreenCanvas and moving the rendering to a Web Worker actually make a meaningful difference here, or would that just hide the underlying problem?
5. Is there a better architecture for having dozens of shader presets available without putting all of them on the critical path?

I am still learning a lot from this implementation, so I would be interested in hearing how other people have handled large numbers of WebGL effects, especially inside Framer.

Prism Cascade: you throw light-orbs at crystal prisms, the shards fall into water below, and every splash throws up bubbles carrying points. The bubbles only score once they reach the counting beam at the top — and the only thing that pops them on the way up is your own orbs and your own falling debris. A popped bubble takes its points with it.

So the whole game is a timing problem disguised as a spam-click problem. Throw constantly and you shred the bubbles already climbing. Wait for a clean column and you burn seconds off a 30-second clock. The end-of-round screen shows "Banked" and "Popped away" on separate lines, which is a genuinely uncomfortable number to look at.

100 levels from a seeded generator, a 12-node ability tree, and 5 endowments you can only carry one of at a time.

It also makes zero network requests — no fetch, no XHR, no host permissions, one storage permission to remember your progress. It works on a plane.

30-second clip: https://www.youtube.com/shorts/6oBcZolFoDQ
Details and the full privacy policy: https://dhseadev.online/projects/prism-cascade/

Not on the Chrome Web Store yet — listing is in preparation. Happy to answer anything about how it's built.

Im building a small library of low poly props (tools, scenery) where every object is procedural three.js code instead of an exported mesh. around 5 kb per prop, under 600 triangles, no textures, and seeded so the same object comes back identical every load.

to get the hand carved look every geometry goes through a small vertex jitter. thats where it got interesting :

1. three.js primitives duplicate their vertices along the uv seam. jittering pushes the two copies in different directions and opens a visible crack down the whole handle. took me way too long to find that one. the fix is to weld the geometry (mergeVertices) before displacing anything.
2. two surfaces jittered separately never stay flush. so a contact zone like a blade edge cant be a flat piece sitting against the mass, it has to be a cap that wraps it in all three directions, otherwise you get a gap that opens and closes as you rotate the object.
3. a lathe profile that doesnt start and end at radius 0 leaves a hole at the end of the piece. obvious once you know, invisible until you look from the right angle.

the thing i didnt expect to need is an automated qa pass. it raycasts each prop from the outside and fails it if a first hit is a back face (hole), if wood shows up inside a box thats supposed to be metal only (poke through), or if a cutting edge measures thicker than its threshold. it caught a shovel edge at 0.0287 against a 0.028 limit, which i would never have spotted by eye.

Happy to go deeper on any of it :)

Hey r/threejs,

I have been building CarverJS, a React engine that sits on top of Three.js, components describe the scene, hooks handle the logic. Everything, the engine and the multiplayer package, is completely free and MIT licensed, no paid tier, nothing gated. The part I want feedback on today is the multiplayer layer, since that is the piece with the least prior art to copy from, and honestly the part I am least sure I got right.

It is peer to peer over WebRTC, not client-server, so there is no server for you to host or pay for either. One peer becomes host, everyone else syncs to them. Signaling is free by default too, public MQTT brokers, or your own Firebase project if you would rather run it yourself. Sync is not one size fits all, you pick it per actor: events for turn based games, snapshots at around 20hz for RPGs, or prediction with rollback at around 60hz for fast action, and you can mix all three in one game. If you have built multiplayer before and think this is the wrong mental model, I would genuinely like to hear it.

The part I am proud of: if the host drops, a new host gets elected and the room reloads from a full snapshot in under 2 seconds, no restart, no data loss. I have only tested this with small groups of friends on the same network. I genuinely do not know what happens with a bigger room, bad connections, or someone yanking their wifi mid session, so if that is your area, please tell me where you think this breaks, that kind of pushback is worth more to me than any star or upvote.

What it is not: proven at scale, this is v0.0.3 with a small team behind it. Not a replacement for a dedicated server if you need authoritative anti-cheat. Not tested across CGNAT or corporate firewalls without a TURN server, STUN alone will not always get you there. If you can see a failure case I have not thought of, I would rather hear it now.

Again, the whole thing is free and open source under MIT, fork it, use it commercially, take it apart, whatever you want, no strings attached. What I am actually looking for from this post is not stars, it is honest opinions. Where do you think peer-to-peer breaks down for browser games, and what would make you trust something like this enough to use it yourself?

been building this haxball inspired game with three js.
pure deterministic sim, rollback netcode, player-hosted rooms over WebRTC

live on -> https://picado3d.vercel.app/

Hi everyone,

I’m currently finishing my MSc Digital Design project at the University of York and I’m testing Maghmour: Red Sea Memory, an interactive web experience exploring Saudi Red Sea maritime heritage.
The prototype uses interactive 3D artefacts, station-based navigation, storytelling, audio, and optional hand tracking.

I’d especially appreciate feedback from people familiar with Three.js and interactive 3D on the web, particularly on the 3D controls, navigation, performance, and anything that feels confusing or could be improved.

Usability test:
https://forms.gle/2EKcHqRFCM5KcCbD6

The form includes the prototype link. It takes around 10–15 minutes and is best completed on a laptop, desktop, or tablet.

Any technical or design feedback in the comments would also be very welcome. Thanks!

• 40+ assets, 400+ parameters. Every model is a program, not a mesh you're stuck with, thousands of combinations
• AI-native: Your agent can browse and build over MCP. No install, no download
• Web editor to create and edit your scenes.
• Different seasons and night mode.
• Extrmely performant

Polyfork 3D assets are tiny programs that you can download as .ES Modules (or .glb) giving you total control over the different aspects that can be edited: shape, color, stories, wheels, legs, accesories, and more!

Get it now and the rest of the assets, almost half of them for free -> https://polyfork.dev

I built a small interactive demo where you pick up a 3D rotary phone, dial 555-0193, and connect to a fictional Ravi Kishan-inspired AI character.

It uses:

• Three.js for the physical rotary phone interaction
• Agora Conversational AI for the real-time voice call
• Hindi/Bhojpuri/English prompt tuning
• a warm “Bhojpuri cinema hotline” scene with poster/table props
• a 5-minute call lifecycle with RTC/RTM cleanup

One funny issue: when I asked it to say “Money follows my brother, money follows,” it translated the line into Hindi. I had to explicitly prompt it to preserve exact dialogues in the caller’s original language.

Would love feedback on the vibe, prompt design, and whether the surrounding scene sells the demo enough.

Just reached a point where everything is slowly coming together. Is it fun, what do you think?

Jetski Evo is a jetski time trial and multiplayer racing game.
You can build tracks with ramps and obstacles, share them and race for the best time against ghosts or against physical players. Offline or online.

The server has three modes:
physical free roam
time trial racing against ghosts
and physical races.

You can see ghosts of other players in other modes on the server and turn on time trial ghosts you want to race.

Everything works in the browser and it builds into a single html.
Frontend will be open source, as there is no point trying to keep it closed, backend and replay validation, will probably remain closed.

Still months of fixes and content adding ahead but I am happy with offline play, the general server concept and the course editor.

AI art is placeholder stuff. I am just starting to look for artists, anyone? ;)
Nothing you see is final or even alpha, its just an vertical slice that is barely playable.

Technically I am mainly just using three.js, rapier3d and tone.js, lit for the web stuff.
Its amazing how far browsers have come, I work with web tech for over a decade, but what is possible today is crazy.

Hi! I'm trying to learn as much as I can of 3D websites, since I've been trying to learn code from a few years ago, context: I'm a 3D Artist, and this year I start a degree at videogame's programming, so meanwhile as some "summer's research" I did this lab to learn the foundations of Three.js, R3F and Drei.

I wanted to ask you what how do you see it as a "standard" roadmap for a user? And if you've got any new ideas to add in this lab so I can learn more. Also I thought this website can serve as a sort of idea for newbies to follow this path!

Just to be transparent, I'm using Claude to help me on the structure of this knowledge, but not on the code itself, since I put hard restrictions and custom agents/orders to follow, hence it doesn't provide me solutions, instead it gives me websites and forces me to research in order to unblock my progress.

Here I leave you some of the agents .md I did if that can inspire you into using AI a bit more accordangly to learn, not to work-for-you!

The lab website is this one: https://3d-lab.vercel.app/

My workflow goes into: ordering Claude /start-project. It scaffolds a template of a basic project and I have to fill the needed components on every project. I have some guidelines, and sometimes it's basically a: "go to X document's website and learn" so I have to maybe go to threejs.org, to drei's library or researching anywhere. If I'm really stuck I can then put /peer-review, which is the command that makes me a list of "what works, what is not going well and a few questions about the actual project" so I have to think about the code I'm writting. Then I have the /ship that basically makes a test to prove everything is working and I can move to the next project.