The interesting part here isn't really the 3D library itself. It's the moment where the problem stops being “how do I place this object?” and becomes “why am I still editing coordinates by hand?”
The marker approach makes a lot of sense because you're using the environment itself as the authoring interface. Instead of mentally translating a visual position into x/y/z values, you stand where the object should go and let the tool capture that state.
I also like the decision not to introduce a separate editor as another source of truth. Since the library already has its own data model from DEV data → district → room → shelf, keeping the layout information inside that system avoids creating another pipeline to keep synchronized.
The Sanity persistence is a nice touch too. Once the markers have IDs and can be exported, they stop being temporary debugging helpers and become actual layout data. It feels like a good example of a useful rule in tooling: when the workflow starts fighting the project, sometimes the right fix isn't changing the workflow. It's building the missing tool.
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
This is exactly the shift that happened while I was building it. At first I kept treating the coordinates as the problem, like i just needed to get better at estimating positions or organizing the values.
Eventually I realized the actual problem was that I was trying to author a spatial environment through numbers instead of through the environment itself. Once I could stand somewhere, drop a marker, and persist that state, the whole workflow started making much more sense.
Exactly. That distinction is what makes this interesting to me. Once you realize the environment itself is the thing you're authoring, coordinates become an implementation detail rather than the interface.
I think that's a useful pattern beyond 3D too: when a workflow forces you to constantly translate between what you see and what the system needs, that translation layer may be the real problem. Sometimes the best developer tool is simply removing that translation step.
I build data grid and pivot grid components for React and plain JavaScript at KanuniLabs. I write about performance, Web Workers and software licensing.
the marker idea feels much more natural for this kind of project. if the thing you're building is already a 3d world, being able to stand somewhere and say "this goes here" is probably a better interface than trying to translate everything into x, y and z values manually.
it's also a good example of how a small developer tool can end up becoming part of the architecture rather than just another utility.
good job
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Exactly!! That was the moment it clicked for me too. I kept changing coordinates, rebuilding, walking back into the scene, realizing it was wrong, and repeating 😭
Once I could just stand where I wanted something and drop a marker, it stopped feeling like I was fighting the world I was building. I’m honestly tempted to keep expanding the marker system into a tiny in-world level editor.
"Aspiring technologist with a bold vision — exploring languages, systems, and ideas to build something unbeatable in the AI era. Questioning the status quo, one post at a time."
This is such a cool shift in thinking going from "cyberpunk city" to "library" because the space needed to actually mean something, not just look impressive. That distinction between decoration and information architecture is something I wouldn't have even known to look for as someone just starting out.
The part that got me most was building your own in-world marker tool instead of switching to a traditional level editor. Turning the 3D space itself into the source of truth for coordinates, instead of guessing numbers and reloading a hundred times, feels like exactly the kind of "build the tool you actually need" thinking I'm hoping to learn as I go deeper into code.
Also really appreciated seeing the actual code for placeAsset as someone only a few weeks into Java, seeing how spatial logic gets structured in a completely different language and context is genuinely useful to look at.
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Thank you!! 🥹 The marker tool ended up being one of those “I only built this because the workflow was driving me insane” features, but it completely changed how I could work on the space. Once I could walk around, place a marker, grab the coordinates, and drop them straight into placeAsset, the library started feeling way more intentional instead of like I was guessing my way through a 3D scene.
And I’m really glad the shift from cyberpunk → library came through too. That was the point where I stopped thinking “how do I make this look impressive?” and started thinking “what environment actually makes sense for browsing articles?”
There’s still a lot I want to do with it, so I really appreciate you following along 📚💜
Self-taught dev. Creator of Mochi, a native Linux desktop pet. I build Linux/web tools and write about them. Open to software engineering and technical writing roles.
Your approach is really interesting. One big advantage I see is that the engine becomes reusable, so you can build other cool stuff on top of it.
And speaking of other cool stuff: I love the cyber city idea. It reminds me of Cyberpunk and Night City, which I'm a huge fan of, so I'd definitely love to see that too. Imagine reading DEV articles in City Center or the Badlands. Mmm... what an experience.
Okay, back to Earth: I can't wait to try out the library.
Building the editor after hitting the limits of the code first approach is a strong product move. The key test now is whether the visual layer keeps the underlying scene data inspectable and exportable, so the convenience does not become a new lock in.
Building CleanMD, a converter that turns PDFs, scans and recordings into Markdown with the headings intact. It started when a DeepSeek paper came out of every tool as soup.
Making the markers Sanity documents with stable IDs is the smart move here, it turns debug state into real layout data. Snapping yaw and position to a grid plus a bounding-box check on drop would catch most clipping before the walkthrough. Are the pins resolved from Sanity at runtime or baked in at build time?
The interesting part here isn't really the 3D library itself. It's the moment where the problem stops being “how do I place this object?” and becomes “why am I still editing coordinates by hand?”
The marker approach makes a lot of sense because you're using the environment itself as the authoring interface. Instead of mentally translating a visual position into x/y/z values, you stand where the object should go and let the tool capture that state.
I also like the decision not to introduce a separate editor as another source of truth. Since the library already has its own data model from DEV data → district → room → shelf, keeping the layout information inside that system avoids creating another pipeline to keep synchronized.
The Sanity persistence is a nice touch too. Once the markers have IDs and can be exported, they stop being temporary debugging helpers and become actual layout data. It feels like a good example of a useful rule in tooling: when the workflow starts fighting the project, sometimes the right fix isn't changing the workflow. It's building the missing tool.
This is exactly the shift that happened while I was building it. At first I kept treating the coordinates as the problem, like i just needed to get better at estimating positions or organizing the values.
Eventually I realized the actual problem was that I was trying to author a spatial environment through numbers instead of through the environment itself. Once I could stand somewhere, drop a marker, and persist that state, the whole workflow started making much more sense.
Thanks for such a thoughtful read! 💚
Exactly. That distinction is what makes this interesting to me. Once you realize the environment itself is the thing you're authoring, coordinates become an implementation detail rather than the interface.
I think that's a useful pattern beyond 3D too: when a workflow forces you to constantly translate between what you see and what the system needs, that translation layer may be the real problem. Sometimes the best developer tool is simply removing that translation step.
the marker idea feels much more natural for this kind of project. if the thing you're building is already a 3d world, being able to stand somewhere and say "this goes here" is probably a better interface than trying to translate everything into x, y and z values manually.
it's also a good example of how a small developer tool can end up becoming part of the architecture rather than just another utility.
good job
Exactly!! That was the moment it clicked for me too. I kept changing coordinates, rebuilding, walking back into the scene, realizing it was wrong, and repeating 😭
Once I could just stand where I wanted something and drop a marker, it stopped feeling like I was fighting the world I was building. I’m honestly tempted to keep expanding the marker system into a tiny in-world level editor.
This is such a cool shift in thinking going from "cyberpunk city" to "library" because the space needed to actually mean something, not just look impressive. That distinction between decoration and information architecture is something I wouldn't have even known to look for as someone just starting out.
The part that got me most was building your own in-world marker tool instead of switching to a traditional level editor. Turning the 3D space itself into the source of truth for coordinates, instead of guessing numbers and reloading a hundred times, feels like exactly the kind of "build the tool you actually need" thinking I'm hoping to learn as I go deeper into code.
Also really appreciated seeing the actual code for placeAsset as someone only a few weeks into Java, seeing how spatial logic gets structured in a completely different language and context is genuinely useful to look at.
Following to see how the library grows! 📚
Thank you!! 🥹 The marker tool ended up being one of those “I only built this because the workflow was driving me insane” features, but it completely changed how I could work on the space. Once I could walk around, place a marker, grab the coordinates, and drop them straight into placeAsset, the library started feeling way more intentional instead of like I was guessing my way through a 3D scene.
And I’m really glad the shift from cyberpunk → library came through too. That was the point where I stopped thinking “how do I make this look impressive?” and started thinking “what environment actually makes sense for browsing articles?”
There’s still a lot I want to do with it, so I really appreciate you following along 📚💜
Great job, waiting to see it working 😃
Thank you! It's coming along nicely, designing the 3D layout has been my favorite part so far :)
i understand you 100% enjoy it!!!
...
Proceeds to build an entire game engine 😄
That's usually how it goes, though.
Your approach is really interesting. One big advantage I see is that the engine becomes reusable, so you can build other cool stuff on top of it.
And speaking of other cool stuff: I love the cyber city idea. It reminds me of Cyberpunk and Night City, which I'm a huge fan of, so I'd definitely love to see that too. Imagine reading DEV articles in City Center or the Badlands. Mmm... what an experience.
Okay, back to Earth: I can't wait to try out the library.
Building the editor after hitting the limits of the code first approach is a strong product move. The key test now is whether the visual layer keeps the underlying scene data inspectable and exportable, so the convenience does not become a new lock in.
Making the markers Sanity documents with stable IDs is the smart move here, it turns debug state into real layout data. Snapping yaw and position to a grid plus a bounding-box check on drop would catch most clipping before the walkthrough. Are the pins resolved from Sanity at runtime or baked in at build time?
Great job! Good luck!