写在前面

1. OCC的arguments和tools都是一组对象，要考虑交线再次相交。因此，在VV等处理中会有很多看似无用的逻辑。
a. acis操作对象数量
b. 操作的body是不合法的吗？
2. OCC考虑vertex在相交过程中容差再次扩大，所以会有RepeatIntersection等操作。（我认为容差扩大是有好处
的）

3. OCC抽象出Pave等类，记录source edge的拆分信息，不对原有拓扑进行拆分
4. （考虑求交结果复用，我们的solver就不用并行去做了）
5. 类BOPDS_DS存储相交信息（paveFiller应该是ps的Imprint）

核心类介绍
1. 存储求交结果的类

2. 抽象Pave、PaveBlock 和 CommonBlock类，表示新Edge的端点、新Edge和多条Edge对应的融合Edge
图1.1 Pave类图 图1.2 Pave类解释

图2.1 PaveBlock类图 图2.2 PaveBlock类解释

图3.1 CommonBlock类图 图3.2 CommonBlock类解释

1. 初始化
1. 抽象出BOPDS_ShapeInfo类，描述拓扑对象。
mySubShapes：记录subShapes的索引（考虑了拓扑被复用）

myReference：为了不对原有拓扑进行修改，抽象出PaveBlock(针对Edge)、和FaceInfo概念Edge，

myReference记录了他们在BOPDS_DS中的索引

好处：创建新拓扑对象的时候，不需要改变原有拓扑，在ShapeInfo中暂存。Build过程中再拿出来重建。

2. 使用BVH进行碰撞检测
occ处理两组对象，bvh有一定加速作用

对自交情况进行了过滤

2. PerformVV
初始化阶段，通过bvh获得的碰撞的vertices pairs

2.1 实现细节
1. 使用same domain vertex(SD)进行距离计算 （如果不重复计算的话，那么这里不会有SD）
2. 计算相交对，建立连通链，生成Same Domain Vertex，更新相交数据
添加vertex的shapeInfo
建立source vertex 到 SD vertex的映射（myDS.myShapesSD）

建立source vertex 和 source vertex的映射（myDS.myInterfTB,myDS.myInterfered 会检测自交warning)

创建InterfVV对象（myIndexNew是生成的vertex SD对象）
3. 初始化Vertex对应Edge的pave数据（使用source vertex对应的t， SD vertex的 id）

2.2 对比 & 小结

1. 找重合vetices，存在一对多可能。没说生成same domain vertex.

2. 生成same domain vertices，后续使用它们进行计算（应该是减少计算过程中短边的处理问题）。如果这样的
话，对于Edge而言，顶点的中心就不是在几何曲线之上了。但不管怎么说，新的容差顶点不可能在每一条几何曲
线上，所以直接合并是没问题的。

3. 如果不考虑repeat，逻辑可以简化很多（论文中EF是提到repeat）

3. PerformVE

3.1 实现细节
1. 通过FillShrunkData扣除Edge上Vertex的影响
2. VE会提前进行多种过滤（如查询subshape是否相交）
3. 使用VSD进行计算 是否与Edge相交 （在李老师给的流程逻辑中，是V-E vertex pair，所以应该是分别打断，不
考虑vertex是否融合？）

todo: 两个重合的长方体形成compound/TopAbs_COMPSOLID，与第三个体做布尔
todo： vertex tolerance 无限扩大的情况

4. 计算相交后要更新vertex容差！ 因为有fuzzyValue，需要改变容差。否则不交就是不交。
5. 更新相交数据
记录BOPDS_InterfVE（我们的逻辑中不会生成新的vertex）

建立source vertex 和 source Edge的映射（myDS.myInterfTB、myDS.myInterfered)

更新Edge对应的Pave（pave的t是投影点算出来的）
6. 拆分PaveBlock，如果边过短，会直接融合顶点；（如果PB有CB，还会生成拆分后的PB 记录CB和被拆分先后的
PBs，有可能是多条pb拆分的）

3.2 小结
1. 计算的时候使用VSD对应的vertex
2. InterfVE中使用nVOld，因为可能多个vertices对应一个same domain vertex
3. 在SG的逻辑中，VE只考虑对V的容差进行扩大，不考虑生成新的vertex

3.3 对比 & 问题

1. 论文中应该是用最近点打断Edge，记录新vertices correspond；OCC中对vertex容差扩大，保证Vertex包围球覆
盖到Edge上。 （存在局部容差异常增大的情况）
2. 论文中使用原始vertex进行打断，OCC中使用same domain vertex进行打断
a. 我觉得occ更合理，避免短边，减少计算
b. 假设两条Edge顶点重合，顶点都靠近第三条Edge。如果分开计算VE，那么第三条Edge多两个vertices，可
能无法淹没Edge，受第三条Edge.toler控制。但使用融合后的，只产生一个vertex。
c. 不过按照occ的方法，会产生下列与Parasolid不一致的情况（这里不是说local tolerance）
3. ？ OCC做边融合有什么好处？
a. 避免后续操作中的短边，过程中就扩大vertex容差

4. PerformEE

4.1 实现细节
1. 使用Edge进行计算（不是commonBlock），使用shrunkRange

2. 分为两种场景：端点重合使用快速求交，算最大距离；基于细分&投影做相交
3. 过滤VV/VE的情况
4. 交线为Edge的话，认为是完全重合（多条交线是不处理的）
添加InterfEE，myDS.myInterfTB
形成新的commonBlock

5. 交线为交点的话：
交点对应的是一个范围range
通过参数t的比较，过滤VV/VE等情况
添加InterfEE对象

6. 交线继续形成CB，交点再Fuse一把，然后调用VE（）
4.2 对比&问题
1. OCC会对交线的交点们做一次合并，用合并后的交点去打断相应的Edges。
a. 使用交点，而非最近点对，会导致新增vertex的局部容差变的比较大 （为什么我觉得在有fuzzy value的情况
下，变大是合理的？？？ 后续还是要merge的）

b. EE相交要生成新的Vertex，而Imprint的目的不是向对方压吗，如果我知道我的目的是向target上压，我为什
么搞这么大容差呢？如果只是压印的概念
c. 所以vertex的投影计算是一个范围，真值在这个范围内部
2. 论文中只是说split the edge，也没说是用压印点

todo: edge-edge交点的tolerance

5. PerformVF

5.1 实现细节
1. 使用EE交点和原有VF pair进行求交（VSD）
2. 会更新vertex容差
3. 抽象出faceInfo信息描述
5.2 对比

6. PerformEF

6.1 实现细节
1. 如果PB的端点在FaceInfo上，使用快速计算（如果不抽象Pave类，在拆边的时候就要给定新的vertex对象，也可
以实现）
2. 如果结果是交线，(端点不在Face上会提前过滤掉，算面面交线)，创建BOPDS_InterfEF对象。会为PaveBlock创
建CommonBlock对象。

3. 如果结果是交点，先进行过滤，再会对多个交点再做Fuse，执行Edge打断操作
4. 更新FaceInfo中的 PBIn和PBOn信息

6.2 对比&问题

1. EE中特别说明要有toler，这里没说，但也不代表没有。
2. 对于重合的情况，在Face中添加Edge，这个是通过InterfEF的newIndex实现的，记录了产生的Edge对象
3. OCC中有RepeatIntersection 和ForceEE/EF的函数。就是对vertex的容差进行扩大，然后再求交

7. SplitEdges
执行Edge的拆分工作，实际是创建新的Edge，建立映射。
8. PerformFF & MakeBlock

8.1 实现细节
1. PerformFF负责计算，MakeBlock才是生成相交数据的部分
2. 计算出交线、交点，执行

8.2 对比

todo: occ的样条线都有pcurve吗？
todo: 容差扩大的例子！

思考:
1. 要有fuzzy value这个概念吗？要做限制吗？
parasolid: modeling tolerance

2. 不抽象Pave和PaveBlock，直接拆会怎样？
需要存储oldEdge到newEdge的映射关系，这样初始化时候的相交信息可以直接使用

3. 不考虑求交过程中的容差扩大会怎样？
我认为是需要的，这样可以带来好处。比如说VV认为重合的点，进行VE计算的时候就会形成小短边
如果操作过程中不新建，只是缓存pair，那么计算过程中要查询pair吗？在后续操作中查询pair的逻辑
是什么呢？

容差相切情况下，可以返回一个点
求交规范：不存在不包含端点的重合段（作为一个切点返回）