KhronosGroup
KITTYCAD_boundary_representation
The glTF core specification provides geometric data in the form of polygonal meshes. Meshes are ubiquitous in hardware accelerated rendering of 3D models; however, since they are composed of flat faces, they cannot represent smooth surfaces accurately. Boundary representation ('B-rep') is an alternative approach, providing an accurate and flexible method of describing 3D shapes. In B-rep models, solid volumes are expressed as the composition of connected faces, bound by curves on surfaces, of which both are described by smooth parametric functions.
The aims of this extension are: (1) to reduce the processing required to import B-rep information when compared to existing formats such as STEP (ISO 10303); (2) to provide an open, royalty-free specification for B-rep data; and (3) to provide additional metadata alongside existing glTF-based manufacturing workflows.
The extension is intended to provide supplementary information to standard mesh-based glTF models. By providing the B-rep data alongside meshes, applications can render approximated previews of solid models without implementing a computationally expensive and complicated tessellation operation. Alternatively, to reduce the size of the asset, the extension could feasibly be used in place of mesh-based models.
Please refer to the README for a technical introduction.
The KITTYCAD prefix does not (yet) appear in https://github.com/KhronosGroup/glTF/blob/main/extensions/Prefixes.md . You might consider an issue/PR to add it.
Beyond that, there are some issues/discussions that may be related, e.g. https://github.com/KhronosGroup/glTF/issues/2306 or https://github.com/KhronosGroup/glTF/issues/1783 . It might be worthwhile checking these, to see whether there has been any previous discussion or similar proposals.
@javagl, noted, the vendor prefix is tentative.
Bézier surfaces are a subset of the more general NURBS curves and surfaces proposed in this extension.
#1783 mentions NURBS and B-reps but makes no proposal. This extension is intended for engineering use cases such as manufacturing and simulation.
The ideas in this extension have been developed on a branch of the Rust glTF library: https://github.com/alteous/gltf/blob/brep/gltf-json/src/extensions/kittycad_boundary_representation.rs
This branch also contains the JSON schema generator: https://github.com/alteous/gltf/blob/brep/gltf-json/src/bin/generate_schema.rs
the vendor prefix is tentative.
I created a PR for adding it via https://github.com/KhronosGroup/glTF/pull/2345 , but should emphasize that there currently is no established policy for handling renamings of prefixes. Iff there is no existing extension with such a prefix, then we could probably handle that, but the goal of the prefixes is to provide some sort of stability/reliability for the actual, final extension name.
Also have a look at the "Naming" section:
Names SHOULD be structured as
<PREFIX>_<scope>_<feature>, where scope is an existing glTF concept (e.g. mesh, texture, image) and feature describes the functionality being added within that scope. This structure is recommended, but not required.
In this case, it might be something like KITTYCAD_mesh_brep or so (I haven't looked at the details of this PR yet).
The main reason for pointing to these issues is the encourage a form of "collaboration", with the goal of finding something that multiple people can agree on. For example (depending on the maturity of this PR and your own judgement!) you could consider to @mention someone from these issues and point them to this PR - maybe they want to review it and chime in with their thoughts and ideas...
Iff there is no existing extension with such a prefix, then we could probably handle that, but the goal of the prefixes is to provide some sort of stability/reliability for the actual, final extension name.
That's fine. By 'tentative' I was thinking along the lines of "another party might be interested in this" and therefore it could be made EXT.
In this case, it might be something like KITTYCAD_mesh_brep or so (I haven't looked at the details of this PR yet).
That's a good point. The mesh scope is related but feels inappropriate. What we're proposing essentially is a new 'solid' scope. So perhaps X_solid_brep would be a better name. This extension is related more closely to the proposed EXT_manifold extension. Is manifold is the name of the scope in that case?
Leaving the option to change the prefix to EXT makes sense. After all, I assume that this PR is still work in progress, and possibly taking into account further feedback. (I cannot give that - I'm not technically involved in the topic - but I'm sure others might be interested in that)
(BTW: One could consider changing this to a 'Draft' unless it is supposed to be 'Ready For Review'. But admittedly, the processes here are not perfectly sorted out. I once started trying to clarify some aspects of the extension development process, but ... the PR at https://github.com/KhronosGroup/glTF/pull/2225 is itself still a 'Draft' 😬 )
This spec has several example JSON snippets for individual features, but I think it would be helpful to add a higher level JSON example near the top. This would help readers who wish to quickly review the overall structure of a Brep.
I love that someone is interested in opening up a modern standard for Brep representation!
As it now stands, this spec does not clearly leverage glTF's core strengths like its well-defined materials model, its animation model (skinning/morphing), and the node model (allows efficient mesh instancing and hierarchical transformations).
I think "playing nicely" with all those features is possible, but the spec should probably make it clear how it all works.
I love that someone is interested in opening up a modern standard for Brep representation!
It's great to have another party interested too, thanks for your review! Modernising B-reps is exactly what we're trying to achieve here. Our main use case is for manufacturing. We want to be able to ship an exact boundary representation, an optional tessellation, and manufacturing data in one bundle. The JSON + binary design of glTF allows this data to be stored more densely than existing formats and with potentially more diverse metadata.
As it now stands, this spec does not clearly leverage glTF's core strengths like its well-defined materials model, its animation model (skinning/morphing), and the node model (allows efficient mesh instancing and hierarchical transformations).
That's a great point. The intention is to integrate well the materials and node model. I'll expand on the documentation there. Solids are meant be to instantiated in the same way as meshes, i.e., they don't appear in the scene unless they are referenced in the node hierarchy. It's up to the application whether they render the pre-tessellated mesh approximation or do something with the B-rep directly.
Animations targeting B-reps are expected to be limited to simple node transformations, i.e., translation, rotation, and scaling.
@alteous all your responses make sense to me. My own interest is the architecture sector as opposed to manufacturing, but I think we'd both want the same things from a Brep format.
I look forward to seeing how this develops, let me know if there's anything I can do to help.
This is interesting, thanks! I agree with @prideout that it would be nice if we could find a way to represent smoothly curved geometry within the existing data structures of glTF, since it would avoid duplication, which can inevitably result in conflicting data. I have some thoughts and progress on this, though it's a pretty different concept from NURBS, or even from subdivision surfaces - it's more a form of curved triangles. I have a short write-up here: https://elalish.blogspot.com/2022/03/smoothing-triangle-meshes.html - I have some improvements I want to make first, but I'm interested in attempting a glTF extension on top of my EXT_mesh_manifold to enable this. Of course, I'm not sure how helpful it'll be for engines that are already NURBS-based, but I'm curious if anyone else is interested in trying a new approach to B-reps?
One semantic nit: glTF meshes are boundary-representations. The difference between triangles and NURBS is first-order vs higher-order, and explicit edges vs implicit edges. I wrote up a taxonomy: https://elalish.blogspot.com/2022/03/solid-geometry-representations.html
