Packing and Cutting Stone Blocks Based on the Nonlinear Programming of Tree Cases

Abstract

Typically, dimension stones, commonly called stone blocks, are cut into multiple small cuboid stones so that multiple sculptures can be produced. To use the stone block as efficiently as possible, it is essential to pack these small cuboids in each stone block as efficiently as possible while satisfying the limitations of the machining. This paper describes methods for packing and cutting stone blocks using nonlinear programming that generate sets of trees, which are also called forests, that decide the packing layout of the small cuboids inside the block. The containers and elements have their own prices and values, respectively. The elements can be translated to the corners of the containers or to the corners of the elements that are already in the containers, if the elements are not outside the containers after the translation. Then, the problem can be interpreted as finding the best forest that packs the elements as efficiently as possible at the lowest total price of containers, which is a subset of all containers. The formula for the score that defines the compactness of the packing is in this paper. The user can define the number of forests so that parallel computing methods can be applied. Each forest is generated randomly. Two different packing methods are introduced: simple packing and slab packing. Simple packing is based on a non-guillotine cutting method and slab packing is a guillotine cutting method for realistic scenarios, such as scenarios with machining limitations. By using this method, it is possible to plan the cutting in a digital environment, which is not possible when using the traditional method with physical templates. Furthermore, by restricting the rotation of the elements, it is possible to make the elements follow the horizontal vein direction of the stone blocks, which is a common vein direction in travertine.

1. Introduction

Stone blocks, also known as dimension stones, typically have a cuboid shape. This shape preference comes mainly from logistics requirements, machining, the characteristics of the quarry, and demands from the market [1]. Based on this shape preference, the quarry can develop an optimized plan for stone block production to avoid fractures using the voxel method [2]. After producing the stone blocks, the blocks are cut to the size of a single sculpture or divided into multiple small stones for multiple sculptures, depending on the project. Through the production cycle, an immense amount of waste can be produced [3]; therefore, it is critical to pack the products in the stone block as efficiently as possible to reduce waste.

The traditional method of packing shapes in a stone block is to use plastic templates on the side surface of the stone block and physically adjust the templates (see Figure 1). This method is limited to a two-dimensional packing layout, and there can be a potential risk of industrial accidents, as workers have to be close to the stone block and the machine.

If there is no limit in the production strategy, this problem can be interpreted as a discrete geometry packing problem, avoiding collision using no-fit polygons [4,5], the Gilbert–Johnson–Keerthi (GJK) algorithm [6], the Expanding Polytope Algorithm (EPA) [7], and so on, which are solutions for the Minkowski sum and difference problem [8,9]. Alternatively, one study used the elastic energy of a rubber band to achieve compact packing [10]. Some studies shows two-dimensional packing solutions [11,12,13]. However, the stone block cutting strategy usually requires a blade or a wire saw, which limits the freedom of packing (see Figure 2 and Figure 3). For this reason, it is more practical to redefine the problem as a problem involving packing shapes in the small stone cuboids that come from the split of the original stone block. This can also be described as the guillotine cutting problem. There are several studies on two- and three-dimensional guillotine cutting problems [14,15,16,17,18]. However, in their three-dimensional studies, ref. [15] has the restriction of using only one block, and ref. [14,18] does not consider the prices of the stone blocks and the value of the small cuboids that will be packed into the stone blocks.

The method in this paper sees this guillotine cutting problem from a graph-theoretic perspective as a problem involving growing trees and forests. The general definition of a tree describes it as a undirected graph consisting of nodes and edges without cycles. However, the method in this paper uses a specific type of tree called a directed rooted tree. A forest is a collection of these trees. Some of the early studies on trees and forests were Cayley’s studies, which concentrated on the enumeration of tree and forest problems [19,20], and, since then, this topic has been well studied by several researchers. These studies have been widely applied in different areas of various industries such as circuit analysis in electrical engineering, databases in data science, game theory, and even recent machine learning studies, etc. [21,22,23,24]. The application of tree theory can also be found in relation to the guillotine cutting problem [25,26]. Still, these approaches are limited to two-dimensional environments.

This paper suggests a method that considers practical manufacturing constraints while using blade and wire saw machines. Its consideration of the prices and values of the stone blocks and elements in the computer environment improves the efficiency of using the stone block. Furthermore, the computation time of this method can be improved by parallelizing the computing processes of tree and forest growth. The packing locations are the nodes. Each stone block forms one tree. After the elements are placed on the nodes in the stone blocks, they generate new nodes and branches connecting with the parent nodes, which is the growth of the trees. Thus, a forest encompasses packing in multiple available stone blocks. Each processor on a computer computes the growth of each forest, allowing parallel computing.

Section 2 shows the fundamental formation of the tree-based cuboid packing algorithm. Section 2.1 introduces the simple packing method. Section 2.2, Section 2.3 and Section 2.4 introduce the slab packing algorithm method, the description of the rotation of elements, and the definition of the score for each forest. In Section 4, an analysis of the introduced slab packing method is shown. Section 5 shows a discussion of the results, their meaning for practical applications, and the advantages and disadvantages of the introduced method.

2. Formulation

The shape of the sculpture defines the shape of the required cuboid, which is called an element in this paper. A stone block that may contain one or more elements is called a container. The problem involves packing the elements in $\mathbf{E}$ as efficiently as possible in the containers in $\mathbf{C}$. $\mathbf{E}$ can be defined with a set of the minimum bounding boxes of the sculptures [27] or the user-defined cuboids. $\mathbf{C}$ is the set of cuboids of the containers. Each element has a designated value $p_i^{\mathbf{E}}>0,(i=1,\cdots ,n)$, and each container has a designated price $p_j^{\mathbf{C}}>0,(j=1,\cdots ,m)$. Thus, an element and its value can be expressed as $\left(e_i\in \mathbf{E},p_i^{\mathbf{E}}\in {\mathbf{P}}^{\mathbf{E}}\right)$ and a container and its price can be expressed as $\left(c_j\in \mathbf{C},p_j^{\mathbf{C}}\in {\mathbf{P}}^{\mathbf{C}}\right)$. $e_i$ and $c_j$ have eight vertices in ${\mathbb{R}}^3$ that define the shape of the element and container:

$$\begin{array}{cc}\hfill e_i& =\{v_1^{e_i},v_2^{e_i},v_3^{e_i},v_4^{e_i},v_5^{e_i},v_6^{e_i},v_7^{e_i},v_8^{e_i}\}\hfill \\ \hfill c_j& =\{v_1^{c_j},v_2^{c_j},v_3^{c_j},v_4^{c_j},v_5^{c_j},v_6^{c_j},v_7^{e_i},v_8^{e_i}\}\hfill \end{array}$$

(1)

The order of the vertices is shown in Figure 4. f is the number of forests. Each processor of the computer computes the growth of each forest through nonlinear programming. The orders of the elements and containers are duplicated and shuffled f times. Each set of shuffled elements and the set of shuffled containers are ${\mathbf{E}}_k$ and ${\mathbf{C}}_k$, $(k=1,\cdots ,f)$, respectively. $Shuffl{e}_q(\cdots )$ denotes the shuffle of the items with seed q. $Shuffl{e}_q(\cdots )$ returns the same order of shuffled items when the number of items and q are the same.

With the nonlinear programming of the forests using the collection of the vertices of the packed $e_i$ and $\mathbf{C}$, the introduced method can have a finite number of solutions. However, due to the immense number of cases of tree growth in the forest and the packing preference in the used containers, this algorithm randomly chooses one of the new leaf nodes for each growth first. If the element can fit inside the container after being translated to one of the leaf nodes, three child nodes are added, which are candidates for the next locations for the elements. Although it cannot guarantee that all elements will be inside the containers in $\mathbf{C}$, this method can still provide a reasonable packing solution.

2.1. Forest and Trees for Simple Packing

In the growth process of a forest and its trees, the trees start at the root nodes of the containers $v_1^{c_j},(j=1,\cdots ,m)$. Therefore, in this paper, the nodes of the tree not only have a graph-theoretic meaning but are also physical locations that the elements can be moved to. $Q_l$ denotes the list of all leaf nodes in the forest at growth level l, and root nodes are added to $Q_0$:

$$Q_0=\{v_1^{c_1},\cdots ,v_1^{c_m}\}$$

(2)

Elements are tested to see whether they can be packed inside the container by moving them to nodes in $Q_l$ and checking whether the moved element is the subset of the container.

If one of the elements in $\mathbf{E}$ is placed in $v_1^{c_1}$ and passes this test, the leaf node $v_1^{c_1}$ is removed, and the three new shuffled nodes of the placed element $Shuffl{e}_1(v_2^e,v_3^e,v_6^e)$ are added at the beginning of $Q_1$. When $v_1^{c_1}$ is the chosen node, $Q_1$ is as follows:

$$Q_1=\{Shuffl{e}_1(v_2^e,v_3^e,v_6^e),v_1^{c_2},\cdots ,v_1^{c_m}\}$$

(3)

Alternatively, when $v_1^{c_1}$ does not pass the test and $v_1^{c_2}$ is the chosen node, $Q_1$ is as follows:

$$Q_1=\{Shuffl{e}_1(v_2^e,v_3^e,v_6^e),v_1^{c_1},v_1^{c_3},\cdots ,v_1^{c_m}\}$$

(4)

This process is iterated until there is no element that can be packed inside the containers after testing all elements in $\mathbf{E}$, moving to the leaf nodes in $Q_l$. Figure 5 shows an example of the growth of trees in a forest in a case involving three containers. The branches of the tree are generated between the selected parent node for the packing of the element and the newly added child nodes after the packing of the element at each growth level. However, as long as the leaf nodes are the remaining candidates for the packing of the elements, $Q_l$ does not have to save all the nodes in the forest, improving memory usage during the growth of the forest.

The problem of this approach is that it does not consider practical machining solutions to separate the elements in the containers without damaging other elements (see Figure 6).

Even though the order of the leaf nodes in $Q_l$ may allow the elements to be placed in the used containers first, the efficiency of container usage can be improved by applying the forest score. Therefore, the following sections suggest the slab packing method, which packs elements in split containers, called slabs in this paper.

2.2. Forest and Trees for Slab Packing

The important additional function of the slab packing method considers the division of containers, which is related to the limitation of the production strategy in the stone industry (see Figure 2 and Figure 3). Split containers, which are called slabs in this paper, are better when used before non-split containers for packing elements so that non-split containers can be saved and used in the latter order. Furthermore, elements should be packed within the slabs without protrusion. For these reasons, good planning of the data structure Q and the slab list S is essential.

The update process of $Q_l$ is the same as the simple packing method:

$$\begin{array}{cc}\hfill Q_0& =\{v_1^{c_1},\cdots ,v_1^{c_m}\}\hfill \\ \hfill Q_1& =\{Shuffl{e}_1(v_2^e,v_3^e,v_6^e),v_1^{c_2},\cdots ,v_1^{c_m}\}\hfill \\ \hfill ⋮& \hfill \end{array}$$

(5)

The difference comes from the list of slabs S. The initial slab list $S_0$ contains containers in $\mathbf{C}$, and also the largest slabs before splitting. These slabs and leaf nodes are matched. Therefore, the order of the slabs in $S_l$ is the same as for the leaf nodes in $Q_l$.

$$\begin{array}{cc}\hfill Q_0& =\{v_1^{c_1},\cdots ,v_1^{c_m}\}\hfill \\ \hfill S_0& =\{s_1=c_1,\cdots ,s_m=c_m\}\hfill \end{array}$$

(6)

When the first element is packed in the slab and passes the packing test, there are three ways to perform the initial split using the three faces of the element that are inside the slab. After that, there are two additional ways to split the slab using the two faces of the element that are inside the slab after the initial split. Therefore, there are six types of segmentation to make slabs (see Figure 7). One of the split methods is randomly chosen. When $v_1^{c_1}$ is the chosen node, the matched slab $s_1$ is removed from $S_0$, and $v_1^{c_1}$ is also removed from $Q_0$. Additionally, the new slabs based on the chosen split method, $s_2^e,s_3^e,s_6^e$, are matched to the new nodes $v_2^e,v_3^e,v_6^e$ (see Figure 8). The new slabs are added in $S_1$ following the same order as the new leaf nodes in $Q_1$.

$$\begin{array}{cc}\hfill Q_1& =\{Shuffl{e}_1(v_2^e,v_3^e,v_6^e),v_1^{c_2},\cdots ,v_1^{c_m}\}\hfill \\ \hfill S_1& =\{Shuffl{e}_1(s_2^e,s_3^e,s_6^e),s_2,\cdots ,s_m\}\hfill \end{array}$$

(7)

By organizing the items in $Q_l$ and $S_l$ via the introduced method, the element needs to take packing tests only $O(\left|Q_l\right|=\left|S_l\right|)$ times with a leaf node $Q_l\left[w\right]$ and a slab $S_l\left[w\right]$$(w=1,\cdots ,\left|Q\right|=\left|S\right|)$ (see Algorithm 1). The reason for not saving the entire history of the slab production in $S_1$ is the same as the reason for the data management of $Q_l$: improving the memory usage.

Figure 9 shows an example of the growth of trees in a forest in a case with three containers. The difference from Figure 5 is that Figure 9 includes the process of making the slabs, which affects the growth of the forest, requiring the elements to be tested to determine whether they are inside the slabs.

Algorithm 1: Slab packing algorithm without score

2.3. Rotation

There are three types of rotation: no rotation, one-axis rotation, and three-axis rotation. The elements can rotate 90° for the latter two types. In the stone industry, one-axis rotation and three-axis rotation are commonly used. One-axis rotation allows the elements to follow the horizontal direction of the vein of the stone block (see Figure 10). This horizontal vein direction is particularly common in travertine because of the nature of the stone development and can be found at different travertine quarry locations [28,29,30]. On the other hand, if the direction of the vein does not matter, it is possible for the elements to rotate on all three axes: $x,y,z$ (see Figure 11). One-axis rotation has two rotation cases, and three-axis rotation has six rotation cases.

• One-axis rotation cases:
  • No rotation;
  • A 90° rotation on one of the $x,y,z$ axes.
• Three-axis rotation cases:
  • No rotation;
  • A 90° rotation on the x axis;
  • A 90° rotation on the y axis;
  • A 90° rotation on the z axis;
  • A 90° rotation on the x axis, then a 90° rotation on the z axis;
  • 90° rotation on the y axis, then a 90° rotation on the z axis.

Each element chooses one of the rotation cases randomly before the packing procedure. For parallel computing, the memory saves $\left|\mathbf{E}\right|\times f$ rotation data, where f is the number of forests.

2.4. Score of a Forest

The containers and elements have prices and values, respectively. It is better to use fewer containers to minimize the price. However, elements must be packed in containers as efficiently as possible. To achieve these two goals, a good design for the score of each forest is necessary. The design of $S_l$ and $Q_l$ from the previous session already makes the packing algorithm prioritize the use of the split slab first, keeping the unused containers in last position on the lists. However, a clear definition of the score is necessary to decide which forest is preferred.

After computing f forests and their growth, there are f sets of packed elements ${\mathbf{E}}_k^{packed},(k=1,\cdots ,f)$ and packed containers ${\mathbf{C}}_k^{\ast },(k=1,\cdots ,f)$. If there are no cases of ${\mathbf{E}}_k^{packed}$ that contain all the elements in $\mathbf{E}$, the best packing is the case that has the highest sum of the corresponding values of the elements. However, if there are cases of ${\mathbf{E}}_k^{packed}$ that contain all the elements in $\mathbf{E}$, the best case is the case that has all the elements and the lowest sum of container prices. When the forest index is $k,\left(1\le k\le f\right)$, the equation of the score ${\mathbf{S}}_k$ is as shown below and the algorithm is as shown in Algorithm 2:

$$\begin{array}{cc}\hfill {\mathbf{S}}_k& =\left\{\begin{array}{cc}\sum {\mathbf{P}}^{{\mathbf{E}}_k^{packed}}\hfill & \mathrm{if}\left({\mathbf{E}}_k^{packed}\cap \mathbf{E}\right)⊊\mathbf{E},\hfill \\ \sum {\mathbf{P}}^{{\mathbf{E}}_k^{packed}}+1-\sigma \left(\sum {\mathbf{P}}^{{\mathbf{C}}_k^{\ast }}\right)\hfill & \mathrm{if}\left({\mathbf{E}}_k^{packed}\cap \mathbf{E}\right)=\mathbf{E}.\hfill \end{array}\right.\hfill \\ \hfill \sigma \left(x\right)& ={\displaystyle \frac{x}{1+\left|x\right|}}\hfill & \hfill \end{array}$$

(8)

The set of indexes of the best forests is as follows:

$$Z=\arg {\min }_k{\mathbf{S}}_k,(z\in Z)$$

(9)

Algorithm 2: Slab packing algorithm with score

If there are forests where all elements in $\mathbf{E}$ are packed in containers and the sum of the container prices are the same, it is possible to choose the most compact packing by finding the lowest sum of the element values in a container among ${\mathbf{C}}_k^{\ast }$. When the index of the container is j, each container in each forest is denoted by $c_{k,j}^{\ast }\in {\mathbf{C}}_k^{\ast }$.

$$\begin{array}{cc}\hfill \left({\mathbf{E}}_{z,j}^{\ast },{\mathbf{P}}_{z,j}^{\ast }\right)& =\left\{\left(e\in {\mathbf{E}}_{z,j}^{\ast },p\in {\mathbf{P}}^{{\mathbf{E}}_{z,j}^{\ast }}\right) | {\mathbf{E}}_{z,j}^{\ast }=\left({\mathbf{E}}_z^{packed}\cap c_{z,j}^{\ast }\right)\right\}\hfill \\ \hfill \\ \hfill Z^{\ast }& =\arg {\min }_{z\in Z}\left({\mathbf{S}}_z+1-\sigma \left(\underset{j}{min}\sum {\mathbf{P}}_{z,j}^{\ast }\right)\right)\hfill & \hfill \end{array}$$

(10)

When the values of the elements and the prices of the containers follow their physical volumes, the score also shows the physical compactness of the packing.

3. Implementation

The elements can be defined using the minimum bounding box of each sculpture [27], or user-defined cuboids. After obtaining data on the containers and elements, it is possible to implement the slab packing with a score. In the stone industry, it is common to build the shape of a sculpture, column, wall, floor, etc., with the assembly of multiple stone pieces. The price of each stone block and the value of each piece are often given before the manufacturing process, and well-planned packing also gives the benefits of reducing material price and good manufacturing planning. In this section, the figures show two implementation cases based on a realistic scenario.

The first implementation case, shown in Figure 12a, shows the packing of irregular stone panels that are installed on a wall. The first case is a one-axis rotation case and follows the direction of the vein of the stone, as shown in Figure 10. The second implementation case, shown in Figure 12b, shows the packing of pieces for benches. The second case is a three-axis rotation case in which the elements can rotate 90° on any axis: $s,y,z$. The third implementation case, shown in Figure 13, shows a case that has a large number of elements and containers with one-axis rotation. In the first and second implementation, the shapes of the elements are user-defined considering the later production process after the split of the blocks. The third implementation case also has one-axis rotation for the elements. The elements are defined by the minimum bounding box algorithm [27]. Typical architectural projects require a large number of elements and containers. Therefore, applicability to these projects is essential.

According to the three implementation cases, the introduced method can achieve a reasonable packing layout of elements in multiple containers in different scenarios.

4. Analysis

The computing environment can be found in

Table 1. Specifications of the tested computer.

OS	Windows 11 Pro 64-bit
CPU	12th Gen Intel(R) Core(TM) i9-12900K 3.20 GHz
BIOS	1620
RAM	65,536 MB
Graphic Card	NVIDIA GeForce GTX 1660 Ti

. In this section, two hypothetical instances are tested: Instance_01 and Instance_02.

Table 2. Instance_01 element and container list.

Name	x Length [cm]	y Length [cm]	z Length [cm]
ele_01_1	104.8	53.8	49.8
ele_01_2	64.5	56.2	45
ele_01_3	38.3	24.7	43.1
ele_01_4	128.4	57.9	75
ele_01_5	32	41.3	60.8
ele_01_6	53.7	53.5	101.7
ele_01_7	108.2	94.1	32.9
ele_01_8	69	95.6	103.7
ele_01_9	44.7	27.2	72.5
ele_01_10	21.2	66.8	30.3
ele_01_11	104.2	92.9	105.8
ele_01_12	23.2	59	52.6
ele_01_13	20.8	84.8	26.2
ele_01_14	76.1	32	26.2
ele_01_15	62	42.3	62.4
ele_01_16	50.7	71.4	33.5
ele_01_17	97.3	71	104.8
ele_01_18	45.9	65.5	28.4
ele_01_19	100.4	92.7	91.5
ele_01_20	29.8	83.2	42.1
ele_01_21	29.1	21	62.4
ele_01_22	57.3	24.4	26.6
ele_01_23	56.3	60.5	93.6
ele_01_24	100.4	34	88.6
ele_01_25	118.6	66	36.7
ele_01_26	109.4	44.9	85.3
ele_01_27	91.9	73.1	40.5
ele_01_28	122	40.9	89.1
ele_01_29	30.9	22.6	101.7
ele_01_30	96.1	46	29.5
ele_01_31	121.8	60.3	22.9
ele_01_32	127.8	85.1	87.8
ele_01_33	31.2	92.4	47.1
ele_01_34	24.3	36.9	30
ele_01_35	57.5	82	54.2
ele_01_36	113.5	32.1	106.2
ele_01_37	95.6	58.4	35.1
ele_01_38	101.8	60.6	89.4
ele_01_39	95.4	89.9	37.5
ele_01_40	30.2	25.3	90.1
ele_01_41	24.5	52.7	50.2
ele_01_42	49.9	37.1	29.2
ele_01_43	49	41.2	106.2
ele_01_44	75	43.1	93.9
ele_01_45	125.8	71.5	67.8
con_01_1	190.8	193	190.8
con_01_2	199.5	178.9	199.5
con_01_3	178.2	198.1	178.2
con_01_4	170.6	191.9	170.6

and

Table 3. Instance_02 element and container list.

Name	x Length [cm]	y Length [cm]	z Length [cm]
ele_02_1	105.5	32.1	99.7
ele_02_2	87.6	19.9	34.5
ele_02_3	88.2	51.6	51.7
ele_02_4	82.3	78.7	43.4
ele_02_5	84.9	68.5	92
ele_02_6	46.8	48.5	68.4
ele_02_7	54.8	41.5	63.2
ele_02_8	61.3	94	60.1
ele_02_9	39.3	19	105.1
ele_02_10	106.5	67.2	39.7
ele_02_11	79.3	12.5	36.3
ele_02_12	44.7	32.1	82.7
ele_02_13	65.6	38.5	31.6
ele_02_14	80.5	98.1	75.6
ele_02_15	108.4	70.7	71.2
ele_02_16	44.8	68.3	22.3
ele_02_17	25.9	35.2	39.8
ele_02_18	37.6	64.8	104.1
ele_02_19	105.3	72.7	98.6
ele_02_20	36.8	72.5	56.3
ele_02_21	33.1	94.5	97.4
ele_02_22	47.1	18.3	91.3
ele_02_23	81.4	24.3	50.3
ele_02_24	67.3	44	92.8
ele_02_25	81.2	81	62.6
ele_02_26	106.2	25.1	79.1
ele_02_27	67.9	80.6	91.5
ele_02_28	99.5	37.3	76.7
ele_02_29	47.8	83.2	86.6
ele_02_30	32.1	88.9	66.1
ele_02_31	99.1	59.5	32.4
ele_02_32	27.9	73.8	69.3
ele_02_33	48.7	72.2	65.2
ele_02_34	41.5	11.2	36.6
ele_02_35	32.1	98.3	58.4
ele_02_36	37.7	81.8	29.7
ele_02_37	48.2	86.4	77.8
ele_02_38	37.6	15.6	93.3
ele_02_39	25	55.8	82.8
ele_02_40	77.2	56.7	64
ele_02_41	36.4	34.3	76.9
ele_02_42	64.5	98.4	102.6
ele_02_43	95.6	71.5	81.3
ele_02_44	56.5	44.4	35.7
ele_02_45	36.2	48.7	31
con_02_1	214.2	124.9	188
con_02_2	218.7	111.1	180.1
con_02_3	158.8	146.7	180.3
con_02_4	221.9	177.2	177.7

show the sizes of the elements and containers of the two instances. Elements are named ele_##_## and containers are named con_##_##. The results of the tests can be found in

Table 4. Results of slab packing with score.

Index	Instance	Number of Forests [f]	Rotation Axis	Time [s]	Score [Max]/${10}^4$	Success Cases
1	Inst_01	10	No Rotation	0.002	1189.751	0
2	Inst_01	50	No Rotation	0.009	1245.514	1
3	Inst_01	100	No Rotation	0.015	1245.515	1
4	Inst_01	500	No Rotation	0.065	1245.514	1
5	Inst_01	1000	No Rotation	0.102	1245.515	6
6	Inst_01	5000	No Rotation	0.599	1245.516	3
7	Inst_01	10,000	No Rotation	0.878	1245.513	1
8	Inst_01	50,000	No Rotation	5.226	1245.515	1
9	Inst_01	100,000	No Rotation	16.755	1245.516	4
10	Inst_01	500,000	No Rotation	153.522	1245.516	30
11	Inst_01	1,000,000	No Rotation	372.532	1245.515	1
12	Inst_01	5,000,000	No Rotation	2130.544	1245.512	1
13	Inst_01	10	$x,y,z$	0.002	1213.347	0
14	Inst_01	50	$x,y,z$	0.008	1245.514	1
15	Inst_01	500	$x,y,z$	0.052	1245.515	2
16	Inst_01	1000	$x,y,z$	0.1	1245.515	2
17	Inst_01	5000	$x,y,z$	0.513	1245.516	3
18	Inst_01	10,000	$x,y,z$	0.919	1245.516	6
19	Inst_01	50,000	$x,y,z$	5.401	1245.514	3
20	Inst_01	100,000	$x,y,z$	15.594	1245.516	5
21	Inst_01	500,000	$x,y,z$	113.176	1245.514	1
22	Inst_01	1,000,000	$x,y,z$	250.039	1245.517	42
23	Inst_01	5,000,000	$x,y,z$	1806.553	1245.514	5
24	Inst_02	10	No Rotation	0.001	978.271	0
25	Inst_02	50	No Rotation	0.001	1052.907	0
26	Inst_02	100	No Rotation	0.014	1049.033	0
27	Inst_02	500	No Rotation	0.083	1087.353	2
28	Inst_02	1000	No Rotation	0.118	1087.353	1
29	Inst_02	5000	No Rotation	0.517	1087.353	2
30	Inst_02	10,000	No Rotation	0.982	1087.352	2
31	Inst_02	50,000	No Rotation	5.457	1087.355	16
32	Inst_02	100,000	No Rotation	16.186	1087.356	25
33	Inst_02	500,000	No Rotation	128.733	1087.354	3
34	Inst_02	1,000,000	No Rotation	380.853	1087.354	5
35	Inst_02	5,000,000	No Rotation	2106.008	1087.355	40
36	Inst_02	10	$x,y,z$	0.001	1053.583	0
37	Inst_02	50	$x,y,z$	0.011	1058.935	0
38	Inst_02	100	$x,y,z$	0.015	1058.881	0
39	Inst_02	500	$x,y,z$	0.058	1087.353	2
40	Inst_02	1000	$x,y,z$	0.144	1087.354	3
41	Inst_02	5000	$x,y,z$	0.489	1087.352	1
42	Inst_02	10,000	$x,y,z$	0.977	1087.353	3
43	Inst_02	50,000	$x,y,z$	4.99	1087.353	1
44	Inst_02	100,000	$x,y,z$	16.668	1087.353	1
45	Inst_02	500,000	$x,y,z$	119.566	1087.352	2
46	Inst_02	1,000,000	$x,y,z$	308.088	1087.356	9
47	Inst_02	5,000,000	$x,y,z$	2319.922	1087.358	24

. Table 4 includes the results of the tests for both Instance_01 and Instance_02. Each instance runs from 10 to 5,000,000 forests with two different rotation options: no rotation and $x,y,z$ axis rotation. The score [max] shows the highest score among the f computed forests. The formula for the score can be found in Section 2.4. The Success Cases column shows the number of tree cases in which all elements are inside the containers.

The result shows that increasing the number of forests can produce more success cases. Furthermore, if rotation is allowed, cases with higher scores than the scores of any no-rotation case can be found. However, increasing the number of forests does not lead to a proportional increase in the number of successful cases due to the nature of the randomness of the generating cases. However, an increased number of forests generally finds better cases than a low number of forests.

When using parallel computing of the forests, the computation time of the forests can increase compared to that during the linear computation of forests. Figure 14 shows the computation pipeline for slab packing with the scores. Before parallel computing, the memory saves the duplicated and shuffled data of elements and containers. Then, each shuffled datum is assigned to each processor to grow the forest. After finishing the growth of a forest, the layout of the packing and the score are saved. If there are any forests that need to be grown after the process finishes growing its assigned forest, a new forest is assigned, and the processor starts growing it. After computing the scores of all forests, the best forest is chosen based on the saved scores.

Instance_01 and Instance_02, shown in Table 2 and Table 3, are used to test the performance of the parallel computing. The results of the comparison are shown in Figure 15. Figure 15 shows that parallel computing obviously outperforms linear computing in both Instance_01 and Instance_02. The performance of the parallel computing highly depends on the number and performance of the available processors.

The distribution of the score of the slab packing of Instance_01 and Instance_02 can be found in Figure 16 and Figure 17. These two graphs show that the score distribution has a skew normal distribution shape in both instances, which means that a few forests have very low scores and the majority of forests are populated on the high-score side of the graph near the peak. Depending on the condition of the elements and containers of the instances, the shape of the skew normal distribution graphs can be different between the no-rotation method and the three-axis rotation method. However, in both methods and in both instances, the graphs show negative skew graphs.

Specifically, there are some recognizable characteristics of the skew normal distribution graphs. First, the histograms show the roughness of the density on the right side of the peak. This is because possible packing layouts that have a high score become scarce and each high score layout has a big difference in score, showing the high density of the specific bin in the histograms. The other characteristic is the difference in densities in the bin at the right end of the histogram. The right end bins of Figure 16 and Figure 17 show higher densities than the skew normal distribution lines. This is because forests where all elements are packed in containers have small differences in score among themselves so they are all in the same right end bin. This also means that it is easier to find the forests of all elements inside the containers in Instance_01 than in Instance_02, according to the higher density in the right end bin.

Figure 18 shows the standard deviation of each bin in Figure 16 and Figure 17. For both Instance_01 and Instance_02, the high standard deviations of the bins are shown in the middle of the graph, which means that the forests in these bins have dispersed scores with various packing layouts. On the other hand, the standard deviation on the right end bins is relatively low compared to on other bins. That is because good forests that have higher scores than other forests packed with all elements are hard to find.

5. Discussion

In Section 3 and Section 4, the implementations of the slab packing method and statistical analysis are shown. In practice, the size of the elements in implementations should consider the tolerance of the machine, the envelope of the machine, and the size of the tools, such as the thickness of the blade and the wire saw. Furthermore, the inventory of dimension stones from the quarries changes in real time. Therefore, it is essential to have up-to-date stone data from the quarry to obtain more accurate data for the containers to compute packing. Furthermore, there is a tolerance for the dimension stone itself. In many cases, dimension stones may not have perfect cuboid shapes due to the production method, for instance, if the quarry uses traditional methods such as plug-and-feather and dynamic splitting [31,32]. Thus, the container sizes should follow the yield dimensions of the stone blocks from the quarries to obtain good cuboid data for the containers.

According to the analysis of the parallel computing in Section 4, parallel computing has a faster computation time than linear computing. However, there is a downside to memory usage. Let us assume that each three-dimensional node takes 24 bytes of memory, each score takes 8 bytes, each rotation option takes 4 bytes, each shuffled index of element and container takes 4 bytes, and there are 400 elements and containers. The memory required to compute ${10}^5$ forests will be about 1.76 gigabytes, even without temporary data from the slabs if all forests successfully pack all elements in the containers. Each slab can take 48 bytes with two three-dimensional points. Furthermore, the number of panels that require an architectural project can easily be thousands. Therefore, a good memory usage management plan is essential for computing large number of elements and containers with a large number of forests.

If the memory usage is well managed, another application of this slab packing method is material cost estimation. The traditional method of estimating material cost is to roughly estimate the stone block number based on the total area of the surface that the stone covers, or the total volume of the stones multiplied by factors. However, the slab packing method shows not only the packing layout of the elements in the containers, but also the optimized total price of the packed containers following the forest with the high score layout.

6. Conclusions

The packing of stone sculpture bounding boxes, denoted as elements, in stone blocks, denoted as containers, can be interpreted as a guillotine cutting problem considering the typical manufacturing strategies in the stone industry (see Figure 2 and Figure 3).

Based on the tree method used to solve this problem introduced in this paper, a sufficient number of forests may provide a higher chance of finding efficient packing solutions, as shown in Table 4. With a careful definition of the score of each forest, as described in Section 2.4, it is possible to find the forest that uses the containers the most efficiently. However, a customized setup is important before computing forests. If the direction of the vein of the stone block matters, the user can set the rotation types. For example, allowing rotation on only one axis can be appropriate with a stone block that contains a horizontal vein direction, as shown in Figure 10. On the other hand, if there is no vein direction, as in Figure 11, rotation of all three axes can be allowed. If a parallel computing method is used, it can result in extreme memory usage. Therefore, the user should adjust the number of forests considering the specification of the computer used to compute the forests, or use additional computers to compute the additional forests.

The implementation of this method can vary. However, specifically in the stone industry, this method is suitable for the production of various sizes of elements that need to be made in containers from the same quarry.