Packing with unknown box size

[patrick-fls]

Hey there,

We're in a situation where we have a machine that can create a box on the fly with set dimensions.

Would there be an easy way to adapt the code so that it packs like does right now, but then outputs what box size would be required to pack what was calculated?

[dvdoug]

Yes...and no.

The algorithm is designed around making decisions about orientations of items within a space, so changing that to work within an unbounded volume would be very hard I think.

However, each PackedBox has getUsed[Width|Length|Depth()] methods which represent the hypothetical box that encapsulates the contents - if you came up with a set of rough sizes to use as input boxes (e.g. small/medium/large) I think you'd get pretty reasonable solutions for the hypothetical ones.

Note, you probably wouldn't just be able to use just a single a very large fake box because the algorithm would try to pack everything along the bottom and you'd end up with a solution that's very wide and shallow, whereas in real life you'd probably want your created box to be something more cube-like.

[iget-esoares]

First thanks @dvdoug for this package.

This is a need for us too, because I have the following situation: to get a shipping quote from an API I need to know the size of the box that will be sent.

Our client have a few default boxes to some products. That's fine to solve. But the shipping API doesn't accept multiple boxes, so I want to know the size of a box that fit all boxes in order to get a quote.

[mobyg]

Hey there @dvdoug thanks for this package - one question I had is in regards to the documentation - I notice when going over the examples ("Packing a set of items into a given set of box types") there are 8 parameters passed to new TestBox, not including the name - and similarly there are 4 passed to new TestItem, not including the name or the boolean for keeping the item flat. Is there a reason for this? Could we get a breakdown of what those parameters are?

For example:

$packer->addBox(new TestBox('Le petite box', 300, 300, 10, 10, 296, 296, 8, 1000));

$packer->addItem(new TestItem('Item 1', 250, 250, 12, 200, true));

What are the parameters these values are being passed as?

Thanks!

[dvdoug]

@garryhicks the interfaces (https://github.com/dvdoug/BoxPacker/blob/master/src/Item.php and https://github.com/dvdoug/BoxPacker/blob/master/src/Box.php) explain them a little more, but perhaps that page of the docs could explain it too - essentially, because boxes have walls there is a small difference between the external dimensions of the box that you'd give out to e.g. a shipping company, and the internal dimensions of the space inside the box for packing the items into. Although the library itself only uses the internal dimensions, it enforces the distinction on consuming applications so that people remember to actually measure things.

Otherwise people get a nasty surprise when they try and pack something and it doesn't quite fit :)

[dvdoug]

@iget-esoares sincere apologies for the delay, but could you expand on your usecase a little more?

[sandrodz]

@dvdoug Use case could be following:

• Shop makes its own boxes, any size. Shipping company accepts these without an issue.

Consequence:

1. No need to create pre-defined box sizes.
2. Algorithm, taking item sizes, finds out what box would fit all those items together.

Essentially this is bin-packing without the bin.

[dvdoug]

@sandrodz I get that use case, I'm confused by the notion of creating a big fake box for a shipping API that can't accept multiple real life boxes - the price returned for that wouldn't match the price for shipping the actual multiple quantity of the real ones?

[sandrodz]

¯_(ツ)_/¯ You are right, it is a far fetched use case.

[noknokcody]

Potentially interested in sponsoring development of this feature if it's in the interests of the developer.