Add JS bindings for CrossSection

[elalish]

There's also a few other APIs missing, like Split and Trim.

[elalish]

@geoffder Any interest in trying this one? I made it a lot easier to develop and test our WASM: https://github.com/elalish/manifold/tree/master/bindings/wasm#local-development - it would be awesome to use crossSection in manifoldCAD.org!

[geoffder]

I've been a bit busier lately, but I can add that to my manifold TODO slate. The spare time I've put into coding stuff lately has been spent tidying up the OManifold library a bit more (particularly the build) in preparation for finally releasing it on opam (ocaml package manager). Also been meaning to add MeshIO import to the C bindings.

Should have a bit more time to knock these things off soon.

[geoffder]

I guess the non-member functions like compose and differenceN, should be made polymorphic with a dynamic check that they are all the same type? That way current use of them wouldn't be broken by a renaming to make room for coexistence of Manifold and CrossSection (the bindings as they are currently were made without anything to clash with Manifold on these names of course).

[elalish]

That's a good point. Honestly, shouldn't they be static members of Manifold/CrossSection anyway? I suppose it would be a breaking change, but it seems like the right direction to go. Any thoughts @pca006132?

[geoffder]

Now that I think about it a bit more, the empty list case for the batch booleans would be a bit sketchy with the polymorphic route (could be an empty Manifold, empty CrossSection, or an exception).

[elalish]

Yeah, I'm realizing now that all the places we wrote things like Module.cube = function(...args), we should have been doing Module.Manifold.cube = function(...args) to create static members instead of functions on the module. Does that sound reasonable to you?

[geoffder]

Yea I think it's reasonable. Technically not required for constructors like cube, but it would clean up the global namespace (at the cost of the prefix making it wordier).

[geoffder]

Is there a particular reason why setMaterial is a toplevel function, rather than a method of Manifold?

Also, RE the show and debug visualizers, should they be made to accept CrossSection as well?

Something like:

function debug(shape: Manifold | CrossSection, map: Map<number, Mesh>) {
  const manifold = (shape instanceof module.CrossSection) ? shape.extrude(1) : shape;
  const result = manifold.asOriginal();
  map.set(result.originalID(), result.getMesh());
  return result;
};

[elalish]

Those are only added for our editor, not part of the manifold API, so let's not worry about them for now. If you think of a good way to visualize 2D stuff, great, but I'll probably punt on it.

[geoffder]

Right, that's why I thought simply extruding them to a thickness of 1 to show them like a manifold (how OpenSCAD shows 2d shapes in preview mode) might be good enough.

[elalish]

Not a bad idea; we can probably make the editor-specific functions polymorphic, but let's save that for a follow-on PR to simplify review.

[geoffder]

Ah well, I've already added the above, but it is just a single line slipped into debug, which is a drop in the ocean of this PR (so I'll leave it there for now).