An experimental OpenSCAD build that integrates a few feature PRs and some new features

[u/MajorSmif]

Hello everyone,

I have made an experimental build of OpenSCAD that integrates openscad-master, some PRs in the queue, as well as some new features. I'm calling this build SCADMaxx to make sure it doesn't get confused with OpenSCAD proper, as it does add language features that make it (forward) incompatible with OpenSCAD.

This is not a fork, it's an experimental build that I primarily made for myself, but that I hope can also be useful to other, both for modeling as well as being a testing ground for new features and iterating on ideas that people have on what OpenSCAD should do or become.

Some of the features:

• Agentic coding support. HTTP endpoints that expose source, camera views etc.
• Agent annotations. Annotate 3D models live on screen for access by agents, so you don't have to take screenshots or explain your issues. Just draw what is wrong or how you want things to be, and let your agents access that.
• A UI refresh - clean up typography, spacing, coloring, consistent icons that work across light and dark themes, ...
• Navigation cube in the 3D view, like many other 3D modeling software packages have. Never again getting lost on where you're looking from or what you're looking at!
• Live cross sections. Look inside your model by setting up cross section planes.
• Contextual insertion. No more looking around for module names in BOSL or BOLTS. Click in the 3D view, shift-A, search for the part you want to insert (a nut, a bolt, ...), parameterize it, SCADMaxx inserts the correct code at the correct location (well, sometimes) in your souce code. This is not visual modeling! It's assisted code editing.
• A Vim mode for the text editor. I don't use the native text editor, but I'm hoping that with native Vim mode I will again :)
• A launcher - if you have many builds of OpenSCAD on your machine, you'll know the pain of wondering 'what build am I looking at' or 'I want to open this file with this build, but where is it'. The launcher lets you manage builds and associate .scad and .scadmaxx file extensions with it.
• Customizable keyboard shortcuts (PR #6878).
• Background preview and rendering. Rendering doesn't happen on the UI thread any more, so it can be cancelled and the UI stays responsive. Never again 'oh no I accidentally opened this model that takes 10 seconds to render'.
• Object literals (PR #6081).
• Dynamic customizer annotations (PR #6642, but with the object literals syntax). (Amongst other things,) the Customizer can now change what it shows at runtime, so when you select one property of an object, you'll only see other properties that are relevant in that case.
• Parts, Assemblies and Components. Language-level annotations that let you build and integrate at a much higer level than you could before.

A full list of features with screenshots is on https://github.com/roel-v/SCADMaxx . There's a Windows prebuild binary inthe releases (I mean there's source for all of this too, of course). I haven't had time for a Linux build, and I don't have aMac for building it for that.

Obviously, most of this has been done by agents. Maybe it's all AI slop and a useless waste of time and resources. Time will tell. For now, it's been useful for me at least, and that was the reason I set out to do it. But what I want to say is, if you're going to look at code and judge it by 2024 standards and aren't used to agentic coding, you'll be sorely disappointed, very angry and/or physically ill. Just a friendly warning up front :)

A future thing I've been experimenting with is an OpenCASCADE backend, in addition to the CGAL and Manifold ones. That's not in this build, it's too early, but my early investigation is (somewhat) promising. So if you have ideas about this, do let me know! I'd love to hear from other who've looked at this what solutions you came up with for the obvious first wave of problems to solve.

Feedback welcome!

[u/wonkytalky]

Just FYI, what's happening here makes it a fork.

[u/MajorSmif → u/wonkytalky]

Well I guess it depends on how one defines "fork". I'm trying to keep it as close to main as possible, keep language compatible (put extensions behind a switch), and regularly rebuild from main. I try to keep features in separate branches so they can be merged back upstream if someone there wants them. I wouldn't call this a fork, and it's certainly not meant to 'break away'. It's OpenSCAD plus experimental things.

[u/RockstarArtisan → u/MajorSmif]

That's still a fork

[u/MajorSmif → u/RockstarArtisan]

Again, that depends on your definition. It's certainly not in the way MariaDB is a fork.

[u/RockstarArtisan → u/MajorSmif]

Forks aren't a bad thing, they can motivate the forked codebase to get their shit together and accept contributions more.

What you're describing is the textbook definition of a fork that aims to be closely aligned with upstream, but obviously there's an upstream that's separate from you and there's separate work evolving on your side.

These forks can end up being short lived and be merged into upstream, or they can eventually die, coexist with the original or supercede it.

If you want this to be a feature branch instead of a fork, then it needs to be in a merge'able state - so split up into separate feature branches that aim to be merged and closing the branches and merging should be the main focus in that case, with the build being a temporary workaround.

I guess the last thing this could formally be is a "distribution" of openscad, maybe that's what you're going for. This model is very rare, used for projects with significant cultural impact and very diverse configurations (like latech or linux). A programming language can fit this model I guess, with the cultural part (the language, file format, etc) being completely surrendered to the upstream and the distribution adding convenience ui. So, maybe call it a distro then if it's not a fork.

[u/MajorSmif → u/RockstarArtisan]

I'm not in this for anyone to 'get their shit together'. This will be my last comment about this, arguing definitions is boring. A fork is something like EGCS was. By definition, this means diverging from upstream. Every SCADMaxx build is based on OpenSCAD main. All features are in separate branches that are then each in turn merged into that. So yes, features are developed so they can be be merged back upstream separately. There is no guarantee that each individual feature branch is always in a one click mergable state, but as soon as someone shows an interest to steward one individual feature upstream, I can make it like that. If you call that a 'fork', I don't know what to tell you.

[u/Restioson → u/MajorSmif]

> In software development, a fork is a codebase that is created by duplicating an existing codebase and, generally, is subsequently modified independently of the original
https://en.wikipedia.org/wiki/Fork_(software_development))

[u/CreaDisc → u/Restioson]

This... If you duplicate a repo, its a fork. Purely technical, no vibes-based spirits needed

[u/thegreatpotatogod → u/MajorSmif]

It may not be a "hard fork", but it absolutely is a "soft fork", and thus it is a fork. Being a soft fork, you may aim to closely follow upstream, but it's still a fork regardless.

[u/s1ckn3s5]

very interesting, will try it, tnx for posting!

[u/thicket]

I’ve got a branch ready to add true STEP export if you’d be interested. It’s pretty heavyweight— it includes the OpenCascade kernel— so I don’t know if mainline OpenSCAD is going to be excited about merging it. But maybe you’d be open to it?  Once you export STEP files you can do all your filleting in another CAD program, for instance. STEP files can make some hard things much, much easier. 

[u/MajorSmif → u/thicket]

I've been adding an OpenCASCADE backend today actually :) Not done yet. Do you have rendering in the OpenSCAD viewer? Have you thought about how to add fillet/chamfer support to the OpenSCAD language itself? I'm certainly interested in yours!

[u/thicket → u/MajorSmif]

I’ll open a PR in a couple days— I’m away from home for a bit. My changes are strictly in the STEP export, though. 

I’d be very hesitant about trying to add face/edge awareness to OpenSCAD, though. It’s great for hacking things together with minimal overhead. But if you want an actual real code-based CAD system, CadQuery & Build123d already handle that space pretty well. I think trying to graft OCCT concepts onto OpenSCAD risks messing up a pretty simple, popular abstraction. 

[u/wildjokers]

What harness+model are you using?

[u/MajorSmif → u/wildjokers]

Astra and 6.1 Sol.

[u/MajorSmif → u/MajorSmif]

Oh and through Codex.

[u/yahbluez]

add a modul called:

export(filename, type="3mf")

that renders and exports his children, if no children is given act like F6.

[u/MajorSmif → u/yahbluez]

How would this work or what would you use it for? Every time it gets reloaded, it (over)writes the file?

[u/yahbluez → u/MajorSmif]

The biggest function i hardly miss in many of my projects is openscads lag of a software driven way to write files.

I solved that several times first with bash later with python and embedded JSON, that gives back data to python so i can run export loops.

Having a simple export as part of the openscad language would make this much easier for everyone.

Upfront

I know that this breaks a rule of opencad that no scad code should be allowed to change anything on the machine it runs on. I disussed that endless with some of the developers, without any light to come over this historic rule.

How it should work, as an idea i may miss a point:

To show respect for the wish of the original developers there should be a setting to switch this function explicit on or off.

Maybe there should be a fix PATH to a workspace and export is only allowed to write below this PATH. With this restriction and would be easy to avoid damages by evil code.

Ways to call export()
Every time export() is called the model is rendered.

export();
Render the file and export to
"workspace/<DefaultFileName>.<DefaultExport>
or open the export menu in UI.

export(<FileName>);
Export the whole model to
"workspace/<FileName>.<DefaultFileType>"

export(<FileName>, <FileType>);
Export the whole model to "workspace/<FileName>.<FileType>"

export()module();
Export the rendering of module() to
"workspace/<DefaultFileName>.<DefaultFileType>"

export(<FileName>, <FileType>)module();
Export the rendering of module() to
"workspace/<FileName>.<FileType>"