Skip to content

Attempt at allowing build element with no built items #62

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Attempt at allowing build element with no built items #62

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
487cbbe
Attempt at allowing build element with no built item and clarifying t…
atardugno Mar 30, 2022
960041d
Changes as per comments
atardugno Mar 30, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 8 additions & 9 deletions 3MF Core Specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,7 +188,7 @@ _Figure 2-1. A typical 3MF Document_

### 2.1.2. 3D Model Part

The _3D Model part_ contains definitions of one or more objects to be fabricated by 3D manufacturing processes. The 3D Model part is the only valid root of a 3D payload.
The _3D Model part_ contains definitions of one or more objects that could be fabricated by 3D manufacturing processes. The 3D Model part is the only valid root of a 3D payload.

A 3D Model part has two sections: a set of resource definitions that include objects and materials, as well as a set of specific items to actually build. The content type of the 3D Model part is defined in Appendix C, "Standard Namespaces and Content Types."

Expand Down Expand Up @@ -292,7 +292,7 @@ The 3MF Document core _XML namespace_, the principal namespace used for elements

As a reminder, a non-default XML namespace on an element DOES automatically apply to any attributes of that element (unless another namespace is prefixed), but DOES NOT apply to sub-elements, so they must all be individually prefixed. Any attributes falling into an anyattribute extension point MUST be prefixed with their corresponding namespace (as all such extension points specify "other" for the required namespace in the XSD schema).

A consumer or editor MUST ignore all XML nodes and attributes from namespaces it does not explicitely support.
A consumer or editor MUST ignore all XML nodes and attributes from namespaces it does not explicitly support.

### 2.3.4. Whitespace

Expand All @@ -308,12 +308,12 @@ The language of the contents of a 3MF Document (typically useful for content pro

# Chapter 3. 3D Models

The _model_, in this specification, refers to the object or objects to be created via 3D manufacturing processes as a single operation. It might include a single object, multiple homogenous objects, multiple heterogeneous objects, an object fully enclosed in another object, or multiple objects in an interlocked and inseparable _assembly_.
The _model_, in this specification, refers to the object or objects to be ultimately created via 3D manufacturing processes as a single operation. It might include a single object, multiple homogenous objects, multiple heterogeneous objects, an object fully enclosed in another object, or multiple objects in an interlocked and inseparable _assembly_. A 3MF Document can be in an intermediate state in which none of the defined objects is yet ready to be manufactured, in which case no actual output object is expected.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the "ultimately" is needed here, we are not changing the core intention of 3MF to be a manufacturing format so the end state of being created by 3D manufacturing is unchanged and since the intermediate state (from editors, simulators etc.) is a possibility but not a certainty we don't necessarily need to make the distinction.



## 3.1. Coordinate Space
## 3.1. Output Coordinate Space

Coordinates in this specification are based on a right-handed coordinate space. Producers and consumers MUST define and map the origin of the coordinate space to the bottom-front-left corner of the device's output field (such as a tray, platform, or bed), with the x-axis increasing to the right of the output field, the y-axis increasing to the back of the output field, and the z-axis increasing to the top of the output field. Producers and consumers MUST use the unit resolution of the coordinate space as specified in the \<model> element.
Coordinates in this specification are based on a right-handed coordinate space. Producers and consumers MUST define and map the origin of the output coordinate space (i.e. the coordinate space used to represent any item within the build element) to the bottom-front-left corner of the device's output field (such as a tray, platform, or bed), with the x-axis increasing to the right of the output field, the y-axis increasing to the back of the output field, and the z-axis increasing to the top of the output field. Producers and consumers MUST use the unit resolution of the coordinate space as specified in the \<model> element.

_Figure 3-1. Coordinate space_

Expand Down Expand Up @@ -363,9 +363,9 @@ Element **\<model>**
| recommendedextensions | **xs:string** | | | Space-delimited list of namespace prefixes, representing the set of extensions that are recommended for processing the document with its design intent. Editors and manufacturing devices SHOULD warn and inform the user if they do not support the recommended extensions and ask for input how to proceed. Required extensions MUST NOT be recommended at the same time. |
| @anyAttribute | | | | |

The \<model> element is the root element of the 3D Model part. There MUST be exactly one \<model> element in a 3D Model part. A model may have zero or more child metadata elements (see [3.4.1. Metadata](#341-metadata) for more information). A model must have two additional child elements: \<resources> and \<build>. The \<resources> element provides a set of definitions that can be drawn from to define a 3D object. The \<build> element provides a set of items that should actually be manufactured as part of the job.
The \<model> element is the root element of the 3D Model part. There MUST be exactly one \<model> element in a 3D Model part. A model may have zero or more child metadata elements (see [3.4.1. Metadata](#341-metadata) for more information). A model must have two additional child elements: \<resources> and \<build>. The \<resources> element provides a set of definitions that can be drawn from to define a 3D object. The \<build> element provides a set of items (if any) that should actually be manufactured as part of the job.

Producers SHOULD NOT require extensions unless the document would lose key meaning without the extension data. Allowing consumers to ignore unsupported extensions gives a more graceful fallback. Required extensions MAY supercede the requirements of the Core specification. However, the Core specification MUST be fully supported when used with optional extensions.
Producers SHOULD NOT require extensions unless the document would lose key meaning without the extension data. Allowing consumers to ignore unsupported extensions gives a more graceful fallback. Required extensions MAY supersede the requirements of the Core specification. However, the Core specification MUST be fully supported when used with optional extensions.


### 3.4.1. Metadata
Expand Down Expand Up @@ -437,8 +437,7 @@ Element **\<build>**

![element build](images/element_build.png)

The \<build> element contains one or more items to manufacture as part of processing the job. A consumer MUST NOT output any 3D objects not referenced by an \<item> element.

The \<build> element could either be empty, in case of a 3MF Document providing only design objects, or contain one or more items to produce as part of processing the job. A consumer MUST manufacture only 3D objects which are referenced by an \<item> element. Any unreferenced object can still be processed by an editing application, which could finalize their manufacturing by referencing them in corresponding \<item> elements.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would make this:
"The <build> element contains zero or more <item> elements to manufacture as part of processing the job. A consumer MUST NOT manufacture any 3D objects not referenced by an <item> element. Any unreferenced object can still be consumed by an editing application, which could then reference them in corresponding <item> elements when they are ready for manufacture."

I think that wording makes it clear that we are supporting new cases without changing any existing workflows.


#### 3.4.3.1. Item Element

Expand Down