Topo Coordinates

--- DRAFT IN PROGRESS ---

Hyperglyphs encode n-Dimensional data into Topological Hierarchies, so where am I?

Short answer, it depends on your reference frame and how you choose to project the dimensional basis from one space to another. But hey, maybe your not an Einstein type, nor do you enjoy GL matrix math and just want to know where the thing is. Well, for that we suggest you just look at the (GUI) Compass, which displays the World position of the current node, also in the np_node table: world_x ...y ..z fields (which are runtime calculated).

Each node (glyph, grid, etc.) in a Hyperglyph Tree defines its position relative to its parents Topological Space. Relative Local coordinates are visible in the GUI, and stored in the np_node table: translate_x ...y ..z, rotate_x..., scale_x..

Switching Topologies Retains Local Coordinates (when feasible)

Scaling or Compacting the Scene

• World Coordinates
  • Subgrid Scenes

Pre-defined Topologies

• Currently, as of 2021-02-06 we have 13 pre-defined topologies (np_topo_id = 1-13).

|--- np_topo_id | name | range | offset | scale | parent dependent | Description ---| | 0 | NULL | +/- inf | 0,0,0 | 1.0, 1.0, 1.0 | no | (reserved) | | 1 | cube | | | | | Each face is a subspace ortho Cartesian coordinates | 2 | sphere | | | | | Polar coordinates with offset (surface is z=0) | 3 | torus | +/- 180 Latitude | | | | Similar topo sphere but wraps around the inside | 4 | cylinder | | | | | Earth wrapped on a tube, (aka cylindrical) | 5 | pin | | | | | Similar to a pole, where translate_x is up | 6 | rod | | | | | Akin to a pole whose scale doesn't affect children | 7 | point | | | | | Polar | 8 | plane | | | | | Cartesian Coordinates (eg. grid default). | 9 | zcube | | | | | | 10 | zsphere | | | | | | 11 | ztorus | | | | | | 12 | zcylinder | | | | | | 13 | rodz | | | | | | 14-10000 | | | | | Reserved (future pre-defined presets) | | 10001+ | | | | | User defined np_topo table. |

| - Planar (eg. Main Grid) - Cartesian Coordinates

spacetime for deeper comprehension

Hyperglyphs encode data in spatial queues designed to be naturally processed by bio sensory systems (eg. humans). So things like color, shape, texture, movement and hierarchial relationships are all relevant. However, here we are concerned with the subset of Hyperglyphs dimensional queues that provide the illusion of kinematic object hierarchies (eg. a robot arm or a monkey swinging through the trees). .

nD what 2-3-4-n chess human vs machine n sphere packing (muller) how do we perceive space 1d 2d 3d........... nD?

Neurocosmology, here we are mostly concerned with how we project space coords and how to compute them (Khi ro). For higher dimensional spaces, how do we project them (nD -> 3D -> VR -> 2D) so that we may interact (including interact with the projection, akin to navigating the basis projection of nD spaces into the apparently more intuitive 3D euclidean space+time and see it on our (rather limiting) 2D screens, or if your slightly lucky these days, maybe a 3D screen of some sort, (Stereo 3D -> VR -> volumetric -> holographic).

biocybernetics = 2D screens, dual 2D (aka stereo 3D) and VR (stereo 3D with lookaround, proper perspective if off axis from the screen). Spatialized sound Sonification of data, Haptic, Ofactory smell is quantum entanglement, and other cellular processes, electron tunneling, etc dogs in 3D+ (space, time and other prey/friend/sick/healthy etc.) and more: EM (north), Temperature, Telekinetics, Holographic Mind Theory, etc.

World Space - Main Grid

Our native 3D World Cartesian coordinates are derived from the (GIS) KML standard, with a notable exception, our coordinates are a normalized orthagonal basis (versus KML which uses degrees of Latitude, Longitude and Altitude in meters). Our Y-axis (Latitude) and Z-axis (Altitude) are normalized with Longitude at the equator. Hence, our units differ from the KML standard, but can be converted. Earth's circumference around the poles is 40007.863km and around the equator is 40075.017km.

• All coordinates (position & orientation) follow the Right-hand rule.
  • translate_x ...y ..z position units:
    • X-axis = 1.0 = a degree of Longitude = 111319.49m (ONLY) at the equator.
    • Y-axis = 1.0 = a degree of Latitude = 111329.53m on average.
    • 1 unit on the Z-axis is normalized with Longitude, eg. translate_z = 1.0 = 111319.46m altitude (KML)
      • Earth is approximately an oblate spheroid, hence the length of a degree of Latitude varies.

http://www.csgnetwork.com/degreelenllavcalc.html

Hyperglyph Tree of Topologies

Topological space is the most general notion of a mathematical space.

Each glyph in a hyperglyph tree defines a child Embedded Space basis which is akin to a subspace. But is NOT a subspace in the strict definition of the term, as the Embedded Space is not necessarily a subset (subspace) of the parents basis. That is to say the embedded space can be defined as any other type of space. Topo-Topo offsets and child to parent scaling relationships.

Hyperglyphs Inherit a Compound of Spaces

Each glyph in a hyperglyph tree has a local space (basis) that is a compound basis of all its ancestors, as well as its own topology. A glyph becomes a hyperglyph when it has a family, either an attached parent glyph or any number of children (of any type). Each glyph has it's own space (basis), which is a combination of their own topo type and their parents (ancestrial) compound basis (tree of topos) and this determines the attributes of their space. In compute terms this is model space matrix stack. That is each node transforms the model matrix to position, orient and scale (non-uniform XYZ) *OpenGL uses a modelview matrix which is the model matrix multiplied by a (virtual camera) view matrix.

Cube with Subspace Topologies

Our cube 'np_topo_id = 1' has an independent 'subspace' topology for each of the six facets. Each subspace has a Cartesian coordinate system whose origin projects orthogonally from the center of its facet, (+Z away from the surface),

Cube facet subspace orientations are as follows: The sides of the cube all have their North edge touching the top of the cube with subspace = 1 on the East (+X), 2 facing West(-X), 3 facing North(+Y), 4 facing South(-Y), 5 is the top(+Z) and 6 is the bottom(-Z). Note that the top and bottom are both oriented such that their North(+Y) edge touches the North facet (subspace 3), this keeps them oriented in the same direction as the cubes parent glyph.

The face of the facet is bound to KML coordinates, which means that while it appears square, it has +/- 180 on the X-axis (longitude) and +/- 90 on the Y-axis (latitude) (note that it does not squish it's children, ie. the subspace children are given a uniform scale (if the cube scale is uniform). So a worldmap will appear square and so will its children!

Link Space

Links are NOT a "child Embedded Space", but they are an "Embedded Space". They are positioned in World Space such that they link (connect) any two glyphs and they have their own space. The default Link Space is a kind of cylindrical space whose Z-axis is scaled to fit between its two endpoint glyphs and has the additional property of 'ratio' which sets the XY scale, (the topologies radius in World Space). Link end-A is its parent and link end-B is its first child, so links are directional graphs, (but may be traversed bi-directionaly).

Spacetime Topology and Scope

The Universe is misunderstood, suffice https://en.wikipedia.org/wiki/Spacetime_topology

Eigenbasis for Any Space

"Showing that eigenbasis makes for good coordinate systems" - video by Sal Khan

Eigenvectors with eigenvalues and matrix operations can (and are) used to transform the basis (space) of any n-Dimensional space to any other basis, eg. your screen is (typically) a 2D plane, the illusion of 3D is (in part) a projection of 3D model space (basis) onto a 2D basis (screen space) space is a projection This rather convient for computing (especially GPU's) which are rather good at matrices. Scale Relativity

Showing that an eigenbasis makes for good coordinate systems

• Topological space and coordinates:

  • Model coordinates vs camera view.

    • Default model coordinates are an

  • Local vs World coordinates for nodes

  • Non-3D Euclidean spaces

  • Our default main grid topology is a

Euclidean Space Eigenspaces & Egienbasis

*Note that the Right-hand rule is also the international standard for a laws of physics and math.

as (32bit) decimal floats

Further details about KML coordinates can be found here:

• Google KML coordinates - World Position
• [

Our World Space position coordinates (Translate XYZ) are based on a Right-Handed Coordinates, with Z-axis up. Orientation (Rotate XYZ) is defined using (yaw, pitch and roll) in degrees. Neither is restricted in the range (+/- infinity), but our topologies can wrap the coordinates within the topo's unique range (eg. A cube facet has a translate X range of -90 to +90, but a toroid has an X range of -180 to +180 with > 90 corresponding to the inner side of the tube.

• Precision is limited to the 32bit float (native to the GPU).
  • At the equator 1 deg longitude = 111.320km and a 32bit float is going to give you roughly +/- 3m, for details see:
    • stackoverflow topic on 32bit precision for -360.0 to +360
  • If you need greater precision, you can create a parent node (eg. sub-grid), scale it down and the child nodes precision will be relative to their sub-coordinates. For example, you could create a sub-grid that is a map of a city, but scale it such that the units are in meters and then attach the people, buildings, vehicles, etc. to (parent) sub-grid. Then you have 7 digits of precision in meters, so at 10km (10000.00m) from local origin (map center) you get +/- 1cm.
• Translate XYZ (eg. translate_x):
  • KML coordinates can be converted
    • Altitude (Z) is normalized with longitude, eg: Translate Z = 1.0 is 111.320km from the surface.
  • https://en.wikipedia.org/wiki/Longitude
  • The main root grid scale will affect the (visually drawn) world position of child objects (eg. glyphs). But their relative coordinates will
    • This means that objects coordinates
• Rotate XYZ orientation follows the (Google) KML object standard:
  • X = Heading (yaw) in CW degrees range is 0 to 360
    • North = 0.0 or 360.0, West =
  • Y = Tilt (pitch).
• Scale is independent for each axis (scale_x ..y ..z)
  • Scaling a affects the world position of child nodes:
    • Local node coordinates remain the same, regardless of scale (at any level in the tree).
    • Note that scaling a grid affects world position but not the shape of the grids children.
• Topology (np_topo_id)
  • Plane, Sphere, Cylinder, Cube, Torus and more.
    • Cube has 6 facets each facet is a subspace topology :
      • https://en.wikipedia.org/wiki/Subspace_topology

Orientation is designed to be in accordance with (Google) KML standard for objects relative to the surface. Rotate X = Rotate Y = Rotate Z =

---

GUI Compass Indicator

The compass default mode is to display 'World' coordinates for the current node. You can click on the compass heading (top menu bar item) to change the display mode to 'Local' coordinates, which are relative to their parents topo space, ('translate_x/y/z' is local coordinates).

Note that the World coordinates of a node are the topo (offset) origin for it's child nodes. So the coordinates are not always identical to Local coordinates even for a root node, (it depends on the topo).

---

Coordinates

The following table describes the coordinate system for a KML based Sphere in comparison to a Torus. The range for the two are the same, except for translate_y where the Torus has a range of -180 to 180 latitude vs KML -90 to +90 deg. Cube and Grid topo coordinates are the same as a Torus. Latitude values greater then +/- 90 degrees are wrapped onto the Sphere, (causes upside down object.) For detail see 'Topologies & Coordinates' section.

order	field_name	kml_name	kml_lo	kml_hi	torus_lo	torus_hi
1	translate_x	longitude	-180	180	-180	180
2	translate_y	latitude	-90	90	-180	180
3	translate_z	altitude	0	none	none	none
4	rotate_y	heading	0	360	0	360
5	rotate_x	tilt	0	180	0	180
6	rotate_z	roll	-180	180	-180	180

Translate

Position is based on translation, rotation and scale (of the parent.) Root nodes are relative to the global origin. Child node coordinates are relative to (or inherent) there parents position and topo type.

'topo' types include default, cube, sphere, torus, surface, pin and grid. Each defines a coordinate system with a unique set of operations that transform the position, orientation and scale of any attached child nodes.

Some topo types, (such as a 'cube') have multiple local coordinate systems. The child node 'facet' value tracks which system, (or cube side to use.) See 'Cube - Key Table' appendix and 'Coordinates & Topologies' section.

Radial offset is 'translate_z' for a torus.

Translational velocity is set by 'translate_rate_x/y/z' and is the delta distance applied per cycle, (typically 60 cycles per second.) Nodes may be restricted (or wrapped) by both local node limits imposed and/or the parent topo type limits.

Typically you do not assign a 'translate_rate' to a root-node as it will continue to move until it disappears by leaving the scene boundaries, (at the clipping planes.) However, child nodes will typically limit or wrap there coordinates when boundaries are hit, (depends on parent topo type.)

---

Rotate

The rotate_x/y/z sets the node orientation with units in degrees. Order of operation is:

1st rotate about z-axis by the Heading, rotate_y 2nd rotate about x-axis by the Tilt, rotate_x 3rd rotate about z-axis(again) Roll, rotate_z

Camera 'Tilt' differs from all other objects in that the 'rotate_x' axis is inverted. A value of 0 results in a view looking straight down the -z axis, basically looking straight down on a map. At x = 90 deg the cam will rotate CCW about the x-axis and look at the horizon towards North (with Heading rotate_y = 0.) Effectively this is a 'Right-Handed' coordinate system for rotation, (with an inverted up vector.) Translation is still a 'Left-Handed' coordinate system. Compatible with the google KML '' standard.

Objects (other then the camera) use a 'Left-Handed' coordinate system for rotation (and translation.) An object with zero Tilt will be upright. At rotate_x = 45 deg the object will lean towards North, (with Heading = 0).

rotate_y Heading range is 0 to 360 deg, North = 0, E=90, S=180, W=270. rotate_z Roll range is -180 to +180 deg.

'x' axis of a child node can be used to set the spacing of toroids around there parent. 'y' axis will spin the torus, not very noticeable unless it has a texture map or is assigned a different primitive.

Rotational velocity is set by 'rotate_rate_x/y/z' and is applied (added) to the 'rotate' orientation every cycle.

Orientation and position of nodes, (other then the camera,) are compatible with the google KML '' specification. The altitude units are not the same. Instead of feet (or meters) altitude is specified relative to the circumference, altitude units are 1 to 1 with translate_x at the equator.

Cameras use the '' KML coordinate system which differs in that the 'Tilt' x-axis is inverted, (and camera up vector.) See 'Camera Position” in this appendix for further detail.

---

Camera Position

Position is set using 'translate_x/y/z' and 'rotate_x/y/z' for orientation.

Tilt is 'rotate_x', straight down is 0.0 deg, horizon is 90 deg, up is 180. Heading is 'rotate_y', North is 0.0 deg, E 90, S 180, W 270. Roll is 'rotate_z', CW is 0 to 180 deg and CCW is 0 to -180.0 deg.

Note that the x-axis 'tilt' is essentially a flipped axis, and is therefore a right-handed coordinate system. This is an exception, the rest of the coordinates are all left-handed systems.

Note that the 'rotateVec_x/y/z/s' parameter should be ignored, it is a unit vector calculated from 'rotate' and is automatically updated.

There are multiple cameras available to the user. There is a single root camera that all other cameras are attached to as child nodes. New child camera's may be created or existing child cams may be deleted. The Root-Camera is locked and cannot be deleted. By default there are four child cams attached to the Root-Camera.

The coordinate system is designed to be compatible with the Google KML standard for a '', not to be confused with ''. For detail see 'Topology & Coordinates' section in this document.

Also see the '' specification in the Google KML docs:

http://code.google.com/apis/kml/documentation/kmlreference.html

*At this time, all cameras coordinates are relative to the World Origin, which is flat cartesian space, (non-spherical coordinates.) Future updates will allow for attaching a camera to any node. Attaching a camera to a parent with a Sphere topo type would result in polar coordinates.

---

scale

Object size is set by 'scale_x/y/z'. A scale value of 0.5 is equivalent to a 50% reduction, default is 1.0 which results in no change in size. Valid scale values can be very small or large. A negative value results in an inversion of the geometry, including all child nodes of the current node. For uniform scaling the x, y and z values must be identical. Individual axes may have different scale values. This results in non-uniform scaling which causes an object to appear stretched or squished.

In general 'scale_rate_x/y/z' is used internally by the application but is not practical if set to a value other then zero. Otherwise continuos scaling will occur and an object will typically become far too large.

---

ratio

The 'ratio' sets the inner and outer radius of a torus. Range is between 0.01 and 1.0, where 1.0 is a donut with no hole and 0.01 is a very thin donut. The default ratio is 0.1 which is equivalent to 10% of the outer radius. Nodes attached to a parent of Torus topo type are positioned relative to the surface, so scale and ratio (inner radius) effect the position.

*Ratio may effect other characteristics depending on geometry and topo type.