diff options
author | Ghostkeeper <rubend@tutanota.com> | 2020-04-27 01:56:58 +0300 |
---|---|---|
committer | Ghostkeeper <rubend@tutanota.com> | 2020-04-27 01:56:58 +0300 |
commit | 27bfe68659f0233d74bce5561570601b63c3b049 (patch) | |
tree | 79882fc741b4249534d5ccb7f4259cee9132ff41 /docs/profiles | |
parent | 8146030bc8ea56432ae5bd8916ee27640ff8a015 (diff) |
Add header on how settings are used in CuraEngine
This should hopefully fix a couple of the links to this header in the rest of the article. Hopefully I guessed it right as to how Github shows these chapter headers (because Github is the targeted renderer for this documentation).
Diffstat (limited to 'docs/profiles')
-rw-r--r-- | docs/profiles/getting_a_setting_value.md | 10 |
1 files changed, 9 insertions, 1 deletions
diff --git a/docs/profiles/getting_a_setting_value.md b/docs/profiles/getting_a_setting_value.md index 08ad12ea9c..39128f8c9c 100644 --- a/docs/profiles/getting_a_setting_value.md +++ b/docs/profiles/getting_a_setting_value.md @@ -40,4 +40,12 @@ If the evaluation for a setting reaches the last entry of the global stack, its 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.
\ No newline at end of file +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. + +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.
\ No newline at end of file |