“You don’t start with a 3D scanner.” Inside the pipeline that produces 3D at scale

Most brands approach 3D the same way. Buy scanning hardware, produce a model, then work out what to do with it. Fibbl built its pipeline in the opposite direction, and after more than 20,000 shoes scanned and over 72 million end consumer interactions recorded between April 2024 and August 2026, the two people who built it have a clear view of why the usual sequence fails.

Joakim Tennfors runs production. Christian Kaunissaar is CTO. Their two departments sit at opposite ends of the same chain, and both describe the collaboration between them as the reason it works at all.

We asked them to explain it.

The philosophy

What is the core philosophy behind the production pipeline?

Joakim Tennfors: End to end interoperability. The field of 3D is so broad that there are endless possibilities, and you can do anything you want. But if you want to scale production, as with any kind of industrialisation, you need to be specific and narrow about what you produce. And you need to control the entire chain from start to finish. Then you can scale something.

What is the biggest misconception you encounter?

Joakim Tennfors: People want to start with the master file. The thinking is that if we can just get a 3D master of our products, we can solve all the problems downstream. If we buy a scanner that produces 3D models, then we have a 3D model, and all the opportunities open up. That is not the case.

3D scanning, whether you use photogrammetry or NeRF or Gaussian splatting, is one tool in the toolbox. You have multiple problems to solve in a 3D pipeline. What we do instead is look at the outputs. What are the deliverables? What are we going to use the 3D for? Then we build the pipeline backwards and figure out what tools we need.

You don’t start with a scanner and get a 3D file. You start with the deliverables and figure out what you need.

Choosing the technology

There are a lot of capture technologies. How do you choose?

Joakim Tennfors: It is a broad field. There is hard surface modelling, which suits some product types. There is photogrammetry. There is NeRF, Gaussian splatting, and other AI tools appearing, which are interesting. They all have their own use cases, but I always come back to the same question. What is the use case? What is the end deliverable? That is where you have to start.

We use a lot of photogrammetry because it is a very competent and very mature technology. It has some drawbacks. But going back to starting with the deliverables, we walked our way backwards. We know the limitations of photogrammetry and we have planned for them in the pipeline. We use other tools to accommodate for its weaknesses.

You have been working with photogrammetry longer than you have been at Fibbl. How did the pipeline evolve?

Joakim Tennfors: The drawbacks have been familiar to me for a long time. The journey has been about scaling across product categories.

When we started we were trying out a range of product categories, and we were focused on shoes then as well. But you get a very different range of shoes, and you cannot produce them all with the same techniques. You need different tool sets for a sneaker than for a knee-high leather boot.

So a few years in, we came up with what we call a CPM, a Category Production Manual. We realised we had to aggregate these challenges into blueprints. It is similar to industrialising a car plant. You don’t build a car plant and then build any type of model. You narrow it down to a few selected lines of products that you can produce effectively and scalably.

We needed to document what differentiates a sneaker from a knee-high leather boot from a production point of view. Again, start from the outputs, work backwards, and figure out what processes and tools we need to accommodate that. We have also learned to run certain processes in parallel. We use hard surface modelling for some parts of some products, and running that alongside the photogrammetry process shortens the lead time to deliver.

Where the two ends meet

Christian, you have been there almost the whole time. How did the tech side develop alongside that?

Christian Kaunissaar: If you go back at least four years, Joakim and his team were working hard on how to build the pipeline and how to scale. My team was starting to make use of what production delivered. It was very early in our journey that we understood we needed to make an end to end solution.

Creating the 3D models is obviously one of the biggest problems, probably the biggest one. But we also looked at the entire journey. What can we do to actually enable e-commerce brands to use these 3D models?

So it was an iterative process with Joakim’s team, and most of the time we focused on how the models should be presented in the viewer. That was the first alignment between building the tech and building production, because you can build 3D models, but you also have to show them.

We started out with a generic model viewer. We found flaws in it, so we had to build our own. And then it became an iterative process between production and tech, changing things in production knowing we could change things in the viewer, to create a synergy between the two.

Joakim, how does the platform affect what you do at the very start of the pipeline?

Joakim Tennfors: Directly. We want to deliver a model quality that works in an offline render to create 2D images and videos, and it also has to work in the online viewer that Christian’s team built. My team looks very much at the fidelity of the models. Then we get his perspective on distributing this at scale. What are the file sizes? Is this running on older hardware for some end consumers?

Those specifications, the fidelity from my side and the technical weight and performance from his, influence what we do from the very start. How do we shoot this product? How much data do we collect? How do we process it, for it to end up weighing this many megabytes, performing well on mobile phones, and still holding high fidelity in offline renders.

It affects the entire pipeline. That is the foundation. Producing the models has to be tied to the end experience. If those are in the same boat, you get the extra quality you need, whether that is in a viewer or a content production pipeline.

How important is the collaboration between your two teams?

Joakim Tennfors: It is fundamental. What Christian’s platform delivers to clients, the specifications and processes there, affect the very beginning of my production pipeline. That is why end to end is the only way to do it. They are incredibly interlocked. I cannot make a decision to change my pipeline that will affect the distribution of our models without them.

Christian Kaunissaar: Same. It is fundamental. The model viewer is built not only by tech developers but by production developers as well. We are sitting in the same boat.

What happens after the model is finished

A model is completed. What happens next?

Christian Kaunissaar: First of all, the reason we even built the experience layer was that we understood we had to. To offer great product experiences based on 3D models, we needed to build the viewer, and we needed to offer an easy way to implement it on their website.

So on that end we built a package of experiences, based on components, that the client can implement into their current web store without messing the web store up. That is the most important part. Clients do not go from 2D to 3D from one day to the next. So we needed a layer that appears on the products that have 3D, while the products that do not have 3D look exactly the same, and we had to handle the logic for that.

In between those two ends there is an ocean of challenges.

Joakim, what actually gets delivered into the platform?

Joakim Tennfors: We have had to collaborate quite a bit to pull this off. We deliver a web optimised GLB, and an FBX with high resolution textures for offline rendering. That is the raw material we feed into the platform.

But to cover all operating systems, AR on iOS requires the USDZ format, so there are file conversions. Christian’s team built an automated way to both compress and convert. We have our partners at ArtLabs to automatically convert GLBs to prepare them for the Virtual Try-On experience. We have an automated rendering pipeline that outputs different types of 2D content and uploads it to the platform.

Our regular GLBs are enhanced too. Similar specification to the FBX, but we pre-bake a ground shadow for the viewer, which is not present in the FBX because we do not want pre-baked shadows in offline renders.

Christian Kaunissaar: And that is a good point, because we also understood that we cannot solve every problem ourselves. When we mapped out everything we needed to solve to offer this experience, we decided we did not want to build all of it. So we work with specialists where that makes more sense than building. ArtLabs handles the Virtual Try-On experience, and we have partners on the optimisation and conversion side. We have our own compression as well. It is a mix.

What else sits in that middle layer?

Christian Kaunissaar: Distribution. One idea was to give the files to our clients and let them host them. But that is a problem too. It is messy for the client to manage files. And we saw that the most common CDNs and distribution platforms were not fast enough. They were not optimised for 3D content. You want a very nice 3D model in high detail and you want it to be fast. You don’t want the customer waiting for the experience. So we had to build that as well.

Then there is matching. Some of our clients have hundreds or thousands of 3D models. There has to be a mechanism that connects a model to the actual product, so the script knows which models and experiences to show. So we built a matching mechanism that scans all of the client’s products and all of our models and works out which model belongs to which product.

Why it scales

Explain in clear terms why this pipeline scales when other approaches do not.

Joakim Tennfors: It is the industrialisation mindset. Narrow your scope. Try to achieve something very specific. If you set out to build a 3D pipeline that can create anything, it won’t scale. You need to aggregate the problems and standardise the processes. That is the only way to do it.

A lot of people who come from a 3D background come from the mindset that every asset is the hero asset, and every asset is unique. They are not. There are common problems that you need to solve. Aggregate them, package them neatly into processes that are predictable and repeatable. That is how you scale.

You can produce anything in 3D. But if you want a thousand of the same type of object, you need a blueprint.

Christian Kaunissaar: From the delivery side, the scale is in the API and the components. We made the system to be a one-time implementation. You implement the Fibbl script once on your product page template. The script then determines whether to execute or not. It asks our API whether we have a model for this product. If not, it stops executing immediately. If we do, it lights up all the experiences the client wants.

That enables scale, because the client only does a one-time implementation. Then they send their products to us, we create the models, it goes into the system, and after some time it delivers the experience.

Was there one problem that felt like the breakthrough?

Joakim Tennfors: That is a trick question, because the problems never end. Another core philosophy of my team is continuous improvement. After we figure out a process, we automate everything we can, and everything we cannot automate we standardise, so it is predictable and repeatable. Then we continuously revisit and improve.

Take the scanners. We used to buy them. We tried different vendors. The scanning times were very long and it ate up a lot of our resources. So we built our own scanners and improved the scanning time by an order of magnitude. Then we figured out another way to pre-process the material and shaved off 25% of the processing time. It is always about revisiting the pipeline and finding where the bottleneck is now that the last one is solved.

Christian Kaunissaar: I can’t point to one either. It is a lot of problems that all needed solving. If you stop innovating, someone will surpass you.

But if I had to pick one, it was when the first version of our component layer was released. I saw how it worked, and how simple it was to implement, and I was relieved. I could see how it would enable this for so many clients. Their hesitation about going live with 3D disappeared when I saw that solution play out.

The question every brand asks

How important is speed?

Christian Kaunissaar: Speed is a total deal breaker. There is the time it takes to create the experiences, which has to be almost instant. And then there is performance on the client’s site. That is a total deal breaker. With a lot of clients we talk to, the first question is whether it slows down their site. That was something we had to handle.

Joakim Tennfors: Fundamentally, the future we are heading towards is not tacking a 3D experience onto the end of your usual content production pipeline. We should rework how content production pipelines are built. If you are going to fundamentally change how you get access to your 2D content, for wholesale, for an upcoming release, for ads, then we need to be faster than a photographer. In that sense it is very important for this 3D shift to really kick off.

“But we already have 3D files”

Brands often say they already have 3D models, sometimes from their design tools. What is the answer?

Joakim Tennfors: Back to misconceptions. The assumption is that if you have a master 3D file you can use it in all 3D applications, which is not entirely true, because you need a translation layer.

If you have a model from a design process, what specification does it have? What is the poly count? How large are the textures? Do you even have shaders for the offline renderer you intend to use, or do you need to build those? Do you need a script to build them automatically? Are the meshes quad-based or triangulated? There are a lot of questions.

If you are in that position and you want to use them in an offline renderer or in a web context, the real question is whether you want to spend your time and resources building that translation layer. Taking a high poly quad-based mesh that needs triangulating for WebGL, downsampling your textures, and so on.

We have had clients with existing 3D models where we worked out that it was cheaper and more effective for us to just produce the models again, because of the efficiency of our pipeline. That way we also know it is to our specification and works across all of our deliverables. That is the benefit of the end to end mindset. There are no question marks.

Translating a simulated mesh from a design tool for use in WebGL is a completely different pipeline. We can build it, but it is a different pipeline, and a different approach might be more effective.

What happens when a brand decides to build its own viewer?

Joakim Tennfors: We have had those discussions with potential clients and partners. And that is fine. But then my next question is when I can talk to them, because they are going to make decisions about their viewer that affect how our pipeline has to deliver into it.

Everything is interlocked, from making sure we have colour accuracy at the point of capturing the raw data, through processing, through creating the textures, to them being rendered in the viewer, and normalising how we light our 3D environment and how our diffuse textures normalise for that environment. It is all interconnected. In those discussions we need to talk to the team building the viewer. Otherwise we can’t do it. It is not scalable.

Closing advice

Someone is looking at this whole range of problems and deliverables. What is your best advice?

Joakim Tennfors: Start with your deliverables. Figure out what the end result is going to be, and work your way backwards. And the second thing is that there is no one-stop-shop tool you can buy that solves the entire problem. It is a pipeline. You need multiple tools for different problems.

Christian Kaunissaar: Start with what you want to deliver to your customers. What is the experience you are looking for? Design that. Think about it thoroughly. Then find a way to create 3D models, make sure they are consistent, and match that with a good model viewer. Make sure your consistent models look good in that viewer, or in whatever experience you offer. And then keep the consistency.

Joakim Tennfors is Head of Production at Fibbl. Christian Kaunissaar is Fibbl’s CTO.