In arc3d.in, one of the most interesting challenges we faced wasn’t just rendering architecture in 3D. It was figuring out how to actually build designs inside a real-time environment in a way that feels natural for architects and designers.
Most tools in architectural visualization are built around output—final renders, polished walkthroughs, static scenes. But we wanted something closer to a working space, where design decisions can be made while you’re already inside the environment.
This post is about how we approached that problem using the tools we had, and what broke along the way before things started working properly.
Moving from static models to something modular
At the beginning, everything was straightforward: we imported full architectural models into the scene and rendered them as complete environments. It worked fine for showing results, but it completely failed as a design system.
The moment we tried to make changes—move a wall, adjust a room, replace furniture—it became obvious that the entire pipeline was too rigid. Every small update meant going back to the modeling tool, re-exporting, and rebuilding the scene.
That’s when we shifted the entire approach.
Instead of treating a building as one big model, we broke it into modular parts. Walls, floors, ceilings, furniture—everything became independent components that could be loaded and updated separately inside the scene.
This changed the workflow completely. It stopped being “export and view” and started becoming “compose and adjust.”
Lighting was the first real performance problem
Once we moved to more dynamic scenes, lighting immediately became a bottleneck. Architectural visualization depends heavily on lighting realism, but real-time lighting is expensive.
Initially, we tried full dynamic lighting across the entire scene. It looked good, but performance dropped quickly, especially in interior-heavy environments with multiple light sources.
We had to rethink it instead of just optimizing blindly.
What worked for us was a hybrid approach:
We kept a stable base lighting setup for the entire scene
Only key interaction areas used dynamic lights
Shadows were scaled based on camera distance
And we avoided unnecessary real-time calculations in hidden areas
This gave us a balance where the scene still felt alive, but didn’t destroy performance when complexity increased.
Scale perception turned out to be a silent issue
One thing we didn’t expect early on was how easily users misinterpret scale in 3D architectural spaces.
On paper or in renders, scale is abstract. But in a walkthrough environment, even small inaccuracies feel very noticeable. A hallway that is slightly too narrow or a ceiling that is too low immediately feels “wrong,” even if the model is technically correct.
To fix this, we enforced strict real-world scaling across everything. But that alone wasn’t enough.
We also added subtle constraints that helped perception:
Camera height fixed to a realistic human eye level
Doors, furniture, and structural elements kept as reference anchors
Field of view tuned to avoid exaggerated depth distortion
Once these were in place, users started judging spaces more naturally instead of feeling disoriented.
Iteration speed was another major blocker
Architectural workflows are usually slow because of constant exporting and re-importing. That delay kills experimentation.
We wanted the opposite: fast iteration, even if the system wasn’t perfect visually at every step.
So we built a workflow where updates could happen inside the environment itself. Instead of rebuilding scenes, we made changes live.
In practice, this meant:
Swapping assets without reloading the full scene
Updating materials and textures in real time
Using configuration-based adjustments instead of hardcoded changes
Adding a quick preview mode for testing design variations
This alone changed how design decisions were made. People started experimenting more because the feedback loop became immediate.
Navigation had to feel like “being inside” not “orbiting around”
One of the biggest UX decisions we had to make was how users move through spaces. Most 3D tools default to orbit controls, which works fine for inspection but not for architectural experience.
Orbiting a building doesn’t feel like being inside it—it feels like analyzing a model.
So we shifted towards a more grounded navigation system. For interior spaces, we focused on first-person movement with controlled physics-like behavior. Not a game-like experience, but something subtle enough to feel natural.
We also separated two modes:
Exploration mode (walking through spaces)
Design mode (editing and adjusting elements)
Switching between these helped maintain clarity between “experiencing” and “building.”
Performance was a constant balancing act
As scenes became more detailed, performance challenges became unavoidable. Architectural models tend to be heavy, and combining multiple rooms, materials, and assets quickly adds up.
Instead of relying on a single optimization trick, we had to stack multiple strategies together.
Some of the key ones were:
Level-of-detail switching for complex models
Reusing and compressing textures wherever possible
Instanced rendering for repeated objects like chairs, lights, etc.
Loading scenes in chunks instead of everything at once
None of these individually solved the problem, but together they made the system stable enough for real use.
What all of this led to
Once these systems came together, something interesting happened. The focus of Arc3D shifted from “how do we render this building” to “how do we experience this space while designing it.”
Design stopped being a separate stage from visualization. They started happening in the same place.
And that changed how decisions were made—faster feedback, clearer spatial understanding, and fewer misunderstandings between intent and execution.
Top comments (0)