I've recently starting posting again on my project blog https://willmorrison.net. Someone else shared my most recent thing here and I wound up sticking around.
I've actually done clear prints with LEDs installed. The bottom is much brighter than the top and it just look kinda tacky. I briefly hollowed out the supports and tried running fiber optics but it didn't help much.
I'm realizing now that I tried a lot of weird shit during this project that just did not work at all or make it into the final product, I should do another video just of all my failed abomination marble runs.
Minor suggestion/request: would be great if you added a final STL file to the github repo of a working example. Might be easier for people to try if they can't get the python code running on Linux.
(I haven't tried yet. But I'd love to just send an STL to my printer to see how well it prints.)
That's pretty much it! It's the simplest method of supports I could come up with that allows for robust keepout zones. I did have a bunch of issues at first with supports blocking the path but with a little tuning it became surprisingly consistent. I doubt I'm the first to come up with it but I have not seen any similar systems.
Thank you! The emergent forms are much more interesting than they have any right to be for such a simple system.
I actually attempted this, the idea of a python script that converts a midi track into a marble run is just too good to not try. I printed a large drum with different track structures inside so I could test various "slopes" by changing the speed and it just doesn't work, the balls bounce around too much to get an audible pitch. A less rigid material or a larger bearing would likely work better but I decided to focus on getting the normal version working well.
Maybe at the bottom your marbles could land on surfaces with different accustic properties. Track selection would determine the surface and release time would determine the timing.
Not the person you asked, but look up "Hilbert Curve" on Thingiverse, Printables, or Thangs and I bet you'll find somebody who uploaded a marble run with more information for you.
It's actually much weirder than that: banking changes the axis of rotation and thus kills the rotational inertia. The tracks bank super aggressively in order to prevent the ball from accelerating too much and hopping the track. This is part of why the descent is so smooth and all the balls move at more or less the same speed.
Also to be fair the final system does lose a ball every 30ish minutes. The tuning was largely me staring at the run or taking a video trying to catch where they get lost. Instead of hand tuning I would just update the generator and print another one. I'm considering closing the loop with a camera but that would be a whole new project.
First, I thought about Ansys or CATIA software but I couldn’t find any module specialized for simulation of balls.
But I think that people from those companies could help as well and participate in simulation as an interesting usecase. (These software are expensive for personal projects.)
My point was that these software could help to find weak parts in trajectory - so instead of trying to figure it out by looking where balls are too quick to fall from the ride - you can simulate it. I saw real tramway simulation done in Ansys.
I think the physics are different, a ball is basically a car without a differential, so it's going to behave differently on the tracks. I'd imagine the ball is harder to simulate because of that.
One of the results for hilbert curve marble tracks, mentioned elsewhere in the thread, was a video showing how to make one in blender, which has a physics engine so it can simulate it pretty well.
But for hobby purposes I would suggest to contact some university, they have such software, and they could find simulation of balls motion at marble fountain interesting for research (and educational) purposes.
I haven't actually measured it but that's a good thought, I may borrow a thermal camera and do some testing! It's not noticeably warm to the touch but this functionally a system that converts potential energy into heat and sound so there's probably a measurable change.
It's specifically using SolidPython2 to generate the models. I originally wanted to do a quick code cleanup and have the specific math be much clearer but by the time it was working that was an absolutely massive undertaking. If I touch the code again I'm probably going to refactor the entire codebase and use a different 3D engine.
Mostly speed, I'm mostly doing large boolean unions of primitives or chain hulls and OpenSCAD chugs pretty good at large numbers of operations. Don't get me wrong, they're great tools for what they're good at. I need to do more research before I start a port, SDFs seem like the best option but I'm not 100% confident. I am considering using your SDF library though (github.com/fogleman/sdf) but need do do some experimenting/benchmarking first.
Not sure if this matters for you or not, but my understanding (with some experiments) is that the "slicers" implicitly do a union. As in: you could have an STL with a bunch of overlapping blobs and the 3d printer slicing code just checks isInside -- which is effectively a union.
At least that's what I found when I was generating STLs in code.
reply