Three.js: GPGPU birds were not able to fly, after r76.

[cx20]

Description of the problem

GPGPU birds were not able to fly, after r76.
...

Three.js version

• [X] Dev
• [X] r76

• [ ] ...

  Browser

• [ ] All of them

• [X] Chrome
• [X] Firefox
• [X] Internet Explorer

• [X] Edge

  OS

• [ ] All of them

• [X] Windows
• [ ] Linux
• [ ] Android
• [ ] IOS
  

  Hardware Requirements (graphics card, VR Device, ...)

PC1) ThinkPad X201 + Win10 + Intel(R) HD Graphics
PC2) Desktop + Win7 + Intel(R) HD Graphics 3000

• r76
  https://cdn.rawgit.com/mrdoob/three.js/r76/examples/webgl_gpgpu_birds.html
  
• r75
  https://cdn.rawgit.com/mrdoob/three.js/r75/examples/webgl_gpgpu_birds.html
  

[mrdoob]

Hmm, they do work here... Intel HD Graphics 6000 (OSX)

[antont]

Here not, with Intel HD 4000 on Win 10.

Is like with OP for me too: works in r75, not in r76. My favourite example too!

[Mugen87]

I've tested with Chrome 50, Firefox 46.0.1 and Safari 9.1 on OSX 10.10.5 and a AMD Radeon R9 M295X . Everything works fine. But on my Windows 10 VM and Chrome, i have the same behavior like @antont and @cx20.

Maybe the changes in this PR #8415 cause the problems...

[antont]

reverting #8415 did not fix it for me.

https://github.com/mrdoob/three.js/compare/dev...antont:revert8415?expand=1 is where i reverted the two commits of the PR. both reverts had conflicts and the dev version used the i guess new gl.* thing so i just deleted that part to get rid of a runtime error with the if - AFAIK does not affect what happens.

i pushed that branch to http://antont.github.io/three.js/examples/webgl_gpgpu_birds.html

made a mistake first when tested, it didn't work locally but worked from gh-pages, but that was just due to cache or gh-pages not having been updated yet. now gh-pages is up-to-date and consistently broken.

gtg now so can't doublecheck if the reverts & solving the conflicts went right but i think so.

[SuberFu]

Seems to be a Windows issue (maybe something with the ANGLE implementation of webgl?).
It doesn't work on my window machine, but works in OSX.
Perhaps the changes used something that's not available in ANGLE?

[Mugen87]

I also have the problem with Ubuntu 15.10 and Chromium 49.0.2623.108. Doesn't seem to be Windows exclusive...

[Mugen87]

/ping @tschw @bhouston for opinion

We had some changes to WebGLRenderTarget in R76. Do you think these changes could affect SimulationRenderer and the way it evaluates data from DataTexture?

[tschw]

Where it worked, did by coincidence: The vertex shader of the geometry had incomplete uniforms.

[Mugen87]

@tschw Hey, thanks for the fix! Can you explain why the implementation suddenly needs this enhancement?

[tschw]

@Mugen87

Can you explain why the implementation suddenly needs this enhancement?

...and I was hoping I could spare you my usually unpopular opinion :laughing:

It might have been missing all along.

The currentPosition and currentVelocityproperties were exposed from SimulationRenderer, so it was either just simply forgotten to ever wire them up, or the code that did so got sliced away at some point.

It worked because of another apparently open (didn't we fix that?!) bug: A samplerUniform.value === null should probably just give you an empty texture, not random results based on previous rendering.

So there is no enhancement. Instead, I fixed a bug previously hidden by another one. That other bug still exists, but its effect changed. Internal changes of the renderer affecting the allocation order of texture uniforms let the ticking time bomb encoded in the example go off.

[mrdoob]

@cx20 do you mind verifying that this is now fixed in dev?

[cx20]

@mrdoob
I confirmed fixed in the following environment.

PC1) ThinkPad X201 + Win10 + Intel(R) HD Graphics
PC2) Desktop + Win7 + Intel(R) HD Graphics 3000

• 77dev

https://cdn.rawgit.com/mrdoob/three.js/dev/examples/webgl_gpgpu_birds.html

Thank you everyone!

[mrdoob]

Sweet! Thanks guys!

[WestLangley]

@tschw Nice. We were so confused about this one... : - )

[tschw]

Reading that SO post, seems the code was not so redundant, after all. Or actually was, but not on the basis of behavior one should rely upon.

What's the history of the samplerUniform.value === null issue that made it fail to fail? Is it a regression? I think we should ensure an empty texture is used in this case. As we can see here, it can hide programming/editing errors that then pop up out of nowhere at some later point in time.

[Mugen87]

@tschw Many thanks for your explanations 👍