DEV Community: J

Building a Reusable WebGPU & Rust Engine: Part 2 — Loading Custom Geometry & WGSL Shaders

Fri, 09 Oct 2026 05:09:30 +0000

In Part 1, we talked about the CPU event loop and established our foundational wgpu state. Now, we expand our engine to load 3D geometry (.obj files) from disk and feed it through a custom WGSL Shader Pipeline.
old-post link

Writing WGSL Shaders

Shaders are the small, highly parallel programs that run directly on the GPU to render 3D geometry and color pixels.

In wgpu, we primarily work with two types of shaders:

Vertex Shader (@vertex): Processes incoming vertex positions and attributes. Its primary job is converting 3D coordinates into Clip Space coordinates.(homogenous coordinates used by the GPU rasterizer)
Fragment Shader (@fragment): Runs once for every pixel (or fragment) covered by a primitive (like a triangle) to determine its output color.
We will go back to this part in short furture! it’s very useful process.

(Note: traditional APIs had geometry shaders, WebGPU omits them to ensure consistent cross-platform performance.)

When loading external 3D models (like an .obj file), here I pass three core vertex attributes to the vertex shader:

Position: The 3D spatial coordinates [x, y, z].
Texture Coordinates (UV): Mappings used to align 2D textures onto 3D surfaces.
Normals: Surface direction vectors, essential for calculating real-time lighting in the fragment shader.

Preparing Memory Layouts & CPU-to-GPU Buffers

To pass .obj model data from the CPU to GPU memory, we establish two key data structures:

1. Vertex custom data struct (wgpu::VertexBufferLayout & wgpu::VertexAttribute):

position — [f32; 3]
tex_coords — [f32; 2]
normal — [f32; 3]

Defines how memory is ordered inside the vertex buffer. Using wgpu::VertexAttribute, we specify memory offsets for each field (Position, UV, Normal) so the GPU knows exactly where each attribute begins in raw binary data.

2. Mesh custom data struct (CPU Side):

Once the .obj file is loaded into your Vertex structs, you upload them to the GPU. You create a Mesh struct to hold onto those GPU handles:

Vertex Buffer: Stores the array of packed vertex data.
Index Buffer: Stores the vertex indices, allowing triangles to reuse shared vertices to save GPU memory.
Index Count (indices.len()): Tracks the total element count required by render_pass.draw_indexed().

3. Connecting Everything in the Render Pipeline

[ .obj File & .wgsl Shader ]
              │
              ▼
    Load from Local Disk
              │
              ▼
  device.create_shader_module()  ──► Compile WGSL Code
  Mesh::load_obj()               ──► Upload Vertex/Index Buffers to GPU
              │
              ▼
 device.create_render_pipeline() ──► Reference Vertex::desc() for Memory Layout
              │
              ▼
 [ Store Mesh & Pipeline in State ] ──► Ready to Draw in state.render()

Load Assets: Read the .obj file into a Mesh struct and compile the WGSL shader code using device.create_shader_module().
Build the RenderPipeline: Create the pipeline via device.create_render_pipeline(), setting the @vertex and @fragment entry points. Pass description Vertex::desc() into the pipeline setup so wgpu render_pipeline knows how to map the vertex buffer straight into shader inputs.
Execute during Render: Store both the RenderPipeline and Mesh inside your State. Inside render() loop, bind the pipeline and draw the mesh buffers

Just like in Part 1, in the end the exciting result: we can load a 3D box into the scene using our custom shader—even without setting up a camera yet!

Thanks for reading, here is my Industrial Rust Projects:
Building industrial 3D vision or AI pipelines? Check out ForgeOptics on Gumroad for high-performance Rust ray-tracing, physical sensor noise, and synthetic dataset generation.

Building a Reusable WebGPU & Rust Engine: Part 1 — Windowing & Pipeline Architecture

Tue, 06 Oct 2026 12:52:27 +0000

Building a modular render engine or simulator template requires a clean separation between CPU-bound application logic and GPU-driven rendering pipelines.

In this post, I will track the process of building a lightweight, reusable render template in Rust using wgpu and winit.

Nowadays, we can utilize AI to handle implementation details, but as creators, we still need to review and master the architecture from a high level. Understanding the top-level structure helps us learn faster, validate the AI's output, and ensure our systems remain robust and maintainable.

1. Project Setup & Dependencies
Initialize a new Rust project and add wgpu (for graphics API abstraction) and winit (for cross-platform window management):

additionally: pollster: A minimal async executor used to block on GPU async calls during initialization.

2, Host Application Setup (CPU Side)
Before setting up wgpu, we build the host CPU process. This handles input, windowing, network requests, and overall application state separately from the renderer.

The event loop is the key structure on the CPU side. It drives the entire application lifecycle and coordinates user interactions, window events, and graphics updates.

       +------------------------------------+
       |         winit::EventLoop           |
       +------------------------------------+
                         |
                         v
  +----------------------------------------------+
  |  Event Handling (Main Loop)                  |
  |                                              |
  |  * WindowEvent::CloseRequested -> Exit App   |
  |  * WindowEvent::Resized        -> Resize GPU |
  |  * Other Events                -> Ignore     |
  +----------------------------------------------+

By isolating CPU application logic from rendering calls, you keep the host process clean and modular before bringing in wgpu.

3. GPU Pipeline Architecture (wgpu)
Once the window exists, we initialize the wgpu state. Rather than focusing on syntax, think of the GPU initialization as connecting five key structural primitives:

+-----------------------------------------------------------------------+
|                              wgpu State                               |
|                                                                       |
|  [ Surface ]  <--->  Bridge between the OS window and the GPU         |
|  [ Device ]   <--->  Virtual GPU interface (creates pipelines/buffers)|
|  [ Queue ]    <--->  Command channel to send work to physical hardware|
|  [ Config ]   <--->  Surface settings (pixel format, dimensions, vsync)|
|  [ Size ]     <--->  Tracks viewport bounds for dynamic resizing      |
+-----------------------------------------------------------------------+

As your engine grows, this structure expands to hold high-level rendering primitives like , , and .

The Core Execution Loop
Once initialized, the GPU pipeline operates around two primary execution routines:

[resize]

Fired whenever the window dimensions change. It updates the and reconfigures the so the rendering context stays locked to the window bounds without distortion.

[render]

The per-frame execution sequence:
Acquire Frame: Request the current frame buffer (output) and construct its texture view (view).
Encode Commands: Open a command encoder and launch a scoped Render Pass.
Manage Ownership: Crucially, the render pass must finish and drop its resource locks within its localized block {} before submission.
Submit & Present: Pass the encoded commands to the for execution on hardware, then display (present) the output frame.

After that, the "event handler" will connect "AboutToWait" and "RedrawRequested", invokes the [render] sequence

Finally showing the exciting result (a colored canvas- yeah!!!):

Bridging the Sim-to-Real Gap in 3D Structured Light Vision with Physics-Based Ray Tracing

Sun, 27 Sep 2026 13:57:11 +0000

The Problem with Geometric Z-Buffers

Standard depth-map generators output perfect geometric distances. However, real-world 3D vision relies on phase-shifting optical projections.

To solve this, ForgeOptics — a high-performance 3D structured light simulator specifically for computer vision researchers and robotics engineers.
Instead of generating ideal depth maps, ForgeOptics simulates the entire physical phase-shifting optical process:

Projecting sinusoidal fringe patterns
Path-tracing PBR surface reflections and scattering
Decoding phase shifts into ground-truth 32-bit floating-point depth maps Check out the full workflow below—covering GUI parameter tuning, Sigmoid sensor noise injection, and dataset generation:

Key Capabilities at a Glance |
1) High-Performance Ray-Tracing Engine, Built natively in Rust and powered by LuisaRender for fast, denoised, near-real-time previews and rapid dataset generation.

2) Dual Interactive & Automated Workflows

Interactive GUI Mode: Visually import 3D meshes (.obj, .glb, .gltf, .stl), edit PBR materials on the fly, adjust projector frequency, and configure instance segmentation IDs.
Headless CLI Mode: Every GUI parameter—projector, camera, lighting, and materials—is fully exposed in JSON format for automated background execution and batch dataset generation.

3) Real-World Degradation & Point Cloud Verification
Introduce custom Sigmoid sensor noise in camera settings to simulate physical hardware degradation.
Directly export reconstructed 3D PLY point cloud data, 32-bit floating-point depth maps, and exact camera intrinsic matrices for immediate downstream processing.

Try the Free Sample Dataset

Before buying or deploying, you can download and inspect free sample datasets containing full 32-bit depth maps, PLY point clouds, and camera intrinsics:
💾 Free Sample Dataset on GitHub: ForgeOptics GitHub Repository

🤗 Hugging Face Dataset Hub: ForgeOptics Structured Light Samples

Commercial Licensing & Downloads

Ready to automate synthetic dataset generation for your AI training pipeline or 3D vision algorithms?

🛒 Purchase Commercial Binary Licenses: ForgeOptics on Gumroad

Why Vision Models Fail on Glass: A Synthetic Benchmark for Transparent Objects

Fri, 25 Sep 2026 15:27:53 +0000

*Transparent objects like glass, acrylic, and water are the ultimate blind spots for modern Computer Vision models. *

Whether you are training Depth Estimation, 3D Reconstruction (NeRFs/3DGS), Segment Anything (SAM), or Object Detection models, transparent surfaces ruin feature matching and depth sensors. RGB light passes right through, reflections distort geometries, and standard datasets completely lack labeled ground truth for transparency.

To solve this, we built a synthetic benchmark dataset tailored specifically for training and evaluating vision models on transparent materials.

🛑 Why Traditional CV Pipelines Break on Glass

Depth Sensors Fail: ToF (Time-of-Flight) and active stereo depth sensors pass through or scatter when hitting optical-grade glass.
Refraction & Reflection: Standard RGB feature extractors detect background features behind the glass or virtual highlights on the surface—leading to incorrect bounding boxes and false segmentations.
Lack of Ground Truth Data: Capturing real-world paired RGB-D images of transparent objects with pixel-accurate normal maps and segmentation masks is near impossible manually.

🎬 Synthetic Data Generation Benchmark (Demo)

Watch our synthetic pipeline render optical-grade reflections, precise refraction passes, and exact ground-truth depth maps in real-time:

📊 What's Inside the Benchmark Package

To help researchers and engineers train robust models, we synthesized a specialized 3D dataset focused entirely on glass physics and transparent geometries:

Clean Ground-Truth Annotations: Instant access to aligned RGB images, 2D Bounding Boxes (BBox), and precise Instance Segmentation masks.
Physics-Based Refraction: Varied Index of Refraction (IOR) materials—from glass bottles and windows to lab glassware.
Complex Lighting Environments: High dynamic range (HDR) lighting variations to teach models edge detection under extreme specular reflections.
Ready for Model Training: Pre-formatted annotations for YOLO, SAM, and Depth Anything models.

📦 Get the Synthetic Glass Dataset Package

Ready to benchmark your depth estimation models or fine-tune your vision architecture for hard transparent objects?

👉 Download the Glass Benchmark Package on : package1
package2

Discussion

How are you currently handling transparent object segmentation in your vision pipeline? Are you relying on multi-modal sensors, or fine-tuning vision foundation models? Let's discuss in the comments below!

Sythetic data generation

Thu, 24 Sep 2026 15:55:40 +0000

Synthetic data often fails in production because domain gaps

— especially with transparent objects!
I am developing a solution focused on High-Fidelity Validation Assets. By moving beyond "pretty" images to industrial-grade evaluation, we can stress-test models against complex refractions and dynamic lighting while maintaining 100% geometric truth.

Github-link: https://github.com/ForgeCore-Labs/Synthetic-Glass-Transparent-Packaging-Indoor-Pack

FC-babylon-pathtracer — an open-source progressive path tracer built for Babylon.js!

Thu, 24 Sep 2026 04:13:48 +0000

Excited to share FC-babylon-pathtracer — an open-source progressive path tracer built for Babylon.js!
The core focus here is interactive viewport quality: it includes a zero-readback GPU a-trous denoiser that reads first-hit AOVs (Albedo, Normals, Depth) to clean up noise instantly without killing performance.
Highlights: • GPU A-Trous Denoising (edge-aware filtering) • Web Worker BVH construction (SAH Quality) • Live material parameter updates without shader re-compilation • Support for PBRMaterials, StandardMaterials, and environment maps
Quick Start: You can pull it straight into your local Babylon.js setup before the official npm publish:
npm install @babylonjs/core
npm install /path/to/babylon-pathtracer

Git:https://lnkd.in/ghxuyue6