GTAOPass error: Texture dimensions must all be greater than zero

Questions
,
1

I’ve got a scene that renders fine like this:

// ...

const composer = new EffectComposer(renderer)
const renderPass = new RenderPass(scene, viewCamera)
const outputPass = new OutputPass()
const passes = [renderPass, outputPass]
for (const pass of passes) composer.addPass(pass)

requestAnimationFrame(function loop() {
  composer.render() // works perfectly
  requestAnimationFrame(loop)
})

There are no effect yet. Then when I try to add GTAOPass it breaks:

// ...

const composer = new EffectComposer(renderer)
const renderPass = new RenderPass(scene, viewCamera)
const gtaoPass = new GTAOPass(scene, viewCamera, width, height) // ADDED
const outputPass = new OutputPass()
const passes = [renderPass, gtaoPass, outputPass] // UPDATED
for (const pass of passes) composer.addPass(pass)

const aoBox = new Box3().setFromObject(scene) // ADDED
gtaoPass.setSceneClipBox(aoBox) // ADDED

requestAnimationFrame(function loop() {
  aoBox.setFromObject(scene) // ADDED
  gtaoPass.setSceneClipBox(aoBox) // ADDED
  composer.render() // it breaks, with warnings in console
  requestAnimationFrame(loop)
})

And after this seemingly simple update, the scene shows nothing/empty, and I see these warnings in console:

255 [.WebGL-0x1c4411daaa00] GL_INVALID_VALUE: Texture dimensions must all be greater than zero.
WebGL: too many errors, no more errors will be reported to the console for this context.

Screenshot From 2025-04-28 15-24-58
Screenshot From 2025-04-28 15-24-581664×152 33.5 KB

What am I missing?

(Note, in the first example, replacing composer.render() with renderer.render(scene, viewCamera) works perfectly, the scene is working great up until the point where I add GTAOPass)

2

How are width and height defined? Have you tried to console log the individual params of GTAOPass before the pass is created? You could also try adapting the GTAOPass and GTAOPass examples to compare differences between your current setup, It’s great to see GTAO becoming integrated!

7

Here’s an example that works with GlitchPass on r176:

https://codepen.io/trusktr/pen/zxxEava

Here’s an identical example with GlitchPass replaced with SSAOPass, not working, with the same warnings as above:

https://codepen.io/trusktr/pen/wBBrXWW

8

I stepped through your codepen in the chrome debugger:

In your resize:

  pass.setSize(window.innerWidth * renderer.pixelRatio, window.innerHeight * renderer.pixelRatio);

renderer.pixelRatio is undefined.

However renderer.getPixelRatio() returns a valid value.

Switching them fixed the issue.

2 Likes
9

The f***. That’s irritating as h***!!

F****n type definitions:

10

@Mugen87 I see the new JSDoc comments in Three.js source have type definitions.

Will these be officially exposed from three instead of having to use @types/three?

I spent hours looking in the wrong places because I thought WebGLRenderer.pixelRatio was an actual property.

11

Yeah It was a surprise to me. I could have sworn it was just available on the renderer as well. Maybe the behavior has changed, or maybe the resize observer kicks in before the library has fully initialized or something. Could be a recent change as well. I didn’t bother to check if it magically appears later in the lifecycle.. but who knows.
rare ts L.
common debugger W.

1 Like
12

The setPixelRatio and getPixelRatio methods write and read a private local variable since a decade ago:

And before that it was a .devicePixelRatio property and not .pixelRatio (as seen that diff).

And here’s what the code looked like a day after that commit in DefinitelyTyped was published, there is clearly no .pixelRatio property:

Ugh. I cannot believe I spent so much time because of a fake non-existent property from @types/three.

How could no one notice until now too?

1 Like
13

I feel your pain. Muy frustrado.