Thread
-
embree实现line art交线以及虚拟三角形求交算线条遮挡还有一些需要解决的问题:
-
剩下的主要工作:
embree实验。 多线程加载(和Sebastian)。 平滑轮廓线修改器。 投影支持更新到最新。 以及通过投影的轮廓代码取得正向轮廓。 考虑如何记录阴影和照明片段以实现通过这个筛选被照或者在阴影中的内容。 照相机多段变形。(需要有上下文地将剩余工作整理成完整的说明放在DBO话题↗上。)
-
接下来的首要研究内容是完全通过BVH,利用照相机出发的假三角形做遮挡查询。
利用embree的rtcCollide()可以求自相交(例子中即是这样使用的)。注意回调应当多线程友好↗
-
Utility Programs
Go check out the code repository.
Featured
Our Paintv0.2 LaGUI Blender Line Art laMDWiki User Manual And Log GPencil Font Plug-in Manual And LogEarlier works
Rastiq Small Car Simple Desk StopperStashed
Retopology with monte-carlo method Palette for MyPaint Pan-cloud-travel website ESP32 typewriter Hardware progress Line Art embree experiment (done) Blender Nurbs Keyable fully-automatic projectile launching effect tool , based on Blender. 尝试实现一个简单的实时大气光散射Concepts
The conceptual problem of parametric shape forming
-
2022/03
-
先按照Github上的建议将索引号直接放如自定义数据里面防止每次都来重新找。
-
有个不大不小的问题:线是局部删掉了的(含有裁切以及其他标记为丢弃的情形),embree没有办法指定跳过的线(虚拟三角形)。
到时候可以尝试看下全设置成0管不管用。
以及还有个更不大不小的问题:获得不了几何的的
eln
实例。已解决的:
scene0
Andgeom0
是对应的而不是乱序的,因此可以rtcGetGeometry()
。- 因此可以通过
geom
的userData
来传递eln
指针。
- 因此可以通过
-
有个比较关键的问题:
BMesh 的三角索引号和Mesh的不一样,这导致找不到三角形。改成统一从eln
获得,运行上的确也没问题了,只是遇到了一个小问题:似乎BMesh
出来之后的totface
Andtotloop
可能不一致。 -
目前的问题:
- 交线还没添加到遮挡用虚拟三角形几何中去。(如果这样做,还存在交线来源面目前未知的问题,这个要写在配对里面,因为现在已经用已加载几何来碰撞了)
- 可能由于内置
isect_tri_tri_v3()
的精度或者对重叠点处理手段的问题,某些遮挡对会丢失,将上面那个函数全改为double
不是很现实或者很实用,因为他的逻辑过程似乎和LineArt自己使用的不一样,这个尚不清楚如何操作。- 他那个函数的逻辑似乎并不是很兼容两个三角形有共享点的情况,至少从目前运行的状况看出来是这样的。
- 由于需要将
double
拷贝为float
以使用blender内部的数学函数(目前),以及由于需要一直调rtcGetGeometry()
等,所以整个碰撞回调非常慢。727文件要跑一分多钟。 - 还有什么想到了补充。
所以目前的工作大约是将内置的那个交叉改成完全线程安全和无锁的(因为几何后面才创建),这样就无需使用Blender自带的那个。
-
目前理论上embree方法可能还有个问题:传统方法默认情况下遮挡到足够的时候就不再计算了,embree一直要计算,并且是3d包围盒重叠就要算。
还有个性能瓶颈是添加遮挡对时现在加了锁,不应该加锁。
在交叉线测试文件中只运算遮挡碰撞都要七八秒时间,而只获得几何并返回也需要2.8秒,直接返回也需要2秒。似乎embree调用完了碰撞函数之后还有一截后处理不知道他在忙什么,打扫线程的栈空间么?
-
昨天意识到一个问题,应该在图像空间做这个事情而不是在几何空间,应当试一下。(试完了,效果很好,基本上和多线程版LineArt持平了,因此应继续完善)
-
新问题(不算太大但是也不算很安逸):
- 老三角形求交函数记录了已交点,新的估计没法弄。
-
-
rtcThreadLocalAlloc
不适用于在rtcCollide
中使用,因为它只在BVH构建过程中调用。 -
Jacques Luke提出可以这样使用一个Blender自带的TLS(TBB的):
/* Setup. */ EnumerableThreadSpecific<MyType> value_per_thread; /* On different threads. */ MyType &local_value = value_per_thread.local(); do_something(local_value); /* After threading. */ for (MyType &value : value_per_thread) { do_something2(value); }
运行是成功了,但是似乎仍然不是很快……明天再来解决没有
delete
的内存。 -
通过在
CMakeLists.txt
中显式打开-DWITH_TBB
使得embree使用TBB
调度,节约了锁占用的时间,但是由于配对多,并且顺序集中,所有操作都挤到了occlusion_worker
的锁上,又占用时间。 -
由于负荷转移到后面的锁上,因此应尝试在碰撞回调内做求交并且只记录剪切,完了之后再把剪切应用了(不清楚这个又还不好记录,如果可以都放到TLS里面后面似乎可以一次性多线程剪切完?)
-
尝试了直接在碰撞回调里做求交,似乎要快一些,并且移除了复制预检查那块,速度基本不变/略慢(感觉),现在主要是锁线条剪切那里慢了,尝试用100个锁来看能不能有所好转。
-
Sebastian 上周提供的:鲁棒的三角形求交 1↗ 2↗
-
多线程加载代码闪退是因为没有处理边数为0的情况。(但是还是会出现
edge_hash==NULL
的情况,还不清楚是什么导致的这个问题) -
将内存管理改为
TLS
之后反而变慢,不适用,不清楚具体情况,可能是local()
调用,但看上去又不是很像。 -
合并可以简化为一次
reserve()
之后添加,就更快。(可以了,不知道快了多少,无所谓……)✓ -
以及线程结果不定会闪烁,不清楚为什么。
-
2022/01
-
目前尝试先做没有远近裁剪的交叉线。带有裁剪的还有问题因为裁剪后的几何不是针对按物体连续的,新生成的裁剪几何也不是按物体分开保存的(但有可能做成抽象索引,因此似乎没有特别大的问题?)。
-
Sebastian提议只加载边而完全不加载三角形,因为如果遮挡和交叉都通过虚拟三角形交叉来算的话实际就不需要
LineartTriangle
。这种情况下裁剪可以只对生成的边操作,因此似乎更加方便。
-
近裁剪的做法是在相交检查中按最近投影距离切断遮挡部分。
之后做投影裁剪仍然只需要完全在边上操作,不需要仔细切三角形。
-
rtcCollide
只对RTC_GEOMETRY_TYPE_USER
有用,由于在Bound回调函数会给索引来找所以还是要有个mesh的列表。rtcSetGeometryUserData
不支持stride所以要手工搭建一个列表…… -
-
-
__attribute__((optimize("O0")))
不予优化。 -
-
目前的运算时间:
文件 master temp-lineart-embree temp-lineart-contained 727 2.07 1.91 2.22 -8.02% +7.05% Mr. Elephant 13.65 9.75 7.13 -28.62% -47.73% Engine 13.65 1.90 1.67 -37.38% -45.21%
2022/03/31 16:09:28