Updated 3D Environment for Library
Reading DEV Articles
A lot of you wonderful people enjoyed my last post on Oni, so her...
For further actions, you may consider blocking this person and/or reporting abuse
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.
How are you persisting transforms from the in-world editor back into the code-owned scene graph, and does the saved output stay diffable when shelf slots and collision bounds share the same placement data?
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!