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.

[markschlosseratbentley]

@danielzhong will resolve any conversations that are solved. @danielzhong, let us know when you feel it's ready to merge (after a final quick review).

[danielzhong]

@danielzhong will resolve any conversations that are solved. @danielzhong, let us know when you feel it's ready to merge (after a final quick review).

Ready to merge and review again!

[lilleyse]

I haven't reviewed the code thoroughly, but I have been using this branch for my snapping experiments and functionality-wise it's working nicely.

[lilleyse]

Sorry, meant to post that here CesiumGS/cesium#13110 😄

[weegeekps]

@markschlosseratbentley @danielzhong I am a bit tight on time this week. I've set aside an hour on Monday for myself to sit down and actually give this a deep final review pass.

@danielzhong Could you also please provide me with a little summary that has changed with both spec and implementation since I last looked at this in January? That would be helpful to speed things along. Thank you!

[danielzhong]

Could you also please provide me with a little summary that has changed with both spec and implementation since I last looked at this in January? That would be helpful to speed things along. Thank you!

• Replaced cumulativeDistance accessor index in the material schema with a proper vertex attribute semantic (BENTLEY_materials_line_style:CUMULATIVE_DISTANCE) on line-type primitives.
• Accessor component type now explicitly supports both FLOAT and normalized integer types to enable compatibility with meshopt and similar compression schemes.
• Small details changes like:
  • Copyright year updated from 2025 → 2026.
  • Trailing newline added to material.BENTLEY_materials_line_style.schema.json