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:

1. Position: The 3D spatial coordinates [x, y, z].

2. Texture Coordinates (UV): Mappings used to align 2D textures onto 3D surfaces.

3. 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

1. Load Assets: Read the .obj file into a Mesh struct and compile the WGSL shader code using device.create_shader_module().

2. 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.

3. 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.

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     |
  +----------------------------------------------+

1. 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 
|  [ Queue ]<---> Command channel to physical hardware|
|  [ Config ]<--->  Surface settings|
|  [ 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!!!):

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

1. Depth Sensors Fail: ToF (Time-of-Flight) and active stereo depth sensors pass through or scatter when hitting optical-grade glass.

2. 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.

3. 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:
%[https://www.youtube.com/watch?v=aKlNZl4Qsro\]

📊 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 ready for YOLO, SAM, and object detection pipelines.

📦 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!