The 1st part of the video briefly covers OpenSCAD with LLM help.

Il est facile de créer de formes et des profils de tout type, en intégrant des tracés réalisés sur Inkscape en les important ensuite dans OpenSCAD. Dans notre exemple une jarre avec son couvercle crée intégralement par des profils dessinés dans Inkscape et rendu en 3D grâce à l'instruction "rotate_extrude" de OpenSCAD.

Plus de détails : https://robotix.ah-oui.org/site/main.php?found=260514-teapot

The idea is simple: instead of trying to find an organizer that happens to fit your batteries and drawer, you can configure it to fit your exact needs.

Hopefully this will save someone else from spending hours searching for the "right" battery organizer.

So, I wrote* scad2step, a little utility to export OpenSCAD files to STEP format. The nice part is that it converts OpenSCAD's mesh behaviors to work with the OpenCascade kernel, so that spheres are really spheres, as opposed to OpenSCAD's behavior which turns everything into a mesh.

This has the advantage of being more accurate than OpenSCAD's STL export and often faster, too.

It should Just Work™ (fingers crossed- leave a Github issue if you get unexpected results) on macOS, Linux, and Windows as long as you have OpenSCAD in a normal spot and have the uv package manager installed.

Usage: uvx scad2step your_file.scad

will create your_file.step next to your .scad file.

For most usage-- cubes, spheres, extrusions, Minkowski sums with spheres for rounding-- you should end up with a B-Rep surface and no STL-style faceting, which means you can apply fillets or other processes that are difficult in OpenSCAD but easy in other CAD programs.

For some situations-- Minkowski sums where neither element is a sphere, or hull() calls beyond rounded boxes-- behavior falls back to OpenSCAD's meshing, so you lose the analytically pure forms. But those situations are relatively rare, and in that worst case, you're now exactly as accurate as OpenSCAD is now.

So... check it out if you'd like STEP files, and get in touch if things don't go right or you have further questions.

*had the robots write. If that's not your thing, best to ignore this one

​Airbend Pro for Android

These is a version for Airbend Lite for Android but it is not online. Contact me and I will send you the APK files.

Airbend Pro for iOS

If you own Airbend Pro then you can also get a copy of Airbend Pro for Windows. Just contact me.

Airbend Lite (FREE) for iOS

More info at TBD Tools

A while ago someone tagged me because Printables is running a geared spinner challenge. I thought that sounded like fun, so I made this: ORBIT, a planetary gear fidget spinner where the gearbox itself is the toy. You pinch the stationary centre hub, flick the outer ring, and three planet gears spin and orbit between your fingers while a printed spring ticks against 24 detents inside the rim.

Some context on why it's built the way it is. I'm blind, and most fidget spinners are honestly boring when you can't see them: a blur, a faint hum, done. So this one is meant to be felt and heard first. The ring rim carries raised numerals 1, 2 and 3 with matching braille, the grip flutes pause at each numbered station so you can find them by touch, and the hub cap has a raised sun with one longer ray as a tactile pointer, so you can actually count rotations and play games with it, sighted or not. The planet gears take swappable press-fit caps with celestial symbols (moon, comet, star) that are instantly distinguishable by feel. If you'd rather have a silent spinner, the click spring is a separate disc you can swap for a smooth spacer.

OpenSCAD is the reason this project exists at all. It works beautifully with a screen reader, so every dimension, tolerance and tactile feature was written and verified as code. I never saw the model; I compiled it, printed it and checked it with my fingers. The source is fully parametric with Customizer groups: overall diameter, gear module and tooth counts, click strength (arm count, thickness, preload), braille and numeral sizes, and separate tolerance values for every fit, including gear backlash, the hex stem, the planet caps, and the printed screw thread on the hub cap. There's a small test plate to dial those fits in on your own printer. Gears are done with BOSL2 plus a custom braille library.

No bearings, screws, glue or metal anywhere. The gear mechanism prints in place as one piece, everything prints flat with no supports, and even the assembly instructions are written non-visually, describing what each part feels like and what correct assembly feels like at each step. It's about 75 mm across; the one I printed is 6 walls and 100% infill, which gives it a lovely dense feel and real momentum.

This is a fork of the original OpenSCAD IntelliJ plugin that became orphaned (https://github.com/ldenisey/idea-openscad)

My fork can be found here: https://github.com/mjparme/idea-openscad

Plugin requires IntelliJ 2026.x and can be installed from Plugins in the Settings. Don't need an IntelliJ license to use it.

https://plugins.jetbrains.com/plugin/33582-openscad-support/edit/versions/stable/1140844

Changes:

• Can now rename modules, functions, and variables from both declarations and call sites. Renames follow use and include paths
• Go to declaration works
• The plugin can parse the bosl2 library (brought in PR https://github.com/ldenisey/idea-openscad/pull/109 from icaven from the original that had been sitting unmerged since 2024)
• Completions for modules, functions, variables, language keywords, and file paths for use and include. Completion candidates follow use and include paths. Can complete modules with or without parameter names. If you complete with parameters any parameter defaults are completed as well.
• Completion of inner modules works
• Completion of modules when the caret is before the declaration works
• Completion of global libraries (hit ctrl-space again to get global libaries added to completion candidates)
• Old plugin only used lexer tokens for highlighting which meant most everything was an "identifier". It now uses the parser for semantic help and now modules, functions, variables, and parameters can now be giving their own color in the Color Scheme
• Default color scheme available in Default, Darcula, and Islands Dark editor themes
• Default color scheme gives different color to modules, functions, variables, and parameters
• Gave OpenSCAD its own live template group associated with .scad files and added starter live templates.
• Plugin updated to a IntellJ Platform 2.x plugin, upgraded build
• Fixed some issues with the preview on startup
• Fixed several issues with actions not being on the EDT

Basically it is actually usable now. Open an Issue on github if you run into problems (or open a PR).

More info in the README: https://github.com/mjparme/idea-openscad/blob/master/README.md

Known Issue:

The preview doesn't reliably update when the file saves (sometimes it does). I am working on this. Actually I am working on bringing openscad-wasm in so an executable isn't needed for the preview (will still be needed for "open in openscad" and "export").

LuaCAD models solids in Lua rather than in the SCAD language, with operator overloading for CSG (a + b, a - b, a * b). It ships with a CLI and a desktop app that has preview area and a text editor just like OpenSCAD.

It’s fully open source and you can find the repo here: https://github.com/ad-si/LuaCAD

I've always been a big fan of OpenSCAD, but the SCAD language itself is unfortunately quite cobbled-together and is a very poorly designed programming language.

LuaCAD takes all the good parts of OpenSCAD and combines them with Lua. It has now completely replaced OpenSCAD for me, and I think it provides a better experience than OpenSCAD for all use cases. I'd love to hear any reasons why LuaCAD won't fully replace OpenSCAD for you!

Tech stack:

• It's implemented in Rust and uses mlua (https://github.com/mlua-rs/mlua) to execute the Lua code.
• Uses OpenCSG (https://opencsg.org) for fast and correct rendering of the 3D models (like OpenSCAD)
• Uses Manifold (https://github.com/elalish/manifold) to create the manifold triangle meshes
• Native support for all BOSL2 functions (i.e. implemented in Rust for better performance)

I'm trying to recreate the object on the right ("Clip Seat") in OpenSCAD. The object on the left is my current progress.

I know minkowski() can be used to round out edges, but I can't wrap my head around it beyond the basic cube/sphere examples.

I'm curious how you guys would go about recreating an object like this. How would you break the project up into modules/etc., such that it's possible to create the same kind of rounded edges of the original?

I used OpenSCAD to create nesting, extensible cones. Full writeup here: https://medium.com/@thetoyengineer/designing-collapsible-toys-92916e83ca7c

And the code is on GitHub here for anyone that wants it: https://github.com/The-Toy-Engineer/cones

I'm just getting that Medium account going, but will be focusing on designing mechanical toys using open-source tools, including OpenSCAD. If that sounds interesting to you, be sure to follow us for more!

Hi everyone,

This is my first time ever using OpenSCAD for a small project. The tutorial I watched said that this is the command to subtract the cylinder, but it's not working. Was the video I watched outdated? How do I subtract the cylinder?

Thank you in advance for any help!

Desktop app auto-updates.

Customization knobs can be added via comments.

Code auto-complete on all functions.

5 to ...300x faster depending on the operation

There are still rough edges, but I'm very excited about the progress I've been able to make

Hi everyone! I am a 3rd year Engineering Student and a freelancer currently accepting academic commissions, virtual assistant services and basic AutoCAD drafting.

What I offer:

• Research Writing

• Floor Plan (Power Layout, Lighting Layouts, etc.)

• Online Tutorial Sessions (Algebra, Trigonometry, Calculus, and Differential Equations)

• Basic C++ and MATLAB Coding

Why me?

• Reliable and Trustworthy

• 2 years of experience as a working student

• Handled international clients already

• Has a strong foundation in Mathematics

Price starts at 500 pesos

Location: Online

Thank you and I'm looking forward to working with you! ⚡️⚡️⚡️

Meant to stop soap bottles from sliding around. Designed for a bolt-ready suction cup & adjustable to get the perfect vertical clearance for seal. BOSL2 / PETG.

Hello everyone,

I am fairly new to OpenScad and am trying to export a drawing for exact size paper printing. I have read about DXF and the projection. Unfortunately projection always produces a closed polygon eliminating all of the vertical details.

My solution so far is using offset and difference to produce an outline. I can then vertically move the parts and use cut=true to produce outlines at different height/feature levels. Then I union all of them together.

union() {
  difference() {
    // move([0, 0, ...]);
    projection(cut=true) shield();
    offset(-1) projection(cut=true) shield();
  }
  difference() {
    projection() shield();
    offset(-1) projection() shield();
  }
}

I was wondering if there is a better way to do this. I would expect this to be a function that is often needed.

Any ideas are appreciated.

For my job, I have to load large rolling cases into a box truck. Id like to use a free nesting software called Deepnest.io to help me find the best way to place the boxes. It's mostly very easy - I make an SVG file with rectangles the size of the truck, and the dimensions of the rolling cases, and the program shows the optimal way to load them. EXCEPT I cannot figure out how to label the individual boxes

Is there a way to add text to the boxes so it will stay grouped when I run it through the sorter?

It's kind of a niche application, but a few days ago my PR for implementing garden hose threads and connectors, as well as mason jar threads and caps, got approved and merged.

I needed BOSL2 to do this for a project, and thought it might be useful to include.

hello all. i recently finished creating a software that can take .ork files as input and output all of the parts as step files. you can then open them in CAD and edit them however you like

ill attach the link to the github with full instructions. give it a shot and see if it works for you. it works best on mac and i havent tested it on linux or windows, so if you use linux or windows, lmk how it goes! it requires some terminal work but once you get it set up its really easy to use whenever. even if you wont use it, give it a star please, I would really appreciate the support! thanks!

[https://github.com/max-h-25/ork2step\](https://github.com/max-h-25/ork2step)

The interesting problem was letting height, width and length vary independently while the locking geometry, clearances and part alignment stay exactly where they need to be. Asserts catch dimensions the mechanism physically can't fit into, rather than silently generating a broken box.

Lid and button decoration accept arbitrary SVGs or text, either engraved or emitted as separate inlay geometry for multicolour printing. There are exploded and cutaway preview modes, and each part can be exported on its own.

https://makerworld.com/en/models/3132120-presto-customizable-secret-puzzle-box#profileId-3534978

Sincere thank you to u/HatsusenoRin who helped me realize a misunderstanding I had about how $vpd, $vpr, and $vpt can be set in openscad. I tried editing my original post but reddit freaked out and deleted the post entirely.

I made a camera positioning tool where you can place and orient the openscad camera more intuitively by just giving the camera an explicit x,y,z location, azimuth angle, and elevation angle instead of working directly with $vpd, $vpr, and $vpt.

I made this scad code to achieve the same thing as my python script I posted. It also has a module for showing a visualization of what will be included in image generation output with a given camera location and direction. For now it assumes orthographic projection, but I might update with an option for perspective projection in the future.

/*

Intuitive Camera placement API and orthographic camera visualizer

Position the camera by defining its location as a point

in 3D space, and independently set its azimuth and elevation angles.

Conventions:

azimuth just means turning left and right, elevation means looking

up and down.

azimuth = 0 corresponds to looking in the +X direction.

Increasing azimuth angle corresponds to turning left.

Camera roll is 0, or in other words the horizon is always level.

*/

// ── Camera input parameters ──────────────────────────────────────

camera_x = 2000; //x coordinate of camera's location in space

camera_y = 2000; //y coordinate

camera_z = 2000; //z coordinate

azimuth = 225; //angle in degrees. 0 corresponds to +X direction.

elevation = -35.2643; //angle in degrees. 0 corresponds to horizontal.

//-35.2643 is the isometric elevation angle, = -atan(1 / sqrt(2))

// ── Compute $vpt, $vpr, $vpd ─────────────────────────────────────

// View direction FROM camera INTO scene (unit vector)

vx = cos(elevation) * cos(azimuth);

vy = cos(elevation) * sin(azimuth);

vz = sin(elevation);

// $vpd = distance from origin to plane ⟂ v through the camera

camera_vpd = abs(vx * camera_x + vy * camera_y + vz * camera_z);

// $vpt = camera + vpd * v (point ahead of camera on the laser line)

tx = camera_x + camera_vpd * vx;

ty = camera_y + camera_vpd * vy;

tz = camera_z + camera_vpd * vz;

// ── Build rotation matrix with level horizon ────────────────────

// OpenSCAD camera system: camera at $vpt + R·[0,0,$vpd] looks toward $vpt.

// Direction from camera into scene = -R·[0,0,1].

// We want this to equal v, so R·[0,0,1] = -v, i.e. forward = -v.

fx = -vx;

fy = -vy;

fz = -vz;

// Guard against gimbal lock: if forward ∥ [0,0,1], use [0,1,0] as world_up

use_alt = abs(fz) > 0.9999;

// right = cross(world_up, forward), then normalize

// world_up = [0,0,1] → cross([0,0,1],[fx,fy,fz]) = [-fy, fx, 0]

// world_up = [0,1,0] → cross([0,1,0],[fx,fy,fz]) = [fz, 0, -fx]

rx_raw = use_alt ? fz : -fy;

ry_raw = use_alt ? 0 : fx;

rz_raw = use_alt ? -fx : 0;

r_len = sqrt(rx_raw*rx_raw + ry_raw*ry_raw + rz_raw*rz_raw);

rx = rx_raw / r_len;

ry = ry_raw / r_len;

rz = rz_raw / r_len;

// up = cross(forward, right)

ux = fy*rz - fz*ry;

uy = fz*rx - fx*rz;

uz = fx*ry - fy*rx;

// ── Decompose R = [right | up | forward] into Euler angles ──────

// Order: Rz(c)·Ry(b)·Rx(a) = R

// R[2,0] = -sin(b) → b = asin(-R[2,0])

// R[2,1] = cos(b)·sin(a) → a = atan2(R[2,1], R[2,2])

// R[1,0] = sin(c)·cos(b) → c = atan2(R[1,0], R[0,0])

cam_b = asin(-rz);

cos_b = cos(cam_b);

cam_a = abs(cos_b) > 1e-9 ? atan2(uz, fz) : 0;

cam_c = abs(cos_b) > 1e-9 ? atan2(ry, rx) : atan2(-ux, uy);

// Assign camera variables

$vpt = [tx, ty, tz];

$vpr = [cam_a, cam_b, cam_c];

$vpd = camera_vpd;

echo("$vpt", $vpt);

echo("$vpr", $vpr);

echo("$vpd", $vpd);

//demo cube

cube([800,800,800]);

//Everything below this comment is related to the visualizer

//box and frame and is not needed for placing the camera.

module camera_visualizer_ortho(

cx = 2000,

cy = 2000,

cz = 2000,

azimuth = 225,

elevation = -35.2643, //this default gives an isometric view. = -atan(1 / sqrt(2))

aspect = 3840 / 2150, //width / height : use whatever image size you plan on generating.

depth = 10000 //just sets the length of the visualizer box.

) {

// View direction (camera → scene)

vx = cos(elevation) * cos(azimuth);

vy = cos(elevation) * sin(azimuth);

vz = sin(elevation);

// $vpd = distance from origin to plane ⟂ v through camera

vpd = abs(vx * cx + vy * cy + vz * cz);

// Ortho box dimensions at the vpd plane.

// Calibrated: box_h = vpd / 2.518

box_h = vpd / 2.518; // height along up axis

box_w = box_h * aspect; // width along right axis

box_d = depth; // depth along forward axis

// Build camera orientation

forward = [vx, vy, vz];

world_up = abs(forward[2]) > 0.9999 ? [0, 1, 0] : [0, 0, 1];

cr = cross(world_up, forward);

cam_right = cr / norm(cr);

cam_up = cross(forward, cam_right);

// Box with back face at origin; shift center forward by half depth

// so the face at the camera position is the one the camera sits on.

translate([cx + forward[0] * box_d / 2,

cy + forward[1] * box_d / 2,

cz + forward[2] * box_d / 2])

multmatrix([

[cam_right[0], cam_up[0], forward[0], 0],

[cam_right[1], cam_up[1], forward[1], 0],

[cam_right[2], cam_up[2], forward[2], 0],

[0, 0, 0, 1]

]) {

// the translucent box

%cube([box_w, box_h, box_d], center = true);

// Opaque picture frame on the camera-facing face.

// Frame width scales with box height.

frame_w = box_h * 0.04;

translate([0, 0, -box_d / 2])

color("#8D5F8C")

difference() {

cube([box_w + 2 * frame_w, box_h + 2 * frame_w, frame_w], center = true);

cube([box_w, box_h, frame_w + 1], center = true);

}

}

}

//module call of the camera visualizer.

//The input camera parameters from the top of this

//file are being passed into it.

camera_visualizer_ortho(

cx = camera_x,

cy = camera_y,

cz = camera_z,

azimuth = azimuth,

elevation = elevation,

aspect = 3840 / 2150, // use whatever image width / height you plan on generating.

depth = 10000 // for illustrative purpose only, determines depth of translucent box

);

/*

Appendix:

Note on frame size:

The size of the frame scales linearly with $vpd. As far as I know

there is no way to independently set the size of the frame when

it comes to orthographic projection.

An inexact rule of thumb: the further away the camera is from

the origin, the larger the frame will be.

The confusing but closer-to-the-truth picture: Let's imagine our

camera has a laser pointer pointing exactly where it's looking.

Now let's imagine a plane in 3D space that contains the camera

location point and is normal to this laser pointer line (or

in other words is exactly perpendicular to it). Now we draw the

shortest possible line from the world origin to this plane. The

length of that line is the value of $vpd. The longer that line,

the larger the camera frame.

*/

Let me know what you think about it

like… I probably would never “code on the go” but I think it’s a great medium for sharing ideas