refactor(): restructure

[kaosat-dev]

WORK IN PROGRESS DO NOT MERGE this PR starts in depth restructuring of this library

[z3dev]

Matrix4x4

• rightMultiply1x3Vector & leftMultiply1x3Vector should NOT know Vector3, instead use arguments Array and return Array
• rightMultiply1x2Vector & leftMultiply1x2Vector should NOT know Vector2, instead use arguments Array and return Array

[z3dev]

Assuming that the Math classes can change...

Matrix4x4:

• rightMultiply1x3Vector() --> rightMultiply1x3() and adjust for array parameter and Array return
  • same for other such routines
• translation() rotate(), scale() should not rely on Vector classes

On second thought, how about moving these non-Matrix functions to matrixUtils.js? Then Matrix4x4 becomes "pure".

[kaosat-dev]

@z3dev not changing the api in this PR, will be in the next major one but good points all around , I keep them for the next 'breaking' one

[z3dev]

General comment about math classes....

• a lot of the math is performed by Vector, even for non-vectored classes. There must be a lot of "new Vector" calls for any math. Horrible for memory and performance

[z3dev]

Lime2D and Lime3D...

• these reallly are non-ending, directional lines. Not very useful.
  • rename to Ray2D and Ray3D
  • create new Line2D and Line3D for use with CNC and other applications.
• this don't feel like Math classes as these contain other classes , more like User level classes.

[z3dev]

OrthoNormalBasis...

• a very strange class. Could this just be a bunch of functions?
• there's test code in comments
• uses vectors for all math

[z3dev]

Vertex2 and Vertex3...

• are these necessary? I don't see any additional functionality
• if kept, shouldn't these be named Vertex2 and Vertex3? It's very confusing to have the same class names
• can Vector2 be merged into Vertex2?
• can Vector3 be merged into Vertex3?

[z3dev]

Vector2 and Vector3...

• those horrible constructor functions should be fromObject() functions. The constructor should take ONLY the values as required for the instance variables, i.e. x,y,z
  • and all calls to this function should be fixed to supply straight values
• the Vector3.Create() function is not necessary. Fix the constructor
• get() and set() functions... remove... name the instance variables correctly
  • add a warning to NEVER manipulate the instance variables directly
• randomNonParallelVector() might be better as a separate function

[z3dev]

Side...

• what is _fromFakePolygon() used for? Maybe this should go into sideUtils
• this might be the basis for a Line2D class

[z3dev]

Polygon3...

• all prototype functions that return other things should move to general functions
  • maybe polygonUtils ?
• constructor should take exactly what's required only
• is CSGDEBUG really supported?

[z3dev]

Path2D...

• constructor does checks for distance... no no... that should be another function
• interesting... this class does a lot of checking and throws errors. is this an Math class?
• prototype functions that return other things should move to path2dUtils

[z3dev]

Utils...

• does iPolygon3.sStrictlyConvexPoint() belong here?
• does Polygon3.isConvexPoint() belong here?
• does Vector3.randomNonParallelVector() belong here?
• does lineUtils belong here?
• does Math reTesselateCoplanarPolygons() belong here?

[z3dev]

utils.js ...

• move solve2Linear() to lineUtils
• the remainder looks like sort utility functions... HINT

[z3dev]

CagValidation.js...

• isSelfIntersecting() has if (debug)... what is this? Dead code?

CsgProjections.js ...

• projectToOrthoNormalBasis() is horribly inefficient. 💀

FixTJuctions.js...

• deleteSides() has throw statements... why? Debugging? If so then _CSGDEBG should be used

[z3dev]

General...

• which is better?
  • cag instanceof Array
  • isArray(cag)
  • length in cag
  • cag.prototype is Array

Maybe there are more but we should use the JavaScript standard. Whatever that is...

[z3dev]

CSG.js...

• getFeatures() seems like a nice function, but should this be in Utils
  • also, can this be applied to CAG?
• toPolygons() returns the instance variable. Why? This breaks from the standard of being immutable. Is this used?

FYI.... done with core

[z3dev]

General...

• the split of factories is good. But there are more... Vector, Lines, etc.
• functions that convert from on class to another should be split out, for example extrude, toPoints, projection, etc.
  • a general toPoints() maybe possible
• functions that convert to non-core or non-math should be come API, such as toTriangles()
• where should toCompactBinary and fromCompactBinary exist? These are really special and should live separately
  • toObject() and fromObject() as well? There may be special logic required, like now.

[z3dev]

Properties...

• a totally unused class? I know nothing about this

[z3dev]

Connector...

• rename connectors.js to Connectors.js for consistency

ConnectorList...

• this is one strange thing... is this used internally, or something bolted on?

[z3dev]

Mutators...

• I understand these but really question the worth of this morphing of classes
  • is maintaining these directly in each class difficult? Is this just being lazy?
  • can JavaScript engines optimize these functions?
  • how to add documentation for these?
  • is this really the way objects should be "extended"?

[z3dev]

Trees...

• there are some checks that throw which are not wrapped by _CSGDEBUG

[z3dev]

General...

• the unreliability of instanceOf shows that we should not use it
• just wondering... we test for array parameter... but could the API also accept iterable objects?

[kaosat-dev]

@z3dev I will be merging this today, and will add your very good remarks as issues :)

[z3dev]

Awesome! I’m looking forward to trying out the new structure.