jasonrhansen/cut-optimizer-2d

Cut count optimization

Opened this issue · 3 comments

I found a trivial case where human layout scores better than cut_optimizer_2d driven layout. I have documented it below.

My scoring criteria was reducing waste (no change) and reducing cut lines (human solution preferred).

Thank you for authoring this lovely piece of software.

Screen Shot 2022-03-07 at 8 24 24 AM

Source

use cut_optimizer_2d::CutPiece;
use cut_optimizer_2d::Optimizer;
use cut_optimizer_2d::PatternDirection;
use cut_optimizer_2d::StockPiece;

fn main() {
    let plywood = StockPiece {
        width: 1220,
        length: 2240,
        pattern_direction: PatternDirection::ParallelToLength,
        price: 130,
        quantity: Some(1),
    };

    let top = CutPiece {
        external_id: Some(1),
        width: 500,
        length: 835,
        can_rotate: false,
        pattern_direction: PatternDirection::ParallelToLength,
    };

    let left = CutPiece {
        external_id: Some(2),
        width: 500,
        length: 1250,
        can_rotate: false,
        pattern_direction: PatternDirection::ParallelToLength,
    };

    let right = CutPiece {
        external_id: Some(2),
        width: 500,
        length: 1250,
        can_rotate: false,
        pattern_direction: PatternDirection::ParallelToLength,
    };

    let bottom = CutPiece {
        external_id: Some(3),
        width: 575,
        length: 875,
        can_rotate: false,
        pattern_direction: PatternDirection::ParallelToLength,
    };

    let mut optimizer = Optimizer::new();
    optimizer.add_stock_piece(plywood);
    optimizer.add_cut_piece(top);
    optimizer.add_cut_piece(left);
    optimizer.add_cut_piece(right);
    optimizer.add_cut_piece(bottom);
    optimizer.set_cut_width(2);

    fn simple_callback(_: f64) {
        // print!("Progress {}", progress);
    }

    let result = optimizer.optimize_guillotine(simple_callback);

    match result {
        Err(error) => println!("error!, {:?}", error),
        Ok(solution) => {
            println!("Fitness: {}", solution.fitness);
            println!("Stock pieces: {}", solution.stock_pieces.len());

            for stock_piece in solution.stock_pieces {
                println!("Stock: {}x{}", stock_piece.length, stock_piece.width);
                for cut_piece in stock_piece.cut_pieces {
                    println!(
                        "Cut piece: {}x{} at X={} Y={}",
                        cut_piece.length, cut_piece.width, cut_piece.x, cut_piece.y
                    );
                }
            }
        }
    }
}

Output

Fitness: 0.6325602099578904
Stock pieces: 1
Stock: 2240x1220
Cut piece: 875x575 at X=0 Y=0
Cut piece: 1250x500 at X=0 Y=877
Cut piece: 1250x500 at X=577 Y=0
Cut piece: 835x500 at X=577 Y=1252

I will admit, the cut_optimizer_2d solution is better if you're scoring for sequential first rips. Would love to hear your thoughts on this.

The fitness of a solution doesn't currently take cuts into account. It's mostly driven by the ratio free_area / total_area. It's not immediately clear to me how I would add cuts into the equation, but maybe I'll play around with it when I get some time.

Thanks for the info. I do think cut count should be considered, otherwise really bizarre solutions could be given, such as no pieces touching