Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KITTYCAD_boundary_representation #2343

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
250 changes: 250 additions & 0 deletions extensions/2.0/Vendor/KITTYCAD_boundary_representation/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,250 @@
# KITTYCAD\_boundary\_representation

## Contributors

* David Harvey-Macaulay, KittyCAD [@alteous](https://github.com/alteous)

## Status

Draft

## Dependencies

Written against the glTF 2.0 spec.

# Overview

A [boundary representation](https://en.wikipedia.org/wiki/Boundary_representation) (abbreviated as 'B-rep') provides an exact definition of solid volumes. B-reps can represent smooth surfaces such as spheres more precisely than polygonal meshes.

B-reps need to be tessellated to be able to be rendered using standard graphics APIs such as Vulkan and OpenGL. For backward compatibility, this extension allows for B-reps to be associated with a tessellation (i.e., a mesh) that has been precomputed. When this is the case, the extension will appear in the `extensionsUsed` property. Where tessellations are not provided, the extension is listed in the `extensionsRequired` property and nodes are permitted to reference a sole B-rep item.

## Concepts

### Solid

A _solid_ represents a single volume of solid material. The boundary of the volume is called the solid's _outer shell_. In addition to its outer shell, a solid may have internal hollow regions; such regions are called _inner shells_. Both outer shells and inner shells are represented by the `Shell` data structure.

![solid-example](figures/solid.png)

#### Example

The interior hollow space of a tennis ball would be represented by an inner shell. The surface of the tennis ball would be represented by its outer shell.

![tennis-ball-cross-section](https://content.instructables.com/FRV/UI1L/J2AW02WE/FRVUI1LJ2AW02WE.jpg?auto=webp&frame=1&width=1024&height=1024&fit=bounds&md=da5cf8a96b88acbea9eb082a7b378ae7)

### Shell

A _shell_ is a collection of _faces_ in 3D space which form a 'watertight' volume. A shell is represented by the `Shell` data structure.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some applications might permit non-manifold modeling, in which case it would be desirable to allow shells to be non-closed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. I'm thinking of reworking many of the data structures in this direction. In particular, I'm considering removing the outer/inner loop distinction in faces, perhaps replacing it with extra metadata in the loop data structure instead. The same idea can be applied to shells.


### Face

A _face_ is a portion of a _surface_ in 3D space. Multiple faces are referenced to form _shells_.

Faces are associated with the 3D surface they are defined on. The boundary of faces are defined by a set of _edges_ which form a closed _loop_ in 3D space, following the contours of its associated surface. The boundary of a face is defined by its _outer loop_. In a similar manner to _shells_, faces may have internal hollow regions; such regions are called _inner loops_. Both outer loops and inner loops are represented by the `Loop` data structure.

![face-example](figures/face.png)

#### Example

This face is formed by a closed loop of 3D curves which are coincident to its associated planar surface. The grid visualizes the associated planar surface.

### Loop

A _loop_ is a set of _edges_ that combine to form a closed circuit. Edges are referenced in the loop so that their direction may be reversed.

![loop-example](figures/loop.png)

### Curve

A _curve_ defines a function that evaluates a single parameter to a point in either 2D or 3D space, depending on context.

Curves are referenced by _edges_ to define the boundary between _faces_ in 3D space. Supplementary curves may be referenced by _loops_ to define the same boundary between _faces_ in 2D _surface_ parameter space.

#### Base structure

```json
{
"type": "curveType",
"curveType": {
"curveSpecificValue": 1

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is curveSpecificValue?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This snippet is meant to convey the general structure of a curve entry. The structure is similar to that of cameras where there is a type field set to either "perspective" or "orthographic" and the camera-specific fields are put under camera.perspective/camera.orthographic respectively.

https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#reference-camera

On a slightly unrelated note, this kind of sum type has been discussed in #2311.

},
"domain": {
"min": 0,
"max": 1
}
}
```

#### Line (start & direction)

```json
"line": {
"start": [-1, -1, -1],
"direction": [1, 1, 1],
}
```

#### Line (start & end)


```json
"line": {
"start": [-1, -1, -1],
"end": [1, 1, 1],
}
```

#### Circle

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be more flexible for a curve to be "circular arc" rather than a "circle"?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good point. I think this is a matter of naming. All curves have an optional subdomain so they are meant to be flexible in this way already, i.e., a circle curve with a subdomain would be an arc of the circle.



```json
"circle": {
"radius": 1,
"origin": [0, 0, 0],
"normal": [0, 0, 1],
"xbasis": [1, 0, 0]
}
```

#### [NURBS](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)


```json
"nurbs": {
"controlPoints": [
[1.0, 0.0, 0.0, 1.0],
[1.0, 1.0, 0.0, 0.7071],
[0.0, 1.0, 0.0, 1.0]
],
"knotVector": [0, 0, 0, 1, 1, 1],
"order": 3
}
```

## Surface

A _surface_ defines a function that evaluates two parameters to a point in 3D space.

Surfaces are referenced by _faces_ to define the implicit geometry bounded by _loops_.

#### Base structure

```json
{
"type": "surfaceType",
"surfaceType": {
"surfaceSpecificValue": 1
},
"domain": {
"min": [0, 0],
"max": [1, 1]
}
}
```

#### Plane

```json
"plane": {
"normal": [0, 0, 1],
"point": [0, 0, 0]
alteous marked this conversation as resolved.
Show resolved Hide resolved
}
```

#### Cylinder (extruded circle)

```json
"cylinder": {
"circle": {
"radius": 1,
"origin": [0, 0, 0],
"normal": [0, 0, 1],
"xbasis": [1, 0, 0]
}
}
```

#### Torus (revolved circle)
Copy link

@prideout prideout Nov 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NURBS, RevolutionSurface, and Plane all seem like fundamental surface types to me, but torus does not. Although, it's unclear if the object key here is just a human-readable name or if it defines the actual type of parametric surface.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surfaces of revolution and extrusion are planned and in progress at the moment but haven't been added to this PR yet.

This particular section was intended to introduce a type of a parametric surface. Perhaps that could be made clearer.

Now that you mention it, I do wonder if it's worth having distinct types for cylinders and tori at all since they could be simply inferred as circle + extrusion/revolution.


```json
"torus": {
"origin": [0, 0, 0],
"radius": 5,
"circle": {
"radius": 1,
"normal": [0, 0, 1],
"xbasis": [1, 0, 0]
}
}
```

#### Sphere

```json
"sphere": {
"horizon": {
"origin": [0, 0, 0],
"radius": 1,
"normal": [0, 0, 1],
"xbasis": [1, 0, 0]
}
}
```

#### [NURBS](https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline)

```json
"nurbs": {
"controlPoints": [
[0, 0, -1, 1]
[0, 2, -1, 1],
[1, 0, -1, 0.7071],
[1, 2, -1, 0.7071],
[1, 0, 0, 1],
[1, 2, 0, 1],
],
"numControlPoints": [3, 2],
"numKnots": [6, 4],
"knotVector": [3, 3, 3, 4, 4, 4, 0, 0, 2, 2],
"order": [3, 2]
}
```

## Orientation

Many objects in boundary representation have two _orientation states_. Such objects are called _orientable_ objects. These are often given colloquial terms such as 'right/wrong side', 'up/down', 'in/out', 'forward/backward', et cetera. When referencing orientable objects, it is important to state which orientation of the object is desired. The orientation of a referenced object is described as being 'same-sense' or 'opposite-sense'. This extension utilizes the sign bit of floating point numbers to select the desired orientation. A positive sign selects the 'same-sense' and a negative sign selects the 'opposite-sense'.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the working group meeting, it was raised that -0 would likely be parsed as 0 by some JSON parsers. Also, it was raised that the IEEE754 specification says -0 == 0 should evaluate as true. These are both good points, so I will come up with an alternative.

I have a few ideas:

  1. Encode using an object { "index": 0, "reverse": true }. This was actually the original proposal but since this use case is so common, this approach was deemed too verbose/bloated.
  2. Use indices starting at 1. This avoids the tricky zeroth index but would be inconsistent with the core specification. I would like to avoid this one if possible.
  3. Encode as a string instead, i.e,. "-0" instead of -0. This could work; however, it was raised this has its own set of problems. For example, glTF JSON permits additional integer representations such as exponential notation.
  4. Move this data into the binary blob and encode as a one's complement integer.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple more ideas:

  1. Encode using two integers per array, an index followed by a sign.
{
    "edges": [
        0, 1,
        1, -1,
        2, 1,
        3, -1
    ]
}
  1. Encode the sign using a separate paired array, which could be omitted if all items are same-sense:
{
    "edges": [0, 1, 2, 3],
    "edgeOrientations": [1, -1, 1, -1]
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reworked this as an integer/orientation pair. It looks like this:

Before

{
    "loops": [0, -1],
    "surface": 0
}

After

{
    "loops": [
        [0, 1],
        [1, -1]
    ],
    "surface": [0, 1]
}

[index, 1] could be implied by [index] but I'll keep it explicit for now.

#### Example

```json
"loops": [
{
"edges": [0, 1]
},
{
"edges": [-0, -1]
}
]
```

### Shell

Outer shells have all their faces oriented to point outside of the shell interior. Inner shells have all their faces oriented towards the shell interior. A shell could be referenced in its opposite sense when used to form a hollow region in a _solid_.

### Face

The circuit direction of the outer loop of a face determines its orientation. A face is typically oriented facing 'outwards' from the interior of its parent shell. This is the case when the outer loop forms a counter-clockwise circuit when viewed from above and outside the material. This circuit direction is often called its _winding order_. A face could be be referenced its in opposite sense when used to form an inner shell.

### Surface

The orientation of a surface refers to the normal vector evaluated at any point on the surface. In the opposite-sense, the normal vector evaluated at any point on the surface is inverted, i.e., all components are multiplied by -1.

### Edges

Edges are always oriented in the same sense as their associated 3D or 2D curves.

Edges are referenced in their opposite sense to form loops with a specific _winding order_ (see faces).

### Curve

Curves are oriented in the direction of increasing values of their evaluation parameter.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

Large diffs are not rendered by default.

Loading