Move 'transform-feedback' example out of WIP, fix errors

[donmccurdy]

Fixes the transform-feedback example. Some cleanup still needed. Like #1879, I'm relying on an extra buffer instead of reading/writing the same buffer, and I'm not sure how to avoid that yet. The 'swap' implementation is more verbose than in v8, I'll wait for other ideas on the API to fix that.

transform-feedback.mov

Related:

• [engine] Minimum Transform implementation #1879

[donmccurdy]

Marking as 'ready for review' just in a general aim to move more code out of WIP into a stable folder, but clearly there are some non-ideal things still in this PR:

• requires separate read/write buffers which could be consolidated
• buffer-swapping implementation is verbose
• final Transform API for v9 is still TBD

[ibgreen]

Thanks. This used to be part of the tutorials I think, but since TransformFeedback is webgl specific better to keep it in another section, maybe API, maybe webgl

This also affects the transform feedback tutorial page in the docs folder.

If you are interested in adding to the to the website, build the website (cd website; yarn; yarn start) and make sure it shows up in the right place and the tutorial pages work. That could be a separate PR of course.

[donmccurdy]

I've assumed we intend the Transform class to be platform-independent, and (aside from one bit of API leakage) the example doesn't touch TransformFeedback directly. Maybe it'd make sense to keep this in example/api, but rename it something that isn't WebGL-related, like transform/ or buffer-transitions/?

[ibgreen]

I've assumed we intend the Transform class to be platform-independent

That would be great, but I felt that first we have to create a computeShader variant for WebGPU and see how that looks. Until then it is hard to say how a portable API would look, or if making Transform portable truly makes sense.

Transform class accept code snippets I think, which might be very different.

Also computeShaders can e.g. do random access on memory through storage buffers which could lead to very different programming patterns from per-row attribute -> attribute processing.

[donmccurdy]

Hmmm good points. So for v9.0 I'm looking at splitting BufferTransform / TextureTransform as two (immediately deprecated) classes we'd replace in v9.1. Given that they're temporary, and only nominally WebGL-agnostic... maybe we'll put this in a webgl folder but keep it out of the website for now?

[ibgreen]

as two (immediately deprecated) classes we'd replace in v9.1.

Well, we can always "un-deprecate" them in 9.1, should they grow on us.

It is just one of our mechanisms for signaling that we are not sure. We can also export with leading underscores etc.

[ibgreen]

maybe we'll put this in a webgl folder but keep it out of the website for now?

That is reasonable.

[donmccurdy]

Current dependencies on/for this PR:

• master
  • PR fix(shadertools): Explicit GLSL version and language #1904
    • PR feat(engine): Transform → BufferTransform + TextureTransform #1896
      • PR Move 'transform-feedback' example out of WIP, fix errors #1883 👈

This stack of pull requests is managed by Graphite.