As the Google Summer of Code 2014 - where OpenSCAD had the chance to participate in collaboration with BRL-CAD - now almost comes to an end, here’s a nice blog post about what’s been done: GSOC project – UI brushup of OpenSCAD – Shaina Sabarwal
The main topic was to freshen up the GUI a bit to make it more user friendly. The biggest changes are
Integrating a new editor component which brings things like line numbers, auto-indent, error markers and allows further improvements like auto-complete or code folds.
Adding toolbars so most used actions are easily accessible by mouse
New welcome screen to give some guidance how to get started
Right now the remaining work is to get the changes integrated nicely and check that everything works on all supported platforms. Dev-Snapshot binaries including those changes will hopefully be available soon.
Comments and feedback are very much appreciated, here, on the OpenSCAD mailing list or via IRC ( openscad at freenode).
I actually don’t care about the gui. Much, if at all. It needs a better renderer, and better debug support (like more information on a compile error). It needs a better language, like object oriented. It needs better variable handling. There are so many things on the backend that don’t make sense, that the gui is inconsequential. In fact, the editor could be removed from openscad and I wouldn’t complain.
Ah, yes, there’s much room for improvement. GSoC tries to bring students into the open source community, which is great. There were a number of topics offered and the selected one was the GUI topic.
OpenSCAD is open source so things get done when people get motivated to work on it and spend time to help (which does not just mean writing code, but also testing, discussions, documentation). An additional result of the GSoC project is that it did improve communication across different open source CAD projects, namely BRL-CAD as umbrella org for the project and LibreCAD.
I don’t agree with the need for a completely different language. The actual engine should probably be changed to use something existing and there are quite some areas where more powerful features would help a lot (like the new list comprehension functionality in the dev snapshots: https://gist.github.com/kintel/4645e2c91eb02e577688).
All that changes should not fail to retain the simplicity for simple things (e.g. http://rosettacode.org/wiki/Death_Star#Openscad).
Specific feature requests are best placed as issue in github. Wishes can only be granted when put on the wishlist :).
I mostly agree with Stephanie. I use openscad as a viewer and edit in my favorite editor. Useful features for me would be multi-material support and AMF output. Maybe it needs a different language, I’m not sure on that.
If it gets more people involved with OpenScad, and leads to more advanced improvements, then that would be good
Logically it should be object oriented. It uses solids, actually objects, then apply modifiers to them. That is what object oriented languages were created for. Imagine for a moment: mybox = box(x, y, z) ; mysphere = sphere( radius) ; mybox.translate(x=sphere.radius);
That would create a box and a sphere and move the box in the x axis the radius of the sphere. Then you could do a difference as simple as: myobject = mybox - mysphere;
It just makes sense, and is so simple.
Yes, an object oriented language may have some benefits especially as a general programming language. But “object oriented” did not deliver the holy grail as told by lots of theoretical books (I can see that daily, working on Java code that could be so nice when using the available OO features… but mostly it isn’t).
In case of OpenSCAD, I’ve seen a number of language wrappers which mostly make things look more complicated without providing much benefit regarding the actual modelling. That does not mean they can’t be the best solution for some use-cases. Like always, it’s not possible to have one tool work in every single case imaginable.
That said, there’s lots of useful discussion regarding the language and it may be possible to include some of the features without breaking all the existing scripts. Maybe it’s even possible to have 2 language frontends somewhere in the future, but that’s a huge amount of work :).
(http://forum.openscad.org/OpenSCAD-3000-td8431.html)
@bob_cousins AMF output is already available in the dev snapshots. It can’t yet use the extended features that are possible with AMF. This requires some core changes like not forcing the top level union of modules so it would be possible to export multi-object AMF, but work on that topic is on the way…
I would recommend not breaking the existing language… Much. It may require an identifier like a new file format. The main idea that I would want implemented is local variables and functions, and primitives handled like objects so you can access those functions and variables.
Being able to recall the attributes of a primitive would greatly simplify the code, instead of creating a bunch of global variables. Ive started to do this in my own code by creating global tuples and accessor functions for them, but its still a pain in the ass and is not standardized. It does allow me to do similar things.
Yeah, that’s basically the idea. Having something like a “version 2” format where changes are possible that break backward compatibility while still supporting the older things for quite some time.
The difficult thing here is to find a way that does not impact performance. Actual CSG operations can take a long time for more complicated models with high vertex count and getting actual coordinates will need to enforce geometry evaluation which is currently skipped in preview (F5) mode.
When I was playing around with the opencascade python lib, it was incredibly fast as compared to openscad. I wonder where the slowdown is, as other renderers can do almost real-time.
Most of the time is spend in libCGAL with Nef Polyhedrons as data structure. This is a nice way to enforce strict solid objects and prevent degeneration due to floating point issues, but it’s very slow in some cases.
One surprising case is a union of 100 overlapping vs. 100 non-overlapping cubes.
Unfortunately there are not much alternatives, but someone was working on faster CSG calculation. Maybe that’s going to produce some results sometimes.
Totally unrelated, the OpenGL code really needs some love to make the actual display faster and maybe also support OpenGL ES.
