ParametricGeometry: Added serialization/deserialization support.

[Mugen87]

Fixed #17381

The assumption of this PR is that ParametricBufferGeometry.func is a self-contained function (like the ones from THREE.ParametricGeometries).

[mrdoob]

Sweet! Thanks!

[mrdoob]

Although... Lets be aware that, if I'm not mistaken, this allows people to add evil scripts inside serialised scenes 🤔

[Mugen87]

Although... Lets be aware that, if I'm not mistaken, this allows people to add evil scripts inside serialised scenes

It's seems hard to evaluate if parametric function code is evil or not. I think I would defer this security issue to the application. If a hacker is able to manipulate a serialised scene, he can also do a lot of other funny stuff^^.

[mrdoob]

But, imagine that I create a cool 3d model and then I add a parametric function in it that downloads access the internet and starts mining. Then I serialise it / export it to json and share it with people. Any end-user displaying that model will end up doing some bitcoin mining.

[Mugen87]

I see, I see^^. Then let's revert the change since I can't think of an easy way to make the PR more safe.

[peteroupc]

Parametric curves and surfaces ought to be expressed in a grammar that supports only basic operations and math functions (such as sin and ln), not in a general-purpose programming language like JavaScript. A hypothetical example is the following JSON:

 { "x":"sin(u)*cos(v)", "y":"sin(u)*sin(v)", "z":"cos(v)" }

Such a grammar reduces the risks involved in arbitrary code execution because it doesn't support access to network resources, clocks, threads, etc., and neither does it support control flow statements such as loops.

However, I'm not aware of any data formats that support storing parametric curves or surfaces in a limited math grammar like this.

A while back, I wrote a script that compiles a grammar like this into an expression tree that can later be evaluated to support parametric curves and surfaces (example). This script and example are just for your information only, to show the effort involved.

[Mugen87]

@peteroupc Right now, I don't think we want to add this complexity to ParametricGeometry. A workaround could be the serialization/deserialization of the pure geometry data, without parameters. The geometry could be restored in this way, however not the original parameterization (meaning the parametric function).

[mrdoob]

@peteroupc That's interesting. 1300 LOC feels a bit too much though...