Compartments for shelled bins

[trohnjavolta]

Hi, first of all thx for this, it's awesome!

I already read that with shelled bins the compartments option isn't possible but since it says "currently" I guess it's not ruled out :) Is there any ETA when compartments will be possible for shelled bins?

[Le0Michine]

Hi, that's not very high on my priorities list. The reason being is that it's quite hard to adapt the way compartments are generated at the moment (they are subtracted from a solid body representing internal space of the bin). And in combination with scoop fillet I'm not sure "shelled" part would make sense anymore as there won't be much difference in neither capacity nor material comparing to regular bins

[trohnjavolta]

Too bad, but I can imagine it wouldn't be easy to implement. Iwas fiddling around in fusion earlier and after deleting a few surfaces I could add a rounding: https://ibb.co/Wk91zt1

I'm printing it right now, I'm just trying different bins out and see which ones I like best.

[Nickduino]

Would it be possible to grey out an option if it's unavailable?

[Nickduino]

Hi, that's not very high on my priorities list. The reason being is that it's quite hard to adapt the way compartments are generated at the moment (they are subtracted from a solid body representing internal space of the bin)

I just tested something and it worked. I generated a bin with compartments with your script, suppressed the bottom fillets of the compartments (I removed them from the bodies that were used for the cuts) and then shelled the finished body from the bottom of the compartments (leaving one as is to show what I started with).

And voilà:

I personally think it's worth it to implement it (so, if shelled is ticked, don't fillet but shell the bottom of the bins) as a hollow box uses more filament (40% more on my test without compartments) and take longer to print (20% longer on my test without compartments) than a shelled one.

[Nickduino]

so, if shelled is ticked, don't fillet

So just don't pass the input.hasBottomFillet argument as True when calling binBodyCutoutGenerator.py for a bin that is shelled and has compartments ?

but shell the bottom of the bins

Just pass the right faces to shellUtils.py?

[Le0Michine]

How does it behave when compartments don't match base grid?

[Nickduino]

How does it behave when compartments don't match base grid?

You're right, it's less than optimal, as the walls hover over the bottom:

Still better than nothing but not great.

[Nickduino]

Here's an alternative approach that should work and not be too complex to implement:

Currently, from the input grid, you create bodies representing the compartments and you subtract them from the box. You could keep most of that math to calculate the section of the compartments, subtract them from the section of the box to get the section of the walls and then extrude the walls to object:

[Nickduino]

I've also compared both options in PrusaSlicer, the hollow ones need 50% more material:

Hope this helps.

[Le0Michine]

not to be nit picky, but that is 34-35% which would also depend a lot on the height, amount of internal walls, width and length of a bin. I don't disagree with that it would be nice though.

Unfortunately I don't thing the proposed solution would work for a script, extend to object isn't very stable even when used within the UI (often it would just fail in one case and succeed in a very similar situation) unless it is extending to a flat surface. Another concern is that even if we get it to work it will likely break with one of the Fusion upgrades which keeps happening with much simpler features already.

I think it is possible to get it working but through a different set of operations similar to how those cutouts done already. If we get positive volume to include internal volume of shelled base then negative volume can be modelled in a way so it is reaches all the way down. That will also require rerouting shelled bin flow into the same path as for the other kinds.

[Nickduino]

not to be nit picky, but that is 34-35% which would also depend a lot on the height, amount of internal walls, width and length of a bin. I don't disagree with that it would be nice though.

64.91/43.27 = 1.5001155535012710885139819736538 The hollow one requires 50.011555% more filament than the shelled one. (Which means the shelled version saves 33% filament compared to the hollow one)

Unfortunately I don't thing the proposed solution would work for a script, extend to object isn't very stable even when used within the UI (often it would just fail in one case and succeed in a very similar situation) unless it is extending to a flat surface. Another concern is that even if we get it to work it will likely break with one of the Fusion upgrades which keeps happening with much simpler features already.

Good to know

I think it is possible to get it working but through a different set of operations similar to how those cutouts done already. If we get positive volume to include internal volume of shelled base then negative volume can be modelled in a way so it is reaches all the way down. That will also require rerouting shelled bin flow into the same path as for the other kinds.

You lost me there

[Le0Michine]

My bad on the math there. Somehow I read it as twice as more plastic which isn’t what you wrote 😀

[Nickduino]

If A needed 50% less than B, B would need twice as much as A ^^