What causes "Attempt to use color attachment as depth/stencil!" in FyroxEngine/Fyrox?

Create the depth texture with a depth or depth/stencil pixel kind (e.g. D32, D24S8) and pass that as depth_attachment

Attempt to use color attachment as depth/stencil!

Error message

Attempt to use color attachment as depth/stencil!

What it means

When creating a framebuffer in the OpenGL backend, the depth/stencil attachment slot was given a texture that is a color attachment. Only depth or depth/stencil textures can be bound to the DEPTH_STENCIL/DEPTH attachment point, so the library panics to prevent an invalid GL framebuffer.

Solutions

Create the depth texture with a depth or depth/stencil pixel kind (e.g. D32, D24S8) and pass that as depth_attachment
Pass None for depth_attachment if no depth testing is needed
Check texture.kind() / AttachmentKind before constructing the framebuffer and fail fast with a clear message

Example fix

// before
let color = RenderTarget::texture(Texture::new(ctx, TextureDescriptor { kind: TextureKind::D2{..}, pixel_kind: PixelKind::RGBA8, ..}));
let fb = FrameBuffer::new(ctx, Some(&color), Some(&color));
// after
let depth = Texture::new(ctx, TextureDescriptor { pixel_kind: PixelKind::D24S8, .. });
let fb = FrameBuffer::new(ctx, Some(&color), Some(&depth));

Defensive patterns

Strategy: validation

Validate before calling

assert!(matches!(depth_tex.pixel_kind(), PixelKind::D32 | PixelKind::D24 | PixelKind::D24S8), "depth attachment must be a depth/stencil texture");

Type guard

fn is_depth_attachment(a: &Attachment) -> bool { !matches!(a.kind, AttachmentKind::Color) }

Prevention

Always create depth textures with D32/D24S8 pixel kinds
Never reuse a color target texture as depth attachment
Wrap framebuffer creation in a helper that validates attachment kinds

When it happens

Trigger: Calling FrameBuffer::new (fyrox-graphics-gl) passing a texture created with a color pixel kind/format as the depth_attachment while supplying another (or no) color attachment.

Common situations: Building a render target manually and reusing a color texture (e.g. RGBA8) as the depth buffer; forgetting to create a separate DEPTH32F/D24S8 texture for the depth slot; copy-pasted framebuffer setup code from a color-target example.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of FyroxEngine/Fyrox@76c91aad8e (2026-09-10). Data as JSON: /api/errors/e1f25830440a90a6. Report an issue: GitHub.

Appendix: source

Thrown at fyrox-graphics-gl/src/framebuffer.rs:112

        }
    }
}

impl GlFrameBuffer {
    pub fn new(
        server: &GlGraphicsServer,
        depth_attachment: Option<Attachment>,
        color_attachments: Vec<Attachment>,
    ) -> Result<Self, FrameworkError> {
        unsafe {
            let fbo = server.gl.create_framebuffer()?;

            server.set_framebuffer(FrameBufferBindingPoint::ReadWrite, Some(fbo));

            if let Some(depth_attachment) = depth_attachment.as_ref() {
                let depth_attachment_kind = match depth_attachment.kind {
                    AttachmentKind::Color => {
                        panic!("Attempt to use color attachment as depth/stencil!")
                    }
                    AttachmentKind::DepthStencil => glow::DEPTH_STENCIL_ATTACHMENT,
                    AttachmentKind::Depth => glow::DEPTH_ATTACHMENT,
                };
                let texture = depth_attachment
                    .texture
                    .as_any()
                    .downcast_ref::<GlTexture>()
                    .unwrap();
                set_attachment(
                    server,
                    depth_attachment_kind,
                    texture,
                    depth_attachment.level() as i32,
                    depth_attachment.cube_map_face(),
                );
            }

View on GitHub (pinned to 76c91aad8e)