mgunlogson

It does work. Just not very well. Not enough to be widely usable.

If it was an idea it wouldn't have thousands of lines of code and working binaries.

100% infill doesn't remotely solve the problem I'm referring to. I'd ask you not jump to conclusions if you aren't experienced with 3D printing.

Printing 100% infill also wastes a ton of time and material on the interior of the part for nothing. I added a "dual infill shell" feature where you can use a light, fast infill for the interior of the part.

> It wouldn't give you prints that are stronger than those printed with 100% infill even if worked.

This is very speculative and I doubt accurate. Even 100% infill parts are 10X more brittle than injection molded ones and around half the strength. All because of z layer bonding weakness

Yes. It's a modified triangle infill pattern.

A solver pairs the triangle with one of its neighbors. Then cuts a window at the bottom during the slice. So plastic gets injected into the top of a triangle tube and flows through the window at the bottom of the U to its neighbor cell.

Download the binaries and try slicing with magma infill type. Turn off visibility of all the other line types and you'll see how it works

Because that's not accessible.

IMO the reason other efforts to achieve similar Z reinforcement have gone nowhere is because it was one guy fiddling with G-Code. All the big innovations in 3DP have been community projects. Now anyone can download my binaries and try it.

I'm personally very convinced this will work. That's why I did it. We just need to figure out the right settings. Maybe use a different material for injection or coat the nozzle in something.

We'll see. There's a long history of crazy ideas and cold receptions. We even have famous examples from this site https://news.ycombinator.com/item?id=9224

Either I'll end up wrong, and this will fade into obscurity. Or it will turn out I was right and a lot of people will read this comment someday.

Thank you!

A lot of people here took issue with the crappy docs. My mistake, I barely spent any time on them.

The reason this "came out of nowhere" is because I was working on it in secret for a long time. So that patent trolls couldn't screw the 3DP community yet again.

because the plastic has to displace air.

This method seals the nozzle against the tube and injects under pressure (theoretically). And leaves a path for air to escape. Pretty much a micro version of injection molding

Z layer weakness is the main reason that 3d printed parts are brittle and much weaker than injected molded ones.

This is meant to knit together the part in the Z axis

You can set the tube height to like 4mm and that's pretty much what you'll get.

The tubes only need to be tall enough for a "window" at the bottom and a splitter in the middle so that plastic will flow up one side and down the other.

The window height calculations are automatic right now. To make sure the window area is as large as the tubes so it doesn't create a bottleneck that stops flow.

But if you print tiny tubes with a tiny nozzle you could probably get the tube height down to ~3mm.

There's binaries if you want to play with the settings and see it for yourself

> Will this pressure could cause the walls to delaminate from each other or deform?

Nobody knows :) . Give it a try!

> You're also parking the nozzle at the injection points, which will cause a lot of uneven cooling at the surface as well.

There's an "injection fan speed" setting that should probably be kept at 100%.

I'm not sure the "not have any cooling" will be a problem in practice. Because unlike normal printing you're not concentrating all the heat on one layer. It's going down Z dozens-hundreds of layers to already cooled areas of the part printed minutes ago. And the design tries to avoid having nearby tubes end on the same Z. So the area directly adjacent to the tube has probably been cooling for a while.

> So I guess the underlying question should be, does this actually work? What is the measured difference in tension strength between parts printed normally vs with MAGMA infills? Specifically when using the same amount of plastic. There's no data or even pictures that indicate this is working.

No one knows. And I can't test it anymore. The code is done and I have other projects to work on. I've done probably a hundred test prints on my POS Ender 3. I need testers with better hardware. No matter what I try the top of the cell gets melty. This could be the low flow rate of my hotend (limits injection speed), the fairly bad cooling, or maybe something fancier like dual material is needed. Or maybe I just haven't landed on a good combination of settings since there's dozens of them.

I particularly want someone with dual nozzle to test so they can try injecting a low melting plastic like PLA into a heat resistant shell like CF-Nylon or more exotic materials. There's printer plastics that aren't even at glass transition temp when PLA is at printing temperature.

I added dual nozzle and multi material support. Obviously hasn't been tested though

Resin would be very interesting. The tube design seals them everywhere below the top layer. And the two ends of the tube tops are always at the same Z.

You could technically inject anything liquid enough into the tubes. Grout, resin, glue, silicone.

I did some basic calculations on isotropic heat loss in a circular tube. I don't have the knowledge to model it in detail but I don't think this is correct.

You can set tube height to something tiny like 5mm. It takes a fraction of a second to fill that.

As someone who's printed a lot, on fast printers you have to set a minimum layer time because it takes up to 20 seconds for the layer below to solidify, cool to below the glass transition. Plastic is a bad conductor so heat loss through the walls probably isn't as bad as you'd think

It's more than that.

I added a SAT solver to refine the tube endpoints so that nearby tubes don't start or end on the same layers. Even the default greedy solver (CP-SAT is SLOW) does a pretty good job at "staggering" the tube ends.

The part is "knitted" together in 3D at different Z layers.

Try the binaries. They've only been tested in Linux but they build fine for all platforms.

Slice something with MAGMA infill turned on and flip off the visibility of everything but injection lines. You'll see how the U shaped tubes knit the part together

The post was from a week ago. Must have been refreshed by the algo (or admins) for more visibility. Originally never got any comments.

Have you looked at the code or tried the binaries? I can assure you it very much exists as described.

Maybe I should have spent more time on the docs. I had LLM write some of the settings pages and other boring stuff.

The injection probably happens faster than you think. With a high flow hot-end and 5mm deep channels its reasonable for the injection to complete in less than a second.

> How are you expecting this filament to stay as hot as the inside of your nozzle while it’s flowing through the part and touching all of those walls? How are you expecting the walls to not melt, but the melted filament to flow through them?

Specially formulated injection materials with viscosity near water at injection temps. Dual nozzle setups where PLA is injected near its breakdown temperature into a heat resistant shell like CF-Nylon or Ultem. I need people with more time and hardware to test this. This was a side project for me, out of a dozen I'm working on. And I already spent a bunch of time on it.

For a years there's been talk about doing some kind of 3D injection on the GCODE level, like Z-pinning https://github.com/OrcaSlicer/OrcaSlicer/discussions/4815 . But it was hard to experiment because slicers don't support it. Now there's a codebase with dozens of different knobs to play with.

I added support for dual nozzle printers and using a different material for the injection stage. I just don't have the hardware to test it

> The problem that the author is describing is that the plastic is actually far too hot when injected and causes wall collapse. This is because the author isn't taking into account that FDM walls don't handle the required pressure near/above glass-transition points.

Yes exactly. And it may be a solved problem.

I need someone with a dual nozzle printer to try injecting something like PLA in a CF-Nylon part. I anticipated this and added support for dual nozzle and multi-material with a different material selectible for the injected channels. But be warned, it hasn't been tested it at all.

The filament is injected into tiny triangular U shaped channels, about twice as wide as the filament diameter. The depth of the channels is configurable and you can go as shallow as ~4mm. If you inject at a high rate that's not nearly enough time for the filament to cool off.

I actually had the opposite problem in testing. Plastic has bad thermal conductivity and the large volume of plastic in the channel was melting the top of the cell. That's why I asked for testers with dual nozzle printers. So they could try injecting a low melting point material into the channel while printing the rest of the part with something like Polycarbonate or CF-Nylon.

Some of the docs were written by LLM because writing docs is boring. Did you look at the code or try the binaries?

> Reading any of the research on that should make it obvious that you can't "inject" molten plastic into larger cavities, though.

There is quite a bit of research on injection molding. The pressure at the tip of a regular 3DP nozzle is around 200psi. That's actually high enough to inject a reasonably large cavity.

No, unfortunately. I've printed a ton of objects but nothing clean enough to be interesting.

The top of cells always melt as I'm using the same material for injection and the rest of the print. Someone with a dual nozzle printer could try something like PLA injection in a polycarbonate part. I added support but don't have a printer capable of that.

It's also possible that different print settings would work. I'm releasing the features to the community as I've run out of patience with doing a hundred hours of test prints.

We need to crowd test the best settings and nozzles, materials, etc to make this work well

Here for any questions about how it all works :).

Google's Guava Bloom implementation is very well tested. I suggest looking at their guava test GitHub repo. They even use pre-seeded and manually verified filters as controls as some responses suggested.

Or you could just use Guava's Bloom ;)

As for probabilistic testing of fp rate... The problem is that every once in a while a test will fail.

Disclaimer: I wrote a cuckoo filter library.

If you want to test fp rate check my cuckoo filter test at sanityOverFillFilter() in github.com/MGunlogson/CuckooFilter4J/blob/master/src/test/java/com/github/mgunlogson/cuckoofilter4j/TestCuckooFilter.java

The unit test basically does fuzzing, filling the filter repeatedly in the hopes that one day any errors will surface. The error bounds are pretty large but small enough to detect any egregious failures. Importantly, my filter defaults to a random seed. Guava DOES NOT, so any tests using the same items will be deterministic. The guava filters use this property to verify some filters that have been manually determined to be correct

Depends on the language I guess. The most efficient way to represent buckets is to pack the buckets right next to eachother in a giant memory block made of bits. The other part of your question about using a flag, your method definitely works but adds an extra bit when you only need one value for zero.

Using bit flags: Using zero as empty, 4 bits could represent numbers 0-15, so 15 values plus empty/zero. With 5 bits you can represent 0-31, so 30 values plus empty/zero. If you're always using one of your bits for the flag it reduces the uniqueness of a fingerprint by almost 50%.

How the filter is built in memory: At least in Java, the best way to build the backing data structure is a giant array of longs. Really what you want is just a giant block of memory you can address by bit offset. Unfortunately modern CPU's can only index into a byte offset. Because of this, buckets and fingerprints can overlap byte boundaries. To make this happen as little as possible, it's best to go the other way and index into the largest primitive structure the CPU supports. In Java at least, this means you want to simulate bit-addressable memory using a long array.

My java filter uses a Bitset implementation borrowed from Apache Lucene because the Java builtin Bitset only allows a 32 bit index(same with java array indices). You would think this limits you to a 2GB filter but it's actually only around 270MB since the Bitset indexes are a 32 bit int. Anyways, the Lucene Bitset uses a long array to simulate bit addressable memory.

Using regular arrays of booleans doesn't work in higher level languages unfortunately. They tend to use CPU supported primitives underneath so for example a boolean could take up a byte underneath. Every Cuckoo filter library I know of besides the reference implementation and mine doesn't handle this properly and is extremely space-inefficient :(.

No problem, The paper authors left a lot of the specifics off... I got burned by the victim cache too. I saw one in their reference code and thought it was pointless until weeks later when I got around to writing tests and had one of those aha moments.

The code should use bits, the point of the filter is to increase space efficiency so you need to pack everything together as close as possible. Having fingerprint sizes of only multiples of 8 bits doesn't make sense.

Also, from the quote, it's probably more accurate to say a Cuckoo filter is identified by it's fingerprint size, bucket size, and capacity. In most implementations the bucket size is fixed at 4, so you can define a filter with only fingerprint size and capacity.

And yes, deleting can cause false negatives but only in a roundabout way. Deleting will only cause false negatives if you delete something that wasn't added previously. Because the filter has false positives, sometimes it will tell you it's seen an item that it hasn't. If you delete one of these false positives it will cause a false negative. If you only delete items that have been added before, and in the case of duplicate items, added the same number of times, you won't get any false negatives.

Essentially if you saved a log of all the inserts then replayed it as deletions you would have a perfectly empty filter every time with no false negatives. I actually have a unit test that does this in my java Cuckoo filter :), it exorcised quite a few demons from the code.

If you're curious the unit test is sanityFillDeleteAllAndCheckABunchOfStuff() in https://github.com/MGunlogson/CuckooFilter4J/blob/master/src...

Hi there, I've wrestled with Cuckoo filters myself, so I took a look at your lib and there's a some things that stood out.

Fingerprint size- It allows fingerprints that are too short, basically less than 4 bits doesn't allow a reasonable fill capacity. The paper authors only hinted at this, but check out the fill capacity graphs on page 6. This could be why your inserts are slowing down around 80% level when in my experience it doesn't happen till around 93%.

Modulo bias - Your filter capacity code doesn't seem to round the filter size to a power of two. This is a simple fix, but without it your array indexes will be skewed by modulo bias, possibly badly if someone picks a nasty number.

Alternate bucket positions - Your code seems to do a full hash for calculating alternate bucket positions. I know the paper mentions this, but I haven't seen anyone actually doing it :). Its a lot faster to just XOR with a mixing constant. TBH that's what most libraries are doing... whether it's a good idea is debatable :).

Fingerprint zero corner case - I'm not that great at python, but I didn't see any special handling for the rare case that the hash fingerprint is zero. In most implementations zero means empty bucket, so this could violate the "no false negatives" aspect of the filter by making items rarely disappear when they were supposed to be inserted. Most implementations either just add one to it, but I prefer to re-hash with a salt.

No victim cache - Didn't look too much into it, but I didn't see a victim slot used in your code. This will cause problems when the first insert fails. The problem is, by the time the first insert actually fails, you've relocated a bunch of different fingerprints like 500 times. It becomes unclear which fingerprint you originally tried to insert, and you're left holding a dangling item from a random place in the filter that you cannot insert. This violates the "no false negatives" mantra. Even though the filter is full it shouldn't break by deleting a random item when the first insert fails. You either need to store this last item or figure out a way to unwind your insert attempts to be able to reject the item that originally failed to insert.

Check out my Java library if you want to see how I dealt with these things. Also I have a bunch of unit tests there that I either came up with or borrowed from other Cuckoo libs. Should be pretty easy to convert some of those to python :) .

https://github.com/MGunlogson/CuckooFilter4J

Cheers, Mark

The thing with Cuckoo filters is that the item's alternate position is determined solely from it's current position and fingerprint.

Mathematically this is done by XOR'ing with a magic mixing constant borrowed from Murmur2 :) (or in my lib from Mumur3). The quality of the randomness of alternate bucket positions is...probably bad, but in practice it seems to work fine.

Because of this finding alternate positions doesn't require a rehash per se, just a few CPU instructions.

However, there IS a corner case that requires re-hash that comes up more frequently the shorter the fingerprints used. Conceptually a tag/fingerprint of zero means empty bucket, and occasionally the fingerprint hash for an item will end up being zero. In this case I've seen some libraries just add 1, which I didn't really like since it increases hash collisions slightly. Or you can do it like my lib does and just re-hash the item with a salt.

Hmmm.... this might be an artifact of the python implementation?

The insert speed should be roughly constant until the filter begins moving items into their alternate buckets(when one of the two buckets for that item is full). In my implementation this doesn't usually happen until well over 90% capacity.

Insert speed will slow slightly as the filters fills up if the implementation uses a shortcut to determine the first empty bucket position by just checking if it's zero. Conceptually, if a bucket is empty you only need to check the first position before the insert. When the filter is half full you need to check ~%50 of bucket positions before an insert. In practice the bucket operations are so fast and buckets only hold 4 items each, I haven't noticed a difference.

Just so nobody is confused, HyperLogLog etc. are used for a different operation than Bloom/Cuckoo filters.

HLL is used to determine how many unique items you have, the cardinality of a set.

Bloom/Cuckoo is used to determine set membership, as in "have I seen this item before".

Not sure how much that helps but the distinction was lost on me when I started reading about them.

I try to think of these filters as the opposite of a cache. Bloom/Cuckoo has no false negatives and a cache has no false positives. Besides this they are very similar conceptually and used in the similar contexts.

I built a cuckoo filter library in Java that nobody uses :) https://github.com/MGunlogson/CuckooFilter4J

So this bot also creates fake hackernews upvotes? because it's fairly obvious that it does...Nothing in the last 20 hours has more than 10 upvotes in Show HN