This is the port of Keenan Crane "Developability of Triangle Meshes" https://www.cs.cmu.edu/~kmcrane/Projects/DiscreteDevelopable/ [www.cs.cmu.edu] to OpenCL SOP.
It's mostly based on Junichiro Horikawa video: https://www.youtube.com/watch?v=5jikaAnrOLo [www.youtube.com] which I've used as a baseline, because I'm very terrible with reading math notations. This one helped me a lot.

Anyways apparently this thing is quite easy to parallelize with graph coloring (same as vellum constraints solver).

Paper and video also discussed the optimization by dynamic resolution during solving. I haven't implemented that because this is not quite friendly for GPU and here iterations are cheap. Even at thousands iterations it's still reasonable.

This is not an hda, I don't want to deal with licensing difference. It's just a subnet that can be easily convert to hda on any license if needed. This implementation is free for use by anyone, for any purpose, without any attribution.

There are just two controls: Step and Iterations to adjust the result. It works only on triangle meshes.

I've also tried to used it personally for couple of stylized meshes for the game. Here is my take aways:
- It's very good for stylized relatively low-poly meshes. Here it's much better than mesh sharpen approach because it doesn't squish triangles
- Very dependent on topology, but Remesh SOP can help
- I couldn't come up with "universal" parameters, unfortunately I have to manually tweaking them for mesh, but it looks like the most significant feature is trinagles area
- Surprisingly it can help with lods. So the chain with high-poly -> developable mesh -> poly reduce in some cases can give a better mesh as it tends to simplify features but keeping the contour

==

I've also learned that @-bindings with OpenCL SOP are not working as intended inside compiled loop block. It basically transpiles on every iteration which hurts performance quite a lot. So that's why OpenCL wrangles here are not that readable, they are written with @-bindings and then manually expanded and saved inside code block.

So be aware that multi-step solvers with @-bindings are not possible right now (technically possible but performance is terrible)

(this was already reported as #143291)

Here is the illustration for poly reduce with developability combined.
It looks like it makes sense only for extreme reduction, like ~90% polycount. Probably flattening and strengthening hard edges also helps poly reduce to keep the original shape better as a side effect. UV distortion, topology and overall shape reading sometimes just feels better if you apply developability before.