• Home
• Home, Charter
When BitcoinOS set out to revolutionize Bitcoin, they asked Studio Freight to match that ambition with the mandate to build a brand and digital presence as progressive as the mission itself. What started as sketches and atmospheric references became a fully immersive 3D world. One that had to perform within real browser constraints without losing narrative depth or visual intensity.
To help bridge that gap, Studio Freight brought in 3D and VFX artist Yousef Alhaddad. In this written conversation, Yousef walks us through how he turned abstract concepts into physically coherent and performance-ready assets while working closely with the team to align art direction with technical reality.
)
AA
When we first talked about what this project needed to be, the word that kept coming up wasn't “brand” or “website.” It was “world.
YA
The brief was essentially that Bitcoin?? is an extremely trusted system and deserves a future where everyone benefits. So we explored creating the kind of place that could make someone believe in that future and where we landed was a journey guides people towards it with lore.
We mapped it as a path through darkness toward light. The cave portal positioned Bitcoin as something ancient and alive that you approach rather than install. The bioluminescent forest recast crypto's many failed promises as landscape features, navigable instead of damning. A tesseract marked the moment of ZK-proof verification on Bitcoin — a seminal moment and a genesis for Bitcoin’s new possibilities. And the golden sun, for BitcoinOS, was conceived to represented the idea of lighting the way forward.
We mapped it as a path through darkness toward light. The cave portal positioned Bitcoin as something ancient and alive that you approach rather than install. The bioluminescent forest recast crypto's many failed promises as landscape features, navigable instead of damning. A tesseract marked the moment of ZK-proof verification on Bitcoin — a seminal moment and a genesis for Bitcoin’s new possibilities. And the golden sun, for BitcoinOS, was conceived to represented the idea of lighting the way forward.
AA
We wanted the mythology to carry the explanation. As you built, were you more focused on the objects or their meaning?
YA
Honestly, both, but never at the same moment. While my hands were in it, I was thinking about the thing itself, almost obsessively. The homepage sequence was the same, I wasn't thinking "navigable failure," I was thinking about whether the bioluminescence felt like it came from inside the growth or sat painted on top. You have to lose yourself in the object, because if the thing isn't convincing on its own terms, no amount of meaning rescues it.
People feel a fake instantly, even when they can't say why. If the orb is solid, you trust the cave. If you trust the cave, you'll follow the forest. If you follow the forest, the sun means something when it finally arrives. So the craft was never separate from the journey. It was how I earned the right to move someone through it.
The sun was the one place I had to set the technician down (mostly cause its a simple object) and think like a visitor. By then you've been in the dark so long that the question stops being "is this rendered well" and becomes "does this feel like relief?" That isn't a technical question anymore; that's the person walking through. And if we got the earlier objects right, they're the ones who made the sun land. Not me.
People feel a fake instantly, even when they can't say why. If the orb is solid, you trust the cave. If you trust the cave, you'll follow the forest. If you follow the forest, the sun means something when it finally arrives. So the craft was never separate from the journey. It was how I earned the right to move someone through it.
The sun was the one place I had to set the technician down (mostly cause its a simple object) and think like a visitor. By then you've been in the dark so long that the question stops being "is this rendered well" and becomes "does this feel like relief?" That isn't a technical question anymore; that's the person walking through. And if we got the earlier objects right, they're the ones who made the sun land. Not me.
)
01 of 03
AA
When you joined the project, how did you approach working within the art direction that was already defined?
YA
My first step was to gather references and understand how the concept would behave in real 3D space. You had shared the Notion board and concept references, but translating that into 3D meant figuring out what the materials actually were and how they would exist physically. In 3D, everything has to work across dimensions, so I needed to understand not just the shape but how it would look from every angle and how it would react to light.
A lot of specific questions have to be considered. Is this metal that's been brushed or cast? Is this plastic with a matte finish or does it have a slight subsurface scatter? Is this fabric woven or felted, and how thick is the weave? Every material decision cascades. The specularity, the roughness value, how it holds shadow in the crevices. I'd be staring at a reference image trying to reverse-engineer a real-world object from photographs and IA samples, asking myself, what would this feel like if I picked it up?
For example, with the LED mask and other elements, I looked at real-world references to understand materials and surface behavior. That’s always my starting point. I try to ground the concept in something physically believable so I can build from there.
A lot of specific questions have to be considered. Is this metal that's been brushed or cast? Is this plastic with a matte finish or does it have a slight subsurface scatter? Is this fabric woven or felted, and how thick is the weave? Every material decision cascades. The specularity, the roughness value, how it holds shadow in the crevices. I'd be staring at a reference image trying to reverse-engineer a real-world object from photographs and IA samples, asking myself, what would this feel like if I picked it up?
For example, with the LED mask and other elements, I looked at real-world references to understand materials and surface behavior. That’s always my starting point. I try to ground the concept in something physically believable so I can build from there.
)
AA
You mentioned Notion. Can you talk about the pipeline organization?
YA
Notion?? was the backbone of the production pipeline. Each scene was broken down into its individual components, so I could see exactly what elements needed to exist in 3D: the orb, the terraces, the mage, the mushrooms, the environment details. That structure was really helpful because it gave me clarity on scope and hierarchy. Instead of interpreting a single image, I was translating a system. Notion became the place where art direction, asset lists, and scene planning all lived together, which made it easier to understand what needed to be built and how it would function across the site.
As the project evolved, that structure became even more important. We would test a scene to see what was technically feasible in WebGL. Once we understood what worked and what didn’t, we could adjust the asset list and modeling approach accordingly. So Notion wasn’t static. It reflected iteration. It was essentially the shared map between design, 3D, and development.
As the project evolved, that structure became even more important. We would test a scene to see what was technically feasible in WebGL. Once we understood what worked and what didn’t, we could adjust the asset list and modeling approach accordingly. So Notion wasn’t static. It reflected iteration. It was essentially the shared map between design, 3D, and development.
)
)
)
AA
We used AI tools like ChatGPT and Midjourney in the concept stages. Can you share how that process unfolded?
YA
AI was very useful at the beginning, but mostly as a reference generator. The initial sketches were hand-drawn, then interpreted through ChatGPT?? and Midjourney?? to produce visual directions quickly. That allowed the team to explore aesthetic territory without spending weeks modeling. But AI outputs are unpredictable. The shapes can look great in a still image, but they’re often nonsensical when you examine them structurally because the surfaces don’t connect logically, materials aren’t defined, and light behavior is ambiguous.
AA
You've come back to how light and material shape the outcome a couple of times, can you unpack that?
YA
We tend to treat light in 3D as a tool for illuminating objects. It isn't. Light is what creates form. The sharpness or softness of a shadow tells you where something sits in space; a wet street mirrors the sky; glass bends what passes through it. Form is sculpted by how we choose to interpret light's behavior — light is the information system that ties concept to execution. That mattered because of where our concepts came from.
“Flat art gets to lie. In 3D, light interrogates everything.”
Yousef Alhaddad
The AI generated our 2D concepts by guessing at these optical properties, and often guessing wrong. But the errors were often beautiful, with forms that don't obey optical realism yet stay compelling, like a surreal fabric that bends color to its will or alien, spore-like grass lit by rules that exist nowhere in the physical world.
Our job was to recognize that those rule breaks weren't mistakes to fix, they were aesthetic choices to honor. So we changed the question, from "how should this material behave optically?" to "what happens to this form when we treat light this way?" That's where the Yeezy fabric and mossy grass came from: parameter choices that preserved the AI's strangeness instead of correcting it, such that the fabric reads as technically real but treated, almost synthetic, and the grass references real moss but leans into the dreamy, near-handmade feel of the original. We were bridging two kinds of artifice: the algorithmic strangeness of early diffusion models and the tactile strangeness of unconventional 3D choices. Light is what let us cross between them.
Our job was to recognize that those rule breaks weren't mistakes to fix, they were aesthetic choices to honor. So we changed the question, from "how should this material behave optically?" to "what happens to this form when we treat light this way?" That's where the Yeezy fabric and mossy grass came from: parameter choices that preserved the AI's strangeness instead of correcting it, such that the fabric reads as technically real but treated, almost synthetic, and the grass references real moss but leans into the dreamy, near-handmade feel of the original. We were bridging two kinds of artifice: the algorithmic strangeness of early diffusion models and the tactile strangeness of unconventional 3D choices. Light is what let us cross between them.
)
01 of 03
AA
What were the most difficult technical challenges, especially with performance and WebGL constraints?
YA
The cloth simulation was probably the most technically challenging part. We originally wanted a looping cloth animation on the website, but cloth simulations are extremely data-heavy. WebGL has strict performance limits, and if we pushed it too far, the site would lag, crash, or feel slow. So we had two options: rig and animate the cloth manually, or run a cloth simulation in Marvelous Designer.??
With nearly six scenes to handle, rigging would have been a disaster, especially given how often the geometry had to change (to achieve ideal performance). Every time we updated the geo, we would have had to restart the rigging from scratch, and we changed it about six times. This made simulation the clear choice. But that came with its own challenges: the file sizes were heavy, and looping a cloth sim is notoriously difficult because you're essentially trying to make physics behave in a seamless cycle. I spent a lot of time working through both of those problems and eventually found an approach that was light, loopable, and performant enough for the web.
With nearly six scenes to handle, rigging would have been a disaster, especially given how often the geometry had to change (to achieve ideal performance). Every time we updated the geo, we would have had to restart the rigging from scratch, and we changed it about six times. This made simulation the clear choice. But that came with its own challenges: the file sizes were heavy, and looping a cloth sim is notoriously difficult because you're essentially trying to make physics behave in a seamless cycle. I spent a lot of time working through both of those problems and eventually found an approach that was light, loopable, and performant enough for the web.
)
Midjourney image generation
)
Texture reference
01 of 04
AA
Any learnings from this project about how to approach 3D work?
YA
The biggest takeaway for me was that art direction and technical direction can't be separated on a project like this. They have to evolve together from the start. When those conversations happen independently, you risk creative decisions that are difficult or impossible to execute within the technical constraints. If I did a similar project again, I'd merge those discussions much earlier, so vision and feasibility are aligned from day one. That alone would prevent a lot of friction later.
That lesson came straight out of Scene Two. The BitcoinOS site is built as a six-part visual journey rather than a typical landing page, a world the user travels through as Bitcoin comes back to life. Scene Two is the turning point, where the dead landscape first reawakens — a figure descends into a luminous valley of glowing mushrooms, rivers, and rising light, an orb climbing overhead. It's the most loaded beat in the sequence, the most elements, the most motion, the most layered environment, which is exactly why it became the proving ground for the whole project. Before we could commit to anything, we had to know what WebGL?? could actually hold, and the only way to find out was to push it until it broke.
Every asset in that scene went through its own interrogation. The first question was always the same: what can be a plane? At first we assumed almost everything could, then worked our way down until almost nothing did. In the end only the river survived as a plane, everything else demanded more. The wizard went through revision after revision: geometry, textures, the relationship between the two, how it read at different distances, how it held up under the scene lighting. Nothing was assumed. Every element was picked up, examined, stress-tested, and either rebuilt or rethought.
That lesson came straight out of Scene Two. The BitcoinOS site is built as a six-part visual journey rather than a typical landing page, a world the user travels through as Bitcoin comes back to life. Scene Two is the turning point, where the dead landscape first reawakens — a figure descends into a luminous valley of glowing mushrooms, rivers, and rising light, an orb climbing overhead. It's the most loaded beat in the sequence, the most elements, the most motion, the most layered environment, which is exactly why it became the proving ground for the whole project. Before we could commit to anything, we had to know what WebGL?? could actually hold, and the only way to find out was to push it until it broke.
Every asset in that scene went through its own interrogation. The first question was always the same: what can be a plane? At first we assumed almost everything could, then worked our way down until almost nothing did. In the end only the river survived as a plane, everything else demanded more. The wizard went through revision after revision: geometry, textures, the relationship between the two, how it read at different distances, how it held up under the scene lighting. Nothing was assumed. Every element was picked up, examined, stress-tested, and either rebuilt or rethought.
)
01 of 03
AA
What about working with WebGL?
YA
I had never worked this extensively in WebGL before, and I didn’t realize how limited it actually is. It changed how I think about optimization. Normally, I might start at full fidelity, using high-resolution maps and detailed geometry, and then scale down if needed. Now I would approach it the opposite way. I would start optimized and scale up only if performance allows it. That means thinking carefully about topology, textures, UVs, and file sizes from the beginning. WebGL forces you to be disciplined, and that’s something I’ll carry into future projects.
With the mushrooms, for example, shape keys are how you animate organic things in Blender.?? You define a resting state, a fully sprouted state, and the software smoothly blends between them. Beautiful result, but it's work the CPU has to redo every single frame, for every single mushroom in the scene. That gets expensive fast.
With the mushrooms, for example, shape keys are how you animate organic things in Blender.?? You define a resting state, a fully sprouted state, and the software smoothly blends between them. Beautiful result, but it's work the CPU has to redo every single frame, for every single mushroom in the scene. That gets expensive fast.
“WebGL forces you to be disciplined.”
Yousef Alhaddad
So we switched to VAT (Vertex Animation Textures).?? The idea is simple actually, where instead of calculating the animation live, you bake every frame of movement into a texture upfront. Think of it like a flipbook that lives on the graphics card.
Each mushroom just reads from that flipbook at runtime, which is something GPUs do almost for free. You can then scatter dozens of instances across the scene and the performance cost barely moves, because they're all reading from the same pre-cooked data rather than each doing their own calculation.
Each mushroom just reads from that flipbook at runtime, which is something GPUs do almost for free. You can then scatter dozens of instances across the scene and the performance cost barely moves, because they're all reading from the same pre-cooked data rather than each doing their own calculation.
)
AA
How would you compare WebGL to your usual cinematic work?
YA
WebGL is restrictive, but that restriction can be a positive. It forces you to be more creative with your choices. You can't push everything to maximum fidelity, so the solutions have to get smarter. Take the cracked orb: a cracked clay orb needs a lot of surface detail to feel convincing, especially at a low poly count, and WebGL won't let you brute-force that detail the way an offline render can. So the detail and the lighting both had to be drawn in by hand. The constraint is what forced the more deliberate solution.
Cinematic work is different. It lets you focus purely on visual quality without worrying about performance limits. You can raise polygon counts, use displacement maps, push materials further. That freedom is fun, but it comes with its own pressure. In our case, we didn't allocate enough dedicated render time early on, which limited how far we could push micro-detail. Both approaches have value, they just demand different mindsets.
Cinematic work is different. It lets you focus purely on visual quality without worrying about performance limits. You can raise polygon counts, use displacement maps, push materials further. That freedom is fun, but it comes with its own pressure. In our case, we didn't allocate enough dedicated render time early on, which limited how far we could push micro-detail. Both approaches have value, they just demand different mindsets.
AA
What does "drawn in by hand" actually mean in practice? Take us through the orb step by step.
YA
Sure. For this project the process was: first, I light the scene properly in a ray tracer like Cycles with full ray tracing, global illumination, cinematic lighting. That version is the "truth" of the orb, it shows exactly how light behaves across the surface and inside the cracks. Then I translate that into textures. The detail a normal map would carry in an offline render gets painted straight into the color texture instead, following the cracks and the clay grain. Then I author a second texture, black and white, that follows those exact same strokes. That one isn't about color, it's about instruction. It tells the scene's light shader where to read as a highlight and where to fall to no light, which is what gives the cracks their clean edge lighting. So I'm studying where shadows fall, where light wraps around edges, where a rim light would naturally appear, and baking those decisions into the textures in a simplified, intentional way.
Why does this matter? WebGL teams can do incredible things with real-time shaders and post-processing, but only if the geometry and textures are clean and purposeful. If the base color is confused or the lighting cues are messy, the effects start fighting the asset. But if the model already understands light, with clear silhouettes and intentional dark and light areas, the real-time work enhances it instead of correcting it. The ray-traced render is my reference. The stylized textures are my translation. The WebGL environment is where it all comes alive.
Why does this matter? WebGL teams can do incredible things with real-time shaders and post-processing, but only if the geometry and textures are clean and purposeful. If the base color is confused or the lighting cues are messy, the effects start fighting the asset. But if the model already understands light, with clear silhouettes and intentional dark and light areas, the real-time work enhances it instead of correcting it. The ray-traced render is my reference. The stylized textures are my translation. The WebGL environment is where it all comes alive.
)
AA
The cinematic had to come together fast, and from the opening shot called for assets we never built for the site. How'd you crack it?
Context note: The cinematic arrived as added scope — an announcement piece meant to expand the site's world, built to launch the rebrand alongside it on a brutal turnaround. To keep production manageable, the team had deliberately skipped making certain assets for the site, then the cinematic turned around and demanded exactly those.
YA
It came up mid-production with no rig, no animation, and no time to build either from scratch. What saved it was the framing: we only ever see part of the feet, so whatever sat underneath didn't have to be precious. I pulled a free Sketchfab model, ran it through Mixamo?? for a rig and a close-enough walk cycle, and had something usable in a fraction of what a proper build would've cost. Refined? Not remotely. It didn't need to be. It needed to hold for the moment it's onscreen and not eat hours the rest of the pipeline was counting on.
What stuck with me wasn't the shortcut, it was what the constraint clarified. When you can't brute-force a shot, you're forced to ask what it actually needs to do, and it's almost always less than your instinct wants to give it. Stripping the feet down to exactly what the frame required freed up everything I had for the shots that earned it. The limit didn't lower the bar; it told me where the bar actually was.
It also sharpened the contrast between the two projects. The cinematic ran on speed: decide fast, improvise, keep moving. The site ran on structure, problems that didn't vanish after one edit and needed solutions that could scale. Doing them back to back is what taught me to switch between those modes instead of forcing one onto the other.
What stuck with me wasn't the shortcut, it was what the constraint clarified. When you can't brute-force a shot, you're forced to ask what it actually needs to do, and it's almost always less than your instinct wants to give it. Stripping the feet down to exactly what the frame required freed up everything I had for the shots that earned it. The limit didn't lower the bar; it told me where the bar actually was.
It also sharpened the contrast between the two projects. The cinematic ran on speed: decide fast, improvise, keep moving. The site ran on structure, problems that didn't vanish after one edit and needed solutions that could scale. Doing them back to back is what taught me to switch between those modes instead of forcing one onto the other.
)
AA
How was working with the studio through these constraints? No pressure!
YA
I really appreciated the your clarity of vision and the level of trust from the studio team throughout the process. I felt trusted to make decisions within my expertise, and feedback was always logical and grounded in real constraints. There was no arbitrary nitpicking. Everyone understood the limitations we were working within. I think the most successful moments happened when the three of us were in the same conversation. When design, development, and 3D were aligned in one meeting, we could quickly identify what wouldn’t work and find a middle ground that preserved the vision while staying within technical boundaries.
AA
What do you think makes a collaboration successful?
YA
In this case, it worked because we were bringing different skill sets into the same discussion. I could speak to geometry and material limitations, Andrea [Giuffrida] could speak to WebGL constraints, and you could speak to art direction and narrative intent. When we bounced ideas back and forth in real time, we found solutions that none of us would have reached alone. The cracked orb is a good example of that. The modeling, compositing, and texturing all came together because we were actively problem-solving as a group rather than sequentially.
AA
Yousef and I go back a lot further?? than this project. He taught me most of what I know about 3D. We went to school together, lived together, and somewhere along the way landed on the same view of things: the universe is absurd and nobody's really steering, so the decent thing is to make something beautiful while we're here. If free will is really a fiction, and we're both pretty convinced it is, then I was always going to end up making things with this guy. Lucky me. Thank you, Yousef.
Exploring The Accidental World of Accidentally Wes Anderson
No. 12
With Wally Koval
from Accidentally Wes Anderson
Category