search

jscad / csg.js

DEPRECATED: CSG Library for JSCAD (See the link below)
https://github.com/jscad/OpenJSCAD.org/tree/master/packages/modeling
MIT License
218 stars 56 forks source link

V2 generations of 2D and 3D primitives #151

Closed z3dev closed 5 years ago

z3dev commented 5 years ago

WORK IN PROGRESS DO NOT MERGE

As discussed, here are the generation functions for the 2D and 3D primitives as converted to V2 geometry and math. Basically, the functions were created from the logic as found in the API layer, api/primitive directory. All the functions work fine, as I have verified that the solids produced are correct.

However... This is just the start of the reorganization, so some additional changes are expected.

  1. The use of shape3 is mandatory. Are we going to keep the shape / geom split or merge? NO
  2. How's the split of functionality? Does 'primitives' make sense. As a first try, this seemed sensible.
  3. There's a lot of tests that need to be completed. These are difficult to produce, so any suggestions would be appreciated.

Changes Required:

Test Suites To Be Complete:

pentacular commented 5 years ago

The concern that I have here is that these are tightly coupled with shape2 and shape3.

Could we change the generators to produce either (a) arrays of points, or (b) arrays of polygons.

And then compose those with calls to shape2.fromPoints, etc, separately?

Then we could use the circle generator to build a path instead, or run it through a post-processing function to do a novel kind of extrusion, or whatever else we like.

pentacular commented 5 years ago

The other thing that I observe is that most of these aren't primitive, and could be easily decomposed into simpler forms using extrude, hull, etc.

So it might be that these belong in the user api, rather than core.

z3dev commented 5 years ago

The other thing that I observe is that most of these aren't primitive, and could be easily decomposed into simpler forms using extrude, hull, etc.

So it might be that these belong in the user api, rather than core.

All of those options would add performance degradation. Hopefully, the primitives are exactly that...

z3dev commented 5 years ago

I have a different pull request staged and ready. So, this pull request is not required.