BENTLEY_materials_point_style

[markschlosseratbentley]

Introduction

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

Overview

Points are fundamental elements in many 3D modeling and computer-aided design (CAD) environments. In such visualizations, individual point primitives may differ in their styling, mainly focused around their diameter in screen pixels. Such diameter can be used to indicate a variety of meanings useful to CAD applications.

This specification describes a minimal extension sufficient to meet Bentley Systems' requirements in supporting CAD-style visualizations of points using glTF.

[pmconne]

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

[markschlosseratbentley]

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

@pmconne As I look more into this, I am not seeing singular "material" used in other glTF extensions names. Extensions like KHR_materials_specular apply to a single material but still have the plural "materials" in their name.

To be consistent, should we actually considering reverting back to the plural "materials" naming we started with?

cc @danielzhong

[markschlosseratbentley]

I changed copyright as suggested by @weegeekps.

[markschlosseratbentley]

The following branch of iTwin.js has a basic reference implementation: https://github.com/iTwin/itwinjs-core/tree/markschlosser/point-style-gltf

[lilleyse]

I'm taking a look at this a bit late, so apologies if some of this has already been covered

• I was envisioning this as a vertex attribute semantic instead of a material property, that way points of different sizes could be batched together. Curious if that had been considered.
• Would BENTLEY_materials_point_diameter or BENTLEY_materials_point_size but a more precise name?
• In this context, is a pixel a hardware pixel or software pixel (a.k.a. CSS pixel)?

[pmconne]

I was envisioning this as a vertex attribute semantic instead of a material property, that way points of different sizes could be batched together. Curious if that had been considered.

It was considered, but after discussion with @weegeekps and @akmorgan99 we decided to limit these vendor extensions to the feature set we need for iModels, which doesn't include batching points of different sizes. It could be a very minor optimization for CAD models though.

If the extension supported that, would you consider using it, e.g., for point clouds, where batching would be a much more significant optimization?

[lilleyse]

If the extension supported that, would you consider using it, e.g., for point clouds, where batching would be a much more significant optimization?

Actually, I don't have any other use cases in mind. For LiDAR points and vector data we would probably use the 3D Tiles declarative styling langue to control point size.

[weegeekps]

In this context, is a pixel a hardware pixel or software pixel (a.k.a. CSS pixel)?

This does need to be explicitly called out.

RE: 3D Tiles declarative styling language

Have we actually evaluated if the styling language solves the problem this extension is attempting to solve?

[markschlosseratbentley]

* Would `BENTLEY_materials_point_diameter` or `BENTLEY_materials_point_size` but a more precise name?

I think we were going for style language to:

1. Match the naming convention of the also-proposed BENTLEY_materials_line_style extension.
2. Allow for the possibility of revising this extension to store future styling information beyond diameter, if necessary.

[markschlosseratbentley]

Have we actually evaluated if the styling language solves the problem this extension is attempting to solve?

@pmconne - Do you have any thoughts about this topic from when you first were thinking about this problem? I think the differentiator of this extension is being able to directly manipulate individual points' diameters instead of devising a condition for pointSize via the styling language.

[pmconne]

Using the styling language to control individual static point sizes seems inefficient (from a rendering POV) and verbose (from an encoding POV). It's also unclear to me how it would interact with any dynamic styling people want to apply at display time.

[weegeekps]

@pmconne verbosity can definitely be a concern, but at least in practice what we've seen is that the rendering efficiency of the styling is very implementation specific.

That said, this extension is fine and while there is potential overlap I wanted to just make sure we have at least considered the topic in case we get asked about it. The need here is different enough we don't need to use a nail where we need a screw.

[markschlosseratbentley]

In this context, is a pixel a hardware pixel or software pixel (a.k.a. CSS pixel)?

In the proposed CesiumJS reference implementation, we are multiplying the diameter by frameState.pixelRatio, which AFAIK, this is how we go from CSS -> device pixels in CesiumJS - or is this not always the case? If so, I believe we will want this spec to say CSS pixels for diameter.

[lilleyse]

If so, I believe we will want this spec to say CSS pixels for diameter.

👍 for CSS pixels or whatever is the standard verbiage for this

[weegeekps]

@markschlosseratbentley @lilleyse if use the CSS pixels verbiage, please include a link to the definition in the CSS3 docs and a note stating that the pixel is defined as $1\text{px} = \frac{1}{96}\text{th}\ \text{of}\ 1\text{in}$. It makes it clear to any would-be readers as well as pins us to CSS3's definition; useful if it gets changed in the future. While the definition has never changed there's been pushes in the past given that the implementation within the browsers has changed over the years. I doubt any of them will go anywhere but it just seems prudent to be explicit.

[markschlosseratbentley]

I added clarification about CSS pixels to this specification. @weegeekps I included your suggested link and the formatted definition text: $1\text{px} = \frac{1}{96}\text{th}\ \text{of}\ 1\text{in}$

[weegeekps]

So, this PR looks good to go to me. I am planning on approving it and merging it on Monday to the new branch once that is created and configured.

[markschlosseratbentley]

So, this PR looks good to go to me. I am planning on approving it and merging it on Monday to the new branch once that is created and configured.

Sounds good. I just edited the PR description to be a bit more verbose and helpful.

[weegeekps]

Looks good. I'll merge it.