Show HN: Impossible Machines: declaratively program the physical world | Hacker News Reader

Show HN: Impossible Machines: declaratively program the physical world

impossiblemachines.xyz

82 pointsbhaprayan22 comments

Hey all —

Sharing a thought experiment I put together. The premise: what might declarative programming feel like for the physical world?

We’re already familiar with this paradigm in software land (eg SQL etc where we declare what we want and the execution engine figures out how).

I didn’t have access to an actuator so I mocked up the concept in software. The way it works is you demonstrate the effect and the system figures out how to achieve it. So say you want to ring a bell and you have a crank. The system will find a way to connect the two. If you add obstacles it figures out how to work around them (runs a constraint solver runs behind the scenes).

I think what’s interesting about this is being able to think about the problem at a higher level of abstraction, with the system figuring out a way to achieve the intended effect.

Anyways, curious to read reactions, feedback, and interesting ideas on how to extend this!

Open articleView on HN

This is cool! I think it would be interesting to expand the language of the world. Right now the interaction with the bell or door is limited (basically binary). Even with binary it would be cool to say ring the bell three times or play shave and a haircut and then a mechanical device that could generate that frequency would be created (for ex a simplistic one would be to skip every other ring for ringing the bell). I guess that would require the world/the objects to account for interactions over some recording period.

Thanks! Great idea, I hadn’t realized the interaction is binary. It would be cool to allow for "continuous" inputs too. The world would have to account for interactions over a recording period right.

Behind the scenes, I’ve tried to make the audio production realistic, so there’s some acoustic modeling going on (eg echoes, attenuation of sound, etc). But yes you could imagine having the input forces be continuous and having the mechanism trying to figure out how to reproduce the sound exactly.

I love this idea of declarative modeling of the world because it seems to me to be the way that we as humans do it. I think the hard part about declarative is understanding intent beyond simple interactions. The current limited framing limits the expression one is capable of in the world but of course these are all tradeoffs.

Understanding intent is really hard indeed. What’s helpful about constraining it to you showing the effect is if you are able to do it, there exists at least one possible mechanism.

The Incredible Machine vibes.

Embarrassed I'm just finding out about this, very cool! Neat that they simulated air pressure too. I should try that, would be fun to influence the texture of the sound.

woah lol. I 100% assumed you used it as inspiration for your software.

Haha it sort of came out before I was born, otherwise I definitely would have! I think I'll take a leaf out of their book and expose a mode to make the simulation deterministic. I'm using a PRNG right now to make the mechanism selection more "creative", but I could see determinism being an interesting experience.

This is actually very interesting idea you had. I watched the demo and played with it and I am looking for a link to repo - I would like to know how did you implement the system achieving the outcome.

Happy to open source, the code is a little messy right now, so I’ll clean it up and post a link in a few days!

High level:

I’m using ThreeJS for the rendering and Rapier (https://rapier.rs/) for simulating bodies, joints, collisions, forces, etc. The mechanism is solved for using a simple heuristic search (eg constraints, etc that you introduce in the scene) and then run through Rapier to find a configuration that works, though there are definitely more sophisticated ways to do this. The audio is based off a sound pack which I tried to make physically realistic so impacts are panned relative to the camera, with compression and a small generated reverb.

Disney's research lab did something along these lines some years ago for making a point follow a path. You draw a path, and it generates the linkages required to match that path as closely as possible. They've had a lot of follow-up work since, but I remember this video for it: https://youtu.be/DfznnKUwywQ?si=F-5NZxKu4hP_mand

Really neat demo! I skimmed through the paper and it looks like they’re using a precomputed database to find an assembly that matches the motion (presumably as a seed to instantiate the solver). That’s definitely more efficient than what I have right now (though perhaps less versatile). I like that they manufactured a few of the characters using 3D printing! That was definitely on my mind, really happy to see they did it.

Some of the mechanisms (belt drives etc) might be a little tricky with 3D printers, but would be very cool to see the mechanism tangibly realized.

It seems people think alike. Something that inspired me in the past also had a similar implementation.

[1]https://www.microsoft.com/en-us/research/publication/motion-...

That was cool! Watched the demo video, didn't go through the paper yet. I'm running a simple heuristic to test for candidate solutions and running them through Rapier (https://rapier.rs), but simulated annealing to efficiently search the configuration space would be a nice extension.

Your work is wonderful, too.

Thanks, appreciate it!

This is great. Had fun playing around with it. Do you plan to add more elements and more challenges? 'Describe the world, not as it is, but as you wish it to be.' - Loved that line!

Thanks! Glad to hear it was fun and that you loved that line. Thought it would be the simplest way to describe the underlying concept. Did you have any elements / challenges in mind that may be fun?

I was primarily thinking about more sources, obstacles, and sinks. Right now the solver picks a random solution so it may be interesting to optionally make that deterministic too.

This is a clean take on Go. What would you change if the input is messy?

This is a clean take on Go. What would you change if the workload grows?

This is fancinating!

Thanks, happy to hear you liked it!

Reply on news.ycombinator.com