EXT_mesh_primitive_edge_visibility
The EXT_mesh_primitive_edge_visibility extension augments a triangle mesh primitive with sufficient information to enable engines to produce non-photorealistic visualizations of 3D objects with visible edges. The edge visibility is encoded in a highly compact form to avoid excessively bloating the glTF asset. Adapted for glTF from https://github.com/iTwin/itwinjs-core/pull/5581. We intend to add support for the extension to the CesiumJS engine.
@pmconne so excited for this!
- @lilleyse could you please take a quick look from a 3D Tiles and CesiumJS perspective?
- @kring could you take a quick look from a Cesium Native and game engine perspective?
@kring @javagl @pjcozzi thank you for your feedback. I've revised the spec accordingly.
@kring @javagl @lexaknyazev or others - do you have any additional feedback for @pmconne on this extension?
@pmconne I read through the spec again and I think this looks great! No further suggestions from me.
I would like to see a complete implementation of this extension in CesiumJS or iTwinJS, though, if there isn't one already. It would be useful both as proof that it can be implemented sensibly in WebGL (2?), and for my own interest in the rendering techniques involved.
I would like to see a complete implementation of this extension in CesiumJS or iTwinJS
Most of the rendering pieces are already in place in iTwin.js. I think the quickest path to a complete implementation would be for me to update the iModel -> 3D Tiles pipeline to encode the edges according to the spec and update iTwin.js decode accordingly.
Would this extension conflict or overlap with present or future support for ngon meshes and/or storing edge connectivity information? I can envisage an extension that handles both of these aims compactly but if an extension merely tackles one or the other then supporting both might result in redundant data being stored. I'm thinking of #1620 and in particular my comment here
How does this extension define the ends of each edge? Do they just end? Are they beveled/rounded? How do they connect to other edges?
Beveling and rounding are only meaningful for wide (> 1 pixel) lines. Wide lines/edges are important in many of the same CAD use cases as visible edges, but IMO they are mostly orthogonal. I plan to propose a separate "line material" extension to describe wide/patterned lines (which would also be applicable to edges).
@kring said:
I would like to see a complete implementation of this extension in CesiumJS or iTwinJS, though, if there isn't one already. It would be useful both as proof that it can be implemented sensibly in WebGL (2?), and for my own interest in the rendering techniques involved.
We have implemented this extension in iTwin.js.
@lexaknyazev Any other changes required preventing us from getting this approved and merged? Like EXT_primitive_restart, this is intended to just be an open multi-vendor extension.
The spec has been updated to now list CesiumJS as a known implementation in addition to iTwin.js. These implementations have the caveat that they do not implement the full capability of this specification, namely materials. This support is forthcoming.