• Project Type: Personal project
• Focus: 3D web pipeline (Blender to WebGL integration)
• Stack: Blender, Three.js
• Goal: Build a performant, web-ready 3D scene from scratch
• Outcome: Interactive 3D experience under 10MB total size

The Start

In 2023, I transitioned into 3D web development and wanted a hands-on way to understand the full pipeline, from modeling, texturing, UV unwrapping, baking, and real-time rendering for the web.

After following isolated tutorials, blogs, and case studies, I decided to build a complete scene and push it until it was viable for Three.js.

A screenshot from Blender where I was trying my first render

My first render, it really felt good

The first render helped me understand how light, geometry, and materials interact. More importantly, I saw what doesn’t translate well to real-time rendering.

One early issue was incorrect light behavior through geometry, which revealed gaps in my understanding of materials and scene structure.

The render now looks like a door

Exploration & Limitations

I ended up creating an abstract scene to push my understanding of colors, materials, and composition. This quickly exposed how complex proper texturing and shading actually are, especially when the target is WebGL.

The render of the abstract scene

At this point, I shifted focus from offline rendering to the web. I explored baking geometry, lighting, and colors into textures that could be efficiently rendered in Three.js.

A screenshot where the web version is on the right, Blender render on the top left, and the baked texture in the bottom left

Matching Blender’s appearance inside a real-time renderer was not easy at all and required understanding color spaces, texture formats, and export settings.

Time to Give It Everything I Have

For the final iteration, I committed to building a complete scene end-to-end, treating it as a production-style exercise rather than a test.

Once I was done with the modeling and was ready to UV Unwrap everything

Everything is colored, but this was the material preview

While rendering, just two samples and it looked greatly amazing back then!

Geometry was merged and textures were baked into smaller atlases to reduce draw calls and load times.

Simple particle systems and lightweight interactions were used to create the illusion of depth and physical response without expensive simulations. Grass, glowing particles, and snow were implemented directly in Three.js to preserve interactivity and make them more randomized.

Optimization Steps

A major goal was keeping the experience lightweight.

• Textures: Personal project
• Models: 3D web pipeline (Blender to WebGL integration)
• Bundled Code (including the Libraries): Blender, Three.js
• Code I Wrote: Build a performant, web-ready 3D scene from scratch

Total size remained under 10MB uncompressed, with several optimization opportunities identified for future iterations.

Reflection

This project marks my entry point into 3D web development. While I would approach many decisions differently today, it validated my ability to move between tools, reason about performance, and ship a complete interactive experience for the web.

• Project Type: Problem-Solving, Technical Analysis and Implementation
• Client: Oreizon.com
• Role: Frontend & 3D Engineer
• Stack: JavaScript/TypeScript, Three.js, React Three Fiber, WebGL, Node.js
• Timeline: 6 Weeks
• Goal: Automate optimization of large scanned mining models for web visualization
• Outcome: ~98% file size reduction and ~34% performance improvement

Context & Problem

Oreizon works with large, scanned 3D mining models that need to be visualized and analyzed on the web. Before this project, they relied on manually optimizing large scanned mining models using Rhino, a process that was slow, repetitive, and unsustainable as new scans were generated frequently.

Raw scanned mining mesh

As the team at Oreizon planned to automate uploads using custom macros and cloud storage, keeping optimization fully manual became a critical bottleneck.

Constraints

To shape up the best solution, constraints needed to be identified:

• No costly back-end infrastructures (running Blender headless on the server, for example)
• It needed to work on low-end devices, including mobile phones
• Oreizon’s visualization stack already relied on Three.js
• The workflow had to avoid reliance on complex 3D software
• Performance needed to scale to hundreds of models in a single scene

With this, many traditional approaches were directly eliminated.

Solution

Evaluated Approaches

.

• Server-side optimization using a Python script proved reliable; however, it introduced compute costs and scaling issues really early.
• Running tools like MeshLab in the browser was technically feasible, but too heavy to load for every session!

Final Approach

I ended up designing a lightweight, client-side optimization pipeline implemented directly in JavaScript and Three.js.

• It runs on the user’s device,
• Required no additional infrastructure,
• Integrated seamlessly with Oreizon’s existing stack, and
• Adds only ~100KB of custom code!

This approach allowed models to be optimized immediately at upload time, even on older mobile devices. It also kept the upload experience fast and predictable, even on unstable connections.

A model getting optimized directly in the browser, on a 2018 mobile device

Implementation

Client-Side Optimization

On upload, the system:

• Loads the raw scanned model,
• Reduces vertex count while preserving overall shape,
• Prevents duplicated or overlapping vertices, and
• Generates three levels of detail (LOD) automatically:
• • High detail (close inspection),
• • Medium detail, and
• • Low detail (far view / placeholder).

The system outputs optimized assets ready for storage and rendering. The optimized assets can then be uploaded directly to AWS, without requiring users to download the files. Yet, it all works right within the local device with no server costs at all in this stage.

Uploading a model and generating three optimized versions

Optimization stages shown during processing

Back-End Final Process

Client-side optimization alone was not sufficient for scanned mining data. To further reduce file size and clean geometry, I added a Node.js back-end step that:

• Further decimated face count,

• Removed unused UVs and textures,

• Recalculated normals for visual stability,

• Converted formats from STL, PLY, DXF, and OBJ into GLTF/GLB, and

• Packaged them using the DRACO compression technique.

  This hybrid approach preserved performance while keeping server runtime minimal.

Large numbers of optimized models rendered efficiently

Performance Engineering

Despite significant file size reductions, performance issues remained on low-end mobile devices.

Profiling revealed two major bottlenecks:

• An inefficient LOD implementation
• An unnecessarily expensive lighting setup

improvements

• Reworked the LOD system using React Three Fiber’s built-in LOD utilities
• Replaced multiple point lights with two lightweight directional lights

FPS comparison before and after LOD & lighting changes

Lighting comparison: top before, bottom after

These changes significantly reduced GPU overhead without losing the visual clarity.

Results & Impact

• File size reduced by ~98% (11.5MB into ~140KB, for example)
• Vertex count reduced by ~80%
• Face count reduced by 50%+
• FPS improved by ~34% (from ~30-45 FPS → ~53-60 FPS)
• Supported formats expanded (.glb, .dxf, .obj, .ply, .stl)
• Fully automated pipeline with zero manual optimization

Data showing file size and complexity at each optimization stage

Scope Expansion & Delivery

While the original task focused on optimization, additional performance bottlenecks were identified and addressed during development. This slightly extended the timeline, but proactive communication ensured alignment and resulted in a far more robust system.

Client Feedback

“It's rare to find someone as hardworking and self-motivated as Mohammed. His problem-solving and communication skills, combined with his experience in JavaScript and Three.js, resulted in impressive solutions. He consistently met expectations and was always eager to go the extra mile.”

— Nawfal El Mkadmi, Founder & CTO at Oreizon

Reflection

This project required balancing performance, cost, scalability, and developer experience. Designing a client-side optimization pipeline under real-world constraints reinforced my approach to performance- driven web engineering and large-scale 3D systems.

Notes

Due to the proprietary nature of the project, source code and live demos are not publicly available.

Context

That Open Company was actively improving their ecosystem, a web-based, open-source BIM and engineering platform. As part of this effort, the team wanted to raise the quality of their UI components library by:

• Adding professional, consistent animations
• Improving usability and visual feedback
• Later, extending support to mobile and tablet devices

I was brought in as a freelance frontend developer to take ownership of these improvements.

Constraints & Environment

Several constraints shaped how the work was approached:

• The UI library was built using LitElement, not React or Vue
• Components relied on Shadow DOM and slots
• The library already included ~25 components, each with multiple variants
• No additional animation libraries (e.g. GSAP) could be introduced to avoid increasing bundle size
• Changes needed to integrate cleanly into an existing production codebase

Task 1: UI Animations

Adapting to the Stack

Although I had strong experience with frontend development and animations, LitElement introduced a different mental model. I invested time upfront to understand:

• Component lifecycle in LitElement
• Slot-based composition
• Shadow DOM styling and encapsulation
• Animation implications within scoped styles

This allowed me to start contributing immediately without disrupting existing architecture.

Animation Strategy

Given the constraint of no external animation libraries, all animations were implemented using:

• CSS transitions and keyframes where possible
• Web Animations API (via TypeScript) when more control was needed

The goal was not flashy motion, but:

• Clear interaction feedback
• Consistent motion language across components
• Animations that feel fast, intentional, and lightweight

Execution

I worked component by component, iterating closely on timing, easing, and subtlety. Because animations are best evaluated visually, I set up a live preview environment to make review and feedback easier:

Live preview: Work Archive For That Open Company

The final result was a cohesive animation system that elevated the perceived quality of the UI without increasing technical complexity, bundle size, or brand identity.

Delivery

• Animation task ran from mid-March to end of April
• All agreed animations were delivered on time
• Changes were integrated directly into the main UI components library

The Founder's LinkedIn post showcasing the animated components

Task 2: Responsiveness & Mobile Support

New Scope, New Challenges

After the animation work, I was asked to make the UI library usable on mobile phones and tablets. This went beyond simply scaling components down.

Key challenges included:

• Touch interactions behaving differently from mouse input
• Browser inconsistencies (especially Firefox)
• Layout constraints across small viewports
• Preparing the ground for future accessibility and internationalization work

Scope Definition & Communication

The initial request was broad, so I worked with the team to clarify priorities:

In scope:

• Mobile and tablet layouts
• Reliable touch interactions
• Visual consistency across breakpoints

Out of scope (for later phases):

• Full accessibility audits
• Internationalization edge cases

This allowed progress without blocking future improvements.

Execution & Timeline

I focused on:

• Making components responsive without breaking desktop behavior
• Ensuring touch interactions worked predictably
• Testing across devices and browsers

Although an initial deadline was set for end of May, communication delays and internal scheduling on the client side extended the calendar timeline into June. This was handled smoothly through continuous updates and flexibility.

Before / After comparisons were documented for the team:

• Before: The Start
• After: Working Animations and Responsiveness

Outcome & Impact

• UI components gained professional-grade animations without increasing bundle size
• The library became usable on mobile and tablet devices
• Motion and interaction behavior became consistent across the system
• The work integrated cleanly into an existing production codebase

Client Feedback

“Mohammed is the kind of developer you want on your team. Proactive, sharp, and no hand-holding required. He took ownership of every task, communicated clearly, and delivered with consistency. His technical chops are solid, and his attitude is even better.”

— Antonio González Viegas, Founder at That Open Company

“Mohammed was a key contributor during his time working with us. He consistently showed a strong sense of ownership, kept me well- informed with proactive updates, and approached every task with professionalism and care.”

— Juan Hoyos, Lead Developer at That Open Company

Reflection

This project was an example of production-focused frontend work: adapting quickly to an unfamiliar stack, respecting architectural constraints, and delivering reliable improvements that directly affected user experience.

It reinforced my approach to UI work as a balance between visual polish, technical discipline, and clear communication.