気泡問題は以前反射光のところで
物体表面を新たな視点としてトレースする時、 起点の交点そのものは次の交点の候補から外す処理を追加しています。
だったはずですが...
ref_rate の値を100万分の1固定から、引数の指定で変更できるようにして試してみます。 とりあえず指定がなかったときのデフォルト値は1000分の1ということで。
v17.patch
diff -urN rt_v16/rt.py rt_v17/rt.py
--- rt_v16/rt.py 2018-04-03 09:46:11.000000000 +0900
+++ rt_v17/rt.py 2018-04-04 21:33:33.000000000 +0900
@@ -36,6 +36,8 @@
col = np.sum(cols, axis=0) if cols else def_col
return ut.map_lst( lambda v: min(v, 255), col )
+ref_rate = ut.arg_f('ref_rate', 0.001)
+
def get_col(data, lights, l_g, video, nest_rate=1.0, ref_len=None):
if nest_rate < 0.01:
return []
@@ -46,7 +48,6 @@
return []
if ref_len:
- ref_rate = 0.000001
lst = ut.filter_lst( lambda crs: crs.get('t') > ref_len * ref_rate, lst )
if not lst:
return []
この「候補から外す処理」の内容は
rt.py
def get_col(data, lights, l_g, video, nest_rate=1.0, ref_len=None):
最後の引数ref_lenで「参考にする長さ」を指定
最初の視点からのトレース時は、デフォルト値でNone(指定なし)
:
if ref_len:
lst = ut.filter_lst( lambda crs: crs.get('t') > ref_len * ref_rate, lst )
if not lst:
return []
もしref_lenの指定があれば、ここでふるいにかけてます
lstは複数の物体の交点情報のリスト
crs.get('t')は視点から交点までの距離のようなもの
それが「参考にする長さ」の100万分の1より小さい、
つまり視点に十分近い位置ならば、除外します
crs = min( lst, key=lambda crs: crs.get('t') )
除外処理済みのリストから、一番視点に近い交点をcrsに
:
crst = crs.get('t')
その交点crsの視点との距離のようなものをcrstに
def reflect_col():
:
col = get_col( data, lights, ref_l, video, nest_rate * reflect, crst )
return col * reflect if col != [] else []
col_ = reflect_col()
:
反射の再帰処理で、交点crsを新たな視点としてトレースするときは
「参考にする長さ」ref_len として、前回の視点と交点の距離のような値crstを指定します
屈折の場合もまた同様にref_lenを指定
試してみます。まずref_rateが1000分の1の場合
$ cat v17.patch | ( cd rt ; patch -p1 ) $ cd rt $ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=ball name=out_v17/ball_1 n=1 init_sec=5 : wh : 307200/307200(100.0%) : fin 3m 55.30s
気泡、北半球は消えてる感じです。
次に、これまで通りref_rateが100万分の1の場合
$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=ball name=out_v17/ball_2 n=1 init_sec=5 ref_rate=0.000001 : wh : 307200/307200(100.0%) : fin 3m 45.27s
気泡、目立ちますね。 反射光対応の最初から100万分の1としてたはずなのですが。
極端に、ref_rateを10分の1にしてみた場合
$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=ball name=out_v17/ball_3 n=1 init_sec=5 ref_rate=0.1 : wh : 307200/307200(100.0%) : fin 3m 5.07s
まぁそうですね。極端にすると逆に問題ありになりますね。 以降ref_rateはデフォルトの1000分の1という事で。
以前の試算で15日以上かかる予想のデータを、このバージョンで荒削り設定で試してみます。
$ ./cg.py eyep=[0,0,0],200,10 sec=10 data_name=objs name=out_v17/objs div=2 fps=4 : wh : 76569/76800(99.7%) : rest 2.30s : 2018/04/05 06:53:42 wh : 76698/76800(99.9%) : rest 1.01s : 2018/04/05 06:53:42 wh : 76800/76800(100.0%) : fin 12m 46.20s frm : 40/40(100.0%) : fin 6h 50m 3.11s
それでも多少、気泡が気になりますね。
解像度1/2でピクセル数1/4 フレームレート4/30 よって本来のピクセル処理量の1/30 それで7時間弱かかったので ( ((6*60+50)*60+3.11) * 30 ) / (60*60*24) = 8.54 約8日半 あら、15日以上の予想より速いですね。 以前の予想のときは $ ./cg.py eyep=[0,0,0],200,10 sec=10 name=out/objs2 div=4 n=1 init_sec=5 : wh : 19200/19200(100.0%) : fin 4m 36.09s 解像度1/4の絵を1枚で4分36.09秒 ピクセル数は本来の1/(4*4*300)なので (4*60+36.09) * (4*4*300) / (60*60*24) = 15.33 まぁ10秒間のうち時刻5秒のときの絵1枚の時間だったので、 たまたま処理が重くなるアングルで、試算していたのかもしれません
それでも一週間以上はかかる予想です。(T_T)