Make a bona fide Circle3DObject #4

New Issue

glen · 2019-09-14T04:34:13Z

glen commented

2019-09-14 04:34:13 +00:00

Right now, one can create a plausible looking 3D circle with the @builtin@/3Dcircle1 macro et al. But it is impossible to compute with the resulting object. For example, if you want its 3D center, you’re out of luck: it’s just a QuadricObject that goes through the correct five points to look right from all directions, so good luck deriving its center.

Instead derive a new class Circle3DObject from PrimitiveCircleObject with a TwoPointLineObject it depends on giving the normal direction, and an Expression giving its radius. To display, that should compute the proper five points on the fly and use shared display code with QuadricObject.

Right now, one can create a plausible looking 3D circle with the @builtin@/3Dcircle1 macro et al. But it is impossible to compute with the resulting object. For example, if you want its 3D center, you’re out of luck: it’s just a QuadricObject that goes through the correct five points to look right from all directions, so good luck deriving its center. Instead derive a new class Circle3DObject from PrimitiveCircleObject with a TwoPointLineObject it depends on giving the normal direction, and an Expression giving its radius. To display, that should compute the proper five points on the fly and use shared display code with QuadricObject.

glen commented

2019-09-14 04:35:48 +00:00

I gave this an initial shot, and had a possible rudimentary Circle3DObject written up except for the display code, which I planned to share from QuadricObject via the following scheme: the paint() function mostly only depends on the quadric coefficients X[]. So I was going to split that stuff out into a QuadricByCoeffs class, and both QuadricObject and Circle3DObject could have one of these QuadricByCoeffs object. In turn, that X[] coeff data is determined by a list of the (x,y) coordinates of five points. In QuadricObject, those five points are bona fide PointObjects that are member data, and we just grab their x and y coords. For Circle3DObject, I was planning on using the member data (center, radius, and normal) to compute five equally-spaced (x,y,z) points around the circle, and then extract their projected (x,y) coords for the construction of the QuadricByCoeffs. But the methodology in the existing CaRMetal code for going from 3D to 2D coords was sufficiently inscrutable to me that I gave up, at least for a bit. I’ll check in the branch as far as I got anyway in case I ever get the oomph to try to polish it off.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: glen/CaRMtl#4