mirror of
https://github.com/Ultimaker/Cura.git
synced 2025-07-23 14:44:13 -06:00
Move documentation to wiki.
CURA-9903
This commit is contained in:
Joey de l'Arago
parent
0eb11031f9
commit
c0afdae64d
32 changed files with 4 additions and 1006 deletions
|
|
@ -57,10 +57,10 @@
|
|||
[Contributors]: https://github.com/Ultimaker/Cura/graphs/contributors
|
||||
[PullRequests]: https://github.com/Ultimaker/Cura/pulls
|
||||
[Machines]: https://github.com/Ultimaker/Cura/wiki/Adding-new-machine-profiles-to-Cura
|
||||
[Building]: https://github.com/Ultimaker/Cura/wiki/Running-Cura-from-Source
|
||||
[Building]: https://github.com/Ultimaker/Cura/wiki/Getting-Started
|
||||
[Localize]: https://github.com/Ultimaker/Cura/wiki/Translating-Cura
|
||||
[Settings]: https://github.com/Ultimaker/Cura/wiki/Cura-Settings
|
||||
[Plugins]: https://github.com/Ultimaker/Cura/wiki/Plugin-Directory
|
||||
[Settings]: https://github.com/Ultimaker/Cura/wiki/Profiles-&-Settings
|
||||
[Plugins]: https://github.com/Ultimaker/Cura/wiki/Plugins-And-Packages
|
||||
[Closed]: https://github.com/Ultimaker/Cura/issues?q=is%3Aissue+is%3Aclosed
|
||||
[Issues]: https://github.com/Ultimaker/Cura/issues
|
||||
[Conan]: https://github.com/Ultimaker/Cura/actions/workflows/conan-package.yml
|
||||
|
|
@ -87,7 +87,7 @@
|
|||
<!---------------------------------[ Buttons ]--------------------------------->
|
||||
|
||||
[Button Localize]: https://img.shields.io/badge/Help_Localize-e2467d?style=for-the-badge&logoColor=white&logo=GoogleTranslate
|
||||
[Button Machines]: https://img.shields.io/badge/Adding_Machines-yellow?style=for-the-badge&logoColor=white&logo=CloudFoundry
|
||||
[Button Machines]: https://img.shields.io/badge/Adding_Printers-yellow?style=for-the-badge&logoColor=white&logo=CloudFoundry
|
||||
[Button Settings]: https://img.shields.io/badge/Configuration-00979D?style=for-the-badge&logoColor=white&logo=CodeReview
|
||||
[Button Building]: https://img.shields.io/badge/Building_Cura-blue?style=for-the-badge&logoColor=white&logo=GitBook
|
||||
[Button Plugins]: https://img.shields.io/badge/Plugin_Usage-569A31?style=for-the-badge&logoColor=white&logo=ROS
|
||||
|
|
|
|||
|
|
@ -1,37 +0,0 @@
|
|||
|
||||
How to Profile Cura and See What It is Doing
|
||||
============================================
|
||||
Cura has a simple flame graph profiler available as a plugin which can be used to see what Cura is doing as it runs and how much time it takes. A flame graph profile shows its output as a timeline and stacks of "blocks" which represent parts of the code and are stacked up to show call depth. These often form little peaks which look like flames. It is a simple yet powerful way to visualise the activity of a program.
|
||||
|
||||
|
||||
Setting up and installing the profiler
|
||||
--------------------------------------
|
||||
|
||||
The profiler plugin is kept outside of the Cura source code here: https://github.com/sedwards2009/cura-big-flame-graph
|
||||
|
||||
To install it do:
|
||||
|
||||
* Use `git clone https://github.com/sedwards2009/cura-big-flame-graph.git` to grab a copy of the code.
|
||||
* Copy the `BigFlameGraph` directory into the `plugins` directory in your local Cura.
|
||||
* Set the `URANIUM_FLAME_PROFILER` environment variable to something before starting Cura. This flags to the profiler code in Cura to activate and insert the needed hooks into the code.
|
||||
|
||||
|
||||
Using the profiler
|
||||
------------------
|
||||
To open the profiler go to the Extensions menu and select "Start BFG" from the "Big Flame Graph" menu. A page will open up in your default browser. This is the profiler UI. Click on "Record" to start recording, go to Cura and perform an action and then back in the profiler click on "Stop". The results should now load in.
|
||||
|
||||
The time scale is at the top of the window. The blocks should be read as meaning the blocks at the bottom call the blocks which are stacked on top of them. Hover the mouse to get more detailed information about a block such as the name of the code involved and its duration. Use the zoom buttons or mouse wheel to zoom in. The display can be panned by dragging with the left mouse button.
|
||||
|
||||
Note: The profiler front-end itself is quite "heavy" (ok, not optimised). It runs much better in Google Chrome or Chromium than Firefox. It is also a good idea to keep recording sessions short for the same reason.
|
||||
|
||||
|
||||
What the Profiler Sees
|
||||
----------------------
|
||||
The profiler doesn't capture every function call in Cura. It hooks into a number of important systems which give a good picture of activity without too much run time overhead. The most important system is Uranium's signal mechanism and PyQt5 slots. Functions which are called via the signal mechanism are recorded and their names appear in the results. PyQt5 slots appear in the results with the prefix `[SLOT]`.
|
||||
|
||||
Note that not all slots are captured. Only those slots which belong to classes which use the `pyqtSlot` decorator from the `UM.FlameProfiler` module.
|
||||
|
||||
|
||||
Manually adding profiling code to more detail
|
||||
---------------------------------------------
|
||||
It is also possible to manually add decorators to methods to make them appear in the profiler results. The `UM.FlameProfiler` module contains the `profile` decorator which can be applied to methods. There is also a `profileCall` context manager which can be used with Python's `with` statement to measure a block of code. `profileCall` takes one argument, a label to use in the results.
|
||||
|
|
@ -1 +0,0 @@
|
|||
<mxfile host="www.draw.io" modified="2019-12-20T12:34:56.339Z" agent="Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0" etag="1NLsmsxIqXUmOJee4m9D" version="12.4.3" type="device" pages="1"><diagram id="K0t5C8WxT4tyKudoHXNk" name="Page-1">7VzbcqM4EP0aP+4WSFzsx8SZmd2tpCqTbO1kn1KKkW3VYOQBObHn61cyF0MLM9jhkmyo8gMSLXQ5R+rTDckIT1fbLyFZL2+4R/0RMrztCF+NEDIthEbqZ3i7uMZ13LhiETIvMTpU3LOfNKk0ktoN82hUMBSc+4Kti5UzHgR0Jgp1JAz5S9Fszv1ir2uyoFrF/Yz4eu035ollXDtG7qH+D8oWy7Rn05nEd1YkNU5mEi2Jx19yVfjTCE9DzkV8tdpOqa8WL12XuN3nI3ezgYU0EHUa/OXdPfz4exV+fRLWl92tG9388/m35CnPxN8kE/4zEOqB8ZDFLl2H6IWtfBLI0uWcB+I+uWPI8mzJfO+a7PhGjSMSZPY9LV0uech+Snviy1umrJC3Q5HAjFXrOfP9Kfd5KCsCvu/g0OhePSzpJqSRbHabztcEVTdkWzC8JpFIB8h9n6wj9rQfsmq4IuGCBZdcCL5KjJKFoKGg26MrbGa4ScJTvqIi3EmTtIGTQJ1w3URWXH45MMecJDbLPGvShiRh6yJ7dtbdnWQ3CRZyCll/2SZJ+7MMrT+npDvkFHsjvqBhQAS95JvAi/Iskhe5mR6q9tw6gWdY4xnb8+xxJrtdcDVTOSi8vciQyHFPIiL21An5dwq4UkIf4rNFIIs+natmClImN/RFUi34Wj1sTWYsWFzvba6sQ81dsk6qisu2c3+/aZfM82ig2MUFEeQpY/+ay5nsF9K+lD+53FPjd3tky4FPZdk8lOVPmYdiygM5F8L2rKKSpy9UcbUeBY9vY52XCS+wTotSGkJe5FlYIMSp6Fsa+vJ0pCGTp8KAdbNY207PWE80rD06ZwETjAcD2g2jPUY9o516oBzcz0RubKUghgO9LdhNY9w37rpw/LGROIndo9it6YB404jjmlKyNcRtDfCvMeCdhApyWv+vUMEtSndslmg0qyxUwBWhwqsAdgaR1txutit3MyoRaWVgt7aZ3eH07hJvu0SmdYr3eFBp3aPuloi0TlE39SM9H4sNyLeFvGmUqLVuoddPeA1lGngXKkMuSzOfRBGbKUElVqn+olsmHpJFV9f/qmu5snHpapu7dbVLC4Ec/UO+kGuliodm+1LaLh4c9bRkPBBUcgJ8E85o1dTT1wRSuNEqDN1yDHOY2SWQpXUh9Ylgz8XxVuRvbxVtcwJwXBSAaAIeEc8zaZVP64MHZe8XMl8DHhSvg/YgCT3Z5cySbXV8wBgM2DUrxwXtsWsDVscjaDTNbOqO7qiIHcKUX4cpFgDRrKtkshOw+ZNNTzA+kYg+ylUfhOsZaYdxpSfrPVJBeoJxyCe3h3fvkQrSE4tZqDKA3SzYvQcoqSh9lUo9U3Gm6jZVunXUbYMq1aopUmN315dKxSBNmanWU1WqBT5VQJZbS6U2JQyR/gr62LEy6MLTdSEa1wx40yOn+aNEfz8RkNWgCE93GvFWecOKsDqrNeDdLN79K0I9pv8oImFcUySgI+nIbkSCbYAMlHumSLBtmMoCD2oolQXFiGUYleOC9hhhwOoWUln4pMB3EC2/Fi0OyJRip+bRlh6BjR9tWA92pf3gwk51YdgoB/6tSBasRx+nu7AzXNFbeBvj1PRh+Mjm7caHWeDTffvcQNcGvsKG3+s05cMs4MOSv0g56sOgvVF4fdOSD9ODso/Ce/Q+eI9AIO+cy3voXG2rHd7bE+DErUn1fpz0wXs9RO2W92Z/vDfeBe8d+HYahhp1ee+CDKkFN1BDvHcBj5FZfd5D+2543+BXJ++N93W/Ouk3VncMSItzz3sQq2O7Hd7DASMLV4/LgBu7i1hd/ybhdN6fyeFzvtJqkPeTd3Hcm4AVDlTldWlvwhRVS8e9Cd+XmdUyB9pbdnVKS3MPp9p34U4sPT3SrTvpMWyuK6P6dSdaZnRy5r6C8TduKXzQ30Pb1ePqI/VroQ/L+7pRc7+fRcDX35ror0178BWw1VK2CI/h9qp2J9DenLzquJfFw/85ic0P/y0Gf/oP</diagram></mxfile>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
|
|
@ -1,81 +0,0 @@
|
|||
|
||||
# Reporting Issues
|
||||
|
||||
Please attach the following information in case <br>
|
||||
you want to report crashing or similar issues.
|
||||
|
||||
<br>
|
||||
|
||||
## DxDiag
|
||||
|
||||
### ![Badge Windows]
|
||||
|
||||
The log as produced by **dxdiag**.
|
||||
|
||||
<kbd> start </kbd> » <kbd> run </kbd> » <kbd> dxdiag </kbd> » <kbd> save output </kbd>
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
## Cura GUI Log
|
||||
|
||||
If the Cura user interface still starts, you can also <br>
|
||||
reach these directories from the application menu:
|
||||
|
||||
<kbd> Help </kbd> » <kbd> Show settings folder </kbd>
|
||||
|
||||
<br>
|
||||
|
||||
### ![Badge Windows]
|
||||
|
||||
```
|
||||
%APPDATA%\cura\<Ｃｕｒａ Ｖｅｒｓｉｏｎ>\cura.log
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```
|
||||
C:\Users\<your username>\AppData\Roaming\cura\<Ｃｕｒａ Ｖｅｒｓｉｏｎ>\cura.log
|
||||
```
|
||||
|
||||
<br>
|
||||
|
||||
### ![Badge Linux]
|
||||
|
||||
```
|
||||
~/.local/share/cura/<Ｃｕｒａ Ｖｅｒｓｉｏｎ>/cura.log
|
||||
```
|
||||
|
||||
<br>
|
||||
|
||||
### ![Badge MacOS]
|
||||
|
||||
```
|
||||
~/Library/Application Support/cura/<Ｃｕｒａ Ｖｅｒｓｉｏｎ>/cura.log
|
||||
```
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
## Alternative
|
||||
|
||||
An alternative is to install the **[ExtensiveSupportLogging]** <br>
|
||||
plugin this creates a zip folder of the relevant log files.
|
||||
|
||||
If you're experiencing performance issues, we might ask <br>
|
||||
you to connect the CPU profiler in this plugin and attach <br>
|
||||
the collected data to your support ticket.
|
||||
|
||||
<br>
|
||||
|
||||
|
||||
<!----------------------------------------------------------------------------->
|
||||
|
||||
[ExtensiveSupportLogging]: https://marketplace.ultimaker.com/app/cura/plugins/UltimakerPackages/ExtensiveSupportLogging
|
||||
|
||||
|
||||
<!---------------------------------[ Badges ]---------------------------------->
|
||||
|
||||
[Badge Windows]: https://img.shields.io/badge/Windows-0078D6?style=for-the-badge&logoColor=white&logo=Windows
|
||||
[Badge Linux]: https://img.shields.io/badge/Linux-00A95C?style=for-the-badge&logoColor=white&logo=Linux
|
||||
[Badge MacOS]: https://img.shields.io/badge/MacOS-403C3D?style=for-the-badge&logoColor=white&logo=MacOS
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
Cura Documentation
|
||||
====
|
||||
Welcome to the Cura documentation pages.
|
||||
|
||||
Objective
|
||||
----
|
||||
The goal of this documentation is to give an overview of the architecture of Cura's source code. The purpose of this overview is to make programmers familiar with Cura's source code so that they may contribute more easily, write plug-ins more easily or get started within the Cura team more quickly.
|
||||
|
||||
There are some caveats though. These are *not* within the scope of this documentation:
|
||||
* There is no documentation on individual functions or classes of the code here. For that, refer to the Doxygen documentation and Python Docstrings in the source code itself, or generate the documentation locally using Doxygen.
|
||||
* It's virtually impossible and indeed not worth the effort or money to keep this 100% up to date.
|
||||
* There are no example plug-ins here. There are a number of example plug-ins in the Ultimaker organisation on Github.com to draw from.
|
||||
* The slicing process is not documented here. Refer to CuraEngine for that.
|
||||
|
||||
This documentation will touch on the inner workings of Uranium as well though, due to the nature of the architecture.
|
||||
|
||||
Index
|
||||
----
|
||||
The following chapters are available in this documentation:
|
||||
* [Repositories](repositories.md): An overview of the repositories that together make up the Cura application.
|
||||
* [Profiles](profiles/profiles.md): About the setting and profile system of Cura.
|
||||
* [Scene](scene/scene.md): How Cura's 3D scene looks.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
Container Stacks
|
||||
====
|
||||
When the user selects the profiles and settings to print with, he can swap out a number of profiles. The profiles that are currently in use are stored in several container stacks. These container stacks always have a definition container at the bottom, which defines all available settings and all available properties for each setting. The profiles on top of that definition can then override the `value` property of some of those settings.
|
||||
|
||||
When deriving a setting value, a container stack starts looking at the top-most profile to see if it contains an override for that setting. If it does, it returns that override. Otherwise, it looks into the second profile. If that also doesn't have an override for this setting, it looks into the third profile, and so on. The last profile is always a definition container which always contains an value for all settings. This way, the profiles at the top will always win over the profiles at the bottom. There is a clear precedence order for which profile wins over which other profile.
|
||||
|
||||
A Machine Instance
|
||||
----
|
||||
A machine instance is a printer that the user has added to his configuration. It consists of multiple container stacks: One for global settings and one for each of the available extruders. This way, different extruders can contain different materials and quality profiles, for instance. The global stack contains a different set of profiles than the extruder stacks.
|
||||
|
||||
While Uranium defines no specific roles for the entries in a container stack, Cura defines rigid roles for each slot in a container stack. These are the layouts for the container stacks of an example printer with 2 extruders.
|
||||
|
||||
|
||||
|
||||
To expand on this a bit further, each extruder stack contains the following profiles:
|
||||
* A user profile, where extruder-specific setting changes are stored that are not (yet) saved to a custom profile. If the user changes a setting that can be adjusted per extruder (such as infill density) then it gets stored here. If the user adjusts a setting that is global it will immediately be stored in the user profile of the global stack.
|
||||
* A custom profile. If the user saves his setting changes to a custom profile, it gets moved from the user profile to here. Actually a "custom profile" as the user sees it consists of multiple profiles: one for each extruder and one for the global settings.
|
||||
* An intent profile. The user can select between several intents for his print, such as precision, strength, visual quality, etc. This may be empty as well, which indicates the "default" intent.
|
||||
* A quality profile. The user can select between several quality levels.
|
||||
* A material profile, where the user selects which material is loaded in this extruder.
|
||||
* A nozzle profile, where the user selects which nozzle is installed in this extruder.
|
||||
* Definition changes, which stores the changes that the user made for this extruder in the Printer Settings dialogue.
|
||||
* Extruder. The user is not able to swap this out. This is a definition that lists the extruder number for this extruder and optionally things that are fixed in the printer, such as the nozzle offset.
|
||||
|
||||
The global container stack contains the following profiles:
|
||||
* A user profile, where global setting changes are stored that are not (yet) saved to a custom profile. If the user changes for instance the layer height, the new value for the layer height gets stored here.
|
||||
* A custom profile. If the user saves his setting changes to a custom profile, the global settings that were in the global user profile get moved here.
|
||||
* An intent profile. Currently this must ALWAYS be empty. There are no global intent profiles. This is there for historical reasons.
|
||||
* A quality profile. This contains global settings that match with the quality level that the user selected. This global quality profile cannot be specific to a material or nozzle.
|
||||
* A material profile. Currently this must ALWAYS be empty. There are no global material profiles. This is there for historical reasons.
|
||||
* A variant profile. Currently this must ALWAYS be empty. There are no global variant profiles. This is there for historical reasons.
|
||||
* Definition changes, which stores the changes that the user made to the printer in the Printer Settings dialogue.
|
||||
* Printer. This specifies the currently used printer model, such as Ultimaker 3, Ultimaker S5, etc.
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
Getting a Setting Value
|
||||
====
|
||||
How Cura gets a setting's value is a complex endeavour that requires some explanation. The `value` property gets special treatment for this because there are a few other properties that influence the value. In this page we explain the algorithm to getting a setting value.
|
||||
|
||||
This page explains all possible cases for a setting, but not all of them may apply. For instance, a global setting will not evaluate the per-object settings to get its value. Exceptions to the rules for other types of settings will be written down.
|
||||
|
||||
Per Object Settings
|
||||
----
|
||||
Per-object settings, which are added to an object using the per-object settings tool, will always prevail over other setting values. They are not evaluated with the rest of the settings system because Cura's front-end doesn't need to send all setting values for all objects to CuraEngine separately. It only sends over the per-object settings that get overridden. CuraEngine then evaluates settings that can be changed per-object using the list of settings for that object but if the object doesn't have the setting attached falls back on the settings in the object's extruder. Refer to the [CuraEngine](#CuraEngine) chapter to see how this works.
|
||||
|
||||
Settings where the `settable_per_mesh` property is false will not be shown in Cura's interface in the list of available settings in the per-object settings panel. They cannot be adjusted per object then. CuraEngine will also not evaluate those settings for each object separately. There is (or should always be) a good reason why each of these settings are not evaluated per object: Simply because CuraEngine is not processing one particular mesh at that moment. For instance, when writing the move to change to the next layer, CuraEngine hasn't processed any of the meshes on that layer yet and so the layer change movement speed, or indeed the layer height, can't change for each object.
|
||||
|
||||
The per-object settings are stored in a separate container stack that is particular to the object. The container stack is added to the object via a scene decorator. It has just a single container in it, which contains all of the settings that the user changed.
|
||||
|
||||
Resolve
|
||||
----
|
||||
If the setting is not listed in the per-object settings, it needs to be evaluated from the main settings list. However before evaluating it from a particular extruder, Cura will check if the setting has the `resolve` property. If it does, it returns the output of the `resolve` property and that's everything.
|
||||
|
||||
The `resolve` property is intended for settings which are global in nature, but still need to be influenced by extruder-specific settings. A good example is the Build Plate Temperature, which is very dependent on the material(s) used by the printer, but there can only be a single bed temperature at a time.
|
||||
|
||||
Cura will simply evaluate the `resolve` setting if present, which is an arbitrary Python expression, and return its result as the setting's value. However typically the `resolve` property is a function that takes the values of this setting for all extruders in use and then computes a result based on those. There is a built-in function for that called `extruderValues()`, which returns a list of setting values, one for each extruder. The function can then for instance take the average of those. In the case of the build plate temperature it will take the highest of those. In the case of the adhesion type it will choose "raft" if any extruder uses a raft, or "brim" as second choice, "skirt" as third choice and "none" only if all extruders use "none". Each setting with a `resolve` property has its own way of resolving the setting. The `extruderValues()` function continues with the algorithm as written below, but repeats it for each extruder.
|
||||
|
||||
Limit To Extruder
|
||||
----
|
||||
If a setting is evaluated from a particular extruder stack, it normally gets evaluated from the extruder that the object is assigned to. However there are some exceptions. Some groups of settings belong to a particular "extruder setting", like the Infill Extruder setting, or the Support Extruder setting. Which extruder a setting belongs to is stored in the `limit_to_extruder` property. Settings which have their `limit_to_extruder` property set to `adhesion_extruder_nr`, for instance, belong to the build plate adhesion settings.
|
||||
|
||||
If the `limit_to_extruder` property evaluates to a positive number, instead of getting the setting from the object's extruder it will be obtained from the extruder written in the `limit_to_extruder` property. So even if an object is set to be printed with extruder 0, if the infill extruder is set to extruder 1 any infill setting will be obtained from extruder 1. If `limit_to_extruder` is negative (in particular -1, which is the default), then the setting will be obtained from the object's own extruder.
|
||||
|
||||
This property is communicated to CuraEngine separately. CuraEngine makes sure that the setting is evaluated from the correct extruder. Refer to the [CuraEngine](#CuraEngine) chapter to see how this works.
|
||||
|
||||
Evaluating a Stack
|
||||
----
|
||||
After the resolve and limit to extruder properties have been checked, the setting value needs to be evaluated from an extruder stack.
|
||||
|
||||
This is explained in more detail in the [Container Stacks](container_stacks.md) documentation. In brief, Cura will check the highest container in the extruder stack first to see whether that container overrides the setting. If it does, it returns that as the setting value. Otherwise, it checks the second container on the stack to see if that one overrides it. If it does it returns that value, and otherwise it checks the third container, and so on. If a setting is not overridden by any container in the extruder stack, it continues downward in the global stack. If it is also not overridden there, it eventually arrives at the definition in the bottom of the global stack.
|
||||
|
||||
Evaluating a Definition
|
||||
----
|
||||
If the evaluation for a setting reaches the last entry of the global stack, its definition, a few more things can happen.
|
||||
|
||||
Definition containers have an inheritance structure. For instance, the `ultimaker3` definition container specifies in its metadata that it inherits from `ultimaker`, which in turn inherits from `fdmprinter`. So again here, when evaluating a property from the `ultimaker3` definition it will first look to see if the property is overridden by the `ultimaker3` definition itself, and otherwise refer on to the `ultimaker` definition or otherwise finally to the `fdmprinter` definition. `fdmprinter` is the last line of defence, and it contains *all* properties for *all* settings.
|
||||
|
||||
But even in `fdmprinter`, not all settings have a `value` property. It is not a required property. If the setting doesn't have a `value` property, the `default_value` property is returned, which is a required property. The distinction between `value` and `default_value` is made in order to allow CuraEngine to load a definition file as well when running from the command line (a debugging technique for CuraEngine). It then won't have all of the correct setting values but it at least doesn't need to evaluate all of the Python expressions and you'll be able to make some debugging slices.
|
||||
|
||||
Evaluating a Value Property
|
||||
----
|
||||
The `value` property may contain a formula, which is an arbitrary Python expression that will be executed by Cura to arrive at a setting value. All containers may set the `value` property. Instance containers can only set the `value`, while definitions can set all properties.
|
||||
|
||||
While the value could be any sort of formula, some functions of Python are restricted for security reasons. Since Cura 4.6, profiles are no longer a "trusted" resource and are therefore subject to heavy restrictions. It can use Python's built in mathematical functions and list functions as well as a few basic other ones, but things like writing to a file are prohibited.
|
||||
|
||||
There are also a few extra things that can be used in these expressions:
|
||||
* Any setting key can be used as a variable that contains the setting's value.
|
||||
* As explained before, `extruderValues(key)` is a function that returns a list of setting values for a particular setting for all used extruders.
|
||||
* The function `extruderValue(extruder, key)` will evaluate a particular setting for a particular extruder.
|
||||
* The function `resolveOrValue(key)` will perform the full setting evaluation as described in this document for the current context (so if this setting is being evaluated for the second extruder it would perform it as if coming from the second extruder).
|
||||
* The function `defaultExtruderPosition()` will get the first extruder that is not disabled. For instance, if a printer has three extruders but the first is disabled, this would return `1` to indicate the second extruder (0-indexed).
|
||||
* The function `valueFromContainer(key, index)` will get a setting value from the global stack, but skip the first few containers in that stack. It will skip until it reaches a particular index in the container stack.
|
||||
* The function `valueFromExtruderContainer(key, index)` will get a setting value from the current extruder stack, but skip the first few containers in that stack. It will skip until it reaches a particular index in the container stack.
|
||||
|
||||
CuraEngine
|
||||
----
|
||||
When starting a slice, Cura will send the scene to CuraEngine and with each model send over the per-object settings that belong to it. It also sends all setting values over, as evaluated from each extruder and from the global stack, and sends the `limit_to_extruder` property along as well. CuraEngine stores this and then starts its slicing process. CuraEngine also has a hierarchical structure for its settings with fallbacks. This is explained in detail in [the documentation of CuraEngine](https://github.com/Ultimaker/CuraEngine/blob/master/docs/settings.md) and shortly again here.
|
||||
|
||||
Each model gets a setting container assigned. The per-object settings are stored in those. The fallback for this container is set to be the extruder with which the object is printed. The extruder uses the current *mesh group* as fallback (which is a concept that Cura's front-end doesn't have). Each mesh group uses the global settings container as fallback.
|
||||
|
||||
During the slicing process CuraEngine will evaluate the settings from its current context as it goes. For instance, when processing the walls for a particular mesh, it will request the Outer Wall Line Width setting from the settings container of that mesh. When it's not processing a particular mesh but for instance the travel moves between two meshes, it uses the currently applicable extruder. So this business logic defines actually how a setting can be configured per mesh, per extruder or only globally. The `settable_per_extruder`, and related properties of settings are only used in the front-end to determine how the settings are shown to the user.
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
Profiles
|
||||
====
|
||||
Cura's profile system is very advanced and has gotten pretty complex. This chapter is an attempt to document how it is structured.
|
||||
|
||||
Index
|
||||
----
|
||||
The following pages describe the profile and setting system of Cura:
|
||||
* [Container Stacks](container_stacks.md): Which profiles can be swapped out and how they are ordered when evaluating a setting.
|
||||
* [Setting Properties](setting_properties.md): What properties can each setting have?
|
||||
* [Getting a Setting Value](getting_a_setting_value.md): How Cura arrives at a value for a certain setting.
|
||||
|
||||
Glossary
|
||||
----
|
||||
The terminology for these profiles is not always obvious. Here is a glossary of the terms that we'll use in this chapter.
|
||||
* **Profile:** Either an *instance container* or a *definition container*.
|
||||
* **Definition container:** Profile that's stored as .def.json file, defining new settings and all of their properties. In Cura these represent printer models and extruder trains.
|
||||
* **Instance container:** Profile that's stored as .inst.cfg file or .xml.fdm_material file, which override some setting values. In Cura these represent the other profiles.
|
||||
* **[Container] stack:** A list of profiles, with one definition container at the bottom and instance containers for the rest. All settings are defined in the definition container. The rest of the profiles each specify a set of value overrides. The profiles at the top always override the profiles at the bottom.
|
||||
* **Machine instance:** An instance of a printer that the user has added. The list of all machine instances is shown in a drop-down in Cura's interface.
|
||||
* **Material:** A type of filament that's being sold by a vendor as a product.
|
||||
* **Filament spool:** A single spool of material.
|
||||
* **Quality profile:** A profile that is one of the options when the user selects which quality level they want to print with.
|
||||
* **Intent profile:** A profile that is one of the options when the user selects what his intent is.
|
||||
* **Custom profile:** A user-made profile that is stored when the user selects to "create a profile from the current settings/overrides".
|
||||
* **Quality-changes profile:** Alternative name for *custom profile*. This name is used in the code more often, but it's a bit misleading so this documentation prefers the term "custom profile".
|
||||
* **User profile:** A profile containing the settings that the user has changed, but not yet saved to a profile.
|
||||
* **Variant profile:** A profile containing some overrides that allow the user to select variants of the definition. As of this writing this is only used for the nozzles.
|
||||
* **Quality level:** A measure of quality where the user can select from, for instance "normal", "fast", "high". When selecting a quality level, Cura will select a matching quality profile for each extruder.
|
||||
* **Quality type:** Alternative name for *quality level*. This name is used in the code more often, but this documentation prefers the term "quality level".
|
||||
* **Inheritance function:** A function through which the `value` of a setting is calculated. This may depend on other settings.
|
||||
|
|
@ -1,78 +0,0 @@
|
|||
Setting Properties
|
||||
====
|
||||
Each setting in Cura has a number of properties. It's not just a key and a value. This page lists the properties that a setting can define.
|
||||
|
||||
* `key` (string): __The identifier by which the setting is referenced.__
|
||||
* This is not a human-readable name, but just a reference string, such as `layer_height_0`.
|
||||
* This is not actually a real property but just an identifier; it can't be changed.
|
||||
* Typically these are named with the most significant category first, in order to sort them better, such as `material_print_temperature`.
|
||||
* `value` (optional): __The current value of the setting.__
|
||||
* This can be a function (an arbitrary Python expression) that depends on the values of other settings.
|
||||
* If it's not present, the `default_value` is used.
|
||||
* `default_value`: __A default value for the setting if `value` is undefined.__
|
||||
* This property is required.
|
||||
* It can't be a Python expression, but it can be any JSON type.
|
||||
* This is made separate so that CuraEngine can read it out for its debugging mode via the command line, without needing a complete Python interpreter.
|
||||
* `label` (string): __The human-readable name for the setting.__
|
||||
* This label is translated.
|
||||
* `description` (string): __A longer description of what the setting does when you change it.__
|
||||
* This description is translated.
|
||||
* `type` (string): __The type of value that this setting contains.__
|
||||
* Allowed types are: `bool`, `str`, `float`, `int`, `enum`, `category`, `[int]`, `vec3`, `polygon` and `polygons`.
|
||||
* `unit` (optional string): __A unit that is displayed at the right-hand side of the text field where the user enters the setting value.__
|
||||
* `resolve` (optional string): __A Python expression that resolves disagreements for global settings if multiple per-extruder profiles define different values for a setting.__
|
||||
* Typically this takes the values for the setting from all stacks and computes one final value for it that will be used for the global setting. For instance, the `resolve` function for the build plate temperature is `max(extruderValues('material_bed_temperature')`, meaning that it will use the hottest bed temperature of all materials of the extruders in use.
|
||||
* `limit_to_extruder` (optional): __A Python expression that indicates which extruder a setting will be obtained from.__
|
||||
* This is used for settings that may be extruder-specific but the extruder is not necessarily the current extruder. For instance, support settings need to be evaluated for the support extruder. Infill settings need to be evaluated for the infill extruder if the infill extruder is changed.
|
||||
* `enabled` (optional string or boolean): __Whether the setting can currently be made visible for the user.__
|
||||
* This can be a simple true/false, or a Python expression that depends on other settings.
|
||||
* Typically used for settings that don't apply when another setting is disabled, such as to hide the support settings if support is disabled.
|
||||
* `minimum_value` (optional): __The lowest acceptable value for this setting.__
|
||||
* If it's any lower, Cura will not allow the user to slice.
|
||||
* This property only applies to numerical settings.
|
||||
* By convention this is used to prevent setting values that are technically or physically impossible, such as a layer height of 0mm.
|
||||
* `maximum_value` (optional): __The highest acceptable value for this setting.__
|
||||
* If it's any higher, Cura will not allow the user to slice.
|
||||
* This property only applies to numerical settings.
|
||||
* By convention this is used to prevent setting values that are technically or physically impossible, such as a support overhang angle of more than 90 degrees.
|
||||
* `minimum_value_warning` (optional): __The threshold under which a warning is displayed to the user.__
|
||||
* This property only applies to numerical settings.
|
||||
* By convention this is used to indicate that it will probably not print very nicely with such a low setting value.
|
||||
* `maximum_value_warning` (optional): __The threshold above which a warning is displayed to the user.__
|
||||
* This property only applies to numerical settings.
|
||||
* By convention this is used to indicate that it will probably not print very nicely with such a high setting value.
|
||||
* `settable_globally` (optional boolean): __Whether the setting can be changed globally.__
|
||||
* For some mesh-type settings such as `support_mesh` this doesn't make sense, so those can't be changed globally. They are not displayed in the main settings list then.
|
||||
* `settable_per_meshgroup` (optional boolean): __Whether a setting can be changed per group of meshes.__
|
||||
* *This is currently unused by Cura.*
|
||||
* `settable_per_extruder` (optional boolean): __Whether a setting can be changed per extruder.__
|
||||
* Some settings, like the build plate temperature, can't be adjusted separately for each extruder. An icon is shown in the interface to indicate this.
|
||||
* If the user changes these settings they are stored in the global stack.
|
||||
* `settable_per_mesh` (optional boolean): __Whether a setting can be changed per mesh.__
|
||||
* The settings that can be changed per mesh are shown in the list of available settings in the per-object settings tool.
|
||||
* `children` (optional list): __A list of child settings.__
|
||||
* These are displayed with an indentation. If all child settings are overridden by the user, the parent setting gets greyed out to indicate that the parent setting has no effect any more. This is not strictly always the case though, because that would depend on the inheritance functions in the `value`.
|
||||
* `icon` (optional string): __A path to an icon to be displayed.__
|
||||
* Only applies to setting categories.
|
||||
* `allow_empty` (optional bool): __Whether the setting is allowed to be empty.__
|
||||
* If it's not, this will be treated as a setting error and Cura will not allow the user to slice.
|
||||
* Only applies to string-type settings.
|
||||
* `warning_description` (optional string): __A warning message to display when the setting has a warning value.__
|
||||
* *This is currently unused by Cura.*
|
||||
* `error_description` (optional string): __An error message to display when the setting has an error value.__
|
||||
* *This is currently unused by Cura.*
|
||||
* `options` (dictionary): __A list of values that the user can choose from.__
|
||||
* The keys of this dictionary are keys that CuraEngine identifies the option with.
|
||||
* The values are human-readable strings and will be translated.
|
||||
* Only applies to (and only required for) enum-type settings.
|
||||
* `comments` (optional string): __Comments to other programmers about the setting.__
|
||||
* *This is currently unused by Cura.*
|
||||
* `is_uuid` (optional boolean): __Whether or not this setting indicates a UUID-4.__
|
||||
* If it is, the setting will indicate an error if it's not in the correct format.
|
||||
* Only applies to string-type settings.
|
||||
* `regex_blacklist_pattern` (optional string): __A regular expression, where if the setting value matches with this regular expression, it gets an error state.__
|
||||
* Only applies to string-type settings.
|
||||
* `error_value` (optional): __If the setting value is equal to this value, it will show a setting error.__
|
||||
* This is used to display errors for non-numerical settings such as checkboxes.
|
||||
* `warning_value` (optional): __If the setting value is equal to this value, it will show a setting warning.__
|
||||
* This is used to display warnings for non-numerical settings such as checkboxes.
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
Repositories
|
||||
====
|
||||
Cura uses a number of repositories where parts of our source code are separated, in order to get a cleaner architecture. Those repositories are:
|
||||
* [Cura](https://github.com/Ultimaker/Cura) is the main repository for the front-end of Cura. This contains:
|
||||
- all of the business logic for the front-end, including the specific types of profiles that are available
|
||||
- the concept of 3D printers and materials
|
||||
- specific tools for handling 3D printed models
|
||||
- pretty much all of the GUI
|
||||
- Ultimaker services such as the Marketplace and accounts.
|
||||
* [Uranium](https://github.com/Ultimaker/Uranium) is the underlying framework the Cura repository is built on. [Uranium](https://github.com/Ultimaker/Uranium) is a framework for desktop applications that handle 3D models. It has a separate back-end. This provides Cura with:
|
||||
- a basic GUI framework ([Qt](https://www.qt.io/))
|
||||
- a 3D scene, a rendering system
|
||||
- a plug-in system
|
||||
- a system for stacked profiles that change settings.
|
||||
* [CuraEngine](https://github.com/Ultimaker/CuraEngine) is the slicer used by Cura in the background. This does the actual process that converts 3D models into a toolpath for the printer.
|
||||
* [libArcus](https://github.com/Ultimaker/libArcus) handles the communication to CuraEngine. [libArcus](https://github.com/Ultimaker/libArcus) is a small library that wraps around [Protobuf](https://developers.google.com/protocol-buffers/) in order to make it run over a local socket.
|
||||
* [cura-build](https://github.com/Ultimaker/cura-build): Cura's build scripts.
|
||||
* [cura-build-environment](https://github.com/Ultimaker/cura-build-environment) build scripts for building dependencies.
|
||||
|
||||
There are also a number of repositories under our control that are not integral parts of Cura's architecture, but more like separated side-gigs:
|
||||
* [libSavitar](https://github.com/Ultimaker/libSavitar) is used for loading and writing 3MF files.
|
||||
* [libCharon](https://github.com/Ultimaker/libCharon) is used for loading and writing UFP files.
|
||||
* [cura-binary-data](https://github.com/Ultimaker/cura-binary-data) pre-compiled parts to make the build system a bit simpler. This holds things which would require considerable tooling to build automatically like:
|
||||
- the machine-readable translation files
|
||||
- the Marlin builds for firmware updates
|
||||
* [Cura-squish-tests](https://github.com/Ultimaker/Cura-squish-tests): automated GUI tests.
|
||||
* [fdm_materials](https://github.com/Ultimaker/fdm_materials) stores Material profiles. This is separated out and combined in our build process, so that the firmware for Ultimaker's printers can use the same set of profiles too.
|
||||
|
||||
Interplay
|
||||
----
|
||||
At a very high level, Cura's repositories interconnect as follows:
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 60 KiB |
|
|
@ -1,54 +0,0 @@
|
|||
digraph {
|
||||
"cpython/3.10.4@ultimaker/testing" -> "zlib/1.2.12"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "openssl/1.1.1l"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "expat/2.4.1"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "libffi/3.2.1"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "mpdecimal/2.5.0@ultimaker/testing"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "libuuid/1.0.3"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "libxcrypt/4.4.25"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "bzip2/1.0.8"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "gdbm/1.19"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "sqlite3/3.36.0"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "tk/8.6.10"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "ncurses/6.2"
|
||||
"cpython/3.10.4@ultimaker/testing" -> "xz_utils/5.2.5"
|
||||
"pynest2d/5.1.0-beta+3@ultimaker/stable" -> "libnest2d/5.1.0-beta+3@ultimaker/stable"
|
||||
"pynest2d/5.1.0-beta+3@ultimaker/stable" -> "cpython/3.10.4@ultimaker/testing"
|
||||
"freetype/2.12.1" -> "libpng/1.6.37"
|
||||
"freetype/2.12.1" -> "zlib/1.2.12"
|
||||
"freetype/2.12.1" -> "bzip2/1.0.8"
|
||||
"freetype/2.12.1" -> "brotli/1.0.9"
|
||||
"savitar/5.1.0-beta+3@ultimaker/stable" -> "pugixml/1.12.1"
|
||||
"savitar/5.1.0-beta+3@ultimaker/stable" -> "cpython/3.10.4@ultimaker/testing"
|
||||
"arcus/5.1.0-beta+3@ultimaker/stable" -> "protobuf/3.17.1"
|
||||
"arcus/5.1.0-beta+3@ultimaker/stable" -> "cpython/3.10.4@ultimaker/testing"
|
||||
"arcus/5.1.0-beta+3@ultimaker/stable" -> "zlib/1.2.12"
|
||||
"libpng/1.6.37" -> "zlib/1.2.12"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "clipper/6.4.2"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "boost/1.78.0"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "rapidjson/1.1.0"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "stb/20200203"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "protobuf/3.17.1"
|
||||
"curaengine/5.1.0-beta+3@ultimaker/stable" -> "arcus/5.1.0-beta+3@ultimaker/stable"
|
||||
"tcl/8.6.10" -> "zlib/1.2.12"
|
||||
"uranium/5.1.0-beta+3@ultimaker/stable" -> "arcus/5.1.0-beta+3@ultimaker/stable"
|
||||
"uranium/5.1.0-beta+3@ultimaker/stable" -> "cpython/3.10.4@ultimaker/testing"
|
||||
"libnest2d/5.1.0-beta+3@ultimaker/stable" -> "boost/1.78.0"
|
||||
"libnest2d/5.1.0-beta+3@ultimaker/stable" -> "clipper/6.4.2"
|
||||
"libnest2d/5.1.0-beta+3@ultimaker/stable" -> "nlopt/2.7.0"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "arcus/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "curaengine/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "savitar/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "pynest2d/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "uranium/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "fdm_materials/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "cura_binary_data/5.1.0-beta+3@ultimaker/stable"
|
||||
"conanfile.py (cura/5.1.0-beta+3@ultimaker/testing)" -> "cpython/3.10.4@ultimaker/testing"
|
||||
"fontconfig/2.13.93" -> "freetype/2.12.1"
|
||||
"fontconfig/2.13.93" -> "expat/2.4.1"
|
||||
"fontconfig/2.13.93" -> "libuuid/1.0.3"
|
||||
"tk/8.6.10" -> "tcl/8.6.10"
|
||||
"tk/8.6.10" -> "fontconfig/2.13.93"
|
||||
"tk/8.6.10" -> "xorg/system"
|
||||
"protobuf/3.17.1" -> "zlib/1.2.12"
|
||||
}
|
||||
|
|
@ -1,55 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="700" height="1010">
|
||||
<defs>
|
||||
<path id="stack-header" d="m0,50 v-30 a20,20 0 0 1 20,-20 h260 a20,20 0 0 1 20,20 v30 z" />
|
||||
<marker id="arrow" refX="2" refY="1.5" markerWidth="3" markerHeight="3" orient="auto-start-reverse">
|
||||
<polygon points="0,0 3,1.5 0,3" />
|
||||
</marker>
|
||||
</defs>
|
||||
|
||||
<g stroke="black" stroke-width="5" fill="silver"> <!-- Stack headers. -->
|
||||
<use href="#stack-header" x="200" y="555" />
|
||||
<use href="#stack-header" x="5" y="5" />
|
||||
<use href="#stack-header" x="395" y="5" />
|
||||
</g>
|
||||
<g stroke="black" stroke-width="10" fill="none"> <!-- Stack outlines. -->
|
||||
<rect x="200" y="555" width="300" height="450" rx="20" /> <!-- Global stack. -->
|
||||
<rect x="5" y="5" width="300" height="450" rx="20" /> <!-- Left extruder. -->
|
||||
<rect x="395" y="5" width="300" height="450" rx="20" /> <!-- Right extruder. -->
|
||||
</g>
|
||||
<g font-family="sans-serif" font-size="25" dominant-baseline="middle" text-anchor="middle">
|
||||
<text x="350" y="582.5">Global stack</text> <!-- Slightly lowered since the top line is thicker than the bottom. -->
|
||||
<text x="350" y="630">User</text>
|
||||
<text x="350" y="680">Custom</text>
|
||||
<text x="350" y="730">Intent</text>
|
||||
<text x="350" y="780">Quality</text>
|
||||
<text x="350" y="830">Material</text>
|
||||
<text x="350" y="880">Variant</text>
|
||||
<text x="350" y="930">Definition changes</text>
|
||||
<text x="350" y="980">Printer</text>
|
||||
|
||||
<text x="155" y="32.5">Left extruder</text> <!-- Slightly lowered again. -->
|
||||
<text x="155" y="80">User</text>
|
||||
<text x="155" y="130">Custom</text>
|
||||
<text x="155" y="180">Intent</text>
|
||||
<text x="155" y="230">Quality</text>
|
||||
<text x="155" y="280">Material</text>
|
||||
<text x="155" y="330">Nozzle</text>
|
||||
<text x="155" y="380">Definition changes</text>
|
||||
<text x="155" y="430">Extruder</text>
|
||||
|
||||
<text x="545" y="32.5">Right extruder</text> <!-- Slightly lowered again. -->
|
||||
<text x="545" y="80">User</text>
|
||||
<text x="545" y="130">Custom</text>
|
||||
<text x="545" y="180">Intent</text>
|
||||
<text x="545" y="230">Quality</text>
|
||||
<text x="545" y="280">Material</text>
|
||||
<text x="545" y="330">Nozzle</text>
|
||||
<text x="545" y="380">Definition changes</text>
|
||||
<text x="545" y="430">Extruder</text>
|
||||
</g>
|
||||
<g stroke="black" stroke-width="5" marker-end="url(#arrow)"> <!-- Arrows. -->
|
||||
<line x1="155" y1="455" x2="345" y2="545" />
|
||||
<line x1="545" y1="455" x2="355" y2="545" />
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 2.6 KiB |
|
|
@ -1,70 +0,0 @@
|
|||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<svg xmlns="http://www.w3.org/2000/svg" width="1000" height="1000">
|
||||
<defs>
|
||||
<marker id="arrow" refX="2" refY="1.5" markerWidth="3" markerHeight="3" orient="auto-start-reverse">
|
||||
<polygon points="0,0 3,1.5 0,3" />
|
||||
</marker>
|
||||
</defs>
|
||||
|
||||
<g marker-end="url(#arrow)" stroke="black" stroke-width="5"> <!-- Arrows. -->
|
||||
<!-- Towards CuraEngine and back. -->
|
||||
<line x1="475" y1="400" x2="475" y2="307.5" />
|
||||
<line x1="475" y1="250" x2="475" y2="210" />
|
||||
<line x1="525" y1="200" x2="525" y2="242.5" />
|
||||
<line x1="525" y1="300" x2="525" y2="390" />
|
||||
|
||||
<!-- From libSavitar. -->
|
||||
<line x1="100" y1="425" x2="142.5" y2="425" />
|
||||
<line x1="300" y1="425" x2="390" y2="425" />
|
||||
|
||||
<!-- From fdm_materials. -->
|
||||
<line x1="350" y1="575" x2="390" y2="575" />
|
||||
|
||||
<!-- To libCharon. -->
|
||||
<line x1="600" y1="500" x2="692.5" y2="500" />
|
||||
<line x1="900" y1="500" x2="945" y2="500" />
|
||||
|
||||
<!-- To Uranium. -->
|
||||
<line x1="500" y1="600" x2="500" y2="690" />
|
||||
</g>
|
||||
|
||||
<g stroke="black" fill="none"> <!-- Boxes representing repositories. -->
|
||||
<g stroke-width="10"> <!-- Major repositories. -->
|
||||
<rect x="400" y="400" width="200" height="200" rx="20" /> <!-- Cura. -->
|
||||
<rect x="350" y="700" width="300" height="200" rx="20" /> <!-- Uranium. -->
|
||||
<rect x="300" y="5" width="400" height="195" rx="20" /> <!-- CuraEngine. -->
|
||||
</g>
|
||||
<g stroke-width="5"> <!-- Minor repositories. -->
|
||||
<rect x="150" y="350" width="150" height="100" rx="20" /> <!-- libSavitar. -->
|
||||
<rect x="100" y="550" width="250" height="100" rx="20" /> <!-- fdm_materials. -->
|
||||
<rect x="430" y="250" width="140" height="50" rx="20" /> <!-- libArcus. -->
|
||||
<rect x="700" y="450" width="200" height="100" rx="20" /> <!-- libCharon. -->
|
||||
</g>
|
||||
</g>
|
||||
|
||||
<g font-family="sans-serif" text-anchor="middle" dominant-baseline="middle"> <!-- Labels. -->
|
||||
<g font-size="50"> <!-- Major repositories. -->
|
||||
<text x="500" y="500">Cura</text>
|
||||
<text x="500" y="800">Uranium</text>
|
||||
<text x="500" y="102.5">CuraEngine</text>
|
||||
</g>
|
||||
<g font-size="25"> <!-- Minor repositories and arrows. -->
|
||||
<text x="225" y="400">libSavitar</text>
|
||||
<text x="225" y="600">fdm_materials</text>
|
||||
<text x="500" y="275">libArcus</text>
|
||||
<text x="800" y="500">libCharon</text>
|
||||
|
||||
<g text-anchor="start">
|
||||
<text x="645" y="490" transform="rotate(-90, 645, 490)">G-code</text>
|
||||
<text x="950" y="500">UFP</text>
|
||||
<text x="535" y="345">G-code</text>
|
||||
<text x="345" y="415" transform="rotate(-90, 345, 415)">Model</text>
|
||||
<text x="510" y="645">Built upon</text>
|
||||
</g>
|
||||
<g text-anchor="end">
|
||||
<text x="465" y="345">Scene</text>
|
||||
<text x="90" y="425">3MF</text>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 3 KiB |
|
|
@ -1,27 +0,0 @@
|
|||
Build Volume
|
||||
====
|
||||
The build volume is a scene node. This node gets placed somewhere in the scene. This is a specialised scene node that draws the build volume and all of its bits and pieces.
|
||||
|
||||
Volume bounds
|
||||
----
|
||||
The build volume draws a cube (for rectangular build plates) that represents the printable build volume. This outline is drawn with a blue line. To render this, the Build Volume scene node generates a cube and instructs OpenGL to draw a wireframe of this cube. This way the wireframe is always a single pixel wide regardless of view distance. This cube is automatically resized when the relevant settings change, like the width, height and depth of the printer, the shape of the build plate, the Print Sequence or the gantry height.
|
||||
|
||||
The build volume also draws a grid underneath the build volume. The grid features 1cm lines which allows the user to roughly estimate how big its print is or the distance between prints. It also features a finer 1mm line pattern within that grid. The grid is drawn as a single quad. This quad is then sent to the graphical card with a specialised shader which draws the grid pattern.
|
||||
|
||||
For elliptical build plates, the volume bounds are drawn as two circles, one at the top and one at the bottom of the available height. The build plate grid is drawn as a tessellated circle, but with the same shader.
|
||||
|
||||
Disallowed areas
|
||||
----
|
||||
The build volume also calculates and draws the disallowed areas. These are drawn as a grey shadow. The point of these disallowed areas is to denote the areas where the user is not allowed to place any objects. The reason to forbid placing an object can be a lot of things.
|
||||
|
||||
One disallowed area that is always present is the border around the build volume. This border is there to prevent the nozzle from going outside of the bounds of the build volume. For instance, if you were to print an object with a brim of 8mm, you won't be able to place that object closer than 8mm to the edge of the build volume. Doing so would draw part of the brim outside of the build volume. The width of these disallowed areas depends on a bunch of things. Most commonly the build plate adhesion setting or the Avoid Distance setting is the culprit. However this border is also affected by the draft shield, ooze shield and Support Horizontal Expansion, among others.
|
||||
|
||||
Another disallowed area stems from the distance between the nozzles for some multi-extrusion printers. The total build volume in Cura is normally the volume that can be reached by either nozzle. However for every extruder that your print uses, the build volume will be shrunk to the intersecting area that all used nozzles can reach. This is done by adding disallowed areas near the border. For instance, if you have two extruders with 18mm X distance between them, and your print uses only the left extruder, there will be an extra border of 18mm on the right hand side of the printer, because the left nozzle can't reach that far to the right. If you then use both extruders, there will be an 18mm border on both sides.
|
||||
|
||||
There are also disallowed areas for features that are printed. There are as of this writing two such disallowed areas: The prime tower and the prime blob. You can't print an object on those locations since they would intersect with the printed feature.
|
||||
|
||||
Then there are disallowed areas imposed by the current printer. Some printers have things in the way of your print, such as clips that hold the build plate down, or cameras, switching bays or wiping brushes. These are encoded in the `machine_disallowed_areas` and `nozzle_disallowed_areas` settings, as polygons. The difference between these two settings is that one is intended to describe where the print head is not allowed to move. The other is intended to describe where the currently active nozzle is not allowed to move. This distinction is meant to allow inactive nozzles to move over things like build plate clips or stickers, which can slide underneath an inactive nozzle.
|
||||
|
||||
Finally, there are disallowed areas imposed by other objects that you want to print. Each object and group has an associated Convex Hull Node, which denotes the volume that the object is going to be taking up while printing. This convex hull is projected down to the build plate and determines there the volume that the object is going to occupy.
|
||||
|
||||
Each type of disallowed area is affected by certain settings. The border around the build volume, for instance, is affected by the brim, but the disallowed areas for printed objects are not. This is because the brim could go outside of the build volume but the brim can't hit any other objects. If the brim comes too close to other objects, it merges with the brim of those objects. As such, generating each type of disallowed area requires specialised business logic to determine how the setting affects the disallowed area. It needs to take the highest of two settings sometimes, or it needs to sum them together, multiplying a certain line width by an accompanying line count setting, and so on. All this logic is implemented in the BuildVolume class.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 96 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 174 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 79 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 196 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 345 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 69 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
|
|
@ -1,113 +0,0 @@
|
|||
# Operations and the OperationStack
|
||||
|
||||
Cura supports an operation stack. The `OperationStack` class maintains a history of the operations performed in Cura, which allows for undo and redo actions. Every operation registers itself in the stack. The OperationStuck supports the following functions:
|
||||
|
||||
* `push(operation)`: Pushes an operation in the stack and applies the operation. This function is called when an operation pushes itself in the stack.
|
||||
* `undo()`: Reverses the actions performed by the last operation and reduces the current index of the stack.
|
||||
* `redo()`: Applies the actions performed by the next operation in the stack and increments the current index of the stack.
|
||||
* `getOperations()`: Returns a list of all the operations that are currently inside the OperationStack
|
||||
* `canUndo()`: Indicates whether the index of the operation stack has reached the bottom of the stack, which means that there are no more operations to be undone.
|
||||
* `canRedo()`: Indicates whether the index of the operation stack has reached the top of the stack, which means that there are no more operations to be redone.
|
||||
|
||||
**Note 1:** When consecutive operations are performed very quickly after each other, they are merged together at the top of the stack. This action ensures that these minor operation will be undone with one Undo keystroke (e.g. when moving the object around and you press and release the left mouse button really fast, it is considered as one move operation).
|
||||
|
||||
**Note 2:** When an operation is pushed in the middle of the stack, all operations above it are removed from the stack. This ensures that there won't be any "history branches" created.
|
||||
|
||||
### Operations
|
||||
|
||||
Every action that happens in the scene and affects one or multiple models is associated with a subclass of the `Operation` class and is it added to the `OperationStack`. The subclassed operations that can be found in Cura (excluding the ones from downloadable plugins) are the following:
|
||||
|
||||
* [GroupedOperation](#groupedoperation)
|
||||
* [AddSceneNodeOperation](#addscenenodeoperation)
|
||||
* [RemoveSceneNodeOperation](#removescenenodeoperation)
|
||||
* [SetParentOperation](#setparentoperation)
|
||||
* [SetTransformOperation](#settransformoperation)
|
||||
* [SetObjectExtruderOperation](#setobjectextruderoperation)
|
||||
* [GravityOperation](#gravityoperation)
|
||||
* [PlatformPhysicsOperation](#platformphysicsoperation)
|
||||
* [TranslateOperation](#translateoperation)
|
||||
* [ScaleOperation](#scaleoperation)
|
||||
* [RotateOperation](#rotateoperation)
|
||||
* [MirrorOperation](#mirroroperation)
|
||||
* [LayFlatOperation](#layflatoperation)
|
||||
* [SetBuildPlateNumberOperation]()
|
||||
|
||||
### GroupedOperation
|
||||
|
||||
The `GroupedOperation` is an operation that groups several other operations together. The intent of this operation is to hide an underlying chain of operations from the user if they correspond to only one interaction with the user, such as an operation applied to multiple scene nodes or a re-arrangement of multiple items in the scene.
|
||||
|
||||
Once a `GroupedOperation` is pushed into the stack, it applies all of its children operations in one go. Similarly, when it is undone, it reverses all its children operations at once.
|
||||
|
||||
|
||||
### AddSceneNodeOperation
|
||||
|
||||
The `AddSceneNodeOperation` is added to the stack whenever a mesh is loaded inside the `Scene`, either by a `FileReader` or by inserting a [Support Blocker](tools.md#supporteraser-tool) in an object.
|
||||
|
||||
### RemoveSceneNodeOperation
|
||||
|
||||
The `RemoveSceneNodeOperation` is added to the stack whenever a mesh is removed from the Scene by the user or when the user requests to clear the build plate (_Ctrl+D_).
|
||||
|
||||
### SetParentOperation
|
||||
|
||||
The `SetParentOperation` changes the parent of a node. It is primarily used when grouping (the group node is set as the nodes' parent) and ungrouping (the group's children's parent is set to the group's parent before the group node is deleted), or when a SupportEraser node is added to the scene (to set the selected object as the Eraser's parent).
|
||||
|
||||
### SetTransformOperation
|
||||
|
||||
The `SetTransformOperation` translates, rotates, and scales a node all at once. This operation accepts a transformation matrix, an orientation matrix, and a scale matrix, and it is used by the _"Reset All Model Positions"_ and _"Reset All Model Transformations"_ options in the right-click (context) menu.
|
||||
|
||||
### SetObjectExtruderOperation
|
||||
|
||||
This operation is used to set the extruder with which a certain object should be printed with. It adds a [SettingOverrideDecorator](scene.md#settingoverridedecorator) to the object (if it doesn't have any) and then sets the extruder number via the decoration function `node.callDecoration("setActiveExtruder", extruder_id)`.
|
||||
|
||||
### GravityOperation
|
||||
|
||||
The `GravityOperation` moves a scene node down to 0 on the y-axis. It is currently used by the _"Lay flat"_ and _"Select face to align to the build plate"_ actions of the `RotationTool` to ensure that the object will end up touching the build plate after the corresponding rotation operations have be done.
|
||||
|
||||
### PlatformPhysicsOperation
|
||||
|
||||
The `PlatformPhysicsOperation` is generated by the `PlatformPhysics` class and it is associated with the preferences _"Ensure models are kept apart"_ and _"Automatically drop models to the build plate"_. If any of these preferences is set to true, the `PlatformPhysics` class periodically checks to make sure that the two conditions are met and if not, it calculates the move vector for each of the nodes that will satisfy the conditions.
|
||||
|
||||
Once the move vectors have been computed, they are applied to the nodes through consecutive `PlatformPhysicsOperations`, whose job is to use the `translate` function on the nodes.
|
||||
|
||||
**Note:** When there are multiple nodes, multiple `PlatformPhysicsOperations` may be generated (all models may be moved to ensure they are kept apart). These operations eventually get merged together by the `OperationStack` due to the fact that the individual operations are applied very fast one after the other.
|
||||
|
||||
### TranslateOperation
|
||||
|
||||
The `TranslateOperation` applies a linear transformation on a node, moving the node in the scene. This operation is primarily linked to the [TranslateTool](tools.md#translatetool) but it is also used in other places around Cura, such as arranging objects on the build plate (Ctrl+R) and centering an object to the build plate (via the right-click context menu's _"Center Selected Model"_ option).
|
||||
|
||||
When an object is moved using the move tool handles, multiple translate operations are generated to make sure that the object is rendered properly while it is moved. These translate operations are merged together once the user releases the tool handle.
|
||||
|
||||
**Note:** Some functionalities may move (translate) nodes without generating a TranslateOperation (such as when a model with is imported from a 3mf into a certain position). This ensures that the moving of the object cannot be accidentally undone by the user.
|
||||
|
||||
### ScaleOperation
|
||||
|
||||
The `ScaleOperation` scales the selected scene node uniformly or non-uniformly. This operation is primarily generated by the [ScaleTool](tools.md#scaletool).
|
||||
|
||||
When an object is scaled using the scale tool handles, multiple scale operations are generated to make sure that the object is rendered properly while it is being resized. These scale operations are merged together once the user releases the tool handle.
|
||||
|
||||
**Note:** When the _"Scale extremely small models"_ or the _"Scale large models"_ preferences are enabled the model is scaled when it is inserted into the build plate but it **DOES NOT** generate a `ScaleOperation`. This ensures that Cura doesn't register the scaling as an action that can be undone and the user doesn't accidentally end up with a very big or very small model.
|
||||
|
||||
|
||||
### RotateOperation
|
||||
|
||||
The `RotateOperation` rotates the selected scene node(s) according to a given rotation quaternion and, optionally, around a given point. This operation is primarily generated by the [RotationTool](tools.md#rotatetool). It is also used by the arrange algorithm, which may rotate some models to fit them in the build plate.
|
||||
|
||||
When an object is rotated using the rotate tool handles, multiple rotate operations are generated to make sure that the object is rendered properly while it is being rotated. These operations are merged together once the user releases the tool handle.
|
||||
|
||||
### MirrorOperation
|
||||
|
||||
The `MirrorOperation` mirrors the selected object. It is primarily associated with the [MirrorTool](tools.md#mirrortool) and allows for mirroring the object in a certain direction, using the `MirrorToolHandles`.
|
||||
|
||||
The `MirrorOperation` accepts a transformation matrix that should only define values on the diagonal of the matrix, and only the values 1 or -1. It allows for mirroring around the center of the object or around the axis origin. The latter isn't used that often.
|
||||
|
||||
### LayFlatOperation
|
||||
|
||||
The `LayFlatOperation` computes some orientation to hopefully lay the object flat on the build plate. It is generated by the `layFlat()` function of the [RotateTool](tools.md#rotatetool). Contrary to the other operations, the `LayFlatOperation` is computed in a separate thread through the `LayFlatJob` since it can be quite computationally expensive.
|
||||
|
||||
|
||||
### SetBuildPlateNumberOperation
|
||||
|
||||
The `SetBuildPlateNumberOperation` is linked to a legacy feature which allowed the user to have multiple build plates open in Cura at the same time. With this operation it was possible to transfer a node to another build plate through the node's [BuildPlateDecorator](scene.md#buildplatedecorator) by calling the decoration `node.callDecoration("setBuildPlateNumber", new_build_plate_nr)`.
|
||||
|
||||
**Note:** Changing the active build plate is a disabled feature in Cura and it is intended to be completely removed (internal ticket: CURA-4975), along with the `SetBuildPlateNumberOperation`.
|
||||
|
||||
|
|
@ -1,216 +0,0 @@
|
|||
Scene
|
||||
====
|
||||
The 3D scene in Cura is designed as a [Scene Graph](https://en.wikipedia.org/wiki/Scene_graph), which is common in many 3D graphics applications. The scene graph of Cura is usually very flat, but has the possibility to have nested objects which inherit transformations from each other.
|
||||
|
||||
Scene Graph
|
||||
----
|
||||
Cura's scene graph is a mere tree data structure. This tree contains all scene nodes, which represent the objects in the 3D scene.
|
||||
|
||||
The main idea behind the scene tree is that each scene node has a transformation applied to it. The scene nodes can be nested beneath other scene nodes. The transformation of the parents is then also applied to the children. This way you can have scene nodes grouped together and transform the group as a whole. Since the transformations are all linear, this ensures that the elements of this group stay in the same relative position and orientation. It will look as if the whole group is a single object. This idea is very common for games where objects are often composed of multiple 3D models but need to move together as a whole. For Cura it is used to group objects together and to transform the collision area correctly.
|
||||
|
||||
Class Diagram
|
||||
----
|
||||
|
||||
The following class diagram depicts the classes that interact with the Scene
|
||||
|
||||
|
||||
|
||||
The scene lives in the Controller of the Application, and it is primarily interacting with SceneNode objects, which are the components of the Scene Graph.
|
||||
|
||||
|
||||
A Typical Scene
|
||||
----
|
||||
Cura's scene has a few nodes that are always present, and a few nodes that are repeated for every object that the user loads onto their build plate. The root of the scene graph is a SceneNode that lives inside the Scene and contains all the other children SceneNodes of the scene. Typically, inside the root you can find the SceneNodes that are always loaded (the Cameras, the [BuildVolume](build_volume.md), and the Platform), the objects that are loaded on the platform, and finally a ConvexHullNode for each object and each group of objects in the Scene.
|
||||
|
||||
Let's take the following example Scene:
|
||||
|
||||
|
||||
|
||||
The scene graph in this case is the following:
|
||||
|
||||
|
||||
|
||||
|
||||
**Note 1:** The Platform is actually a child of the BuildVolume.
|
||||
|
||||
**Note 2:** The ConvexHullNodes are not actually named after the object they decorate. Their names are used in the image to convey how the ConvexHullNodes are related to the objects in the scene.
|
||||
|
||||
**Note 3:** The CuraSceneNode that holds the layer data (inside the BuildVolume) is created and destroyed according to the availability of sliced layer data provided by the CuraEngine. See the [LayerDataDecorator](#layerdatadecorator) for more information.
|
||||
|
||||
Accessing SceneNodes in the Scene
|
||||
----
|
||||
|
||||
SceneNodes can be accessed using a `BreadthFirstIterator` or a `DepthFirstIterator`. Each iterator traverses the scene graph and returns a Python iterator, which yields all the SceneNodes and their children.
|
||||
|
||||
``` python
|
||||
for node in BreadthFirstIterator(scene.getRoot()):
|
||||
# do stuff with the node
|
||||
```
|
||||
|
||||
Example result when iterating the above scene graph:
|
||||
|
||||
```python
|
||||
[i for i in BreadthFirstIterator(CuraApplication.getInstance().getController().getScene().getRoot()]
|
||||
```
|
||||
* 00 = {SceneNode} <SceneNode object: 'Root'>
|
||||
* 01 = {BuildVolume} <BuildVolume object '0x2e35dbce108'>
|
||||
* 02 = {Camera} <Camera object: '3d'>
|
||||
* 03 = {CuraSceneNode} <CuraSceneNode object: 'Torus.stl'>
|
||||
* 04 = {CuraSceneNode} <CuraSceneNode object: 'Group #1'>
|
||||
* 05 = {Camera} <Camera object: 'snapshot'>
|
||||
* 06 = {CuraSceneNode} <CuraSceneNode object: 'Star.stl'>
|
||||
* 07 = {ConvexHullNode} <ConvexHullNode object: '0x2e3000def08'>
|
||||
* 08 = {ConvexHullNode} <ConvexHullNode object: '0x2e36861bd88'>
|
||||
* 09 = {ConvexHullNode} <ConvexHullNode object: '0x2e3000bd4c8'>
|
||||
* 10 = {ConvexHullNode} <ConvexHullNode object: '0x2e35fbb62c8'>
|
||||
* 11 = {ConvexHullNode} <ConvexHullNode object: '0x2e3000a0648'>
|
||||
* 12 = {ConvexHullNode} <ConvexHullNode object: '0x2e30019d0c8'>
|
||||
* 13 = {ConvexHullNode} <ConvexHullNode object: '0x2e3001a2dc8'>
|
||||
* 14 = {Platform} <Platform object '0x2e35a001948'>
|
||||
* 15 = {CuraSceneNode} <CuraSceneNode object: 'Group #2'>
|
||||
* 16 = {CuraSceneNode} <CuraSceneNode object: 'Sphere.stl'>
|
||||
* 17 = {CuraSceneNode} <CuraSceneNode object: 'Cylinder.stl'>
|
||||
* 18 = {CuraSceneNode} <CuraSceneNode object: 'Cube.stl'>
|
||||
|
||||
SceneNodeDecorators
|
||||
----
|
||||
|
||||
SceneNodeDecorators are decorators that can be added to the nodes of the scene to provide them with additional functions.
|
||||
|
||||
Cura provides the following classes derived from the SceneNodeDecorator class:
|
||||
1. [GroupDecorator](#groupdecorator)
|
||||
2. [ConvexHullDecorator](#convexhulldecorator)
|
||||
3. [SettingOverrideDecorator](#settingoverridedecorator)
|
||||
4. [SliceableObjectDecorator](#sliceableobjectdecorator)
|
||||
5. [LayerDataDecorator](#layerdatadecorator)
|
||||
6. [ZOffsetDecorator](#zoffsetdecorator)
|
||||
7. [BlockSlicingDecorator](#blockslicingdecorator)
|
||||
8. [GCodeListDecorator](#gcodelistdecorator)
|
||||
9. [BuildPlateDecorator](#buildplatedecorator)
|
||||
|
||||
GroupDecorator
|
||||
----
|
||||
|
||||
Whenever objects on the build plate are grouped together, a new node is added in the scene as the parent of the grouped objects. Group nodes can be identified when traversing the SceneGraph by running the following:
|
||||
|
||||
```python
|
||||
node.callDecoration("isGroup") == True
|
||||
```
|
||||
|
||||
Group nodes decorated by GroupDecorators are added in the scene either by reading project files which contain grouped objects, or when the user selects multiple objects and groups them together (Ctrl + G).
|
||||
|
||||
Group nodes that are left with only one child are removed from the scene, making their only child a child of the group's parent. In addition, group nodes without any remaining children are removed from the scene.
|
||||
|
||||
ConvexHullDecorator
|
||||
----
|
||||
|
||||
As seen in the scene graph of the scene example, each CuraSceneNode that represents an object on the build plate is linked to a ConvexHullNode which is rendered as the object's shadow on the build plate. The ConvexHullDecorator is the link between these two nodes.
|
||||
|
||||
In essence, the CuraSceneNode has a ConvexHullDecorator which points to the ConvexHullNode of the object. The data of the object's convex hull can be accessed via
|
||||
|
||||
```python
|
||||
convex_hull_polygon = object_node.callDecoration("getConvexHull")
|
||||
```
|
||||
|
||||
The ConvexHullDecorator also provides convex hulls that include the head, the fans, and the adhesion of the object. These are primarily used and rendered when One-at-a-time mode is activated.
|
||||
|
||||
For more information on the functions added to the node by this decorator, visit the [ConvexHullDecorator.py](https://github.com/Ultimaker/Cura/blob/master/cura/Scene/ConvexHullDecorator.py).
|
||||
|
||||
SettingOverrideDecorator
|
||||
----
|
||||
|
||||
SettingOverrideDecorators are primarily used for modifier meshes such as support meshes, cutting meshes, infill meshes, and anti-overhang meshes. When a user converts an object to a modifier mesh, the object's node is decorated by a SettingOverrideDecorator. This decorator adds a PerObjectContainerStack to the CuraSceneNode, which allows the user to modify the settings of the specific model.
|
||||
|
||||
For more information on the functions added to the node by this decorator, visit the [SettingOverrideDecorator.py](https://github.com/Ultimaker/Cura/blob/master/cura/Settings/SettingOverrideDecorator.py).
|
||||
|
||||
|
||||
SliceableObjectDecorator
|
||||
----
|
||||
|
||||
This is a convenience decorator that allows us to easily identify the nodes which can be sliced. All **individual** objects (meshes) added to the build plate receive this decorator, apart from the nodes loaded from GCode files (.gcode, .g, .gz, .ufp).
|
||||
|
||||
The SceneNodes that do not receive this decorator are:
|
||||
|
||||
- Cameras
|
||||
- BuildVolume
|
||||
- Platform
|
||||
- ConvexHullNodes
|
||||
- CuraSceneNodes that serve as group nodes (these have a GroupDecorator instead)
|
||||
- The CuraSceneNode that serves as the layer data node
|
||||
- ToolHandles
|
||||
- NozzleNode
|
||||
- Nodes that contain GCode data. See the [BlockSlicingDecorator](#blockslicingdecorator) for more information on that.
|
||||
|
||||
This decorator provides the following function to the node:
|
||||
|
||||
```python
|
||||
node.callDecoration("isSliceable")
|
||||
```
|
||||
|
||||
LayerDataDecorator
|
||||
----
|
||||
|
||||
Once the Slicing has completed and the CuraEngine has returned the slicing data, Cura creates a CuraSceneNode inside the BuildVolume which is decorated by a LayerDataDecorator. This decorator holds the layer data of the scene.
|
||||
|
||||
|
||||
|
||||
The layer data can be accessed through the function given to the aforementioned CuraSceneNode by the LayerDataDecorator:
|
||||
|
||||
```python
|
||||
node.callDecoration("getLayerData")
|
||||
```
|
||||
|
||||
This CuraSceneNode is created once Cura has completed processing the Layer data (after the user clicks on the Preview tab after slicing). The CuraSceneNode then is destroyed once any action that changes the Scene occurs (e.g. if the user moves/rotates/scales an object or changes a setting value), indicating that the layer data is no longer available. When that happens, the "Slice" button becomes available again.
|
||||
|
||||
ZOffsetDecorator
|
||||
----
|
||||
|
||||
The ZOffsetDecorator is added to an object in the scene when that object is moved below the build plate. It is primarily used when the "Automatically drop models to the build plate" preference is enabled, in order to make sure that the GravityOperation, which drops the mode on the build plate, is not applied when the object is moved under the build plate.
|
||||
|
||||
The amount the object is moved under the build plate can be retrieved by calling the "getZOffset" decoration on the node:
|
||||
|
||||
```python
|
||||
z_offset = node.callDecoration("getZOffset")
|
||||
```
|
||||
|
||||
The ZOffsetDecorator is removed from the node when the node is move above the build plate.
|
||||
|
||||
BlockSlicingDecorator
|
||||
----
|
||||
|
||||
The BlockSlicingDecorator is the opposite of the SliceableObjectDecorator. It is added on objects loaded on the scene which should not be sliced. This decorator is primarily added on objects loaded from ".gcode", ".ufp", ".g", and ".gz" files. Such an object already contains all the slice information and therefore should not allow Cura to slice it.
|
||||
|
||||
If an object with a BlockSlicingDecorator appears in the scene, the backend (CuraEngine) and the print setup (changing print settings) become disabled, considering that G-code files cannot be modified.
|
||||
|
||||
The BlockSlicingDecorator adds the following decoration function to the node:
|
||||
|
||||
```python
|
||||
node.callDecoration("isBlockSlicing")
|
||||
```
|
||||
|
||||
GCodeListDecorator
|
||||
----
|
||||
|
||||
The GCodeListDecorator is also added only when a file containing GCode is loaded in the scene. It's purpose is to hold a list of all the GCode data of the loaded object.
|
||||
The GCode list data is stored in the scene's gcode_dict attribute which then is used in other places in the Cura code, e.g. to provide the GCode to the GCodeWriter or to the PostProcessingPlugin.
|
||||
|
||||
The GCode data becomes available by calling the "getGCodeList" decoration of the node:
|
||||
|
||||
```python
|
||||
gcode_list = node.callDecoration("getGCodeList")
|
||||
```
|
||||
|
||||
The CuraSceneNode with the GCodeListDecorator is destroyed when another object or project file is loaded in the Scene.
|
||||
|
||||
BuildPlateDecorator
|
||||
----
|
||||
|
||||
The BuildPlateDecorator is added to all the CuraSceneNodes. This decorator is linked to a legacy feature which allowed the user to have multiple build plates open in Cura at the same time. With this decorator it was possible to determine which nodes are present on each build plate, and therefore, which objects should be visible in the currently active build plate. It indicates the number of the build plate this scene node belongs to, which currently is always the build plate -1.
|
||||
|
||||
This decorator provides a function to the node that returns the number of the build plate it belongs to:
|
||||
|
||||
```python
|
||||
node.callDecoration("getBuildPlateNumber")
|
||||
```
|
||||
|
||||
**Note:** Changing the active build plate is a disabled feature in Cura and it is intended to be completely removed (internal ticket: CURA-4975).
|
||||
|
|
@ -1,86 +0,0 @@
|
|||
# Tools
|
||||
|
||||
Tools are plugin objects which are used to manipulate or interact with the scene and the objects (node) in the scene.
|
||||
|
||||
|
||||
|
||||
Tools live inside the Controller of the Application and may be associated with ToolHandles. Some of them interact with the scene as a whole (such as the Camera), while others interact with the objects (nodes) in the Scene (selection tool, rotate tool, scale tool etc.). The tools that are available in Cura (excluding the ones provided by downloadable plugins) are the following:
|
||||
|
||||
* [CameraTool](#cameratool)
|
||||
* [SelectionTool](#selectiontool)
|
||||
* [TranslateTool](#translatetool)
|
||||
* [ScaleTool](#scaletool)
|
||||
* [RotateTool](#rotatetool)
|
||||
* [MirrorTool](#mirrortool)
|
||||
* [PerObjectSettingsTool](#perobjectsettingstool)
|
||||
* [SupportEraserTool](#supporteraser)
|
||||
|
||||
*****
|
||||
|
||||
### CameraTool
|
||||
|
||||
The CameraTool is the tool that allows the user to manipulate the Camera. It provides the functions of moving, zooming, and rotating the Camera. This tool does not contain a handle.
|
||||
|
||||
### SelectionTool
|
||||
This tool allows the user to select objects and groups of objects in the scene. The selected objects gain a blue outline and become available in the code through the Selection class.
|
||||
|
||||
|
||||
|
||||
This tool does not contain a handle.
|
||||
|
||||
### TranslateTool
|
||||
|
||||
This tool allows the user to move the object around the build plate. The TranslateTool is activated once the user presses the Move icon in the tool sidebar or hits the shortcut (T) while an object is selected.
|
||||
|
||||
|
||||
|
||||
The TranslateTool contains the TranslateToolHandle, which draws the arrow handles on the selected object(s). The TranslateTool generates TranslateOperations whenever the object is moved around the build plate.
|
||||
|
||||
|
||||
### ScaleTool
|
||||
|
||||
This tool allows the user to scale the selected object(s). The ScaleTool is activated once the user presses the Scale icon in the tool sidebar or hits the shortcut (S) while an object is selected.
|
||||
|
||||
|
||||
|
||||
The ScaleTool contains the ScaleToolHandle, which draws the box handles on the selected object(s). The ScaleTool generates ScaleOperations whenever the object is scaled.
|
||||
|
||||
### RotateTool
|
||||
|
||||
This tool allows the user to rotate the selected object(s). The RotateTool is activated once the user presses the Rotate icon in the tool sidebar or hits the shortcut (R) while an object is selected.
|
||||
|
||||
|
||||
|
||||
The RotateTool contains the RotateToolHandle, which draws the donuts (tori) and arrow handles on the selected object(s). The RotateTool generates RotateOperations whenever the object is rotated or if a face is selected to be laid flat on the build plate. It also contains the `layFlat()` action, which generates the [LayFlatOperation](operations.md#layflatoperation).
|
||||
|
||||
|
||||
### MirrorTool
|
||||
|
||||
This tool allows the user to mirror the selected object(s) in the required direction. The MirrorTool is activated once the user presses the Mirror icon in the tool sidebar or hits the shortcut (M) while an object is selected.
|
||||
|
||||
|
||||
|
||||
The MirrorTool contains the MirrorToolHandle, which draws pyramid handles on the selected object(s). The MirrorTool generates MirrorOperations whenever the object is mirrored against an axis.
|
||||
|
||||
### PerObjectSettingsTool
|
||||
|
||||
This tool allows the user to change the mesh type of the object into one of the following:
|
||||
|
||||
* Normal Model
|
||||
* Print as support
|
||||
* Modify settings for overlaps
|
||||
- Infill mesh only
|
||||
- Cutting mesh
|
||||
* Don't support overlaps
|
||||
|
||||
|
||||
|
||||
Contrary to other tools, this tool doesn't have any handles and it does not generate any operations. This means that once an object's type is changed it cannot be undone/redone using the OperationStack. This tool adds a [SettingOverrideDecorator](scene.md#settingoverridedecorator) on the object's node instead, which allows the user to change certain settings only for this mesh.
|
||||
|
||||
### SupportEraser tool
|
||||
|
||||
This tool allows the user to add support blockers on the selected model. The SupportEraserTool is activated once the user pressed the Support Blocker icon in the tool sidebar or hits the shortcut (E) while an object is selected. With this tool active, the user can add support blockers (cubes) on the object by clicking on various places on the selected mesh.
|
||||
|
||||
|
||||
|
||||
The SupportEraser uses a GroupOperation to add a new CuraSceneNode (the eraser) in the scene and set the selected model as the parent of the eraser. This means that the addition of Erasers in the scene can be undone/redone. The SupportEraser does not have any tool handles.
|
||||
Loading…
Add table
Add a link
Reference in a new issue