INTRODUCTION

3D printing a digital model typically requires a user to make certain choices: users have to select the 3D printer and filament they would like to use, choose a print resolution profile, and scale the model to the desired size. This is done in a slicer, a program that uses the selected print settings to convert the 3D model into a set of machine instructions that the 3D printer can execute.

The required print time and material consumption are strongly influenced by these print settings. For instance, an object printed with a higher print resolution profile requires more layers and thus more print time than the same object printed with a lower print resolution profile that requires fewer layers. Similarly, the scale of the model is an important factor for print time and material consumption since larger models require more layers and more material per layer. Since 3D printing is slow and can take many hours even for hand-sized objects, users often find themselves in a situation where they have to trade-off between different print resolution profiles and model scales.

Unfortunately, today, information on the required print time and material consumption for different print resolution profiles and model scales is not readily available to users. Since slicers first have to slice the model before they can display the expected print time and material consumption, users have to wait after each change of the print resolution profile and model scale. Since a single slicing process can take up to several minutes for complex 3D models, it makes the exploration of suitable print resolution profiles and model scales a time-consuming process.

In this paper, we present an integrated system that enables users to explore different print settings in real-time to find the trade-off between print resolution profile, model scale, print time and material consumption that best fits their needs. Our idea is to augment 3D model repositories, such as Thingiverse, where the same 3D model is downloaded and printed by hundreds of users, with slicing results that have to be computed only once and subsequently are stored and made available to all users of the repository. This allows users to explore multiple print settings simultaneously in real-time without having to wait for slicing to finish.

While our long-term vision is to integrate the slicing results into existing 3D model platforms, such as Thingiverse, these commercial platforms are hard to extend with functionality due to limitations with their APIs. We therefore built the SliceHub repository to be able to prototype and study a system that stores and reuses slicing results. The repository contains for each 3D model, the print time and material consumption for different print resolution profiles and model scales, which users can download through each 3D model’s page.

While current slicers restrict users to explore print resolution profile and model scales one at a time, having the print time and material consumption for different settings available in real-time allows users to explore multiple options simultaneously. To support this exploration, we developed a user interface embedded within an existing slicer that provides users with an overview of the print time and material consumption resulting from different print resolution profiles and model scales. The user interface also supports users in filtering results by their time and material constraints and then displays only those print resolution profiles and model scales that are within the time and material the user has available.

Finally, while SliceHub will contain increasing amounts of data over time, there will always be cases where either the desired print resolution profile and model scale have not yet been sliced or the 3D model is new to the shared repository and no data is available yet. For these cases, SliceHub provides infrastructure to either interpolate or slice the missing print resolution profiles and model scales in parallel. For parallel slicing, SliceHub interfaces with an existing slicing engine and instantiates multiple slicing processes with different print resolution profiles and model scales simultaneously. To make this scalable, SliceHub uses a cloud computing infrastructure that can return up to 1000 slicing results in parallel.

SliceHub’s parallel slicing infrastructure can thus return the slicing results for several hundred print resolution profiles and model scales combinations in the same time it would take to return results for only one.

In summary, we contribute:

• an augmented repository that stores for each 3D model the required print time and material consumption for different print resolution profiles and model scales, which allows future users to re-use the results in real-time;
• a user interface integrated into an existing slicer that supports exploration of multiple print resolution profiles and model scales at once, including functionality to narrow down available options by filtering based on time and ma- terial constraints;
• infrastructure to efficiently generate data for missing print resolution profiles and model scales on the shared repository either through interpolation or by slicing multiple print resolution profiles and model scales in parallel.

FORMATIVE STUDY

To better understand the challenges regarding slicing and the strategies employed by users to achieve various slicing goals for 3D printing, we conducted interviews with 18 participants (6f/12m). Participants had used 3D printers for a diverse range of applications: such as 3D printing models for personal use, printing prototypes for research purposes, and for commercial and architectural use cases. We focused on topics such as the issues faced by participants when using slicers, types of print constraints faced while printing, experiences when exploring models on online 3D model repositories, and ideas for improvements. We identified several recurring breakdowns.

Long Wait Times: Participants expressed frustration with the slow feedback of the slicer. Since the slicer by default re-slices the model after every print resolution profile and model scale change, participants stated that they often have to wait for the slicer even after making only minor changes. Participant P6, for instance, complained about the “long calculation times" and P8 stated “every time I choose a profile, it needs a lot of time to calculate the print time." Participants wondered if the wait time could be shortened. For instance, P6 stated “It would be cool if instead of calculating the entire slice operation after every change, the program would only updated time/material use and then just do a full slice calculation once I choose to save." P8 added that estimates for the print time and material consumption may be enough for initial exploration: “I actually don’t need the very precise time, I just need to know [...] it will take at least 10 hours."

Lack of Information about how Print Resolution and Model Scale relate to Print Time and Material Consumption Participants expressed frustration with the slow feedback of the slicer. Since the slicer by default re-slices the model after every print resolution profile and model scale change, participants stated that they often have to wait for the slicer even after making only minor changes. Participant P6, for instance, complained about the “long calculation times" and P8 stated “every time I choose a profile, it needs a lot of time to calculate the print time." Participants wondered if the wait time could be shortened. For instance, P6 stated “It would be cool if instead of calculating the entire slice operation after every change, the program would only updated time/material use and then just do a full slice calculation once I choose to save." P8 added that estimates for the print time and material consumption may be enough for initial exploration: “I actually don’t need the very precise time, I just need to know [...] it will take at least 10 hours."

Difficulty in Satisfying Print Constraints: Most 3D printers used by participants were shared, and when faced with a deadline or during rapid prototyping, participants (P8, P10, P12) worked under stressful time and material constraints. P8 recounted: “I really, really needed to get that model done within 20 hours or else I [wasn’t] going to make it to the deadline; I had to to find another way. [...] I spent around 20 minutes finding the correct solution so that I can get the thing done." P10 added: “[if] that means sacrificing a lot of resolution to get it, it’s better than not having a product in the end."

Participants (P7, P8, P10, P12) also expressed that exploring different print resolution profiles and model scales took them a large number of iterations before arriving at a suitable solution. They shared ideas for improving the process of finding suitable print settings under time or material constraints. P7, for instance, suggested that “If the slicing program is really smart, then if I can type my purpose [goal], it may suggest some things" and P8: “[if] there’s a bar, and it will tell me if you scale to this, how much material is used."

Lack of Print Information on Online Repositories: Almost all participants had used 3D model repositories, such as Thingiverse, when looking for 3D models. But participants often had to go back-and-forth between the online repository and the slicer because the repository did not include any print information. P10 stated “the website doesn’t give you a lot of the things that the slicer software does." Participants (P4, P5, P7, P8, P10, P11) mentioned that including print-specific information for models on these shared repositories would aid in determining if the model is suitable. P4, for instance, said “having more information on the platform for a specific model before having to download it and testing it out would be great." P5 added: "you could have different size[s], so you could say with this particular size, this is the printing time [..]"

To address the problem of long wait times, SliceHub’s integrated system makes slicing results, i.e. the print time and material consumption for different print resolution profiles and model scales, available in real-time by storing slicing results and sharing them among all users. By making the print time and material amount of multiple print profile resolutions and model scales simultaneously visible in a user interface, it supports users in gaining an understanding of how they relate to each other. To support users in finding print profile resolutions and model scales that match a user’s time and material constraints, SliceHub provides filter functionality that narrows down the options to only those that match the time and material the user has available. Finally, SliceHub embeds basic print information, such as the average print time and material consumption for a 3D model, on the 3D model repository page, which allows users to take this information into account already during the search for a suitable 3D model.

SLICEHUB

SliceHub is an integrated system that allows users to efficiently explore slicing results for a 3D model. It consists of three components: (1) a repository of 3D models that contains for each 3D model the slicing results, i.e. print time and material consumption, for various print resolution profiles and model scales; (2) a user interface integrated into an existing slicer, Ultimaker Cura, that supports simultaneous exploration of multiple print resolution profiles and model scales as well as filtering based on time-and material constraints; (3) a computational infrastructure to efficiently generate data for missing print resolution profiles and model scales either by estimating slicing results through interpolation or by slicing multiple print resolution profiles and model scales in parallel on an external cloud-based system. Together, these components allow users to explore trade-offs between different print resolution profiles and model scales with respect to the print time and material consumption for 3D printing a model.

Note that SliceHub’s components work based on print resolution profiles, i.e. a set of slicer settings (layer resolution, print speed, infill density etc.) that taken together print the model at a certain resolution. This is similar to existing slicers which offer predefined print resolution profiles (e.g. ’fast(0.2mm)’, ’fine(0.06mm)’). Varying individual slicer settings, when not done carefully by an expert user, can lead to invalid prints. We thus exclude this option from SliceHub and only use predefined print resolution profiles whose settings were calibrated by the manufacturer of the 3D printer. In the next sections, we explain each of the three main components of SliceHub in more detail.

Repository of Slicing Data

SliceHub’s shared repository stores for each 3D model the slicing results for different print resolution profiles and model scales when printed on different 3D printers and with different materials.

Content Stored in the Repository: For each 3D model, SliceHub stores the 3D model geometry (.stl) and a meta-data file (.json) that contains for each print resolution profile and model scale the print time and material consumption for fabricating the 3D model. This allows the user to explore various print settings in real-time to find the trade-off between print time, material consumption, print resolution and model scale that best fits their needs. Storing print time and material consumption only requires little storage space (12 KB in total for one model with 16 different print resolution profiles and 16 different model scales, i.e. 256 combinations), which is a requirement to make the repository scaleable. We achieve this small storage overhead by discarding the print path (.gcode) since it does not contain information required to make a decision on the trade-offs discussed above and, additionally, an average .gcode file has an approximate file size of 10 MB per print resolution profile and model scale. Storing 256 .gcode files, one for each combination of the 16 print profile resolutions and 16 model scales, would require 2.5 GB on average and, thus, does not scale for large repositories. Instead, we only store the meta-data in a .json file. At 12 KB per model, even large data bases with thousands of models could store and process this additional data.

Finding Content in the Repository: The repository can be accessed through the SliceHub website and displays the 3D models on its main page (Figure 2). The user starts by selecting the 3D printer and material they want to use. Next, the user can start a query for specific models (e.g., "Mobius"). After clicking on the "Search" Button, SliceHub lists the most relevant models to the query in a result matrix. To provide the user with initial information on the print time and material consumption for a 3D model, SliceHub shows this information at a medium print resolution profile (0.15mm) and at 100% model scale when the user hovers over a 3D model’s thumbnail. In case no slicing results are available yet, the print time and material consumption are displayed as ‘not available’. Clicking on the 3D model’s thumbnail downloads a .zip archive containing the 3D model geometry (.stl) and a corresponding meta-data file (.json) that includes the slicing results for different print resolution profiles and model scales. As mentioned in the introduction, we envision that in the future the data from the SliceHub repository will be integrated with existing 3D model platforms, such as Thingiverse, with the print time and material consumption being made available during model search and on a 3D model’s subpage, and the meta-data file with slicing results added for download with the 3D model’s .stl file.

Figure 2: SliceHub repository: (a) select 3D printer and material, (b) for each model average print time and material consumption are shown, (c) choose model and download .zip file (contains model geometry (.stl) and slicing results in meta- data file (.json)).

Adding Content to the Repository: SliceHub’s repository can be populated with data in two ways. First, users have the option to ‘opt- in’ for sharing their slicing results whenever they use SliceHub’s parallel slicing infrastructure to generate new results (see Section 4.3). Second, SliceHub can generate slicing results itself using its cloud compute service and then subsequently add the results to the repository. Content can be added either to an existing model by providing slicing results for print resolution profiles and model scales that have no data yet or by contributing a new model that does not yet exist on the shared repository and adding an initial set of slicing results to it (see section ‘4.2 User Interface’ for how users can add models). SliceHub identifies if a model already exists in the database or is new using the model’s unique identifier (similar to Thingiverse), which is also encoded in the meta-data file. Thus, once the slicing results are available in the repository, they can be reused by future users without the need to re-compute them.

User Interface for Exploring Trade-Offs

After downloading a 3D model and its meta-data file from the repository, users can load the content into the SliceHub user interface, which is integrated into an existing slicer (i.e., Ultimaker Cura). The user interface allows users to compare multiple print resolu- tion profiles and model scales simultaneously, which facilitates the exploration of trade-offs. In addition, the user interface enables users to filter print resolution profiles and model scales according to material and time constraints.

Loading Data into the User Interface: The user interface takes as input the .zip file, which includes the 3D model geometry (.stl) and the meta-data file (.json) from the repository, which users can load using the ‘Load Model’ button (Figure 3a). Next, SliceHub extracts the slicing results for different print resolution profiles and model scales from the meta-data file and populates the user interface with the corresponding print times and material amounts (Figure 3b).

Figure 3: User Interface (Ultimaker Cura Plugin): (a) load .zip file (3D model (.stl) and meta-data (.json)), (b) UI updates to display print time and material consumption for each print profile resolution and model scale. (c) Adding lower and upper bounds for print time or material consumption shows only valid configurations. (d) Slicing the preferred configuration to generate the .gcode file for 3D printing.

Exploring Resolution and Scale Trade-Offs: The visualization of slicing results (Figure 3b) shows the print time and material amount for different print resolution profiles and model scales. Hovering over a slicing result displays the corresponding print time and material amount. The top left slicing result corresponds to the highest print resolution profile and largest model scale (0.06mm and 100%) whereas the bottom right slicing result corresponds to the lowest print resolution profile and smallest model scale (0.2mm and 10%. This allows users to compare different print profiles and model scales in real-time, which facilitates finding an appropriate trade-off. Since the focus of this paper is not on the particular visualization chosen to present the slicing results, we use a simple grid to represent the two-dimensional search space of print resolution profiles and model scales.

Print Time/Material Constraints: When 3D printing a model, users often work under time or material constraints as shown by our formative user study. For instance, users may not want to fabricate the model with a print resolution profile and model scale that requires printing overnight. SliceHub provides an option to narrow down the configurations to only those that print the model within the user’s available time and material. Users can enter their constraints into the corresponding text boxes for lower and upper bounds (Figure 3c). To provide the user with information on the allowable range for these values, SliceHub initially populates the text boxes with the minimum and maximum values across all print resolution profiles and model scales for that particular 3D model (i.e., the print time and material consumption at the lowest resolution (0.2mm) and smallest scale (10%), and highest resolution (0.06mm) and original model scale (100%). As soon as the user enters the constraints, SliceHub updates the visualization, highlighting only those print resolution profiles and model scale combinations that are within the chosen bounds (Figure 3c). If users enter multiple constraints, such as both print time and material amount, both constraints are considered together.

Infrastructure for Parallel Slicing and Interpolation

Interpolation of Missing Results: When slicing results are not yet available, SliceHub interpolates the missing results from the already sliced results. To indicate which print resolution profile and model scale combinations are sliced and which are interpolated, SliceHub marks the sliced and interpolated results with different symbols in the visualization (Figure 4). The interpolated values can be computed in real-time when the meta-data file (.json) is loaded. Thus, the interpolated results are immediately available for the user to explore. When the user hovers over one of these results, SliceHub shows the estimated print time and material consumption and also notes the prediction accuracy.

Figure 4: Adding slicing results: (a) by default, all missing results are interpolated, (b) selecting individual interpolated results and clicking ‘slice’ turns them into sliced result, (c) moving the ‘slice/interpolation’ slider increases the percentage of sliced results via parallel slicing.

Parallel Slicing to Replace Interpolated Results: To compute the slicing results for one or more interpolated values, users select the interpolated slicing results and then hit the ‘slice’ button (Figure 4a). Alternatively, users can also use the ‘interpolation percentage’ slider (Figure 4b), which allows to decrease the number of interpolated results and thus increase the accuracy of the prediction. To speed up the process of generating new slicing results, SliceHub contains infrastructure to compute slicing results for multiple print resolution profiles and model scales combinations in parallel. Note that when all slicing processes run in parallel, the total time equals the time for a single slicing process, i.e., the time required for the setting that needs the most slicing time, which is the model at 100% scale printed with the highest print resolution profile. While the slicing results are being generated, the progress slider at the bottom of the interface updates to provide the user with an estimate of the remaining slicing time. Once the slicing results are available, the previously interpolated results update, i.e. convert their visual icon and on hover show the print time and material consumption for the sliced result rather than the interpolated estimate. When the ‘Add to SliceHub’ option in the user interface is checked (Figure 5c), all slicing results are added to the SliceHub repository for future re-use by other users (i.e., when SliceHub parallel slices in the cloud it stores the slicing results in the repository by updating the meta-data file of the model at the same time it returns the results to the user interface). However, users have the choice to override this setting by de-selecting the checkbox. The slicing results are then not stored on SliceHub and only saved as a new meta-data file on the user’s local machine.

Adding a New Model: Slicing + Interpolation: To add a new 3D model, SliceHub uses a combination of slicing and interpolation. Users start by loading the 3D model geometry (.stl) into the Slice- Hub user interface using the ‘Load Model’ button (Figure 5a), which instantiates an empty visualization with no available slicing results yet. If users have the ‘Add to SliceHub’ option selected, SliceHub uploads the 3D model automatically to its cloud compute service and parallel slices it to generate 10% of the slicing results while interpolating the rest of the values (Figure 5b). SliceHub uses 10% since our technical evaluation shows that this fraction of sliced results leads to only a small interpolation error (Section 6.3). SliceHub then saves the 3D model together with a newly generated meta-data file that contains the slicing results (.json) on the server before returning the results to the user interface. After this step, the 3D model is available on the shared repository along with the generated slicing results. Users can decide to slice additional results, which are then added to the meta-data file on the server when SliceHub returns values from parallel slicing on its cloud compute service.

Figure 5: Adding a new model: (a) load model geometry (.stl), (b) SliceHub slices 10% of the print profile and model scale combinations and interpolates the rest, (c) SliceHub checks if users allowed sharing the model on the repository and then uploads the model and slicing results.

TECHNICAL EVALUATION

We based our design decisions for the individual SliceHub components, such as what information to store in the repository and how many print profiles and model scales to provide in the user interface, on a set of technical evaluations, which we describe below.

Repository Scalability: Amount of Meta-Data per Model

Figure 6: Higher percentages of interpolated results, lead to larger errors. The error stabilizes when 90% of results are interpo- lated (i.e., 10 % of results are sliced). We thus use this as the default setting when a new model is added to SliceHub.

We investigated how much storage space a model with all print resolution profiles and model scale combinations requires when all results are sliced and when a large fraction of results is interpolated.

Average File Size All Results Sliced For the top 1200 Thingiverse models, we found that the meta-data file (.json) for one 3D printer and material combination with 16x16 print resolution profiles and model scales (256 combinations) and with all results sliced is approximately 12 KB. When the top 7 materials are supported, which cover 90% of the 3D printing demand in plastic, the file size increases to approximately 84 KB. Further supporting the top ten 3D printers, which cover 28.4% of all 3D printing users, increases the file size to approximately 840 KB.

Average File Size 90% Results Interpolated: When 90% of results are interpolated as recommended by our technical evaluation 7.3, the average file size is reduced by 90%, i.e. 1.2 KB rather than 12KB for one material/printer combination, 8.4 KB rather than 84KB for the top 7 materials, and 84 KB rather than 840KB for the top 10 printers.

Average File Size of Geometry (.stl) and .gcode: We found that for the top 1200 Thingiverse models, the average 3D model geome- try file (.stl) was 6MB and the average size for the .gcode file was 10MB.

Based on this data, we conclude that adding the SliceHub meta-data to an existing repository, such as Thingiverse, for a range of popular print materials and 3D printers would only require an increase in the storage by 13.6% if all results are sliced (840 KB on top of the 6MB average model geometry file size), or 1.36% if 90% of values are interpolated (84 KB on top of the 6MB average model geometry file size). Storing the gcode, however, would add significant storage overhead to the repository. Since we generate 1750 slicing results per model (10% of 256 slicing results for 7 materials and 10 printers) and the size of an average gcode file is 10Mb, the overall storage increase would be approximately 17Gb per model (10Mb gcode * 1750 slicing results) and is thus not scale-able.

User Interface: Effect of Number of Print Profiles on Constraint Accuracy

When designing the user interface, we also had to decide on the number of print resolution profiles and model scales that the user can choose from. If there are only few options available, the user may not be able to find a good match for their time and material constraints. For instance, if only two print resolution profiles (e.g., 0.06mm and 0.2mm) are available, the high resolution profile may take much more time than the user has available while the fast low resolution may result in a worse print quality than the user would have had time for. Offering more options, however, increases computational cost to generate the slicing results. To find a good trade-off, we ran the following experiment.

Conditions: We created six conditions, i.e. six user interfaces with different numbers of print resolution profiles and model scales (ranging from 2 print resolution profiles and 2 model scales (4 slic- ing results) to 31 print profiles and 31 model scales (961 slicing results)). The user interface with the fewest options used the print resolution profiles with the highest resolution (0.06mm) and the lowest resolution (0.2mm), as well as the largest (100%) and smallest (10%) model scales. All other user interfaces iteratively added print resolution profiles and model scales at each midpoint of the existing values.

Procedure: We used our data-set of the top 1200 Thingiverse models and generated slicing results for each condition. We then randomly picked 20 print time and 20 material constraints from the available min/max bounds of each model, and for each user interface condition computed the mean relative error to the closest matching slicing result.

Experiment Results: As shown in Figure 6, the more print resolution profiles and model scales the user interface offers, the smaller the mean relative error is. For the smallest user interface (2x2) the mean relative error for the print time is 63.4% and material amount 64.9%, whereas for the largest user interface (31x31) the mean relative error for print time is only 1.6% and material amount 2.4%. However, while there is a strong reduction in error when a small user interface is expanded (e.g., for print time: 2x2: 63.4% vs 3x3: 30.6%), the effect is less emphasized for larger user interfaces (e.g., for print time there is only a 1.3% improvement between 16x16: 2.9% vs. 31x31: 1.6%). Since a user interface with 16 print resolution profiles and model scales requires only 26.6% of the data of a user interface with 31 print resolution profiles and model scales, and thus significantly lowers computational cost, we decided to use the user interface with 16 print resolution profiles and model scales as the default for SliceHub.

Effect of Number of Interpolated Slicing Results on Average Prediction Error

Figure 7: Higher percentages of interpolated results, lead to larger errors. The error stabilizes when 90% of results are interpo- lated (i.e., 10 % of results are sliced). We thus use this as the default setting when a new model is added to SliceHub.

To decide how many slicing results SliceHub should by default slice and how many interpolate, we ran an experiment to evaluate the effect of an increasing number of interpolated results on the mean relative error for predicting print time and material consumption.

Experiment Procedure: We created five conditions, i.e. five user interfaces of 16x16 print resolution profiles and model scales that had different percentages of interpolated results. The user interfaces ranged from containing 0% interpolated results (all 16 print resolution profiles x 16 model scales combinations sliced) to 98% interpolated cells (only 2 print resolution profiles x 2 model scales sliced). We then calculated the relative mean error for the interpolated results from the computed slicing results (e.g., if the computed print time of an object is 2h but the interpolated print time is 1h, there is a relative error of 50%).

Experiment Results: As can be seen in Figure 7, the error in predicted print time and material amount decreases with number of sliced results since there are more data points available for accurately fitting the polynomial function. For instance, the interpolation error for print time when only 4 (2x2) out of 256 print resolution profiles and model scales are sliced is 36.31%, whereas the interpolation error is only 2.08% when 81 (9x9) out of 256 print resolution profiles and model scales are sliced. Comparing the interpolation error for different percentages of interpolated results shows a strong decrease in error when 98% vs 96% of results are interpolated (26.33% less interpolation error) and when 96% vs 90% are interpolated (6.31% less interpolation error). The reduction in interpolation error when 90% vs. 68% of results are interpolated is only marginal (1.79% less error). Since interpolation accuracy no longer strongly decreases after about 10% of sliced results (90% interpolation), SliceHub by default slices 10% of results when a new model is added.