alteous

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

> 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...

> 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...

Looks good, thanks.

I'm using the `"type": "foo"` idiom in https://github.com/KhronosGroup/glTF/pull/2343 for consistency with the camera type, as mentioned in the original post. I agree it could technically be omitted.

This is another case where the core spec has changed such that what was previously required is now optional. https://github.com/KhronosGroup/glTF/commit/f1f0bbe96033105a6e1cc3b3c0621cf9c27bde6e Previously we avoided a breaking semver-change by setting the `Index`...

@kpreid thanks for trying it out and providing feedback so quick! :smile: `byteOffset` not being serialised is a bug, well spotted. `TryFrom` should be a quick fix. I'm not super...

I've given the base constructor a go and it's really not ideal. Here are excerpts of some real code that uses my prototype: ```rust root.push( gltf_ext::buffer::View { stride: Some(vertex_size), target:...

Ah, you're totally right. In that case, I might have to abandon the one data structure approach and go back to having separate structs for core fields and extensions.

A friend of mine suggested to avoid the semver issue by making a major version release each time a new extension is added. I think it kind of defeats the...