Feature requests

[Wilrick-AESC]

Hi,

First off, amazing work. Jagua-rs itself works great and is incredibly fast compared to other solutions. Working with the script, there are a few things we're looking at implementing and were wondering if these are on your radar, or if you would be able to offer any guidance so we're able to implement these features ourselves, happy to create pull requests if we're able to do so.

• Distance between items (and distance from side of the bin)
• Set sheet sizes instead of strip, adding new sheets once the first is full
• Additional algorithms besides lbf > implementation of different crates has been a struggle so far so any guidance you have on coupling additional crates like babushka that would be greatly appreciated.

Many thanks,

Wilrick

[JeroenGar]

Hi Wilrick,

Thanks for taking interest in this project!

We have written an extensive paper explaining the philosophy and inner workings behind jagua-rs, which could help you understand the scope of the project a bit better.
I wish I could share the paper with you, but it unfortunately is still under peer review at this moment.

For the time being, let me briefly go through your questions:

Additional algorithms besides lbf

The lbf algorithm is only meant as a showcase for how to interact with jagua-rs. Its performance is not good at all.
I am however currently finalizing a strip packing heuristic that competes with the academic state-of-the-art in strip packing problems.
Once the algorithm is finished and the paper is submitted I will make this repository public.

Set sheet sizes instead of strip, adding new sheets once the first is full

jagua-rs (and lbf) currently support both strip-packing and bin-packing problems. What you are describing (if I understand correctly) is the bin packing problem. See BPInstance and BPProblem docs.

Distance between items (and distance from side of the bin)

This could be interesting! There is a trait called Distance and SeparationDistance which geometric primitives can implement to calculate distances between each other. But there is currently no implementation for one SimplePolygon to another, since I never needed this.
Feel free to implement them!

any guidance you have on coupling additional crates like babushka that would be greatly appreciated.

Could you elaborate what this would be useful for?

Jeroen

[Wilrick-AESC]

Hi Jeroen,

Thanks for your answer! Very much looking forward to reading the paper once it's reviewed.

I'll look into the initial points, definitely enough to continue with so thanks a lot for the info. Concerning babushka, I think I should have elaborated more on what I needed from it instead of the crate itself: it provides the option to fill polygons with holes with additional items. Considering you're working on a new strip-packing solution I'm curious if this is something you've considered in your approach.

I'm working for a company based in the Netherlands focused on software for the manufacturing industry. Jagua-rs seems like a great fit for one of our software packages, so we're interested to see how this project continues in the future. If you're open to it we'd be glad to have a chat about our possible implementation and the use-case itself.

Thanks again for your time and detailed answer!

Wilrick

[JeroenGar]

it provides the option to fill polygons with holes with additional items. Considering you're working on a new strip-packing solution I'm curious if this is something you've considered in your approach.

As of now only simple polygons (no holes) are supported. I am currently finalizing the strip-packing algorithm so I will also not consider them here. (the academic world largely ignores them for some reason)

However, I do recognize that this is an important feature to support. In fact, #5 is also requesting this.
The collision detection engine in jagua-rs is, in essence, based on simple trigonometry (just sped up a lot 🙂)
It would be relatively easy to add support for polygons with holes.

There are 3 main ways I can think of right now to implement this:

• Add native support (by modifying geometry and collision_detection modules).
• Write a preprocessor to convert them to simple polygons (as I explained in Polygon and MultiPolygon support? #5).
• "Fill" the holes and add a "virtual" bin for every hole.

I'm not sure what the best approach would be, as they all have strengths and drawbacks.

If you're open to it we'd be glad to have a chat about our possible implementation and the use-case itself.

I'd be down to have a chat about a possible implementation!
You can reach my using my university email: jeroen.gardeyn[at]kuleuven.be

Jeroen