1.3.0-dev review

[bubnikv]

1.2. Introduction The following links: Document Conventions Language Notes Software Conformance lead to nowhere.

Chapter 1. Overview of Additions: Producers only using the other specification elements ... MAY mark as REQUIRED. Please add that it MAY be also marked as RECOMMENDED.

2.2 ImageStack

The left-front-bottom corner of this grid corresponds to the (0,0,0)-UVW coordinate Maybe "(0,0,0)-VUW" would be more accurate?

2.1.1 File Formats

A typical approach to store this levelset information is to encode the signed distance field of the boundary of the object in this channel, or to limit the encoding to a narrow region around the boundary of the object.

Referencing a narrow band here is misleading without giving more context. Why is the narrow band mentioned here? One may exploit the "narrow band" concept for better compression by scaling the scalar function so that it will be clamped inside narrow band, thus most of the pixels will be 0/255 or 0/65535.

2.2.2 OPC package layout

The 3D Texture part that is the MUST be associated with the 3D Model part via the 3D Texture relationship.

I suppose one wants to convey that each imagesheet will be referenced as one 3D Texture?

2.2.3 3D Image Sheet Last line:

Adding a different physical implementation of a voxel grid as child under would not affect the remaining parts of this specification.

different physical implementation is a misleading wording as it evokes the manufacturing "physical" properties, not implementation of the data format.

3.2 Scalar Field From Image3D

tilestyle "none" will discard the 's value if the 3d texture coordinate s falls outside the [0,1] range. This means, when blending volumetric layers, no blending of values takes place if this is sampled outside the [0,1]-range. This is useful if a 3d texture is used as masking channel for a volumetric decal of sorts that affects only a limited region in the volume.

Sorry, I don't understand.

It may be much simpler to REQUIRE a "out of UV range" value for "none" tilestyle.

Otherwise we would have to introduce an "undefined" sample value and process it specially in compositions and elsewhere.

5.2. Volumetric Data

Moreover, the volumedata-element MUST not be used in a mesh that is referenced as "originalmesh" by any other mesh.

Why? Add an explanation?

We need to define the clipping surface of a mesh with a element.

"need" may evoke "required". "Mesh may optionally be clipped with a element" sounds more accurately.

We need to define the clipping surface of a mesh with a element. The clipping surface is defined as follows:

2) Please make it explicit, that at least some mesh is required to enclose a levelset, for example a simple cube, otherwise one may suppose that an empty mesh may represent the infinite space.

Volumetric content is always clipped to the clipping surface of the mesh that embeds it. If a property (color, composite or properties) defined at the surface of an object conflicts with the property within the object defined by this extension, a surface layer should be defined with a thickness as small as possible to achieve the surface property on the outside of the object. Outside of this thin surface region, the volumetric property should be applied everywhere within the object.

Infinitesimally thin surface has no meaning in manufacturing context. Better to define, that in surface context the surface color is used, in volumetric context the volumetric color overrides the surface color. Which context to apply (surface or volumetric) likely depends on the consumer / manufacturing process.

In general: Are there any limitations to the transformation matrices? Negative determinant? Skew? Non-zero determinant?

General and compositing in particular (likley nitpicking): Do we want to specify accuracy of the samples? Single / double precision IEEE 754?

[bubnikv]

Add a section "Limitations"?

1) One cannot overlay a scalar / vector field over a meshless (composite) object, one has to duplicate the scalar fields at the object leaves.

2) Fields are limited to 1d and 3d. Vectors of other dimensionality must be assembled by the producer / consumer using multiple 1d / 3d fields.

3) RGB field with alpha channel is not supported, however one may blend one RGB field with another RGBA field explicitely by extracting the alpha channel into a scalar field and by using the alpha scalar field as a composition mask of two RGB vector3dfields.

[martinweismann]

https://github.com/3MFConsortium/spec_volumetric/pull/43 addresses 7 of the points in this issue. The other points have been split off into separate issues.

Last open point:

"Mesh may optionally be clipped with a element" sounds more accurately. @bubnikv Can you elaborate?

Comments to https://github.com/3MFConsortium/spec_volumetric/pull/43:

tilestyle "none" used to work, as the volumetric stack used to always offer a backgorund value. Not the case anymore. I think we can get rid of it.

2.2.2 OPC package layout

The 3D Texture part that is the MUST be associated with the 3D Model part via the 3D Texture relationship.

I suppose one wants to convey that each imagesheet will be referenced as one 3D Texture? Yes, this is clumsy OPC wording from from some other 3MF spec. Should be better now.

5.2. Volumetric Data

Moreover, the volumedata-element MUST not be used in a mesh that is referenced as "originalmesh" by any other mesh.

Addressed.