BENTLEY_materials_line_style

[markschlosseratbentley]

Introduction

This PR describes an extension to glTF which meets the needs of Bentley Systems for styling line primitives with custom widths and patterning. It is written with the possibility of possible future extensibility in mind; line styling other than width and patterning could be easily included in this specification in the future.

Overview

Lines are fundamental elements in many 3D modeling and computer-aided design (CAD) environments. They are used to annotate two- and three-dimensional visualizations, with variations in width and dash patterns conveying semantic meaning or emphasis.

The BENTLEY_materials_line_style extension defines a method for describing the visual style of lines within glTF material. It enables authors to specify line thickness and a repeating dash pattern.

This extension introduces two primary properties controlling line appearance:

• width: the pixel width of the rendered line
• pattern: an unsigned integer whose bits represent a repeating on/off pattern along the line

[pmconne]

The glTF convention appears to be to name extensions based on the glTF object to which they apply. Rename to BENTLEY_material_line_style (singular "material").

[markschlosseratbentley]

@weegeekps Can you let us know where we want to merge this PR and this PR (once we have full approval)?

• To main branch of the Cesium/glTF fork?
• To some other branch of the Cesium/glTF fork?

[weegeekps]

To some other branch of the Cesium/glTF fork?

It's going to be another branch, but I need to sort out exactly which branch. I've been swamped and haven't had many cycles to figure this out for you, but I will try to get an answer for you tomorrow.

[weegeekps]

@markschlosseratbentley Next week when I have a free moment, I will be creating a branch that will be where all of our vendor extensions live. There are a few things that I want to make sure we have set up for the branch, including branch protection rules, so I need to talk to our admins. I'll let you know as soon as I have the branch ready.

[weegeekps]

Since this is just a vendor extension, I changed the base from main to vendor-extensions.

[markschlosseratbentley]

@weegeekps Recently, some discussion occurred about the necessity of enhancing itwinjs-core to allow the option for line patterns to be drawn such that the pattern begins at the line's origin rather than being calculated solely via screen pixel positions.

^This feature does not currently exist.

We were wondering if we should hold up this spec PR for that eventual feature (unscheduled as of now), or move to merge this spec as-is and potentially amend the spec later?

Your feedback is always valuable. Thanks.

cc @ggetz

[weegeekps]

We were wondering if we should hold up this spec PR for that eventual feature (unscheduled as of now), or move to merge this spec as-is and potentially amend the spec later?

@markschlosseratbentley Better to hold if we are going to make changes.

[danielzhong]

@weegeekps
We’d love your input on the extension shape. For the fix in iTwin/itwinjs-core#8922, we currently store line width + dash pattern on the material, but stable dash alignment needs a per-vertex cumulativeDistance attribute on the primitive (line-type or tessellated line mesh).

Few options:

1. Keep BENTLEY_materials_line_style on material for width/pattern, and define a separate primitive-level extension to declare the cumulative distance attribute (e.g. BENTLEY_lines_cumulative_distance on MeshPrimitive/attributes)?
2. Or extend BENTLEY_materials_line_style so it can be applied both to material (width/pattern) and primitive (attribute metadata)?
3. Or move all line-style info to primitive (non-ideal but consistent)?

More details:
iTwin/itwinjs-core#8922 (comment)

[weegeekps]

The best path forward for you right now is:

• Define a new attribute semantic in this extension for storing the cumulative distance per vertex on the primitive.
• Keep the material schema as is.
• Add an additional schema for the primitive. This schema can be without properties and is meant as an indicator that the primitive is using your attribute semantic. This schema must be named mesh.primitive.BENTLEY_materials_line_style.schema.json.

More than willing to walk through any of this with you if something isn't completely clear.

[weegeekps]

You won't want this here. A semantic is required instead.

[weegeekps]

Nitpick: please include a newline at the end of the file.

Many tools will not properly read JSON that is not POSIX compliant and POSIX compliance requires the newline.

[weegeekps]

Since this is a per-vertex attribute you need to add a semantic for it. Check out this part of the recent KHR_gaussian_splatting extension to see how we defined the custom attributes there.

Each custom attribute must be prefixed appropriately for the extension, so in this case you'd use the full semantic BENTLEY_materials_line_style:CUMULATIVE_DISTANCE. You need to consider what data types could be packed in the attribute with this semantic. The easiest is probably float but if you want this to compress appropriately with meshopt or similar, you need to consider adding normalized integer types as well. Reach out directly to me if you need me to sit down and run step by step through this with you.

Once this stuff is defined and decided on, you can pack your data into the glTF as you normally would with any attribute.

[danielzhong]

@pmconne Do you think normalized integer types would be enough for representing cumulative distance in world space? I'm currently using float, I'm not sure whether normalized integer types is enough across all use cases .

[pmconne]

It will depend on the use case. For example, by default when encoding glTF for tiles, we quantize all vertex positions as 16 bit integers, because our tiler ensures that level of precision is compatible with the tile's LOD. For certain tiles (e.g., large leaf nodes) and certain ordinary (arbitrarily-large, non-LOD) glTF models, doing so could introduce precision issues, so we encode vertex positions as floats instead. Cumulative distances should be quantized (or not) to the same range as the vertex positions. I agree with @weegeekps that the spec should support both floats and normalized integers.

[markschlosseratbentley]

@danielzhong Consider adding "Known Implementations" section like https://github.com/CesiumGS/glTF/blob/vendor-extensions/extensions/2.0/Vendor/BENTLEY_materials_point_style/README.md#known-implementations