Line Art

Line Art 是我编写在Blender中的一个风格线绘制工具。它在几何层面计算并生成三维物体的特征线。

这个话题包含了Line Art的工作记录，更详细的信息可以在Blender开发者网^↗上找到。

好吧我们先看Nurbs的什么鬼

到底可不可以流水线

报告说交线过滤不管用（针对拖拉机测试文件，单个修改器勾选交线之后只出现交线，不清楚具体原因逻辑有小问题，已经修了）

线条超出视线盒子

12线程的机器报CPU占用100%

折边强度记录

（想了想好像也可以做轮廓的，以及外轮廓）

edgehash本身可以能优化一些。

远期改：内存池分阶段。

• 做剩余小功能的补丁然后拿去审核。
• 改评论里面的。

远期改：交叉线的重复点先退出问题。

初步的修改丢在这里^↗了

也不对，其实是三角形配对标记没有分线程用。

事实是多线交叉时只锁了分块，这样操作下三角形对有重复计算的可能。可以对每个三角形分配一个锁引用然后修改测试标记。

猴子文件那个交叉线问题跟线程有关，导致多遮挡。误判，实际是调试问题，但总之计算还是有问题的。

大概是这么修的：

• 线线关系查询时多返回一个对齐指标，方便之后判断（但似乎实际产生拦截的情况出现得不多）。
• 点线关系在ab垂直于bc时并正对X/Y方向时错误地返回了真，已修复（应检查是否有遗漏情况）。
• 一点在三角边缘邻域，另一点在外部的情况根据前述指标处理更多情况。

目前正确率非常高，错误的线段仅限于极短且与单个三角边缘平行度极高的场合，实际图像中已经小于一个像素，因此暂无需多虑。

还有问题：

• 重叠导致的交叉线似乎非常容易透过遮挡。
• 猴子盒子文件中的一个方块角有缺失。

其余遮挡错误情况不显著。

• 近裁剪面切割仍然不正确，尚待查找原因，原则上不应使用近裁剪面作为看结构的工具。

修了一些，似乎好得多了

报交线选择在有子集合的情况下不正确。（检查标记的逻辑不对）

报主干密集面崩溃，查是加速块线条数量超界，没有考虑保护因为3万条线集中在一点一般不可能，应加保护。（已经加了）

另外由于主干的一些合并导致线条被添加了两次，现已修复。

2.93的照相机平移问题改好。

通过照相机投影到背景可以生成蒙特法平滑填充所需的内外侧颜色信息。未投影的为背景颜色，应该可以用透明通道，关键算法已经在阴影分支里现成了所以这个坐起来很容易，只需要搞清楚怎么蒙特那个着色即可。

报告有线条闪烁问题（裁剪所用相机方向问题←这里修的）

虚线修改器不能时移

阴影分界线

远处模型崩溃（分块一直细分的问题，一些视口坐标似乎不正确）

裁剪所用相机方向问题。

报告交叉线筛选时有遗漏（不选择时正常）（之后似乎又不能复现）

GPU细分时lanpr只载入了基础模型。（T95470^↗）

同样的问题也出现在T94479^↗。

转移顶点色的选项

噪声串联应该有个保留或者不保留细节的选项。

至于串联的问题：由于发生在同一个遮挡级别因此会跳动（例如可以忽略遮挡层级之间非常短的不同层/更深层小段）。

gp根据曲率和速度的权重。kcanon提供了他自己写的脚本^↗。

要有针对相交线的权重传递 T94033^↗ 这需要在求交的时候记录到六点的距离作为权重？

修改器要带有压扁功能

接下来的首要研究内容是完全通过BVH，利用照相机出发的假三角形做遮挡查询。

利用embree的rtcCollide()可以求自相交（例子中即是这样使用的）。注意回调应当多线程友好^↗

无限制拆分Tile的这个得修好了不然就很麻烦。（先看embree的实现到底快不快）

修复了折边逻辑

正交视角又又又又又坏了

为什么

是因为每次合并就这样了吗（昨天修了，平移不一致问题）

背面剔除选项没有删掉线。

GP带循环的情况的采样和点划线没有考虑到。

三角化不一致问题^↗ 解决了

可能的优化：接受最平的三角形对作为加载进去的几何，这样可以兼容例如阵列合并之后内部剩余的面^↗。（其实不对，考虑一个九十度相交场景）

lineart-shadow的交叉线不串联就出不来了emmmmm（过滤开关未写进逻辑，修了）

剩下的主要工作：

• embree实验。
• 多线程加载（和Sebastian）。
• 平滑轮廓线修改器。
• 投影支持更新到最新。
  • 以及通过投影的轮廓代码取得正向轮廓。
  • 考虑如何记录阴影和照明片段以实现通过这个筛选被照或者在阴影中的内容。
• 照相机多段变形。

（需要有上下文地将剩余工作整理成完整的说明放在DBO话题^↗上。）

轮廓基本上可以了，但是单边多切以及分段组编号尚未处理好。 目前样子不错，只有点小逻辑问题。

可以cas记录元素而不需复制

塞满是不行的……

似乎从头锁到尾了所以这样反而慢，试下只锁最深层看有没有改善。

根据Sebastian的提议现尝试使用CAS（比较和更换指令，CMPXCHG）来避免使用锁。

目前：倒好不坏的，不算慢也不算快，并且内存怎么删都有问题……

还要检查阴影区域投影所用特征线的投射遮挡逻辑，是否有重在面上的那些。

理论上由于在计算阴影的情况下基本上都需要投影两次，那么是否可以将全局位置什么的做到一个数据结构里？这样省空间。。。。？

带光轮廓反投的正确解算已经可以了，另有加州阳光。

哈哈哈封闭阴影形状实现了

小问题是光轮廓没有再投影所以正方形那里还不完全对，但是已经不错了。

（直接再投似乎也不起作用，不知道为什么） 修了，边对应以及来自三角形边的问题。

emmm

理论上可以支持聚光灯，添加加一个虚拟圆孔遮罩即可。

新物体加载没得删除重叠点（决定不再包括这个功能）。

既是光投影轮廓又是摄像机轮廓的线似乎应当不作为光投影轮廓处理（其实它实际应该作为第三次投影查询时的输入）。

第三次投影的原理就是显示暗在明上和隐藏明在明上的轮廓和光投影轮廓线。

阴影大概就是这个样子。

目前是这个效果，但是交线的标识数格式不一样，暂未支持，需要在交线计算完成之后再完成一次匹配才行，这可能明显降低性能，主要由于交线未按物体区分。

做两阶段读取索引匹配以筛选被照亮的线。（逻辑正确了）

应删除e->v1_obindex，不知道为什么用的是这个，因为最后看重叠点时用的是顶点索引。（似乎可以了，以后需要多深度拼接的时候不对再来改）

阴影分支：应当分开投影线和明暗交界线。（可以了，只是还要删掉多于的明暗线区分那里）

改好了新物体加载的面标记筛选

多线程加载检查是否能获得自动平滑信息。（其实是对的，只是稍微改下逻辑等等……）

应检查经典方法中是否需要锁那么长的时间……

问题：

• 遮挡查询目前在列表中遍历，理想情况下应该为在Array中遍历以提升速度。 的确快了。

可能需要再看将duplilist做到add_relation里头。（做了，访问不到粒子和子实例）

视口三角化用于几何计算的效果还是不理想。

Hans和Sebastian提议的二维碰撞查找^↗

windows的atomic_load大约只有这么搞^↗。

Sergey说在计算时获得已计算内容用这样的写法^↗才行，研究研究……（物体和集合实例已经可以了但是粒子和面实例不行）

LineArt 线条类型速查表

{read_more}

外观	特征线	区域	封闭形状
	轮廓 + 折边 + 交叉
	轮廓 + 折边 + 交叉	照亮区 / 阴影区
	轮廓 + 光轮廓 + 投影
	轮廓 + 光轮廓 + 投影	照亮区
	轮廓 + 光轮廓 + 投影	照亮区	封闭形状
	轮廓 + 光轮廓 + 投影 + 标记边	照亮区	封闭形状
	剪影组 1 + 组 2 + 非剪影

轮廓和光照轮廓的明暗要根据摄像机可视面的对光与否判断，目前的方法从背后看形状封闭得不正确。

这个可以，但是似乎曲线的封闭形状选项不起作用，需要检查。

新！通过GPU有偏地算线画也已经可行。与之前的dpix情况相比，由于lineart目前计算好了前后裁剪，因此只需要比深度即可求显隐。

由于lineart也已经计算阴影，阴影线也可以同时丢进去。阴影线计算本身可能也可以丢进去，取决于精度（因为如果跟踪精度不够的话有的地方会飞）

基于GN的解决方案需要通过attribute来过滤而不是通过内部记录和输出源信息。

谷歌文档^↗

2021/10/21 00:12:36 - 2023/03/19 00:20:11