No license? about openjscad.org

[MauricevanLeeuwen]

OpenJSCAD.org (and CoffeeScad) both use code from OpenJSCad. OpenJSCad uses code from CSG.js

[Spiritdude]

License is mostly MIT as indicated in the various .js files, and openscad.js is mostly GPL.

The first sentence on the README.md of OpenJSCAD says "OpenJSCAD.org is a more up-to-date OpenJsCAD frontend where you can edit .jscad files either locally or online via JS editor (built-in)."

[matthijskooijman]

What's still unclear to me is how openjscad.org relates to joostn's openjscad exactly? Are you including it? Copy it, regularly update the code and contribute changes back? Or did you fork it at the start and is development independent now (if the latter, the name openjscad.org is really confusing...).

[Spiritdude]

Development of OpenJsCad by Joost has discontinued AFIK, I continued and Joost allowed me to use his openjscad.org domain. The upgrade is indicated by naming it "OpenJSCAD" - in other words, I continued with his blessings and expanded the functionality. Recently I saw csg.js at OpenJsCad was expanded, likely will be incorporated into OpenJSCAD as well. I deliberately avoided to touch csg.js but extend higher level API and the GUI to make it more useable for people coming from OpenSCAD.

[matthijskooijman]

Cool, thanks for explaining. I guess I should be directing my feature requests here, then :-)

To prevent confusion, perhaps Joost should put up a notice at his pages. I'll open an issue to ask him :-)

[matthijskooijman]

Turns out that opensjcad is still under development, see the ticket referenced above. It would be good if you guys could work out some way to sync changes back and forward on a regular basis and document what project is responsible for what part.

[joostn]

Well I've not strictly discontinued development, I'm occasionally pushing new features (such as the Bezier curves) as I need them for my personal use. And I've included pull requests from others. But I don't have the time or ambition to maintain the project in a more serious way. It's a bit unfortunate to have two forks of CSG.js and that's partly my own fault by just taking the easy route of pushing code to my own repository, but probably it should be relatively easy to merge the two versions again. Ideally there would be a separate repository for CSG.js and for the user interface. And personally I think the 'simple' OpenSCAD-like interface (union(a,b) etc) should be in a separate lib to avoid cluttering the global namespace, or is it already?
The good news is that Stefan ('bebbi') stepped in to help maintaining joostn/OpenJSCad. And of course I'd really love to see OpenJSCad being used more widely, as long as it doesn't cost me too much time..

[Spiritdude]

Hi Joost, nice to hear. I have also slowed down working on this project (OpenJSCAD.org github) as I saw no matter what, the CSG operations in csg.js remain slow, with little chance to improve speed significantly. Some discussion happened on email about GPU use to do CSG but it's just discussion without any code. As said, the csg.js has received little changes, as far I recall, the alpha (rgba) was integrated, as I thought other projects using csg.js would eventually improve CSG algorithms, and then I would adapt it. Yes, the OpenSCAD-like notions are NOT in csg.js but openscad.js where I tried to write all the new additions for people coming from OpenSCAD. Can you inform Stefan of this discussion here? Best I have a talk/email with him regarding OpenJsCad vs OpenJSCAD.org vs CSG.js (the github project). Like you, I have limited time for this project here, but like to avoid to stall it but continue with contributions of others, with little interference by me.

[bebbi]

I agree with UI and csg/processor split. I've had in mind to separate these more strictly in the joostn fork as I'm using the csg/processor part and need to integrate with a different UI. If that's in line with your efforts @Spiritdude I'll be happy to give it a shot, although I can't promise any timelines. I'd also like to have a closer look into your work on importing from .scad (maybe you've seen that I have added polyhedrons to openjscad which may be of benefit), and obviously if that's well separated that would really make things easy. Let me know your thoughts.

[joostn]

Regarding speed improvements: the only real opportunity I see would be to replace the kernel by one which supports curved surfaces (NURBS?). This would allow a sphere to be represented with a few surfaces instead of a thousand triangles. But this is not an area I have any expertise in.
I thought about using GPU as well but the CSG tree operations are not easy to parallelize, and only then there would be any benefit. Using asm.js might be another opportunity although it seems this would only give a 2x or so (?) speedup.
But hey, even at the current speed I think it's usable for many things!

[matthijskooijman]

Any idea on a way forward here? I'd like to contribute some improvements to handling of 2D files, but right now I'm not sure what to use as a base...

Wouldn't it be an idea to move towards a single repo with commit access for all interested (possibly under an "OpenJSCad" github organisation)? Then everyone can focus on whatever they're most interested in, while keeping all changes together.

I'm just an interested bystander and I can't actually make any of this happen, but I'd very much like to see development continue :-)

[bebbi]

First of all, welcome to this project, and I think everyone involved in this discussion here is happy if you plan on contributing something. So from a vision perspective, it doesn't matter.
The merge of the two repos is a reasonable idea, but work is required before this can be achieved, so you'll have to make a choice for now.
In terms of csg.js which is the core, I've compared both instances and the rundown is: they have run out of sync, but not much.
The joostn version has seen speed optimizations, and new functionality like: bezier paths, laser corner cuts, polyhedron, pie sectors, getFeatures. The spiritdude version has less changes, mostly on AMF file support, and the changes tend to be well-isolated blobs that can be merged.
Therefore, from a practical standpoint and unless there is disagreement, my suggestion is that csg stuff goes into a joostn fork for now, and the spiritdude version gets sync'ed from there.
What do you all think?

[Spiritdude]

@bebbi agreed, if there are more changes in @joostn version, then let's merge changes to his version, and then put it back here. I'm very occupied this week with off-line matters, so I won't be able to assist right now. Check the rgba support which came into openjscad.org's csg.js also.
Regarding common repo, I'm not very experienced with all the git/github functionality to comment on it, my concern is that existing .jscad remain functional and do not break (backward funtionality) and the wiki of openjscad.org stays in sync with the growing functionality - it makes no sense to improve csg.js or other parts of openjscad.org and not document it.

[bebbi]

OK, I can do the task of going through all the diffs and merge and post a status when done.
When I’m done and everything works, would you agree to pull in the csg directly from joostn?

On 24 Nov 2014, at 19:17, Rene K. Mueller [email protected] wrote:

@bebbi agreed, if there are more changes in @joostn version, then let's merge changes to his version, and then put it back here. I'm very occupied this week with off-line matters, so I won't be able to assist right now. Check the rgba support which came into openjscad.org's csg.js also.
Regarding common repo, I'm not very experienced with all the git/github functionality to comment on it, my concern is that existing .jscad remain functional and do not break (backward funtionality) and the wiki of openjscad.org stays in sync with the growing functionality - it makes no sense to improve csg.js or other parts of openjscad.org and not document it.

—
Reply to this email directly or view it on GitHub.

[richievos]

@Spiritdude any chance you could formally document this by putting a LICENSE file in the distribution?

[richievos]

Also, clarifying, I looked at OpenJsCad and CSG which both say MIT. So I think "openscad.js is mostly GPL" is incorrect.

[Spiritdude]

openscad.js is what I wrote mostly, that is mostly GPL. Please read my comments carefully, openscad.js is not openjscad.js (these are different filenames). I just wrote a LICENSE, which says say "please refere the individual files with their individual licenses" - this is why I said already that one has to check each file in the distribution individually because so many people worked on it, there the licenses are mentioned, again, for each .js - 80% of the code is MIT, 20% is GPL (openscad.js that is mostly).

[matthijskooijman]

Hm, any reason to use GPL for openscad.js, instead of just sticking to MIT like the rest of the code uses? It seems this is is a bit of an arbitrary distinction that can make things more confusing and harder to use?

[Spiritdude]

@bebbi and @z3dev you might talk to each other, @bebbi is or was about to include OpenJsCad's csg.js changes (speed improvements on CSG?) to OpenJSCAD.org's csg.js, and perhaps (not sure) affects openjscad.js as well? @z3dev just did a pull request on improvements on openjscad.js core, and before I accept it I want to make sure it's won't cross @bebbi 's efforts.

[Spiritdude]

@matthijskooijman I gonna change openscad.js to MIT license, I did first choose GPL as I wanted to make sure bug fixes come back to me. The other parts are mostly MIT, but one has to check all files, in particular in openscad-translator is a lot of code from third parties, all those need to be regarded.

[z3dev]

No problem. I'll wait for @bebbi to complete the integration of the branches for csg.js. @Spiritdude can then fold any changes into openjscad.js, and possibly openscad.js.

I'll wait for the new version of OpenJSCAD.org, and re-test changes that I made.

[z3dev]

I took a quick overview of the work being done to OpenJsCad. There's a lot of refactoring happening to the underlying libraries. All good.
But I just wanted to say that the libraries (all of them) should be maintained, tested, and documented separately. That will allow others to make changes rapidly. There's a lot of interest in these libraries, and there are far more intelligent people than myself. Easy evolution and innovation is key.

[bebbi]

The current situation is that joosts openjscad and Renes openjscad.org codebase have diverged for historical reasons.
I’ve joined the joostn fork a while ago, not aware of the Rene fork. I’ve since sticked to it, mainly for laziness and for its lean codebase suited to my needs.
Joost has focused on different priorities, and I have helped step in on contributions on his repo. At this time, Rene is also not focusing too much on the project.
We’ve previously agreed to get at least csg.js back in sync, and with the exception of very minor todos this is complete.
But still, the very similar project names and codebase makes the situation confusing to contributors, which is a pity.

Given that, I would favor merging the two projects back into a single one. This would require agreement on Joosts and Renes end, and a bit of work. Here’s a quick analysis of what might be required for this:

Project differences:
Joost fork:

• faster csg
• better rendering (touch, non-webgl, transparency, etc.)
  Renee fork:
• CLI
• scad support
• import models from external web pages
• UI stuff
  —> did I miss anything?

Requirements for merging:

• joost fork csg.js and openjscad.js can be extended fit to serve Rene fork with reasonable effort.
  Then, to get high maintainability going forward, I would suggest a few changes:
• scad support: probably needs some changes. I’ve just had a brief look - openscad.js (no j) currently exposes some high-level .scad functions using low-level csg.js plumbing - it should be refactored as a simple translation layer that accesses high-level jscad functions in csg.js. Also, there appear to be some redundancies between openscad.js and the openscad-openjscad-translator - some more info would help there. Also, latter project has a github page that says it’s obsolete.
• external model import - can it do without the perl script?
• UI stuff - may benefit from better separation of UI and processing in both joost and Rene forks, to allow use as a webpage vs library with custom UI
  —> does this sound reasonable? things missing?

Way forward - here’s an idea that doesn't require all work be done at once

1. put a proper github org around both repos.
2. make joostn csg.js the default for both projects (almost done)
3. make joostn openjscad.js the default for both projects (reasonable complexity level)
   —> link joostn csg.js/openjscad.js in openjscad.org, so developers get a single point for changes
4. start adding Rene features into joostn repo one by one, considering the merging requirements
   Add tests etc.
5. when it’s mature enough, merge both projects into one and expose this on openjscad.org

I have almost completed 2., but I’d certainly be more motivated if there’s hope for a unified codebase.
Please add your thoughts & experiences.

[matthijskooijman]

Thanks for your work on this, I really think things will be better off once both codebases are merged.

One small remark regarding structure (that might be slightly off-topic for this discussion, though it can also be something to take into account). You're talking about the OpenSCAD compatibility layer in openscad.org. I'm wondering if it really makes sense to look at it like that. AFAIK a lot of the stuff in there, is just useful and improved API. For example, it has support for text rendering, it has some global union/intersect/etc. functions, etc. that are useful even when you're not trying to convert from OpenSCAD.

So perhaps it would be useful to move over stuff from openscad.js to openjscad.js that adds new features / is generally useful, and leave only things like small wrappers for when function names or parameter names are slightly different between openjscad and OpenSCAD? This is probably something that falls under point 4 in your proposal.

[z3dev]

Many thanks @bebbi
The plan looks fine. I just have one comment about step #2. I suggest moving csg.js to a separate repository. That will allow CSG to live and evolve separately from OpenJSCAD / CoffeeSCAD / OpenJsCAD / etc.
And of course, allow others to contribute changes and documentation.
Finally, create a release of CSG.js once testing completes.

[Spiritdude]

Ok, here it goes, the main difference between OpenJSCAD.org vs OpenJsCad by @joostn

• csg.js: little changes from original, mainly transparency added, and solidFromSlices(), few bug fixes
• openjscad.js: some changes, mainly include() to work, some stream-lining *)
• openscad.js: completely new, OpenSCAD-like JS layer, plus some import of data formats
• index.html: new, mainly giving full browser 3d view UI
• OpenSCAD converter: contributed by @garyhodgson (self-contained code with its own github repository), yet relies on csg.js

*) I would recommend to cleanup the entire web-worker approach, I consider it very cumbersome to work with it, but I am not sure if alternatives are available. Lot of "double" code of debug vs non-debug execution.

It makes most sense to focus on csg.js and speed improvement of CSG operations, which I personally think is most important. openjscad.js itself I am not sure about to centralize, let's see how it goes.

Just to rehash (so all here are having the back story): OpenJSCAD.org I continued from Joost's OpenJsCad, he actually owns the openjscad.org domain, hosted on my server now. Back then when I continued I did not expect Joost to pick up the work again, and I thought it would divert quite from where it was, so I did not formerly github fork his work, but started with his code in a new respository. Now, that Joost continued we kind of want to sync parts again, to avoid double work, so all involved benefit; that's what this "Issue 33" is mainly about now.

@bebbi suggested as first step to bring OpenJsCad csg.js and OpenJSCAD.org's csg.js in sync as first step, and @z3dev eager to make changes/improvements in openjscad.js

[joostn]

The plan looks good to me. If you ask me the most important goal for now should be to be able to have a single .jscad syntax instead of two slightly different ones.

Just to comment on Rene: the web worker approach is the only solution to have a non-blocking user interface during rendering. Without the web worker, during rendering scroll bars stop responding and it becomes impossible to abort a rendering (because the Abort button will be unresponsive). Also some browsers will popup a warning after a couple of seconds. At the very least it looks ugly.

I'm aware of the drawbacks though, in particular importing of external scripts/libraries becomes very tricky.

[joostn]

And Stefan thanks for your work so far! I hope to contribute some things in the future.

[z3dev]

@bebbi suggested as first step to bring OpenJsCad csg.js and OpenJSCAD.org's csg.js in sync as first step, and @z3dev eager to make changes/improvements in openjscad.js

How goes the synchronization? Is CSG.js ready for some testing?

[bebbi]

Yes, joostn csg.js should now be feature equal to the csg.js here. Some open questions which I've just opened an issue for are here: #74
Please feel free to replace it inside your spiritdude/openjscad code and let us know how it works.

[z3dev]

Issues with the licenses have been addressed. OpenJSCAD.org is now MIT. Information on CSG.js and formats.js license and maintenance has been added to the documentation.

Closing this issue. Any new issues can be opened in another thread.