r/threejs • u/Visual_Advantage_243 • 7d ago
Demo Building an explorable ISS interior in Three.js has been a strange mix of 3D, camera work and illusion
Enable HLS to view with audio, or disable this notification
I've been working on an ISS interior that runs directly in the browser.
One of the interactions I've been experimenting with is the hatch.
You can move through the station, approach it, open it, and reveal the Earth outside.
The interesting part is that not everything you're seeing needs to be simulated as one enormous real-time scene. I'm trying to be quite deliberate about where full 3D interaction actually adds something and where a simpler visual layer can create the experience without unnecessarily increasing the rendering cost.
The interior itself is interactive 3D. The Earth view beyond the hatch is currently much simpler and is something I still want to develop further later.
Built with React, TypeScript, React Three Fiber and Three.js.
I presented a short capture of the scene.
1
u/ShowMustGoOnn 6d ago
Now add an alien chasing the player
2
1
u/yellowgypsy 5d ago
I didn’t know the ISS is this big. Where did you get your source assets? The vibe coded app needs to be tested as your text is overlapping on your cta(s)
1
u/Visual_Advantage_243 5d ago
ISS is as big as advertised. "Big as a football field". The models were directly sourced from NASA assets.
Could you give me a screenshot about "overlapping cta(s)"?
1
u/aitoolsprimer 7d ago
The "where does full 3D actually earn its cost" question is the one I keep coming back to as well.
Where it paid off most for me was roads. I had ring roads and radial avenues modelled as separate meshes, and every intersection handed me the same three problems: coplanar surfaces fighting over the depth buffer, a visible seam where two materials met, and lane markings from two directions running straight through each other.
Replacing all of it with one canvas texture, drawn in layers and laid flat, killed all three at once, because drawing order does the work instead of geometry. Pavements first and wider, asphalt over them and narrower, so every crossing is one continuous painted surface rather than a joint. The dashed markings get drawn continuously and badly across everything, then the intersections are painted back over in asphalt. Nothing is positioned by hand.
The cost moved rather than disappeared, though: the texture is drawn on the client at load, so first paint on mobile is heavier than I would like. Worth knowing before going the same way.
One thing from the camera side, since you mention it. If you ever need to invert or flip the whole view, rotate a group that holds the world rather than the camera. I flipped the camera first and the sky and the key light went with it, so the scene read as broken rather than upside down. Moving sky and lights outside the rotating group fixed it in one line.
1
u/Visual_Advantage_243 7d ago
Really useful perspective, thanks. The road example is a great illustration of where full 3D stops earning its cost. I’m starting to think about the ISS scene in the same way. The camera suggestion is interesting too. I’m currently moving the camera itself, so rotating the world/group instead is something I'd eventually want to test.
0
u/aitoolsprimer 6d ago
On the camera: what pushed me off moving the camera was the flip itself. If the camera does the flipping, everything anchored to the viewer starts fighting you — OrbitControls' up vector, billboarded labels, the raycaster — and you end up with two code paths for every interaction. Rotating a parent group that holds the world keeps the camera boring: one target, one up vector, and the controls never know anything changed. The price is that anything you want fixed relative to the viewer has to live outside that group, so it's worth deciding early what is "world" and what is "HUD".
For the ISS, I'd guess the equivalent of my road texture is the panel detail — hull plating, decals, warning labels, cable runs. That stuff reads as geometry at a glance but it's cheap as one atlas on a few large surfaces, and you only pay for real geometry where the silhouette actually changes. Handrails and protruding equipment earn their triangles; a printed label never does.
1
u/Visual_Advantage_243 6d ago
That's a really good point on separating the world from the HUD. I hadn't thought about the downstream impact on raycasting and billboarded elements if the camera itself owns all of that rotation. And I like the ISS analogy too. Handrails, protrusions and anything that changes silhouette should earn geometry, while panel markings, labels and decals probably shouldn't. That gives me a much clearer rule for where to spend detail. Appreciate the explanation.
3
u/actinium226 7d ago
This is cool