-
Notifications
You must be signed in to change notification settings - Fork 21
/
TODO
198 lines (179 loc) · 10.3 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
1. [DONE] Implement some entity dependency code; see p.69 of IGES spec.
For example, every entity added to a Composite Curve should
have a Physical Dependency. In turn any Composite Curve
acting as a Curve on Surface is dependent on that
Curve on Surface (E142).
2. In future if someone wants to render curves etc, it makes
little sense to let the user implement the interpolations.
Implement interpolation routines which return an entire
point set for each curve or surface and let the specific
IGES entity calculate the point set based on an error
parameter specified by the user (default: IGES minResolution).
3. Surface of Revolution:
+ ensure Axis is a LINE entity
4. [FIXED] [URGENT] Bug in IGES_POINT; 'p0 = p1 - p2' returns the wrong result
5. To load Molex model 473460001.igs support is required for entities:
+ [DONE] Type 104: Conic Arc
+ Type 186: Manifold Solid B-REP
+ [DONE] Type 502: Vertex List
+ [DONE] Type 504: Edge List
+ Type 508: Loop
+ Type 510: Face
+ Type 514: Shell
6. [BUG] A NURBS curve must not scale its control points if it is
a curve on a parametric surface (a parent entity is a BPTR of
an Entity 142: Curve on Parametric Surface). Note than in other
cases a NURBS curve may have its control points scaled - for
example when it is a curve used as a generatrix for a surface
of revolution. As an ad-hoc remedy we may simply refuse to scale
NURBS curves; this would work in most cases since these curves
are used almost exclusively as children of a BPTR entity.
Fixing the behavior may involve some refactoring of the load code
to ensure that any scaling is performed after all associations
have been established; this will ensure that ancestors can be
correctly traversed.
7. [FIXED]
[BUG] On reading a file E102::Associate() may fail if the referenced
curve has an associated transform and has not invoked Associate().
To fix this requires setting an "assoc" flag of some sort and all
entities whose Associate() routines rely on subentities being
correctly associated must invoke Associate() on those entities
before invoking any other routines on them.
8. [BUG] When AddReference() is called, the function returns TRUE
when an entry is a duplicate. The invoking routine should not
push the Child Entity onto its list a second time or we may
have data corruption.
**** GENERAL ****
Caveats:
To keep the code as simple as possible a number of constraints
are applied. Without enforcing various constraints we would have to
add substantial code which would make this library more like a full
functional MCAD, a situation which should be avoided. Unfortunately
this desire for simplicity also results in the possibility of
incorrect behavior in a number of pathological cases. This is a
short list of known constraints and expected bad behavior.
A. Constraints:
+ An outline O2 being subtracted or added to an outline O1 may
only intersect at 2 unique points. If there are an uneven
number of unique points then we have invalid geometry.
If we have an equal number of unique points N and N > 2
then a subtraction operation may yield multiple bodies
while for addition the merging code becomes substantially
more complex. A corollary to this is that a cutout/add-on
may not intersect an outline along an edge. Imagine a simple
case of a rectangular outline and a rectangular cutout which
lies along 1 or 2 edges of the outline; such a case must clearly
result in valid geometry, however such cases are prohibited by
this constraint. The same prohibition applies to similar cases
involving the merging (addition) of outlines.
+ Cutouts and circular holes must not overlap eachother. This
means that all overlapping cutouts and circular holes must
be merged prior to specifying them as a cutout to a board
outline. The recommended order of operations are:
(a) subtract all circular holes from the main outline and
repeat the operation until no more holes intersect the
main outline. (b) merge all overlapping circular holes.
(c) add all circular holes to each non-circular cutout
until no more circular holes overlap a cutout. (d) merge
all overlapping non-circular cutouts; note the constraint
on 2 unique intersection points applies to this operation.
+ Cutouts/add-ons must not exist entirely outside the board
outline; the code does not check for such cases and they will
result in bad geometry. However it would be possible to
test for this bad geometry in the future without
too great a cost in computations; once it has been
determined that a cutout/add-on does not intersect the main
outline then it is a simple matter of testing a single
point on the cutout and alerting the caller to whether that
point was inside or outside the outline. It would be the
responsibility of the calling routine to determine if the
operation were a case of bad geometry. Cases of such bad
geometry would include (a) hole or cutout entirely outside
the main outline, (b) add-on entirely inside an outline -
this includes the case of a cutout entirely within a cutout.
Cases which are not necessarily bad geometry include
cutouts entirely outside another cutout or cutouts entirely
inside the main outline.
+ Outlines must not be self-intersecting; this is a requirement
of all MCAD software but the condition is not checked in
this library.
+ Cutouts may not intersect an outline at a single point;
this would result in bad geometry. This constraint is
not unique to this library; no manufacturing design
software will gladly accept what is essentially a
wall thickness of 0.
B. Bad behavior:
+ Applying cutouts:
(a) Imagine a solid consisting of 2 circles with equal radius R
and a distance between centers, D where D < 2*R. This solid
would have a figure-8 appearance. Now imagine a cutout within
that solid and which intersects the vertices of the figure 8.
Applying the cutout would result in invalid geometry,
specifically the figure 8 will be split into 2 bodies which
touch at 2 points. This pathological case can be flagged
by testing the cutout to determine whether all points
aside from the points of intersection lie within the figure 8,
however to reduce the number of computations such a
check is not performed. It is possible for the user to take
any arbitrary solid and construct an arbitrary cutout which
divides the solid into 2 solids which coincide at 2 points.
In all such cases the outline manipulation code will fail
with somewhat unpredictable results. It is not possible
to create an outline which results in 3 or more bodies since
such an outline would violate the constraint on 2 unique
points of intersection. However, the user can willfully
ignore the constraint on non-overlapping cutouts to create
multiple cutouts which in principle should divide the solid
into more than 2 bodies.
(b) A related problem is the case where an outline and a
cutout do not overlap but intersect at 2 unique points;
this will result in bad geometry. Once again it is possible
to test for the condition but at the expense of almost
doubling computation times so the check is simply not
performed.
+ Adding outlines:
(a) Imagine an outline edge with a crescent notch on the
edge and an included angle > PI radians on the arc. A
circular disc can sit in such a way that the outline
is intersected at 2 points but the disc is not large
enough to cover the entire crescent shape and correct
addition of the disc would result in 2 bodies coincident
at 2 points. In such a case the resulting geometry will
be incorrect; the cresent niche will be removed and
there will be a small protrusion in its place. In general
it is possible to contrive 2 arbitrary outlines which
intersect at 2 unique points but produce 2 bodies; in all
such cases the code will produce bad geometry. In this
particular case the intersecting bodies lie entirely
outside eachother but are coincident at 2 points.
(b) In contrast to (a), imagine 2 outlines with one
outline entirely within the second outline but intersecting
at 2 unique points, for example a rectangular outline with
a circular outline inside it. The geometry code will
incorrectly truncate the enveloping outline in such cases.
C. General comments:
+ Despite all these restrictions and shortcomings a user will
generally not have any problems creating a board with good
geometry. If a user creates a board with bad geometry this
will generally be the result of bad design and the user will
need to think more carefully about the design.
+ Even if a user does not violate any of the restrictions it
is still a trivial matter to create a board outline which
is not suitable for manufacture; this is an unavoidable
issue in MCAD systems and is not unique to this library.
Ultimately it is the user's responsibility to check for
manufacturability of the product.
+ The algorithm for determining whether an outline's
winding is CW or CCW is simplistic and is only guaranteed
to work correctly if all outline segments are line
segments. As an example of a case which would yield
the wrong result, take 3 segments arranged in an arc
to form a bracket '['. Now imagine a large clockwise
arc starting at the lower right point and finishing
at the upper right point. The winding in this case
would be clockwise but the calculation would yield
the wrong result. Perhaps this problem could be fixed
by treating arcs in a special way and including the
halfway point on the arc in the calculations. If the
calculated winding value is incorrect then bad geometry
shall ensue.