bevyengine / bevyengine/bevy

Crash on macOS, related to ExtendedMaterial and custom vertex buffer layout

Open
#16,588 7 comments 1 reaction 0 assignees View on GitHub
A-Rendering C-Bug O-iOS O-MacOS S-Needs-Investigation
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 16h
Merged PRs (30d)
171

Description

## Bevy version

0.15

## \[Optional\] Relevant system information

Rust version: 1.83

```
SystemInfo { os: "MacOS 15.1.1 ", kernel: "24.1.0", cpu: "Apple M1 Max", core_count: "10", memory: "64.0 GiB" }
```
```
AdapterInfo { name: "Apple M1 Max", vendor: 0, device: 0, device_type: IntegratedGpu, driver: "", driver_info: "", backend: Metal }
```

## Problem

Since updating to Bevy 0.15, my plugin no longer runs on macOS. The plugin is using `ExtendedMaterial` with a custom shader and one extra vertex attribute.

The application crashes immediately on startup with the following error:
```
thread 'Compute Task Pool (0)' panicked at /Users/joacim/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-23.0.1/src/backend/wgpu_core.rs:1102:18:
wgpu error: Validation Error

Caused by:
In Device::create_render_pipeline, label = 'pbr_prepass_pipeline'
Internal error in ShaderStages(VERTEX) shader: Metal: program_source:252:14: error: from vector 'metal::float3' (aka 'float3') to vector 'metal::float2' (aka 'float2') of different size
uv = metal::float2(unpackFloat32x3_(vb_15_elem.data[12], vb_15_elem.data[13], vb_15_elem.data[14], vb_15_elem.data[15], vb_15_elem.data[16], vb_15_elem.data[17], vb_15_elem.data[18], vb_15_elem.data[19], vb_15_elem.data[20], vb_15_elem.data[21], vb_15_elem.data[22], vb_15_elem.data[23]));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_render::render_resource::pipeline_cache::PipelineCache::process_pipeline_queue_system`!
thread '' panicked at /Users/joacim/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_render-0.15.0/src/render_resource/pipeline_cache.rs:546:28:
index out of bounds: the len is 0 but the index is 6
Encountered a panic in system `bevy_render::renderer::render_system`!
```
It looks like some UVs are being supplied to the shader as vec3 instead of vec2, and I can't figure out why. When the mesh is created, I'm only inserting `[f32; 2]` UV entries.

Other than that, I haven't been able to isolate the problem, but it goes away if I just remove the UV data from the mesh and buffer layout. Also, it seems to be related to `ExtendedMaterial`, because using a different material with the same meshes and layout works, so I think the issue is happening in the pbr pipeline.

It's possible that the error is somewhere in my code, but the fact that it only happens on macOS (with metal backend) causes me to suspect that it's an upstream issue. I was not able to reproduce the issue in Bevys extended_material example though, so it's likely being caused by some combination of things.

## Additional information

The issue can be reproduced by running the `noise_terrain` example (or any example except `custom_material`) in https://github.com/splashdust/bevy_voxel_world

The `custom_material` example does not use `ExtendedMaterial` and does not cause the error to happen.

Contributor guide

Open the contributing guide

Research direction

Reproduce the crash by running the noise_terrain example on macOS with the Metal backend, then compare it with the custom_material example and Bevy's extended_material example. Start at the pbr_prepass_pipeline and the custom vertex buffer layout described in the report. Done means the ExtendedMaterial examples with extra UV data run without the Metal shader validation panic.

Written by the indexing model from the issue text.

Assessment

Tech stack
macos, rust
Domain
computer-graphics, game-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.