Module wgpu 

A ready-to-use wgpu Backend implementation (backend::WGPUPlugin), plus a higher-level descriptor-based material/mesh/texture/compute layer built on top of it so apps never touch raw wgpu types directly.

Building something this layer doesn’t already cover (a camera, a custom compute buffer, anything constructed by hand inside a LazyResource/ Asset impl)? Start with prelude — use pebble::wgpu::prelude::*; — rather than reaching for a hand-written wgpu::*Descriptor: the binding and buffers modules it re-exports are all builders (BindGroupLayoutBuilder, BufferBuilder, BindGroupBuilder, …) producing opaque types (buffer::Buffer, textures::GPUTexture, samplers::Sampler, material::RenderPipeline, buffers::BindGroup, …) instead of raw wgpu ones — chained .method(...) calls that fold in bookkeeping (duplicate @binding(N) detection, dynamic-offset alignment) a hand-written descriptor won’t give you for free.

Pass and dispatch recording are opaque too: ActiveFrame::begin_pass hands back a render_pass::RenderPass (not a raw wgpu::RenderPass), and WGPUBackend::create_command_encoder/ CommandEncoder::compute_pass cover standalone compute dispatch the same way. WGPUBackend’s device/queue/surface fields are pub(crate) — every builder here takes &WGPUBackend directly instead — and even the value types (texture formats, shader stages, buffer/texture usage flags, blend and depth/stencil state, vertex formats) are mirrored as Pebble’s own types (texture_format::TextureFormat, flags::ShaderStages, …) rather than re-exporting wgpu’s. Nothing in this module’s public surface names a raw wgpu::* type.

Modules

animation

Plain CPU data for keyframe animation — no Asset/ Handle/GPU upload involved, same rationale as skeleton: sampling a clip is pure interpolation math, nothing GPU-specific about it.

backend

binding

Shared bind-group vocabulary for material and compute — a material’s own bind group and a compute pass’s own bind group are described the same way, differing only in which shader stage(s) can see each entry (a material entry can be FRAGMENT/VERTEX/VERTEX_FRAGMENT; a compute entry is always exactly COMPUTE). Every constructor below takes visibility explicitly rather than guessing a default per module — build_material/ build_compute validate it’s appropriate for the pipeline kind they’re building, panicking with a clear message otherwise.

buffer

buffers

Buffer and bind-group construction — three builders, one per thing being built:

compute

compute_pass

cubemap

cursor

Mirrors winit::window::CursorIcon and winit::window::CursorGrabMode exactly, so Window’s cursor methods never need a raw winit type. Convert into winit via .into().

flags

Hand-rolled bitflag mirrors for wgpu’s flag-style types — small enough (at most a couple dozen bits) that pulling in the bitflags crate isn’t worth it. Each mirrors its wgpu counterpart’s bit layout exactly, so converting into wgpu is just from_bits_truncate.

gltf_loader

One-shot glTF 2.0 loading — load_gltf parses geometry, a skeleton, and animation clips out of a .gltf/.glb file. Deliberately not part of the Asset/LazyResource pipeline: those retry forever on None, which is right for “the backend isn’t ready yet” but wrong for “this file doesn’t exist” or “this glTF feature isn’t supported” — conditions that can never resolve on their own. Call load_gltf directly (in main(), a .once() system, wherever you need it) and handle the Result like any other fallible I/O.

instance

keycode

Mirrors winit::keyboard::KeyCode (physical key codes) and winit::event::MouseButton exactly, so Input’s methods never need a raw winit type. Convert into winit via .into().

layout

material

mesh

mipmap

player

prelude

use pebble::wgpu::prelude::*; for everything needed to construct and render custom GPU resources against a WGPUBackend — a camera’s uniform buffer, a compute pass’s storage buffers, anything built by hand inside a startup system or Asset impl that isn’t already covered by Material/ Compute.

render_bundle

render_pass

samplers

skeleton

Plain CPU data for a joint hierarchy — no Asset/ Handle/GPU upload involved. A skeleton is pure computation (walking a joint hierarchy, multiplying matrices) right up until you write the result into a buffer of your own — see Skeleton::skinning_matrices.

skinned_mesh

skinning

texture_array

texture_format

Mirrors wgpu::TextureFormat exactly (every variant, including the nested Astc block/channel), so a texture’s format never needs a raw wgpu::TextureFormat — not even for exotic/compressed formats. Convert either direction via .into().

texture_view

textures

vertex_format

Mirrors wgpu::VertexFormat/VertexStepMode/VertexAttribute so a custom vertex struct’s layout (beyond the built-in Vertex/InstanceVertex) can be built with zero raw wgpu. Unlike wgpu::VertexBufferLayout (which borrows a 'static attribute slice), VertexBufferLayout owns its attributes — simpler to build, converted to wgpu’s borrowed shape internally by build_material in a scope that doesn’t need 'static.

window