COLLADA (5)

頭の片隅に常にあった懸案。
・<scene>内の<instance_visual_scene>の出現回数は0または1
・<library_visual_scenes>内の<visual_scene>の出現回数は1以上
・<instance_node>は<library_nodes>を参照する新たなノード
・<instance_material>と<library_materials>
・<instance_effect>と<library_effects>
他
・<instance_geometry>と<library_geometries>

原点回帰とでもいうべきか。

インスタンス化と外部参照
注：COLLADA では、インスタンス間のデータ共有の方法を規定していません。データ共有ポリシーはランタイムアプリケーションに任されています。

とある。
様々な凡例やサンプルを調査すると、よほど単純なものでない限りは共有は意識されていない
ように感じる。
マテリアルを例に出すと、Aという基本になるものに差分変更を加えたB、またはCという具合に
実質３種類のマテリアルがあたかも存在することになる。
ご丁寧に<newparam>や<setparam>などで上手い具合にぼかしてある。
メモリー効率面では断然共有化ではあるが、元データの退避や上書きなど処理が煩雑になる。
おまけに差分要素はぴんからきりである。
実行時に毎回セットアップなんてしてられんなぁということで、<instance_***>系列はそのとおり
インスタンス化する方針に変更。
敢えて他の後に記述した<instance_geometry>。
極端な話をしない限りは<instance_geometry>以外はすべてインスタンス化しても大した量には
ならない。

途中経過の自問自答
<instance_geometry>をインスタンス化しなければならないケースは？
なんらかの頂点に対する操作の結果を必要とする場合。
ソフトウェアでスキンニングとかそういった類か。
vertex_shaderを前提とするなら大抵は回避はできるはず。
地形や背景を1つの*.daeで表現なんて絶対しないししてはいけないだろうが
仮にした場合は共通パターンで影響が出る。
これはそもそもがダメなので問題外。
おっと、モーフィングがあったか。
顔の表現時にボーンじゃ上手くいかん！とか言われて顔だけモーフィングしたことあるな・・・。

とりあえず<instance_geometry>以外をインスタンス化することで妥協する方針で。