[Bug] Actors with opacity < 1 ignore renderer viewport; picking also breaks (v34.11.1)

[cimpermanzan]

Bug description

Summary

After upgrading vtk.js from 30.2.0 to 34.11.1, semi transparent actors render outside their assigned renderer viewport when using multiple non-overlapping renderers in a single vtkRenderWindow. Actor appers to be scalled to "fullscreen". In the same setup, picking stops working when any object in the scene is non-opaque.

This regression was not present in 30.2.0 (behavior was correct there).

Actual behavior

Actors with Opacity < 1 appear to ignore the viewport and render as if they were in a full-window context.

On render, translucent actors can appear at positions outside their renderer’s viewport.

Picking fails if any object in the scene isn’t fully opaque.

Steps to reproduce

Steps to reproduce

1. Create two vtkRenderers with distinct, non-overlapping setViewport settings in a single vtkRenderWindow.

2. Add at least one actor with Property.setOpacity(< 1) to one renderer.

3. Call renderWindow.render().

4. Observe the translucent actor drawing outside its renderer’s viewport.

5. Attempt to pick either actor; observe misses or hits in the wrong viewport.

Image 1 both actors are opaque:

Image 2 one actor opacity set to 0.3:

Workarounds tried

Setting all actors to Opacity = 1.0 → viewport clipping and picking both work again.

Using a full-window renderer (viewport: 0, 1, 0, 1) → also works.

Detailed Behavior

No response

Expected Behavior

Each renderer’s content is clipped to its own viewport.
Picking returns the correct prop in the correct renderer, regardless of actor opacity.

Environment

• vtk.js version: 34.11.1
• Browsers: Chrome 139.0.7258.155
• OS: macOS 15.6

[finetjul]

Can you please identify what precise commit broke the behavior ? That would be very helpful to know what could be the cause of it.

[cimpermanzan]

Hi @finetjul, thanks for the suggestion. I haven’t yet done a commit-level investigation to pinpoint where the regression was introduced. At this stage I only confirmed the issue appears in 34.11.1 and does not in 30.2.0.

I’ll try to narrow it down further when I have time.