Impact
+30 FPS
Gain through memory optimization
75%
Cut in visual production time
4
Client contracts closed with the 3D library
Overview
A web based 3D engine was developed to assess further business opportunities.
Exclusive static 3D visuals were created to elevate client's corporate image value.
The library also helped creating tailor-made infographics for clients with specific technical needs.
Opportunity
Leadership wanted to turn 3D rendering into a real service
Up until now, a few renders had been produced, but 3D had never been a sellable part of any project. We thus decided to make it a marketable solution, but the challenge was to define what to sell, and how.
I benchmarked the agency's core industry and listed past client requests
I decided to define the strategy according to past demand rather than an assumed persona.
I noticed clients asked technical requests like 3D exhibits and virtual galleries or custom brand animations. Those insights helped me to define a base for the possible services to be provided.
84%
Of the agency's clients were in semiconductors
3
Clients asked for 3D enabled digital experience over the year
2
Major competitors already provided 3D related services
Strategy
I proposed 2 solutions: one pragmatic, one ambitious
The pragmatic one was a 3D module library: it would be fast to build, easy to scale, ready for static and animated renders in the short term.
The ambitious path was a web-based 3D engine: a second priority and long-term project that matched past client requests like virtual tours and 3D galleries. This project was explicitly framed as R&D rather than a sellable solution.
The library had to offer flexibility & technical accuracy
From experience, I knew clients cared about details like pin count and component type, so I structured the library atomically, the same logic behind web design systems, keeping every element configurable per client.
To keep every render unique and fast to produce, I created procedural systems to generate most models going from PCB to abstract patterns.
Blender Geometry Node was used to create complex procedural structures easily adjustable.
Architecture
Clients worried existing 3D demos were too heavy
Three.js and Babylon.js demos raised concerns about losing part of the audience due to performance issues.
This recurring comment drove the stack choice for the engine: using C and WebGPU for a stricter memory control. The whole project would then be compiled to WASM for the web.
C was memory-efficient, but slowed down development
To answer this, I decided to split the core and UI to trade productivity over performance.
Since the core had to be optimised for performance, I kept C and used a DOD (Data-Oriented Design) approach with an ECS (Entity Component System) architecture to optimize computation speed.
The UI on the other hand, was only used during development and debugging. Therefore, I decided to use C++ with an object-oriented approach, which led to faster iteration and access to libraries like imGui.
Resolution
Client didn't see any added value in the renders
After delivering the first 3D renders, I noticed clients didn't see why a generic render was worth more than a stock image.
To answer this, I decided to integrate each client's actual branding into the renders, and provide them a short guideline on the visual and how it elevates their brand.
Providing clients with more context helped get the visuals approved for one client out of two.
At first, client felt that the visual didn't connect well enough with their brand and industry.
After adding their logo on the visual and providing them a short introduction of the new guidelines, the client validated the latest visual.
The 3D engine felt slow
After doing some research, I targeted two potential bottlenecks worth trying to fix.
1. Optimizing memory by sharing it across objects
Initially, each object had to carry its own copy of the data, creating unnecessary memory usage and slowing down performance.
After the change, all resources shared and retrieved data from a common storage, preventing bloated data redundancy.
2. Grouping objects to render for greater efficiency
The original rendering architecture processed objects independently instead of drawing them by material, creating redundant GPU operations as scene complexity increased.
After optimization, objects were first grouped by material before being rendered, leading to much less costly GPU compute.
The results spoke for themselves
Both fixes led to clear performance improvements as well as greater scalability.
+30 FPS
After sharing global memory buffer (UBO)
+4 FPS
After batch rendering meshes per pipeline
Bottlenecks had to be tracked
To better profile the whole project, runtime debug tools were added such as live render-mode switching (boundbox, wireframe, solid, texture), a per-pass latency profiler, and a logging console built in.
Outcome
The library helped close 4 contracts,
the engine paid in knowledge
The 3D module library was reused across multiple projects for key visuals, brand revamping, and infographics. It cut the production time by 4x and the strong client feedback led to contract renewals.
The engine is still in development and currently deprioritized, but it produced WebGPU expertise that's ready to apply with Three.js when the opportunity comes up.
Learning
Narrow efforts on 1 efficient solution rather than 2
The library saved real time but adoption stayed narrow (3 key visuals and 1 infographic).
I wish to develop a strategy to increase its adoption and use it as a means to shape the brand's whole 3D direction.
Better assessing technical workload for greater result
The WebGPU engine was correctly framed as R&D from the start, which contained the risk, but I still underestimated the build time versus using existing libraries.
I now reconsider more closely existing solutions vs reinventing the wheel in R&D.
Scale the solution to make it available for others
I'm still the only designer with the 3D skill to use the library, which caps its reach.
The next step would be exporting pre-rendered assets so the rest of the design team can use it without touching the 3D pipeline.
