A Universal, Non-planar Slicer For 3D Printing Is Worth Thinking About

One may think that when it comes to 3D printing, slicing software is pretty much a solved problem. Take a 3D model, slice it into flat layers equal to layer height, and make a toolpath so the nozzle can create those layers one at a time. However, as 3D printing becomes more complex and capable, this “flat planar slicing” approach will eventually become a limitation because a series of flat slices won’t necessarily the best way to treat all objects (nor all materials or toolheads, for that matter.)

How a 20 mm cube looks when sliced in a cone-shaped plane.

[René K. Müller] works to re-imagine slicing itself, and shows off the results of slicing 3D models using non-planar geometries. There are loads of pictures of a 20 mm cube being sliced with a variety of different geometries, so be sure to give it a look. There’s a video embedded below the page break that covers the main points.

It’s all forward-thinking stuff, and [René] certainly makes some compelling points in favor of a need for universal slicing; a system capable of handling any geometry, with the freedom to process along any path or direction. This is a concept that raises other interesting questions, too. For example, when slicing a 20 mm cube with non-planar geometries, the resulting slices often look strange. What’s the best way to create a toolpath for such a slice? After all, some slicing geometries are clearly better for the object, but can’t be accommodated by normal hot ends (that’s where a rotating, tilted nozzle comes in.)

Such worries may not be an issue for most users at the moment, but it’s worth trying to get ahead of the curve on something like this. And lest anyone think that non-planar slicing has no practical purpose, we previously covered [René]’s demonstration of how non-planar slicing can reliably create 90° overhangs with no supports.

Continue reading “A Universal, Non-planar Slicer For 3D Printing Is Worth Thinking About”

Meet The RouterPi, A Compute Module 4 Based GbE Router

[Zak Kemble] likes to build things, and for several years has been pining over various Raspberry Pi products with an eye on putting them into service as a router. Sadly, none of them so far provided what he was looking for with regard to the raw throughput of the Gigabit Ethernet ports. His hopes were renewed when the Compute Module 4 came on scene, and [Zak] set out to turn the CM4 module into a full Gigabit Ethernet router. The project is documented on his excellent website, and sources are provided via a link to GitHub.

A view underneath shows off the RTC, power supply, and more.

Of course the Compute Module 4 is just a module- it’s designed to be built into another product, and this is one of the many things differentiating it from a traditional Raspberry Pi. [Zak] designed a simple two layer PCB that breaks out the CM4’s main features. But a router with just one Ethernet port, even if it’s GbE, isn’t really a router. [Zak] added a Realtek RTL8111HS GbE controller to the PCIe bus, ensuring that he’d be able to get the full bandwidth of the device.

The list of fancy addons is fairly long, but it includes such neat hacks as the ability to power other network devices by passing through the 12 V power supply, having a poweroff button and a hard reset button, and even including an environmental sensor (although he doesn’t go into why… but why not, right?).

Testing the RouterPi uncovered some performance bottlenecks that were solved with some clever tweaks to the software that assigned different ports an tasks to different CPU cores. Overall, it’s a great looking device and has been successfully server [Zak] as a router, a DNS resolver, and more- what more can you ask for from an experimental project?

This CM4 based project is a wonderful contrast to Cisco’s first network product, which in itself was innovative at the the time, but definitely didn’t have Gigabit Ethernet. Thanks to [Adrian] for the tip!

Optimized Super Mario 64 Offers Exciting Possibilities

When working on any software project, the developers have to balance releasing on time with optimizations. As long as you are hitting your desired time constraints, why not just ship it earlier? It’s no secret that Super Mario 64, a hotly anticipated launch title for the Nintendo 64 console in 1996, had a lot of optimizations left on the table in order to get it out the door on time. In that spirit, [Kaze Emanuar] has been plumbing the depths of the code, refactoring and tweaking until he had a version with serious performance gains.

Why would anyone spend time improving the code for an old game that only runs on hardware released over two decades ago? There exists a healthy modding community for the game, and many of the newer levels that people are creating are more ambitious than what the original game could handle. But with the performance improvements that [Kaze] has been working on, your budget for larger and more complex levels suddenly becomes much more significant. In addition, it’s rumored that a multi-player mode was originally planned for the game, but Nintendo had to scrap the feature when it was found that the frame rate while rendering two cameras wasn’t up to snuff. With these optimizations, the game can now handle two players easily.

Luigi has been waiting 26 years for his chance to shine.

[Kaze] has a multi-step plan for improving the performance involving RAM alignment, compiler optimizations, rendering improvements, physics optimizations, and generally reducing “jankiness.” To be fair to the developers at Nintendo, back then they were working with brand new hardware and pushing the boundaries of what home consoles were capable of. Modeling software, toolchains, compilers, and other supporting infrastructure have vastly improved over the last 20+ years. Along the way, we’ve picked up many tricks around rendering that just weren’t as common back then.

The central theme of [Kaze]’s work is optimizing Rambus usage. As the RCP and the CPU have to share it, the goal is to have as little contention as possible. This means laying out items to improve cachability and asking the compiler to generate smaller code rather than faster code (no loop unrolling here). In addition, certain data structures can be put into particular regions of memory that are write-only or read-only to improve resource contention. Logic bugs are fixed and rendering techniques were improved. The initial results are quite impressive, and while he isn’t done, we’re very much looking forward to playing with the final product.

With the Nintendo 64 on its way to becoming a mainline-supported Linux platform, the old console is certainly seeing a lot of love these days.

Continue reading “Optimized Super Mario 64 Offers Exciting Possibilities”

Arm Pumps Up The Volume With Mbed And A Potentiometer

Last time, I told you how to get started with the “Black Pill” STM32F411 board using the Mbed OS. The example program, admittedly, didn’t use many of the features of the OS, unless you count what the USB serial port driver uses behind the scenes. However, this time, we’ll make a practical toy that lets you adjust your PC’s volume level with a pot.

The Black Pill module on a breadboard.

The Black Pill is a good choice for this application since it has analog inputs and can act as a USB keyboard. In fact, the Mbed OS has drivers for all kinds of USB devices. We’ve seen the serial port, but you can also look like a mass storage device or a mouse, for example. Just for practice, we’ll create two threads of execution. One will read the pot and send a message over to the other thread. That thread will communicate with the PC as a USB keyboard. Any computer that understands media keys on a keyboard should work with the device.

Threads

Creating threads is very simple. For many cases, you just define a void function that takes no arguments and use it with a Thread object:

readknobThread.start(vol_thread);

Of course, the function shouldn’t return unless you want the thread to end. As I mentioned in the last post, you can sleep with the ThisThread::sleep_for call. There is also a yield call if you simply want to give up the time slice without sleeping for a specific amount of time.

Continue reading “Arm Pumps Up The Volume With Mbed And A Potentiometer”

Twitch And Blink Your Way Through Typing With This Facial Keyboard

For those that haven’t experienced it, the early days of parenthood are challenging, to say the least. Trying to get anything accomplished with a raging case of sleep deprivation is hard enough, but the little bundle of joy who always seems to need to be in physical contact with you makes doing things with your hands nigh impossible. What’s the new parent to do when it comes time to be gainfully employed?

Finding himself in such a boat, [Fletcher]’s solution was to build a face-activated keyboard to work around his offspring’s needs. Before you ask: no, voice recognition software wouldn’t work, at least according to the sleepy little boss who protests noisy awakenings. The solution instead was to first try OpenCV and the dlib facial recognition library to watch [Fletcher] blinking out Morse code. While that sorta-kinda worked, one’s blinkers can’t long endure such a workout, so he moved on to an easier set of gestures. Mouthing Morse code covers most of the keyboard, while a combination of eye, eyebrow, and other facial twitches and tics cover the rest, with MediaPipe’s Face Mesh doing the heavy-lifting in terms of landmark detection.

The resulting facial keyboard, aptly dubbed “CheekyKeys,” performed well enough for [Fletcher] to use for a skills test during an interview with a Big Tech Company. Imagining the interviewer on the other end watching him convulse his way through the interview was worth the price of admission, and we don’t even care if it was a put-on. Video after the break.

CheekyKeys is pretty cool, doing something with a webcam and Python that we thought would have needed a dedicated AI depth camera to accomplish. But perhaps the real hack here was how [Fletcher] taught himself Morse in fifteen minutes.

Continue reading “Twitch And Blink Your Way Through Typing With This Facial Keyboard”

Wordle Comes To The Nokia N-Gage Thanks To New SDK

You probably never imagined you’d be reading about new software getting developed for Nokia’s infamous N-Gage handheld game system in 2022, and we certainly never thought we’d be writing about it. But here we are. Of course, we aren’t talking about a commercial title — this is an unofficial port of Wordle by “taco phone” superfan [Michael Fitzmayer].

[Michael] tells us that this first version is pretty simplistic, and currently uses a single word list with all 2,309 terms in the New York Times version. Translations to Finnish, Russian, and German are in the works, though interestingly it looks like the effort is currently stymied by the fact that the code doesn’t support words with hyphens in them; meaning it’s possible to find yourself in an unwinnable situation if you’re playing in Russian. We’re sure that’s just a coincidence and not meant as any kind of political commentary, but still…you can’t make this stuff up.

In Soviet Russia, N-Gage plays you!

So how does one go about developing a new game for a failed console from the early 2000s? The answer is by using the modern N-Gage SDK that’s is currently in development, which lets you write code for the system using popular tools and libraries like Visual Studio 2022, CMake, and SDL. But [Michael] isn’t just a user of this new SDK, he’s also the brains behind the operation.

The hope is this new development platform will lead to something of a renaissance for the maligned device, and he’s even started a Discord server to discuss the past, future, and present of sidetalkin’. If you’re surprised to find yourself looking up what a used N-Gage goes for on eBay these days, join the club.

Hacked GDB Dashboard Puts It All On Display

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.