2025-03-09

Last modified: 2025-03-09 23:03:28

• Partners in Crime
• Isoform
• Flywheel truck
• A better smooth min

Partners in Crime

We've played a lot of "Partners in Crime" but the word list is getting old, need to think of new words. A good word is something that has multiple meanings, a lot of them tend to be both a verb and an unrelated noun. Existing words include:

• record
• bat
• tap
• wave

Other good ideas would be words that are really hard to represent, and homophones, because even if they aren't spelt the same you might still work out what your partner has drawn. Also words that are similar but different, for example "noise" and "sound" might confuse each other.

We'd also want a way to shuffle the deck without unpairing the pairs. And a way to do scoring that is more convenient.

I'm working on a list here: https://github.com/jes/partners-in-crime-wordlist

Can print with https://cards.aa.net.uk/

Isoform

I'm going to do a bit of a tidy up:

• the tree stuff should all go under nodes/, and then that directory is kind of a "CAD kernel" independent of the GUI
• the tree view and property editor should be individual components
• write a .cursorrules that explains the architecture?

Good, done.

I wonder if I can get Cursor to make drag-and-drop of the tree view for me?

Wicked, it's working!

So I am now able to drop a node on another node, but I still can't drop them between other nodes to reorder the tree.

Meh, can't figure it out.

Let's try and sort out the view rotation then. It works fine except that the X axis is always horizontal, because it only lets you rotate left/right and up/down, never round and round. And secondly I think even if you do try to rotate round and round you get a gimbal lock and it doesn't work properly.

I made it store a rotation matrix and apply rotations to this matrix, works much better now. I'm still not convinced it works as well as FreeCAD does, but it is better than it was before.

I've also made panning work at 1:1 ratio instead of randomly moving the object further than you drag.

Let's add viewing pane switching. Also may be a good time to get floating toolbars in the viewport?

Now with Mirror and LinearPattern:

The framerate is dropping now, because LinearPattern is based on an explicit union of all of the copies. Doing it with domain repetition is possible, but skip for now since I think we'd need bounding boxes and we don't have them.

• lots of stuff takes an axis parameter, but implicitly has it passing through the origin, we should provide a way to setup datam axes etc. and let you pick any datum axis

Also now with PolarPattern:

All 3 of these pattern tools are based on explicit union, but if we're doing an explicit union we ought to provide a smooth min option. And in fact even if get bounding boxes and use domain repetition to reduce the number of items to union, we could still do smoothing! As long as we expand the bounding box by the size of the blend.

• I'm kind of keen to make the renderer try harder if it is sitting still for several frames in a row, so you could slowly increase the number of iterations of ray marching as long as the user is not interacting with it, and then the rendering would gracefully improve, and if they interact with it then we jump back down to whatever we can do at 60 fps

I've added a really lame "Move up"/"Move down" option to the menu. It's better than nothing.

And there is kind of a powerful idea in here that I can't quite put my finger on.

So look at this:

That is a twist of a PolarPattern.

But the tubes are all distorted because of the twist. Imagine if instead of twisting the shape resulting from the PolarPattern, we instead somehow applied the twist only to the domain transform, and then with a new rotation and translation we put the original object in place without any distortion? I need to get a better intuition for the kinds of things that are possible, and then work out the UI for it. I think the whole "let the user define functions and select functions from a list" is kind of a cop-out, that's just a more complicated UI for OpenSCAD. There should be a way to apply any of my "Modifiers" to the PolarPattern in a way that only modifies the location of the object rather than the shape of it. So in PolarPattern we compute the "new origin", and then add p to it. Before adding p to it, we should ask what the Twist modifier (or whatever) would do to our new origin. And use central differences to calculate the new axis directions. And then apply the Twist modifier's change to the origin and axis directions, and then add p and evaluate the child node.

• draw a local axis indicator at the origin of the secondary node, when shown
• show the coordinates of the point under the cursor
• draggable transform control

So I think key next steps are:

• draggable transform tool
• evaluate SDF in JavaScript, for turning into a mesh, also for showing coordinates under cursor (unless we can do that in GLSL? let the pixel that the cursor is under write to a uniform that JS can see? not sure if possible)
• draw sketches
• add datum planes, datum lines, etc.
• save your work

Flywheel truck

All printed and assembled:

ChatGPT was right, 64:1 is too much. There is nowhere near enough grip to actually rev this up to a good speed. Also I was too lazy to pin the axle gear to the axle, so that slips if you do manage to get enough grip. And if that didn't slip the wheels would slip on the axle.

So I've dripped superglue on all of those joints, not convinced it will do much good though.

If slipping on the rear axle is the only problem then I can make it D-shaped and re-print 2 wheels and a gear, not the end of the world.

The other thing is that with such an extreme ratio it crawls along incredibly slowly, which makes for not a very fun toy.

So I think probably I should modify it to remove one of the gears, and while I'm at it:

• D-shaped shafts
• fix the 11mm bearing bore, should be 10mm
• thicken up the inner bearing mount, it cracked when I pressed a bearing in
• redesign the wheels so they print better and have a longer contact with the axle

A better smooth min

So the issue with smooth min is that surfaces that don't need smoothing get pushed outwards, because "smooth min" is just "min, but if both values are small, add something to them".

2 cubes:

Union with smooth min:

So we need an alternative to smooth min that somehow knows when the surfaces are the same and doesn't bring the surface outwards.

My idea is we compare the direction to the two parts, and when the directions are equal we just take 1x the direction with no smoothing, and when they're directly opposite we let the smoothing be at its maximum.

So basically take the existing opSmoothUnion, and multiply k by some measure of the "oppositeness" of the 2 directions. Take the directions by central differences.

I have tried that but not managed to make any improvement.