Agapenordev 098602ec49 Never crash importing meshes with many materials ...

Every texture set (one per mesh material) allocated full-size display
textures (base color, emissive, ORM, normal, height, aux, with mips) as
soon as it was created: ~130 MB of GPU memory per set at the default
2048 import size. A 16-material OBJ ran a 4 GB laptop GPU out of memory
and wgpu's default error handler panicked, closing the app.

- Display and aux textures start as 1×1 neutral placeholders and get
  their full size with the first non-neutral tile (or aux image), so an
  import costs no GPU memory until its sets are painted.
- That allocation runs in an error scope: on failure the texture keeps
  its placeholder (no retry per tile), the failure is logged and the UI
  shows a toast naming the texture set and the Viewport ▸ Texture
  resolution setting. Painting and export are unaffected.
- The app installs an uncaptured-error handler that logs and reports
  wgpu errors as toasts instead of panicking.
- The GPU path tracer takes each set's size from its largest texture,
  since any kind (base color included) may now be a placeholder.

Tests: 40 sets of 2048 allocate nothing until painted, one painted kind
allocates alone, the aux texture allocates on its first upload, painted
placeholders render, and the GPU tracer matches the CPU with a default
base color beside varying roughness (fails with the old size logic).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-01 21:05:50 +01:00

..

headless.rs

Never crash importing meshes with many materials

2026-11-01 21:05:50 +01:00