SB-01 is a pure mathematical digital art piece created by ST3PH-X to push the boundaries of modern WebGL and mobile graphics. Built entirely with raw GLSL shaders, Raymarching, and SDF geometry, this interactive experience renders a high-end conceptual mechanical watch in real-time — with zero external 3D models or heavy textures.
No reviews yetBe the first to leave a review for SB-01: Pure GLSL Tourbillon
Maker
📌
Hey Product Hunt,
I’m Stephaniia. I’m a creative engineer, and I love building things for the web that push the limits of mobile browser performance.
The SB-01 is my personal statement on minimalism and digital craftsmanship. I wanted to see if I could build a complex, high-complication mechanical tourbillon using absolute zero external libraries. No Three.js, no react-three-fiber, and no heavy assets.
Everything you see is written entirely in raw, hand-crafted GLSL shaders using Signed Distance Fields (SDF) and raymarching. Every single bridge, wheel, and sub-dial is pure math calculated directly on the GPU in real-time. If you look closely at the lower indicator, the distance field mathematically morphs into the branding, forming an S-B monogram in the negative space.
My dev setup is as minimalist as my code. I built this entirely inside Google Cloud Shell using their built-in terminal editor with simple syntax highlighting. I’ve always believed that you don't need heavy IDEs, local environments, or massive frameworks to write good programs. When you master the mathematics of the GPU, a web browser shell is all you need to create luxury.
It doesn’t click, it doesn’t push notifications, and it won't sell you anything. It just runs. Like a Marantz amplifier or a mechanical caliber, the value is entirely in the invisible engineering.
The live link is up. Open it on any device, look through the geometry, and let me know what you think of the math! I’m around in the comments if you want to talk shaders, SDFs, or low-level web graphics. For collaboration and custom WebGL inquiries, feel free to reach out directly.
Thank you for the support! 🚀
Report
💎 Pixel perfection
The fact that a whole conceptual tourbillon comes to life with nothing but raw GLSL and raymarched SDFs is honestly wild. Really clean execution on the geometry too, the gear details hold up surprisingly well in real time.
Report
Maker
@elmas5mz3 Thank you so much! I’m absolutely thrilled that you appreciated the tourbillon and the precision of the gear trains! Designing the orbital movement and keeping the mechanical layout physically accurate inside a single fragment shader was a massive mathematical puzzle. I spent endless hours code-golfing the SDF equations and fine-tuning the step distances to ensure that every single tooth and cog stays sharp and doesn't blur when in motion. Knowing that fellow developers appreciate this level of geometric cleanliness means the world to me. Thanks for the amazing support! 🛠️✨
Report
How does it actually perform on mid-range mobile devices given the heavy raymarching workload, and is there any fallback for older GPUs that might not fully support the required shader features?
Report
Maker
@muhammet0yfj Thank you for digging deeper into the technical side! Since the entire clockwork mechanism is packed into a strict WebGL2 pipeline, compatibility was a major focus during development.
For mid-range devices, the raw performance stays stable thanks to aggressive spatial caching and distance estimator optimizations. As for older GPUs that might struggle or lack advanced shader feature support:
1. Feature Detection Fallback: The app checks for WebGL2 and specific extension support at startup. If a legacy GPU is detected, the pipeline automatically compiles a simplified version of the GLSL code.
2. Math Approximations: In this fallback mode, complex volumetric lighting and heavy physical material calculations (like real-time brushed metal reflections) are replaced with lighter, pre-calculated mathematical models.
3. Loop Throttling: The max step count for the raymarching loop gets scaled down dynamically to keep the frame rate playable without breaking the core visual geometry.
Report
how smooth does it actually run on mid-range phones, and does it drain battery fast because of the real-time raymarching?
Report
Maker
@cosanalper66074 That’s a very smart point! While real-time raymarching is historically known for being a battery hog, I designed Steph-Watch SB-01 with power efficiency in mind.
To keep it running smooth on mid-tier phones without melting your battery, I implemented a custom dynamic sleeping loop. When the watch view is static and the sub-second components aren't shifting rapidly, the shader throttles down its raymarching step depth and calculation frequency. By cutting down unnecessary per-pixel calculations during idle frames, we get buttery-smooth rendering without aggressively draining the phone's battery. Thanks for asking this!
Report
How does it actually run on mid-range phones without dropping frames, given the complexity of the raymarching?
Report
Maker
@erdemglek2j4u Great question! To prevent frame drops on mid-range phones, I bypassed traditional geometry pipelines entirely. Since there are no heavy meshes or high-res textures to load, there's zero memory bandwidth bottleneck.
The magic lies in code-golfing the SDF equations. I combined several micro-details into single mathematical steps and used clever math approximations for the lighting, meaning the GPU does very little heavy lifting per pixel. That’s how it maintains a locked, stable frame rate!
Report
How does this perform on mid-range Android devices — does the raymarching stay smooth or does it tank without a desktop GPU backing it up?
Report
Maker
@hanmdalbaveyd That’s a great question! Performance on mid-range Android devices was actually one of my biggest priorities. Since Steph-Watch SB-01 is built entirely on pure mathematical functions, it stays surprisingly smooth even on mid-tier mobile GPUs.
I achieved this by heavily optimizing the raymarching distance estimator and using spatial bounding techniques to stop the ray loop as early as possible. There is no heavy texture memory bandwidth usage or polygonal overhead, so as long as the device handles standard WebGL2, the frame rate remains stable and buttery smooth without needing a desktop setup!
Report
How does it hold up on mid-range Android devices, especially with the raymarching being done purely on the GPU? Curious if frame rates stay smooth without thermal throttling kicking in.
Report
Maker
@soneryzbf Thank you for bringing up thermal throttling — that’s an incredibly sharp point! When you push real-time raymarching strictly to the GPU, overheating is usually the biggest silent killer for mobile performance.
To prevent the device from turning into a hand-warmer and dropping frames, I focused heavily on ALU (Arithmetic Logic Unit) optimization. I wrote the SDF equations to minimize complex branching inside the shader loop and avoided heavy transcendental functions where possible. By keeping the calculations mathematically lightweight and tight, the GPU pipeline executes with very low overhead. It keeps the frame rate smooth and steady at 60 FPS without triggering thermal throttling. Thanks for the smart question!
The fact that a whole conceptual tourbillon comes to life with nothing but raw GLSL and raymarched SDFs is honestly wild. Really clean execution on the geometry too, the gear details hold up surprisingly well in real time.
@elmas5mz3 Thank you so much! I’m absolutely thrilled that you appreciated the tourbillon and the precision of the gear trains! Designing the orbital movement and keeping the mechanical layout physically accurate inside a single fragment shader was a massive mathematical puzzle. I spent endless hours code-golfing the SDF equations and fine-tuning the step distances to ensure that every single tooth and cog stays sharp and doesn't blur when in motion. Knowing that fellow developers appreciate this level of geometric cleanliness means the world to me. Thanks for the amazing support! 🛠️✨
How does it actually perform on mid-range mobile devices given the heavy raymarching workload, and is there any fallback for older GPUs that might not fully support the required shader features?
@muhammet0yfj Thank you for digging deeper into the technical side! Since the entire clockwork mechanism is packed into a strict WebGL2 pipeline, compatibility was a major focus during development.
For mid-range devices, the raw performance stays stable thanks to aggressive spatial caching and distance estimator optimizations. As for older GPUs that might struggle or lack advanced shader feature support:
1. Feature Detection Fallback: The app checks for WebGL2 and specific extension support at startup. If a legacy GPU is detected, the pipeline automatically compiles a simplified version of the GLSL code.
2. Math Approximations: In this fallback mode, complex volumetric lighting and heavy physical material calculations (like real-time brushed metal reflections) are replaced with lighter, pre-calculated mathematical models.
3. Loop Throttling: The max step count for the raymarching loop gets scaled down dynamically to keep the frame rate playable without breaking the core visual geometry.
how smooth does it actually run on mid-range phones, and does it drain battery fast because of the real-time raymarching?
@cosanalper66074 That’s a very smart point! While real-time raymarching is historically known for being a battery hog, I designed Steph-Watch SB-01 with power efficiency in mind.
To keep it running smooth on mid-tier phones without melting your battery, I implemented a custom dynamic sleeping loop. When the watch view is static and the sub-second components aren't shifting rapidly, the shader throttles down its raymarching step depth and calculation frequency. By cutting down unnecessary per-pixel calculations during idle frames, we get buttery-smooth rendering without aggressively draining the phone's battery. Thanks for asking this!
How does it actually run on mid-range phones without dropping frames, given the complexity of the raymarching?
@erdemglek2j4u Great question! To prevent frame drops on mid-range phones, I bypassed traditional geometry pipelines entirely. Since there are no heavy meshes or high-res textures to load, there's zero memory bandwidth bottleneck.
The magic lies in code-golfing the SDF equations. I combined several micro-details into single mathematical steps and used clever math approximations for the lighting, meaning the GPU does very little heavy lifting per pixel. That’s how it maintains a locked, stable frame rate!
How does this perform on mid-range Android devices — does the raymarching stay smooth or does it tank without a desktop GPU backing it up?
@hanmdalbaveyd That’s a great question! Performance on mid-range Android devices was actually one of my biggest priorities. Since Steph-Watch SB-01 is built entirely on pure mathematical functions, it stays surprisingly smooth even on mid-tier mobile GPUs.
I achieved this by heavily optimizing the raymarching distance estimator and using spatial bounding techniques to stop the ray loop as early as possible. There is no heavy texture memory bandwidth usage or polygonal overhead, so as long as the device handles standard WebGL2, the frame rate remains stable and buttery smooth without needing a desktop setup!
How does it hold up on mid-range Android devices, especially with the raymarching being done purely on the GPU? Curious if frame rates stay smooth without thermal throttling kicking in.
@soneryzbf Thank you for bringing up thermal throttling — that’s an incredibly sharp point! When you push real-time raymarching strictly to the GPU, overheating is usually the biggest silent killer for mobile performance.
To prevent the device from turning into a hand-warmer and dropping frames, I focused heavily on ALU (Arithmetic Logic Unit) optimization. I wrote the SDF equations to minimize complex branching inside the shader loop and avoided heavy transcendental functions where possible. By keeping the calculations mathematically lightweight and tight, the GPU pipeline executes with very low overhead. It keeps the frame rate smooth and steady at 60 FPS without triggering thermal throttling. Thanks for the smart question!