diff --git a/dev-docs/ROADMAP.md b/dev-docs/ROADMAP.md
index 003f4a30..73d9f3cf 100644
--- a/dev-docs/ROADMAP.md
+++ b/dev-docs/ROADMAP.md
@@ -1,10 +1,23 @@
# Roadmap
-## Performance
+## 3D Primitives
-TBA:
+- Add a submodule with the geometry primitives from luma.gl.
-- Quantify
-- Add bench target
+### Geometry Processing
-## About Library Size
+- Provide a library for CPU side geometry processing, for calculating normals, ray casting etc.
+- There is initial code in `@loaders.gl/math` that should be cleaned up and moved to math.gl.
+
+### Improved Columnar Table Support
+
+- Geometries are essentially columnar tables, emphasize this further to simplify integration with columnar table systems, primarily ArrowJS.
+
+### GPU Powered Math?
+
+- TBA
+
+## Interoperability and Framework Independence
+
+- An ambition is that math.gl should be able to serve a general purpose 3D math library, enabling the creation of framework-independent 3D and Geospatial code that interoperates with a variety of frameworks.
+- math.gl modules (such as geospatial math) should be usable by applications using other frameworks, without having to use the core math.gl classes.
diff --git a/docs/modules/core/wip/features.md.disabled b/dev-docs/design-notes.md
similarity index 100%
rename from docs/modules/core/wip/features.md.disabled
rename to dev-docs/design-notes.md
diff --git a/docs/README.md b/docs/README.md
index eb3f335c..2092a5cb 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,22 +1,28 @@
# Introduction
-Welcome to math.gl! math.gl is JavaScript math library focused on **geospatial** and **3D** use cases, designed as a composable, **modular toolbox**. math.gl provides a core module with classic vector and matrix classes, and a suite of optional modules implementing various aspects of geospatial and 3D math.
+Welcome to math.gl! math.gl is JavaScript (TypeScript) math library focused on **geospatial** and **3D** use cases. Designed as a composable, **modular toolbox**. math.gl provides a core module with classic vector and matrix classes, and a suite of optional modules implementing various aspects of geospatial and 3D math.
-While the math.gl is highly **optimized for use with the WebGL and WebGPU APIs**, math.gl itself has no WebGL dependencies.
+While math.gl is highly **optimized for use with the WebGL and WebGPU APIs**, it has no WebGL dependencies and is designed to be usable in any application.
+
+## Features
+
+- **3D math** - Basic vectors and matrices, as well as 3D primitives and culling: **`@math.gl/types`**, **`@math.gl/core`**, **`@math.gl/culling`**
+- **Geospatial projections** - Support for a variety of geospatial projections **`@math.gl/geospatial`**, **`@math.gl/geoid`**, **`@math.gl/proj4`**, **`@math.gl/web-mercator`**
+- **Geospatial utilities** - Cutting polygons and calculating sun position and direction **`@math.gl/polygon`**, **`@math.gl/sun`**
+- **Discrete Global Grids** - Standardized interfaces to a number of the major discrete global grids. **`@math.gl/geohash`**, **`@math.gl/quadkey`**, **`@math.gl/s2`**
## Modules
math.gl is a toolbox that offers a suite of composable modules.
-| **Core math libraries** | Module | Description |
-| --------------------------------------------------- | ------------------------------------ | -------------------------------------------------- |
-| | | |
-| | **`@math.gl/types`** | Basic math type helpers (`NumericArray` etc) |
-| ![core](./images/core.png 'core') | **`@math.gl/core`** | 3D math classes (vectors, matrices, etc) |
-| ![culling](./images/culling.png 'culling') | **`@math.gl/culling`** | Bounding volumes and intersection testing. |
+| **Core math libraries** | Module | Description |
+| ------------------------------------------ | ------------------------------------ | -------------------------------------------- |
+| | **`@math.gl/types`** | Basic math type helpers (`NumericArray` etc) |
+| ![core](./images/core.png 'core') | **`@math.gl/core`** | 3D math classes (vectors, matrices, etc) |
+| ![culling](./images/culling.png 'culling') | **`@math.gl/culling`** | Bounding volumes and intersection testing. |
| **Geospatial math libraries** | Module | Description |
-| --------------------------------------------------- | --------------------------- | -------------------------------------------------- |
+| --------------------------------------------------- | ------------------------------------ | -------------------------------------------------- |
| ![geospatial](./images/geospatial.svg 'geospatial') | **`@math.gl/geospatial`** | Ellipsoidal math for WGS84 coordinates. |
| ![geoid](./images/geoid.png 'geoid') | **`@math.gl/geoid`** | Earth Gravity Model support . |
| | **`@math.gl/polygon`** | Polygon math, including geospatial cutting etc. |
@@ -24,12 +30,12 @@ math.gl is a toolbox that offers a suite of composable modules.
| | **`@math.gl/sun`** | Solar position / direction from position and time. |
| | **`@math.gl/web-mercator`** | Supports 3D Web Mercator (spherical) projections. |
-| **DGGS (Discrete global grid support) libraries** | Module | Description |
-| --------------------------------------------------- | --------------------------- | -------------------------------------------------- |
-| | | |
-| ![geohash](./images/dggs/geohash.png 'geohash') | **`@math.gl/geohash`** | Get geometry of GeoHash tokens. |
-| ![quadkey](./images/dggs/quadkey.png 'quadkey') | **`@math.gl/quadkey`** | Get geometry of QuadKey tokens |
-| ![s2](./images/dggs/s2.png 's2') | **`@math.gl/s2`** | Get geometry of S2 tokens. |
+| **DGGS (Discrete global grid support) libraries** | Module | Description |
+| ------------------------------------------------- | ------------------------------------ | ------------------------------- |
+| | | |
+| ![geohash](./images/dggs/geohash.png 'geohash') | **`@math.gl/geohash`** | Get geometry of GeoHash tokens. |
+| ![quadkey](./images/dggs/quadkey.png 'quadkey') | **`@math.gl/quadkey`** | Get geometry of QuadKey tokens |
+| ![s2](./images/dggs/s2.png 's2') | **`@math.gl/s2`** | Get geometry of S2 tokens. |
In addition, math.gl provides a few deprecated legacy modules, to avoid breaking older applications.
diff --git a/docs/modules/core/developer-guide/debugging.md b/docs/developer-guide/debugging.md
similarity index 100%
rename from docs/modules/core/developer-guide/debugging.md
rename to docs/developer-guide/debugging.md
diff --git a/docs/modules/core/developer-guide/external-frameworks.md b/docs/developer-guide/external-frameworks.md
similarity index 100%
rename from docs/modules/core/developer-guide/external-frameworks.md
rename to docs/developer-guide/external-frameworks.md
diff --git a/docs/developer-guide/dggs.md b/docs/developer-guide/geospatial/dggs.md
similarity index 72%
rename from docs/developer-guide/dggs.md
rename to docs/developer-guide/geospatial/dggs.md
index 03267b00..d62482a9 100644
--- a/docs/developer-guide/dggs.md
+++ b/docs/developer-guide/geospatial/dggs.md
@@ -33,3 +33,34 @@ Rather than expose the original function names as in the existing JavaScript lib
| Get cell center | `getS2LngLat` | `getQuadKeyLngLat` | `getGeoHashLngLat` | `getH3LngLat` |
| Get cell boundary | `getS2Boundary` | `getQuadKeyBoundary` | `getGeoHashBoundary` | `getH3Boundary` |
| Get cell boundary flat | `getS2BoundaryFlat` | `getQuadKeyBoundaryFlat` | `getGeoHashBoundaryFlat` | `getH3BoundaryFlat` |
+
+## Comparison of DGGS Systems
+
+### H3
+
+H3, initally developed at Uber, is now widely used across the geospatial indusry.
+While not directly supported by math.gl, is in fact the DGGS we would recommend for most applications.
+
+- Extensive, optimized, evolving API.
+- Superb cross-language support.
+- Equal distance between neighboring cells
+- Similar size between all cells.
+- K-ring formation for filtering and convolutions
+
+Downsides:
+- More complex projection math.
+
+### GeoHash
+
+Geohash is common choice open source word http://en.wikipedia.org/wiki/Geohash
+
+Good cross-language support.
+
+### QuadKey
+
+Bing Maps uses a [quadkey](http://msdn.microsoft.com/en-us/library/bb259689.aspx.) structure as their tiling scheme. Here is an overview of the concept
+
+- Quadtrees are more predictable in that each level spans a square (at least in terms of coordinates), whereas in geohash representation sometimes squares sometimes rectangles are spanned.
+
+### Other systems
+
diff --git a/docs/developer-guide/geospatial-models.md b/docs/developer-guide/geospatial/geospatial-models.md
similarity index 100%
rename from docs/developer-guide/geospatial-models.md
rename to docs/developer-guide/geospatial/geospatial-models.md
diff --git a/docs/modules/core/concepts/coordinate-systems.md b/docs/developer-guide/math/coordinate-systems.md
similarity index 100%
rename from docs/modules/core/concepts/coordinate-systems.md
rename to docs/developer-guide/math/coordinate-systems.md
diff --git a/docs/modules/core/developer-guide/floating-point.md b/docs/developer-guide/math/floating-point.md
similarity index 100%
rename from docs/modules/core/developer-guide/floating-point.md
rename to docs/developer-guide/math/floating-point.md
diff --git a/docs/modules/core/concepts/homogeneous-coordinates.md b/docs/developer-guide/math/homogeneous-coordinates.md
similarity index 100%
rename from docs/modules/core/concepts/homogeneous-coordinates.md
rename to docs/developer-guide/math/homogeneous-coordinates.md
diff --git a/docs/modules/core/concepts/rotations.md b/docs/developer-guide/math/rotations.md
similarity index 61%
rename from docs/modules/core/concepts/rotations.md
rename to docs/developer-guide/math/rotations.md
index 5982ae5b..3ca81496 100644
--- a/docs/modules/core/concepts/rotations.md
+++ b/docs/developer-guide/math/rotations.md
@@ -1,18 +1,6 @@
# 3D Rotations
-> This article is a work in progress.
-
-math.gl provides a "standard 3D library complement" of mathematical classes for handling rotations in 2D and 3D, such as classes for manipulating `Euler` angles and `Quaternion`s. As in any 3D math library, the key goals are enabling applications to easily and intuitively specify (parametrize) rotations, combine them with other rotations and other transformations, and ultimately transform points with the rotations or resulting transformations.
-
-While math.gl is intended to help programmers' implement the typical 3D application's rotation functionality with a minimum amount of knowledge, and does not even attempt to support rotations in more than 3 dimensions, it should be pointed out that the mathematical treatment of rotations can be very complicated. For some context on this see the background section at the end of this article.
-
-### Properties of 3D Rotations
-
-- In contrast to 2D rotations, 3D rotations are not order-independent, meaning that applying the same two rotations in different order will often yield different results.
-- However, by [Euler's Rotation Theorem](https://en.wikipedia.org/wiki/Euler%27s_rotation_theorem), two 3D rotations around the origin can always be expressed as (combined into) another single 3D rotation around the origin.
-- A 3D rotation requires a minimum of three values to be fully specified (and even then can require careful definitions of which conventions are used).
-
-Also, a simple observation: Rotations around arbitrary points can be treated as rotations around the origin simply by applying a translation before the rotation, and the inverse translation after the rotation. Therefore, for simplicity, this discussion focuses solely on rotations around the origin.
+The math.gl core module aims to provide the standard "3D math library" arsenal of mathematical tools. This includes tools for handling rotations in 2D and 3D via `Euler` angles, `Quaternion`s and 4x4 matrix operations. As in any 3D math library, the key goals are enabling applications to easily and intuitively specify (parametrize) rotations, combine them with other rotations and other transformations, and ultimately transform points with the rotations or resulting transformations.
## Parametrizing 3D Rotations
@@ -43,7 +31,7 @@ Because of the variability, a good approach is often to be extremely careful whe
### Unit Quaternions
-"Unit quaternions" are normally the best representation for "manipulation" of 3D rotations. Manpulation here mainly refers to the "composition" or "addition" and interpolation of rotations.
+"Unit quaternions" are normally the best representation for "manipulation" of 3D rotations. Manipulation here mainly refers to the "composition" or "addition" and interpolation of rotations.
Note that unit quaternions are simply quaternions of norm (or length) equal to `1`, and while a general quaternion (as the name suggests) contains four components, a unit quaternion needs only three values to be fully specified.
@@ -55,7 +43,9 @@ Interpolation of quaternions is done using Spherical Linear intERPolation (aka S
## Rotation Matrices
-When combining rotations with other transformations (translations, scalings, projections etc), 4x4 matrices are the representation of choice.
+Rotations around arbitrary points can be treated as rotations around the origin simply by applying a translation before the rotation, and the inverse translation after the rotation.
+
+Thus, when combining rotations with other transformations (translations, scalings, projections etc), 4x4 matrices are the representation of choice.
## Properties of Rotation Matrices
@@ -109,22 +99,23 @@ Calculate the quaternion that represents the rotation you want to apply (e.g. mo
## Background: Rotations are Complicated
-If you are new to working with rotations and the amount of complications outlined in this article seem overwhelming, take some comfort in the fact that rotations in three and higher dimensional spaces are indeed quite complicated to treat mathematically.
+If you are new to working with 3D rotations it can be good to have an awareness of how they differ mathematically from 2D rotations
-As an example, several fundamental properties of rotations are highly dependent on the number of dimensions involved. To help the reader who has not worked extensively with rotations build some "intuition" for the fact that 3D rotations are non-trivial, the following summary shows how the nice, structured properties of 2D rotations gradually disappear as the number of dimensions increase:
-
-- In two dimensions, rotations are highly structured and intuitive:
+In two dimensions, rotations represent a highly structured and intuitive set of operations:
- A series of 2D rotations can be applied in any order (they commute).
+ - The combination of two 2D rotations can always be expressed as another single rotation (simply by taking the sum of the angles of the two rotations).
- Any 2D rotation can be fully parametrized by a single value (the "angle").
- The combination of two 2D rotations can always be expressed as another single rotation (simply by taking the sum of the angles of the two rotations).
-- In three dimensions rotation start to loose some structure:
- _ In 3D, rotations are no longer order-independent (they are not commutative), meaning that applying the same two rotations in different order will often yield different results.
- _ However, by [Euler's Rotation Theorem](https://en.wikipedia.org/wiki/Euler%27s_rotation_theorem), two 3D rotations around the origin can still always be expressed as (combined into) another single 3D rotation around the origin. \* Also, a 3D rotation requires not two, but a minimum of three values to be fully specified.
-- To give some contrast, in four and higher dimensions:
- - Naturally, rotations still no longer commutative.
- - And worse: Euler's Rotation Theorem no longer holds. There are now two different types of basic rotations, and the combination of two rotations will in general not result in another "rotation", but another, more complex transformation.
- - In addition, the number of parameters (degrees of freedom) required to fully specify a rotation grows with mind-boggling rapidity, as 2^(n-1) - 1, meaning that e.g. a "21 dimensional rotation" would require over one million values to be fully specified!
+However, in three dimensions, rotations start to loose some "structure":
+ - In 3D, rotations are no longer order-independent (they are not commutative), meaning that applying the same two rotations in different order will often yield different results.
+ - However, by [Euler's Rotation Theorem](https://en.wikipedia.org/wiki/Euler%27s_rotation_theorem), two 3D rotations around the origin can still always be expressed as (combined into) another single 3D rotation around the origin.
+ - Also, a 3D rotation requires not two, but three values to be fully specified.
+
+While math.gl does not support rotations in four and higher dimensions, it should be no surprised that rotations continue to "loose structure" as the number of dimensions increase:
+ - Higher dimension rotations are also not commutative.
+ - Euler's Rotation Theorem no longer holds. There are now two different "types" of basic rotations, and the combination of two rotations will in general not even result in another "rotation", but another, more complex transformation.
+ - In addition, the number of parameters (degrees of freedom) required to fully specify a rotation grows with mind-boggling rapidity, as `2^(n-1) - 1`, (meaning that e.g. a "21 dimensional rotation" would require over one million values to be fully specified).
+
## Background: More on Euler Angles
[Euler angle values](https://en.wikipedia.org/wiki/Euler_angles)
@@ -138,4 +129,4 @@ As an example, several fundamental properties of rotations are highly dependent
## Remarks
- In this article, the word "axes" represents the plural of a (coordinate) "axis" (normally, the word "axes" refers to the X, Y and Z coordinate axes).
-- **Note** that one of the most efficient way to specify rotations is to use the Euler-Rodrigues parameters, which has some of the quaternion representation without requiring the introduction of quaternion algebra. math.gl does not directly support this representation though although the vector/angle can easily be converted.
+- **Note** that one of the most efficient way to specify rotations is to use the Euler-Rodrigues parameters, which has some of the quaternion representation without requiring the introduction of quaternion algebra. math.gl does not directly support this representation although the vector/angle can easily be converted.
diff --git a/docs/modules/core/developer-guide/transformations.md b/docs/developer-guide/math/transformations.md
similarity index 100%
rename from docs/modules/core/developer-guide/transformations.md
rename to docs/developer-guide/math/transformations.md
diff --git a/docs/modules/core/developer-guide/view-and-projection.md b/docs/developer-guide/math/view-and-projection.md
similarity index 82%
rename from docs/modules/core/developer-guide/view-and-projection.md
rename to docs/developer-guide/math/view-and-projection.md
index 05c3c012..8f4ed705 100644
--- a/docs/modules/core/developer-guide/view-and-projection.md
+++ b/docs/developer-guide/math/view-and-projection.md
@@ -1,11 +1,11 @@
-## View and Projection Matrices
+# View and Projection Matrices
-One of the major functions of any 3D math library is to let applications create view and projection matrices to enable positioning of the viewer in a 3D world and projection of a field-of-view onto a flat "screen".
-
-## View and Projection Matrices
+One of the major functions of any 3D math library is to let applications create view and projection matrices to enable positioning of the viewer in a 3D world and projection of 3D geometries via a field-of-view onto a flat "screen".
To set up a 4x4 view projection matrix you need a view matrix (specifying the position, direction and orientation of the camera) and a projection matrix (specifying the characteristics of the camera such as its field of view etc).
+## View Matrices
+
The purpose of the view matrix is to translate and rotate your world coordinates so that the eye is located in the origin `[0, 0, 0]`, looking down the positive `Z` axis, rotated so that the right direction is `up`. This is called the "view coordinate system".
The purpose of the projection matrix is to transform from view coordinates to "clipspace" coordinates (which is the only coordinate system that the GPU can work directly with). If a point is between `-1` and `1` (after `w` scaling) in clipspace, it will be rendered. The `z` coordinate in clipspace is also scaled (using 'near' and 'far' planes) and if between `-1` and `1` it is used for depth test.
@@ -22,7 +22,11 @@ Normally positions are transformed by the view matrix. If doing work (e.g. light
## Projection Matrices
-Projection matrices typically show everything inside a frustum (truncated pyramid) or a cube in the view space. Their job is to "scale" or "skew" the geometry inside this virtual shape into the clipspace cube, which is the coordinate system the GPU takes as input.
+A perspective projection typically shows everything inside a frustum (truncated pyramid) or a cube in the view space. Their job is to "scale" or "skew" the geometry inside this virtual shape into the clipspace cube, which is the coordinate system the GPU takes as input.
+
+This projection matrices map your geometry into a "normalized box" where `x` and `y` values of `-1` and `1` represent the bounds of your screen or frame buffer.
+
+Projection matrices can also be ortographic, meaning that 3D objects are mapped via parallel lines onto the screen, rather than via a frustum.
### Perspective Projection Matrix
@@ -30,7 +34,7 @@ To create a projection matrix use:
- `Matrix4.perspective({fov, aspect, near, far})`
-### Creating an Orthographic Projection Matrix
+### Orthographic Projection Matrix
math.gl provides the traditional function create an orhtographic projection matrix by providing the "box" extents:
@@ -46,7 +50,7 @@ In applications it is not unusual to want to offer both perspective and orthogra
## About Projection Matrices
-An ortograhic projection matrix essentially just scales your view to show everything within a box. As can be seen in the matrix below, it just centers your view between the bounds of the box, and scales your positions so that the box limits fall on -1 and +1 in each direction. It also does an inversion of the X and Y coordinates.
+An ortograhic projection matrix scales your view to show everything within a box. As can be seen in the matrix below, it centers your view between the bounds of the box, and scales your positions so that the box limits fall on -1 and +1 in each direction. It also does an inversion of the X and Y coordinates.