RtInt and RtFloat have enough precision there days?

by syoyo

RenderMan の仕様では、整数データは RtInt, 浮動小数点データは RtFloat
で表現され、これらはそれぞれ C 言語でいう int, float に対応しています.

もちろん、RtInt, RtFloat は define されているものなので、
long, double に変えることもできなくは無いのですが、
RIB や DSO などの既存アプリなどとの互換性を考えると
一旦定義してある型を変えることは非常に困難です.

で、int(32bit 整数), float(32bit 浮動小数点)ってそろそろ限界じゃね?ってお話.

まず、RtInt を考えてみましょう.
RtInt はたとえばポリゴンの定義において頂点インデックスの定義などに使われます.

RtInt の場合、2^31 の頂点インデックス数が表現の限界になります.
この数字により表現できるのは、およそ 700 万ポリゴンほどになります.
現在の CG 表現の複雑性を考えると、Polygons, PointsPolygons
で表現できる 1 プリミティブのポリゴン数の限界が 700 万ポリゴンというのは、
そろそろまずいんじゃないか?と思います.もってあと 2, 3 年かな.
まあ Polygon の定義を二回のコールに分けて対応とかできなくはないですが、
そのような処理をエクスポータなどに書くのは面倒くさいですよね.

つづいて RtFloat.

まあシェーディングは float の精度でもまだいけるかなーという感じですが、
ジオメトリデータはそろそろ double でないと精度不足じゃないでしょうか.
特に地形などの巨大シーンを扱う場合.
DelayedReadArchive とか、グリッドで切って分割レンダリングとかで精度を稼いで
対応できなくはないですが、まあそんなワークフローを作るのは面倒くさいですよね.

そんなわけで、lucille は RtInt は long(64bit int)、RtFloat は double にしたいなーと思っています.
ただそれだと他 RenderMan 互換レンダラとの互換性が取れなくなるので、
別 API で long と double を受け付けるものを用意するのが現実的でしょうか.
PointsPolygonsEx みたいな感じで
(うーん、しかし Win32 API みたいで格好良くないですね)

結論

さすがに RenderMan はフォーマットが 20 年前に定義されていることもあり、
いろいろなところで限界が来ています.
今回はその中で精度は足りるか?という話でした.
やっぱいずれは lucille 用に次世代対応な独自フォーマットを定義するようにしたいですね.

Advertisements