Thread
-
embree实现line art交线以及虚拟三角形求交算线条遮挡还有一些需要解决的问题：
-
This thread show latest posts first -
→
-
→
以及线程结果不定会闪烁，不清楚为什么。
-
✓
合并可以简化为一次
reserve()之后添加，就更快。（可以了，不知道快了多少，无所谓……） -
→
将内存管理改为
TLS之后反而变慢，不适用，不清楚具体情况，可能是local()调用，但看上去又不是很像。 -
→
多线程加载代码闪退是因为没有处理边数为0的情况。（但是还是会出现
edge_hash==NULL的情况，还不清楚是什么导致的这个问题） -
→
Sebastian 上周提供的：鲁棒的三角形求交 1↗ 2↗
-
→
尝试了直接在碰撞回调里做求交，似乎要快一些，并且移除了复制预检查那块，速度基本不变/略慢（感觉），现在主要是锁线条剪切那里慢了，尝试用100个锁来看能不能有所好转。
-
→
由于负荷转移到后面的锁上，因此应尝试在碰撞回调内做求交并且只记录剪切，完了之后再把剪切应用了（不清楚这个又还不好记录，如果可以都放到TLS里面后面似乎可以一次性多线程剪切完？）
-
→
通过在
CMakeLists.txt中显式打开-DWITH_TBB使得embree使用TBB调度，节约了锁占用的时间，但是由于配对多，并且顺序集中，所有操作都挤到了occlusion_worker的锁上，又占用时间。 -
→
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的内存。 -
→
rtcThreadLocalAlloc不适用于在rtcCollide中使用，因为它只在BVH构建过程中调用。 -
→
目前的性能不是特别到位，改成内部交叉函数之后似乎又慢了。
基本上是交叉函数和锁的问题。
另外偶尔也会闪退，不知道什么导致的，因为开调试的时候正好又不崩溃。
-
→
新问题（不算太大但是也不算很安逸）：
- 老三角形求交函数记录了已交点，新的估计没法弄。
-
→
昨天意识到一个问题，应该在图像空间做这个事情而不是在几何空间，应当试一下。（试完了，效果很好，基本上和多线程版LineArt持平了，因此应继续完善）
-
→
目前理论上embree方法可能还有个问题：传统方法默认情况下遮挡到足够的时候就不再计算了，embree一直要计算，并且是3d包围盒重叠就要算。
还有个性能瓶颈是添加遮挡对时现在加了锁，不应该加锁。
在交叉线测试文件中只运算遮挡碰撞都要七八秒时间，而只获得几何并返回也需要2.8秒，直接返回也需要2秒。似乎embree调用完了碰撞函数之后还有一截后处理不知道他在忙什么，打扫线程的栈空间么？
-
→
目前的问题：
- 交线还没添加到遮挡用虚拟三角形几何中去。（如果这样做，还存在交线来源面目前未知的问题，这个要写在配对里面，因为现在已经用已加载几何来碰撞了）
- 可能由于内置
isect_tri_tri_v3()的精度或者对重叠点处理手段的问题，某些遮挡对会丢失，将上面那个函数全改为double不是很现实或者很实用，因为他的逻辑过程似乎和LineArt自己使用的不一样，这个尚不清楚如何操作。- 他那个函数的逻辑似乎并不是很兼容两个三角形有共享点的情况，至少从目前运行的状况看出来是这样的。
- 由于需要将
double拷贝为float以使用blender内部的数学函数（目前），以及由于需要一直调rtcGetGeometry()等，所以整个碰撞回调非常慢。727文件要跑一分多钟。 - 还有什么想到了补充。
所以目前的工作大约是将内置的那个交叉改成完全线程安全和无锁的（因为几何后面才创建），这样就无需使用Blender自带的那个。
-
→
有个比较关键的问题：
BMesh 的三角索引号和Mesh的不一样，这导致找不到三角形。改成统一从eln获得，运行上的确也没问题了，只是遇到了一个小问题：似乎BMesh出来之后的totfaceAndtotloop可能不一致。 -
→
有个不大不小的问题：线是局部删掉了的（含有裁切以及其他标记为丢弃的情形），embree没有办法指定跳过的线（虚拟三角形）。
到时候可以尝试看下全设置成0管不管用。
以及还有个更不大不小的问题：获得不了几何的的
eln实例。已解决的：
scene0Andgeom0是对应的而不是乱序的，因此可以rtcGetGeometry()。- 因此可以通过
geom的userData来传递eln指针。
- 因此可以通过
-
→
先按照Github上的建议将索引号直接放如自定义数据里面防止每次都来重新找。
-
→
目前的运算时间：
文件 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% -
→
至少其中一个崩溃是因为有个几何的引用写错。
目前交叉的精度不好，许多断开的。另外727文件也要闪退。
-
→
__attribute__((optimize("O0")))不予优化。 -
→
相邻检查没检查对，现在对了（
ELEM）。
-
→
好的折腾了一会儿
looptri之后索引正确了，这样一来embree求交就算对了（额外需要手工检查重叠边因为bl的实现似乎不兼容重叠的情况）。大点的模型似乎某个地方超界了，再看看是什么问题。
-
→
rtcCollide只对RTC_GEOMETRY_TYPE_USER有用，由于在Bound回调函数会给索引来找所以还是要有个mesh的列表。rtcSetGeometryUserData不支持stride所以要手工搭建一个列表…… -
→
近裁剪的做法是在相交检查中按最近投影距离切断遮挡部分。
之后做投影裁剪仍然只需要完全在边上操作，不需要仔细切三角形。
-
→
Sebastian提议只加载边而完全不加载三角形，因为如果遮挡和交叉都通过虚拟三角形交叉来算的话实际就不需要
LineartTriangle。这种情况下裁剪可以只对生成的边操作，因此似乎更加方便。
-
→
目前尝试先做没有远近裁剪的交叉线。带有裁剪的还有问题因为裁剪后的几何不是针对按物体连续的，新生成的裁剪几何也不是按物体分开保存的（但有可能做成抽象索引，因此似乎没有特别大的问题？）。
2022/03/31 16:09:28
Comments (0)
No comment here yet.Write a Reply