'metaball' function

[gfwilliams]

I just added the metaball code as I'd described on jscad/OpenJSCAD.org#232 (with a few improvements)

Unfortunately I seem unable to build with npm run build even with unmodified code from the scad-api repo )(there's an error about CAG) so I haven't been able to test this - however the code itself works great when run in http://openjscad.org/ and I've done what I believe is needed to make it work with scad-api.

Hope that's some help!

[kaosat-dev]

Hello @gfwilliams sorry for the delay !
This is looking great, thanks a lot for the contribution !
I'll pull it locally and do a more in depth check tomorrow before merging.
What errors did you run into while trying to build btw , so I can try and fix those :)

[gfwilliams]

Great, thanks!

I just filed another issue for it so as not to complicate this one: #8

Looking at the logs I think it was just that my CSG version was old, but it'd be nice to have something in the docs about getting an up to date CSG, or to have something a bit newer in NPM

[kaosat-dev]

Thanks for the bug information @gfwilliams ! Will look into it.
You are right about CSG : to be honest we are still trying to find a good release circle to NPM , but I think it might be worth pushing a new version to NPM (even if it 'just' a patch or a minor one) every time we merge new PRs.

[kaosat-dev]

Hi @gfwilliams sorry for the delay !
Good new is : your metaballs work great , code is clean too!
Problem : we are not sure if it actually belongs here in jscad-api or elsewhere : the logic is this:

• scad-api is to provide a more functional, openscad-like api to csg.js & co
• csg.js is the 'core' of geometric utilities
• OpenJSCAD will evolve more towards being a UI

So I guess your work would fit into something like extra utilities ?
I really hope this does not come off as unpleasant or anything : we are more than willing to discuss what belongs where , while trying to keep repos specialized.
Heck I even created a specific org for any extras created by the community https://github.com/jscad-community .
What do you think ?

[gfwilliams]

Hey, no problem! Yes, it can be hard to keep things clean.

What'd be great from my point of view is an easy way to drag stuff like this into https://openjscad.org/ and encourage code re-use. What about a function that made the process of pulling in 3rd party plugins easier?

var metaball = require("github.com/gfwilliams/jscad-plugins/metaball.js");
// ...

It'd be basically an HTTP GET and an eval, but it'd make stuff like this a lot easier. For instance I was experimenting with a vase here:

https://openjscad.org/#https://gist.githubusercontent.com/gfwilliams/f59a072436968510652404f325229383/raw/dfd479a4ecdf6521d3edbd73210215988d9d3504/koch.jscad

If I could have easily stuck slice_extrude in its own repo I could have made sure that the code (and anything else I did in the same way) would use it.

edit: the separate org could be a nice way of keeping everything together - but it's more work for you guys to maintain. For the moment, anything that allowed me to share functions/plugins in an easily reusable way would be great.

I guess you could have a shorthand (require("metaball")) for anything that's in your plugin repository, that might encourage people to submit their code when they'd got something working?

[kaosat-dev]

thanks for understanding :)
that is a very good idea, and the direction we want to head in as well :)
funny you should mention the use of common.js require calls + http , because I have been experimenting with something similar , thanks to the recent work we did on the whole jscad ecosystem:
https://esnextb.in/?gist=0a2ac2c4e189e27692ea964956a3a2e5 (just hit execute)
it uses this : https://github.com/kaosat-dev/jscad-module-example & some of the newly extracted sub repos of OpenJscad

Your idea of putting slice_extrude in its own repo is a very good one is also why we started making some smaller parts of the jscad ecosystem available on npm : import what you need & no more (this was particularly important for the serializers/deserializers that can have larger dependencies)

The current include functionality is kind of a mess, and this could allow us to leverage existing tools (that work very well), and wether what you import are parts or functionality need not matter

Essentially using either the tooling provided by requirebin https://github.com/maxogden/requirebin
(this has the advantage of working both in browsers in a SAFE manner (no eval & issues of uncertain remote sources) and node.js, as that is a less limiting environment). Only one issue with this is that requirebin & co have a bug preventing to require from packages on github (so gists as well)
We could also emulate the way node modules are required() for a more limited but simpler browser use.

Also, cool vase :)

[kaosat-dev]

also perhaps this discussion actually belongs here ? jscad/OpenJSCAD.org#245

[gfwilliams]

Sure - will post there. Closing this PR then...

[kaosat-dev]

@gfwilliams you still have a copy of the code around? would be a shame to waste it

[gfwilliams]

Well, it won't disappear - the PR will still be around, just closed - and I have the repo I submitted from :)

[kaosat-dev]

@gfwilliams doh' :) never mind me, no sleep , too little coffee:)