| |
话题 |
| | |
| |
|
|
| #934 | 剩下的主要工作:
embree实验。
多线程加载(和Sebastian)。
平滑轮廓线修改器。
投影支持更新到最新。
以及通过投影的轮廓代码取得正向轮廓。
考虑如何记录阴影和照明片段以实现通过这个筛选被照或者在阴影中的内容。
照相机多段变形。
(需要有上下文地将剩余工作整理成完整的说明放在DBO话题↗上。) | | | |
| #813 | 接下来的首要研究内容是完全通过BVH,利用照相机出发的假三角形做遮挡查询。
利用embree的rtcCollide()可以求自相交(例子中即是这样使用的)。注意回调应当多线程友好↗ | | | |
| #315 | 实用程序
欢迎访问代码仓库。
特色
好得涂v0.4 新
热得拍
数字8毫米摄录机
LaGUI
以前的
Blender Line Art
那么的维基使用手册 和 日志
蜡笔字体插件手册 和 日志
新莓帝
小车
简易桌挡
暂存
蒙特法重布线
MyPaint调色盘
泛云旅游网站
ESP32打字机 硬件进展
Line Art 实验embree(完成)
Blender Nurbs
可运用在关键帧动画物体上的全自动发射物效果工具 ,基于Blender。
尝试实现一个简单的实时大气光散射
概念
参数化造型的概念性问题
| | | |
|
| #816 | embree实现line art交线以及虚拟三角形求交算线条遮挡还有一些需要解决的问题:
|
2022/03 … |
| #988 | 先按照Github上的建议将索引号直接放如自定义数据里面防止每次都来重新找。 |
| #989 | 有个不大不小的问题:线是局部删掉了的(含有裁切以及其他标记为丢弃的情形),embree没有办法指定跳过的线(虚拟三角形)。
到时候可以尝试看下全设置成0管不管用。
以及还有个更不大不小的问题:获得不了几何的的eln 实例。
已解决的:
scene0 和geom0 是对应的而不是乱序的,因此可以rtcGetGeometry() 。
- 因此可以通过
geom 的userData 来传递eln 指针。
|
| #997 | 有个比较关键的问题:
BMesh 的三角索引号和Mesh的不一样,这导致找不到三角形。 改成统一从eln 获得,运行上的确也没问题了,只是遇到了一个小问题:似乎BMesh 出来之后的totface 和totloop 可能不一致。
|
| #1003 | 目前的问题:
- 交线还没添加到遮挡用虚拟三角形几何中去。(如果这样做,还存在交线来源面目前未知的问题,这个要写在配对里面,因为现在已经用已加载几何来碰撞了)
- 可能由于内置
isect_tri_tri_v3() 的精度或者对重叠点处理手段的问题,某些遮挡对会丢失,将上面那个函数全改为double 不是很现实或者很实用,因为他的逻辑过程似乎和LineArt自己使用的不一样,这个尚不清楚如何操作。
- 他那个函数的逻辑似乎并不是很兼容两个三角形有共享点的情况,至少从目前运行的状况看出来是这样的。
- 由于需要将
double 拷贝为float 以使用blender内部的数学函数(目前),以及由于需要一直调rtcGetGeometry() 等,所以整个碰撞回调非常慢。727文件要跑一分多钟。
- 还有什么想到了补充。
所以目前的工作大约是将内置的那个交叉改成完全线程安全和无锁的(因为几何后面才创建),这样就无需使用Blender自带的那个。
|
| #1004 | 目前理论上embree方法可能还有个问题:传统方法默认情况下遮挡到足够的时候就不再计算了,embree一直要计算,并且是3d包围盒重叠就要算。
还有个性能瓶颈是添加遮挡对时现在加了锁,不应该加锁。
在交叉线测试文件中只运算遮挡碰撞都要七八秒时间,而只获得几何并返回也需要2.8秒,直接返回也需要2秒。似乎embree调用完了碰撞函数之后还有一截后处理不知道他在忙什么,打扫线程的栈空间么?
|
| #1006 | 昨天意识到一个问题,应该在图像空间做这个事情而不是在几何空间,应当试一下。(试完了,效果很好,基本上和多线程版LineArt持平了,因此应继续完善) |
| #1020 | 新问题(不算太大但是也不算很安逸):
|
| #1021 | 目前的性能不是特别到位,改成内部交叉函数之后似乎又慢了。
基本上是交叉函数和锁的问题。
另外偶尔也会闪退,不知道什么导致的,因为开调试的时候正好又不崩溃。
|
| #1022 | rtcThreadLocalAlloc 不适用于在rtcCollide 中使用,因为它只在BVH构建过程中调用。
|
| #1023 | 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 的内存。 |
| #1025 | 通过在CMakeLists.txt 中显式打开-DWITH_TBB 使得embree使用TBB 调度,节约了锁占用的时间,但是由于配对多,并且顺序集中,所有操作都挤到了occlusion_worker 的锁上,又占用时间。 |
| #1030 | 由于负荷转移到后面的锁上,因此应尝试在碰撞回调内做求交并且只记录剪切,完了之后再把剪切应用了(不清楚这个又还不好记录,如果可以都放到TLS里面后面似乎可以一次性多线程剪切完?) |
| #1032 | 尝试了直接在碰撞回调里做求交,似乎要快一些,并且移除了复制预检查那块,速度基本不变/略慢(感觉),现在主要是锁线条剪切那里慢了,尝试用100个锁来看能不能有所好转。 |
| #1034 | Sebastian 上周提供的:鲁棒的三角形求交 1↗ 2↗ |
| #1040 | 多线程加载代码闪退是因为没有处理边数为0的情况。(但是还是会出现edge_hash==NULL 的情况,还不清楚是什么导致的这个问题) |
| #1042 | 将内存管理改为TLS 之后反而变慢,不适用,不清楚具体情况,可能是local() 调用,但看上去又不是很像。 |
| ✓1045 | 合并可以简化为一次reserve() 之后添加,就更快。(可以了,不知道快了多少,无所谓……) |
| #1046 | 以及线程结果不定会闪烁,不清楚为什么。 |
| #1047 | 前天已经发现Möller算法↗(PDF↗)不行。
|
2022/01 … |
| #817 | 目前尝试先做没有远近裁剪的交叉线。带有裁剪的还有问题因为裁剪后的几何不是针对按物体连续的,新生成的裁剪几何也不是按物体分开保存的(但有可能做成抽象索引,因此似乎没有特别大的问题?)。 |
| #818 | Sebastian提议只加载边而完全不加载三角形,因为如果遮挡和交叉都通过虚拟三角形交叉来算的话实际就不需要LineartTriangle 。
这种情况下裁剪可以只对生成的边操作,因此似乎更加方便。 |
| #820 | 近裁剪的做法是在相交检查中按最近投影距离切断遮挡部分。
之后做投影裁剪仍然只需要完全在边上操作,不需要仔细切三角形。 |
| #821 | rtcCollide 只对RTC_GEOMETRY_TYPE_USER 有用,由于rtcSetGeometryUserData 不支持stride所以要手工搭建一个列表……在Bound回调函数会给索引来找所以还是要有个mesh的列表。
|
| #822 | 好的折腾了一会儿looptri 之后索引正确了,这样一来embree求交就算对了(额外需要手工检查重叠边因为bl的实现似乎不兼容重叠的情况)。大点的模型似乎某个地方超界了,再看看是什么问题。
|
| #824 | 相邻检查没检查对,现在对了(ELEM )。 |
| #825 | __attribute__((optimize("O0"))) 不予优化。
|
| #827 | 至少其中一个崩溃是因为有个几何的引用写错。
目前交叉的精度不好,许多断开的。另外727文件也要闪退。
|
| #828 | 目前的运算时间:
文件 |
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/01/15 17:01:04
2022/03/31 16:09:28
|
| |
订阅我的新闻
输入您的邮件:
|
| | |