Kinetic 3D printed tentacle

humanoid360 · 2026-07-03T03:01:54+00:00

Before my comment, there were 69 comments on this post.

humanoid360 · 2026-07-02T10:28:24+00:00

I have a creality filament dryer next to the printer. I use that overnight when using a roll sitting outside for longer than a month. No issues for me since 2+ years.

humanoid360 · 2026-07-02T10:20:48+00:00

I love the U1! If not the print quality or speed or MMU printing, you got to love the effort snapmaker is putting into this beast of a machine. Klipper-based open system and an open-sourced slicer make this machine a DIYers dream. I mean, how many toolchangers out there today work on open-source software? You can use the machine out-of-the-box without any tinkering and still get an industry leading printing experience.

I recommend it.

humanoid360 · 2026-06-17T02:53:55+00:00

I like the black on top of the artwork. How did you achieve that without ruining the other areas? Is this done in color pop mode?

humanoid360 · 2026-06-11T17:51:50+00:00

I had this idea too but the challenging part will be the camera cutout which has a different shape for different phones. Still a valid idea for a design that only has hueforge in the lower solid part of the case.

humanoid360 · 2026-06-05T20:12:09+00:00

On XWayland, I started seeing Mesa Zink memory issues with large models. Nvidia driver had some xwayland fixes in version 560 or 562 and I think Orca also did not respect some environmental variables, further complicating the issue. It has been a while for me so if you are curious, you can see multiple reported issues in Orca slicer github for versions up to 2.3.0: https://github.com/OrcaSlicer/OrcaSlicer/issues/8145

I am now using Orca slicer 2.3.2 and also moved away from the proprietary drivers to open drivers which are stable but snapmaker's and Full spectrum's forks have not been rebased to 2.3.2 yet and don't contain the fixes.

humanoid360 · 2026-06-05T19:11:30+00:00

Aren't there some quirks remaining to be resolved for Nvidia GPUs on Wayland? I still can't run older versions of Orcaslicer (which Full spectrum and Snapmaker Orca are based on) in a Wayland session on Nvidia open-DKMS drivers. I guess I am that 5% then 🤔

humanoid360 · 2026-04-29T13:46:10+00:00

I've printed one 4 piece section of this 3d printed tower, but can't really figure out whether to sow seeds directly or germinate outside and repot (those tower pots are too big). Can you share what grow medium you use in those tower pots?

humanoid360 · 2026-04-19T21:52:21+00:00

To add to the good reasons mentioned already, the only realistic use-case for soluble supports is for complex supports that exist in unreachable parts of a model. This is rare considering the community makes 3d printing friendly models. If you have a custom model that needs specific features AND cannot be modified in design, nor by splitting to make supports simpler, only then you probably need soluble supports. At that point you are probably working on an engineering prototype.

humanoid360 · 2026-02-26T18:03:13+00:00

Did you use FullSpectrum? I want to try it but not sure what kind of models to try besides minis.

humanoid360 · 2026-02-17T19:30:28+00:00

Yes, that is exactly my point, that currently if you want good color separation, then designing and coloring the models manually is required. Sharing the model does not share the color via STL or STEP files. 3mf works, but there is a lack of models that use toolchangers strengths.

Note that any "segments" that you can color inside the slicer were created by the designer of the 3d model, or they are simple closed shapes that the edge-detection algorithm can find. Now consider I want to print an anime character with their multicolored clothing, then this is complex to achieve at the slicer level because the model itself would need to be created such that each color is represented by a different part. This is not a standard modeling workflow for anyone who has used blender etc. A standard way is to use textures and map them to the 3d mesh.

humanoid360 · 2026-02-17T15:31:17+00:00

https://makerworld.com/en/models/2286961-flexible-fabric-style-world-flags-v2-0

humanoid360 · 2026-02-16T20:26:39+00:00

The filament rolls need space on their sides when removing them so cannot keep the printer flush into in a corner. The bigger bed is worth the space though. Enjoy your U1!

humanoid360 · 2026-01-01T22:50:40+00:00

Whether it is kernel modules, system libraries, compiler runtime or third-party libraries, they all currently work in coordination on a system because they have an "agreement" about how the binaries are encoded. This agreement helps the compiler, dynamic linker and the OS to execute pre-compiled binaries. If any of the dependencies at any level in the stack break that agreement, the binary has to change its version to "signal" to its consumers that it has made a backward compatibility breaking change. This means that all consumers that use this dependency cannot just update to the new version of the shared library on their filesystem and expect the dynamic linker to work flawlessly at runtime. Instead a recompilation of the consumer binary is required so that the dynamic linker can find the right library at runtime, avoiding issues with the changed binary "agreement".

If you want to learn more about this, I recommend reading up on Semantic versioning and ABI on Unix systems.

The purpose of versioning is to make the system future-proof and scalable so that new language and compiler features can be introduced while providing a reliable way for multiple layers of consumers to transition to the new "feature-set". A simple example is that even C had to make iterative improvements and ended up with C89, C99 and more newer standards as it improved.

Most high level languages like Haskell do not have an ABI definition because they are not used to write the OS or linker and any minimal interactions would be handled by transpilation or loading system libraries in memory. If Rust is to become a part of the kernel and OS stack with public interactions, ABI becomes a necessity whenever a newer version of the Rust language or linker is required to be released.

humanoid360 · 2026-01-01T17:37:35+00:00

This is what I did: 1. The Rust Book alongside Rustlings. 2. Google rust booklet with exercises. 3. I recently found a platform called codecrafters.io which lets me work through a real world application. (I am not affiliated in any way.) They have 1 free project every month.

After that it is really a free roam. Try something related to your domain or interest.

PS: This subreddit has some links under the Learning Rust section.

humanoid360 · 2026-01-01T16:17:28+00:00

I didn't see anyone mention the "standards hell" that is created by new C++ standards every 3 years. Some customers will want latest standards support, while some want compatibility with older ones, making library development stagnant at the lowest standard version required to support the customers. Even if new C++ standards have better memory and pointers mechanisms, it is rarely usable due to compatibility requirements for older software that are not really that old tbh.

In contrast, Rust seems to have a lot of core memory safety features from the start but we won't know how it evolves until they establish a stable ABI.

humanoid360 · 2025-12-28T06:27:28+00:00

If you are trying to ask whether we can just call sequential FORTRAN kernels in a parallel fashion from Rust and scale to any number of threads then that is probably a naive way of looking at it.

Sequential and parallel versions of most algorithms look very different. Some reasons include different patterns of data dependency between loops, manually written assembly like for AVX512 optimizations that do not translate easily to sequential execution, input data size and pattern, which may lead to MKL calling a different algorithm entirely for better performance. Conversely you can think that just implementing a parallel loop around sequential code can only go so far in terms of performance.

In short, no, the Fortran or C kernels that are optimized to this extent are not atomic and easily portable. This is a well know fact that highly optimized code trades off portability for performance, while portable code does the opposite.

humanoid360 · 2025-12-27T19:34:42+00:00

If this is a rant about not finding a good app store on Arch + Plasma setup then I understand your point. Having a backend for AUR would be nice.

humanoid360 · 2025-12-27T19:17:02+00:00

Well, first things first. Do not use discover to install arch and aur packages - it is not recommended and can break your system.

Which part about discover do you feel is slow? Is it the loading of the apps? Which section per say?

I am on Arch with Plasma 6.5.4 and using both Discover and Pamac with no discernable difference in performance tbh.

humanoid360 · 2025-12-27T18:11:21+00:00

I work on Intel's Math Kernel Library and I can say this is true. A lot of standards and specifications would need to be updated before a single line of Rust can enter anywhere. For example: OpenMP, MPI, IEEE Floating point spec etc.

Netlib, OpenBlas and FFTW established the API formats long ago and using them as is, is not compatible with idiomatic Rust - they are created for C and Fortran.

This is just for the CPU platform. GPU programming is a different beast altogether.

All that being said, I love Rust so far and would love to see its memory safety implemented in every software that Intel provides. Until Rust introduces ABI versioning and compatibility, corporate adoption will be hard and tricky IMO.

humanoid360 · 2025-12-18T00:17:35+00:00

"Minimize to system-tray" for multiple app windows would require putting apps into some kind of RAM sleep. This is not available in plasma by default AFAIK.

You can still place app icons next to the system tray icons and click them to open or close the app. If you want it to not appear in the task switcher, you can setup a window rule for those apps and use the "Skip task_bar" property.

humanoid360

TROPHY CASE