HLAB 2020-2021

文化的に価値のあるものをデジタルアーカイブとして保存しようという機運の中、建築においても同様の試みが行われています。これら建築デジタルアーカイブの精緻さの程度は、CGとして外観を再現するものから、部品構成まで表現するものまでさまざまです。精緻なものであればあるほど学術的な価値は高いといえるのですが、反面、三次元モデル情報の管理や、他の資料（画像、文章）との関係性（ひもつけ）の管理が難しくなり、資料価値を十分に発揮できていない現状があります。

本研究では、伝統的建築物である法華経寺五重塔（千葉県市川市）を対象に、精緻なデジタルアーカイブの作成と活用に関する提案を行います。デジタルアーカイブのもとになる三次元モデルの作成時に、データベースでの部品管理を徹底することで、イメージの再現に留まらないデジタルアーカイブ化が可能になります。例えばどの部材がどこにあるかといった情報を明示的に示すことができるようにすることで、さらにアーカイブの価値は高まるのではと期待できます。また、部品情報と、他の資料との関係性もデータベースで管理することで、適切な管理を行うことを目指します。

デジタルアーカイブのもとになる三次元モデルは、ArchiCADで作成します。大まかに、上の図１のような流れで作成します。
① 部品雛形集（パーツライブラリ）作成
② 三次元モデルの組み上げ
③ スケール模型での整合性検証
といったような手順です。CADをカスタム拡張することで、このように三次元モデルを組みながら、部品管理に必要な情報をデータベースに送信して管理していきます。

では、①～③の各手順を簡単に紹介します。

現地調査や参考文献の調査をもとに、各部品の寸法を得ます。実測調査では、コンベックスでの採寸に加え、図２左、中のようにコンピュータービジョンでの採寸も行っています。画像の中にビジュアルタグと呼ばれるマーカーをいれておくことで、図２右のように、任意の部位の採寸を行うことができます。調査時に採寸し損ねた部位なども、この技術を使うことで後から採寸することができます。


図２　実測調査の様子（右だけクリックで拡大します。）

このようにして得えられた寸法から、部品雛形（ライブラリパーツ）をモデリングして、それの集まりである部品雛形集を作成します。部品雛形のモデリングは、GDL（ArchiCADでライブラリオブジェクトを拡張するためのプログラミング言語。詳しくはこちら）で行い、パラメトリックに行います。

図３は、パラメトリックにモデリングした部品雛形「巻斗」です。巻斗のパラメータである肘木の幅を、左から二寸、三寸、四寸と変えていますが、モデル全体として形状が破綻していないのがわかります。このように、モデルに必要な寸法が、パラメータによって初期化されるようにモデリングする方法をパラメトリックなモデリングと呼んでいます。


図３　パラメトリックにモデリングした部品雛形「巻斗」

部品雛形をCAD図面に配置し、部品化していきます。この際、CADに追加した独自の機能により、図面上の部品情報を逐一データベースに送信し、部品管理を行うようにします。同時に、プロポーションのチェックや、部品間の納まりの不具合など、視覚による整合性の確認を行います。

作成した三次元データを利用して、試験用小スケール模型を作成して整合性を検証します。例えば、三次元モデル上では確認しにくい、組み上げ順序の検証などがここで行われます。模型の作成には、数値制御加工機（NCルーター）を用います。NCルーターでは、三次元モデルを非常に正確に模型化できるというメリットがあります。反面、NCルーターの構造的な制約を受けるます。例えば、図４のように凹部ではミル（ドリル）の半径だけフィレットができてしまうなどの制約があります。図４中のワイヤーフレームのような形状を意図して切削しても、図４右の赤い部分のように、フィレットが残ってしまいます。

このような制約を回避しながらも、スケール模型での整合性検証の価値を損なわないように、三次元モデルに変更を施し模型での検証を行っていきます。すなわち、伝統的建築物の部品、納まりなどの正確に表現した「アーカイブモデル」と、模型検証用の「NCモデル」の二つのレベルのモデルを各モデルに用意して、対応をとりながら切削、検証していこうというわけです。

現在、図５のように切削、組み上げを行っています。ここでの検証をもとに、不具合などをパーツライブラリ、三次元での組み上げにフィードバックしていきます。

ArchiCADの公開APIを用いてカスタム拡張し、デジタルアーカイブ化に必要な構成情報を、ArchiCADの内部データベースから、外部のリレーショナルデータベースに送信します。外部のリレーショナルデータベースでは、各構成情報に自由に情報を付加することが出来ます。このためには、内部データベースで管理される部品雛形とインスタンス（配置済みの部品・エレメント）に対し、適切な識別子を用いて外部データベース上の情報を対応させる必要があります。

さて、APIでのライブラリパーツ、インスタンスの構造（構造体）を見るに、部品雛形には、OwnUnIDという要素があり、これがデータベースでの管理用の識別子として使えることがわかりました。インスタンスの構造体には、guidという要素がありましたが、データベースでの管理用の識別子には向かなかったため、エレメントのユーザー領域にデータベース用の識別子、「dbID」を独自に作成しました。もちろん、dbIDは、データベースでの部品管理の為に勝手に作成したIDのため、識別子として働かせる（例えば、学籍番号が重複していたら学生の管理はできませんよね。）ための拡張が必要です。CADの作業者のイベント（新規挿入、移動などの操作のこと）に対して、dbIDをマネジメントするハンドラ（各イベントが起きた時に実行されるプログラム）を作成しました。例えばインスタンスが新規に挿入された時には、図６のようなハンドラが働き、挿入されたインスタンスに新しいdbIDを与えます。

これで部品雛形とインスタンスをデータベースで管理するための識別子を準備することが出来ました。部品雛形の構造体からは、定義ファイルのパス（どこのフォルダにあるか）や、部品雛形に設定されている公開変数・パラメータに関する情報が得られます。同様にインスタンスの構造体からは、位置、角度などの情報を得ることが出来ます。図７のスキーマようにデータベースを設計することで、基本的な部品管理を行うことができます。

データベースでの部品管理では、主にCADのもつ情報をデータベースに送信することで行います。では、データベースの持つ情報をCADが受け取り、図面に反映させることはできるのでしょうか？もちろんできます。実は、先ほどの部品管理の基本スキーマの情報と、部品雛形集があれば、それをもとに作業状況を空白の図面に復帰させることができます。このようにデータベースに情報を持たせ、それをCADが参照することで、様々な発展性があるのです。ここではそれらについて簡単に触れていこうと思います。

ArchiCADのようなオブジェクト指向CADで、独自のオブジェクト（部品雛形のことです。）を利用する場合、部品雛形の更新は既存の図面に大きな影響を与える場合があります。CADの作業者の作業日時を管理することで、部品雛形の更新の有無を確認でき、変更があった部品雛形に属するインスタンスを明示的に示すことも可能です。図８では、部品雛形の更新状況をチェックする拡張プログラムを実行し、作業者の前回のログイン時以降に更新された部品雛形がどのパーツであるかチェックし、巻斗のパーツが更新されていることがわかりました。また、データベースの情報から新規の図面に作業状況を復帰できるため、複数人で同一の図面に対して操作を行うといった応用も可能です。

部品同士が互いに干渉する時、ソリッド演算（三次元形状の引き算など）を行う場合があります。どちらが勝ってどちらが負けるかを指定することで、演算を行うわけですが、データベースでこの勝ち負けの関係を管理することで、複雑な勝ち負け関係も整理できます。図９では、データベースには、○ 枠肘木 ： × 秤肘木、○ 枠肘木 ： × 大斗、○ 秤肘木 ： × 大斗といったように勝ち負け関係が定義されています。この様子は、動画として<動画デモ：CADとデータベースの連携　技術デモ①>で紹介しています。

複数の部品雛形に、共通のパラメータとして同じ数値を入力するケースが五重塔のモデリング中にはよくあります。これは規矩術、木割りに沿って五重塔が設計されていて、各部品の設計寸法が体系化されているからなのですが、パラメータをデータベースで管理することで、この体系をまとめようと考えています。CAD上でエレメントにパラメータを与える場合、これら寸法体系は軽視されがちになります。また、設計段階においては、いづれかのパラメータの更新が他のパラメータに影響を与えるケースも少なからず存在します。こういった状況を踏まえ、データベースでのパラメータのデータベースでの管理を試行中です。図１０では、大斗、枠肘木、秤肘木、巻斗の共通パラメータである、肘木の幅を、データベースを参照することで更新しています。

本研究では、作成した三次元モデルを実際に模型化して組み上げることで、整合性を検証していきます。この作業ですが、どの部品の検証が終わり、改善点が何で、それに関係する部品はどこで、、、といった情報を逐一管理していく必要あります。現在、暫定的にモデリングが終わっている部品数は、優に6000個を超えます。これらの情報を部品管理システムと切り離して管理するのは得策ではありません。インスタンス（部品）管理のテーブルに模型検証に関する情報を管理する項目を追加することで、進捗管理などをCADとデータベースで行うことができます。図１１は、デジタルアーカイブ化作業の進捗管理として、スケール模型での整合性検証の作業予定、経過をデータベースで管理して、それをCADのデータに反映させたものです。予め登録した作業予定に対し、順調に終わったものを青色、遅延があったが終了したものを黄色、遅延中のものを赤色、予定が先のものを半透明に塗り分けて示しました。 作業予定の登録や、進捗状況の登録はCADや、WEBサイトなどからも行うことが出来ます。

デジタルアーカイブ化作業の進捗管理で少し触れましたが、データベースとCAD上の部品情報がきちんと対応していることで、各部品（インスタンス）、部品雛形（オブジェクト）に、自由に情報を持たせることが可能です。このメリットを生かして、建築物のデジタルアーカイブ化において切り離されがちな部品の説明文、写真などの関連情報を部品と対応させながら管理します。資料性の高いデジタルアーカイブの作成、活用について試行します。

ここでは、
■ ArchiCAD上でのデジタルアーカイブ閲覧方法
■ WEBでのでのデジタルアーカイブ閲覧方法
について紹介します。

＊＊＊この項目は、随時更新予定です。＊＊＊

データベースで管理されている部品情報と、部品雛形集があれば、空白の図面に三次元モデルを復帰することが出来ます。もちろん復帰後の部品雛形、インスタンスは、データベースの部品管理情報と適切に対応付けられている。図１２のようなシーンを想定し、次のような実装を行いました。

データベースでの部品雛形管理の項目として、説明文、関連画像などを管理することで、CAD上で選択中の部材に関する情報を表示することが出来ます。図１３では、大斗の部品雛形のもつ情報をデータベースから参照しています。データベースでは、部品雛形管理エンティティで、説明文を保持し、部品雛形管理エンティティと関連付けされた参考画像エンティティに参考画像情報を保持しています。この様子は、動画として<動画デモ：CADとデータベースの連携　技術デモ②>で紹介しています。

部品名などのキーワードから検索を行い、検索結果から部品名を選択、強調表示することも出来ます。先ほどの部品説明文からの検索も可能で、ある名称の部品がどんな形状でどこにあるかなどは、この応用を用いることで簡単にわかるようになります。図１４左のように、部品検索ダイアログから、キーワードを入力しダイアログ下に表示される検索結果から、強調表示したい部品名を選択し、OKを押します。すると、図１４右のようにダイアログで選択した部品が強調表示されます。キーワードは、単に部品名を対象に検索することや、先ほどの部品関連情報を対象に検索することもできます。

このように、データベースで部品管理を徹底し、CAD上の部品を管理することで、三次元モデルと資料として保持されるべき関連情報の対応が取れていることがわかります。今までにない、資料性の高い建築物のデジタルアーカイブ化が行われているといえると思います。

データベースには、拡張性に富み、様々な言語から接続できる（情報のやり取りができる）という特長がありあます。ArchiCADからは、APIを介してC++言語でデータベースに接続していましたが、WEBサイトの構築に用いられるPHPというプログラミング言語からも接続を行うことができます。図１５では、大斗をキーワードに、三重大斗に関する情報として、部品関連情報、参考画像、主要パラメータを表示しています。WEBでの閲覧用に新規にデータベースを作成したのではなく、今までと同一のデータベースに接続しています。こちらのWEBサイトは、いずれ公開したいと考えています。

スケール模型での検証工程をもとに、部品の発生順をデータベースに記録し、アニメーション化したものです。実際の施工手順とは多少異なる箇所があるかと思いますが、1/15スケールの模型（と納まり等の設計）では、この順で模型を組み上げていくことができます。

初重四天柱付近と、二層目三手先付近の部品の三次元形状を物理エンジンに出力し、挙動をシミュレーションしたものです。物理エンジンにはOpen Dynamics Engine（ODE）を使っています。データは、データベースを介して出力しています。実装としては、ADDONによってArchiCADで選択中の部品のID（DBID）をシミュレーションプログラムに渡し、シミュレーションプログラムでは、渡されたIDをもとにデータベースから形状情報を得るといった手順になっています。やや不自然な挙動もありますが、いかがでしょうか。

動画デモにシミュレータを改良し、継手仕口に着目にその挙動を確かめたものと、軸部の一部を入力したものを追加しました（こちらです）。

ここまではデジタルアーカイブの基幹となる三次元データの作成方法と、データベースで三次元データに関する部品、図面管理をすることでデジタルアーカイブの活用方法を提案してきました。部品レベルでの納まりまでを表現し、部品名称などでの三次元モデルの検索なども可能なデジタルアーカイブは、資料性も高く、学術的効用も期待できるものであると言えます。さて、ここでは、作成した三次元データは果たして正確か？という点について考えます。”部品レベルの納まりを表現した精緻さ”と銘打つならば、三次元データで表現した納まりが正確かを確認しなければなりません。

本研究では、三次元モデルとして表現されている部品を、模型部品として削り上げ、それを実際に組み上げてみることでデータの整合性を確認することを試みました。三次元モデル同士の干渉（衝突）などに関しては、CADやその他のソフトウェアにでも検証できるかと思います。しかし、伝統的建築物の部品の納まりは部品の組み上げ方向や順序に大きく関係があるため、実際に模型として組み上げてみる方法をとることにしました。模型化には、数値制御加工機（NCルータ）を利用することにしました。NCルータでは、三次元モデルに忠実な模型部品を作成することができます。三次元モデルは実寸で設計されていますが、NCルータの加工範囲や、刃物（エンドミルと呼ばれます）を考慮して１／１５スケールの模型にすることにしました。

NCルータでは、かなり正確に三次元モデルを模型化できますが、NCルータは、基本的に上面から回転刃（エンドミルといいます）での切削を行う（図１７左）ために、切削できない形状というものがあります。この切削出来ない形状は、アンダーカット（刃物がそもそも入らないところの削り残し、図１７中）と、刃物半径分の削り残し（図１７右）に起因します。五重塔のような伝統的な建築物に用いられる納まりには、複雑なものが多く、切削できない形状の影響で模型上で表現出来ないものが多くあります。

切削出来ない形状の影響を受けずに模型検証を行うために、工夫が必要です。今回は、三次元モデルを二つのレベルに分けて考えることにしました。まず一つ目のレベルは、アーカイブレベルです。アーカイブレベルは、伝統的な継手仕口を正確に表現したレベルで、今まで出て来た部品雛形と部品モデルがこれに属します。二つ目のレベルはNCレベルです。NCレベルは、模型検証の為にアーカイブレベルのモデルを変更、分割したものです。NC部品雛形とNC部品モデルがこれに属します。模型検証の価値を失わないように留意しながら、NCルータの切削出来ない形状の影響を受けないように、変更、分割したもの、というのがこのNCレベルです。では、初重の側柱と、側柱に接合する地貫、縁繋ぎを例に、NCレベルによる模型検証について説明します。

側柱と地貫は、地貫が側柱を貫通し、楔で締められるという納まりで納めます。側柱に空く地貫が通るための横穴は、側柱の軸方向からはアンダーカットになるため切削できません。側柱の横方向から切削しようとするとエンドミル半径分の削り残しの影響で納まりとしては破綻してしまいます。これらを回避するために、側柱を図１８左のように分割して切削します。このように分割することで、地貫が通る横穴を開けることができます。分割して切削したあとは、他部材（地貫）との納まりを検証する前に、接着しておきます。側柱と縁繋ぎとの納まりは、アーカイブレベルでは、図１８中のように、側柱に差し込んでから下に落とし楔で締める蟻落としと呼ばれる仕口で納まります。図１８右のようにNCレベルの設計をして、NCレベルでも同様の施行手順になるようにします。

このように設計したNCモデルをNCルータで図１９のように模型化します。アーカイブレベルと同じ組み方で、組み上げられるかを確認します。アーカイブレベルからNCレベルを設計する際に、模型化による検証の意味がなくなってしまわないように、NCモデル設計のルールを下のように決めました。

• NCモデルは、アーカイブレベルで設計した仕口の組み方、組む方向と同じになるよう設計する。
  
• 部品モデルは複数のNCモデルに分割する場合があるが、複数の部品モデルを単一のNCモデルに統合しない。分割して切削したNCモデル部品は接着して一つのアーカイブレベル部品としてから他部品との納まりを検討する。
  
• NCルーターの切削可能範囲を超えるサイズの部品は適当な箇所で分割するが、アーカイブレベルで継手仕口の納まりが問題となる箇所は避ける。NCモデル化に伴う分割も同様であるが、共に位置合わせを正確に行いズレなどが生じないようにする。
  

  
  
  図１９　アーカイブレベルとNCレベル（画像クリックで拡大します）
  

伝統木造建築を構成する部品の多くは、三次元CAD標準のツール（柱ツールやスラブツール）では表現することができません。束や貫などの比較的簡単な形状の部品であれば、複数のツールを組み合わせることでその三次元形状を表すことも一応できますが、本研究では全ての部品に対して部品雛形を用意し、一つの部品が納まりも含めて一つの部品雛形のインスタンス（実体）として表現されるようにすることとしました。部品雛形は、伝統的な作図法をモデル化し、それをGDLによって記述することで用意します。パラメトリックなモデリングを採用し、三次元モデルや雛形の修正の効率化や、高い再利用性の実現を試みます。

伝統木造建築を構成する部品の雛形では、柱や梁といった（広義の）雛形と比較して公開変数が多くなる傾向があることが分かっています。また、インスタンスの形状は、そのインスタンスの属する部品雛形がなにであるかと、公開変数に与えられたパラメータの組み合わせによって決まります。公開変数に設定する値（パラメータ）が正しい組み合わせでないと三次元モデルに不整合な箇所がでるでしょう。ここでは、伝統木造建築の部品を表現する部品雛形にはどのように公開変数（パラメータを設定できる変数）を設計すべきか、また、実体化の際に公開変数にどのようにパラメータを設定すべきか、について考察します。

伝統木造建築は、比較的モジュールに従順で、ある部品の寸法が他の部品の寸法と関係があることが多いという特徴があります。図２０は、腰長押を例に部品間の寸法の関係を表したものです。例えば腰長押の全長は、隅側柱の径（幅）や一枝寸法、脇間枝数などから求めることができます。腰長押の部品雛形の公開変数を考えたとき、「腰長押の全長」を公開変数として設計するパターンと腰長押の全長に関わる他の部品雛形の公開変数と同じ公開変数を設計するパターンがあることがわかります。前者は他雛形の公開変数群から計算して得られる寸法を入力できる公開変数を設計するパターン、後者は寸法の計算に必要な他雛形の寸法と同じ公開変数を設計するパターンであるといえます。二つのパターンを、公開変数間の関係性や計算の記録の観点から考えてみましょう。

前者では、他の部品雛形の公開変数（に設定するパラメータ）などから計算した値を入力できるように公開変数を設計します。腰長押の例でいえば、計算した腰長押の全長を直接入力するための公開変数を用意する、ということになります。このパターンでは、「どのような計算がなされたか」を記録するのが困難であるという点が問題となります。腰長押の全長を求めるには側柱の寸法などが必要ですが、それらからどのように全長が求められたかは記録することが難しく、側柱の寸法がなんらかの理由によって変更された場合、腰長押の全長の再計算を促すといった仕組みを実現するには煩雑な処理が必要になります。後者では、寸法の計算に関わる計算式が部品雛形の内部プログラムの中に記述されています。また、計算に必要な寸法は公開変数として設計されています。

本研究で後者のパターンを採用しました。また、同じ値を意味する公開変数には同じ公開変数名を命名することにしました。以上を踏まえ、部品雛形、公開変数の管理スキーマを図２１のように設計しました。側柱と地貫（上・下）を例に、このスキーマによる管理状態を示すと図２２のようになります（公開変数管理情報にはパラメータが記録されていますが、今のところこの値にはそれほど意味がありません。このスキーマは部品雛形と公開変数の関係を管理するためのものです）。このようなスキーマを採用することで、部品雛形の作成を行う前段階において公開変数とパラメータを整理し、データベースに記録できるようになります。予めデジタルアーカイブ化で用いる公開変数・パラメータを整理することで、公開変数が冗長となるのを防ぐことができます。また、公開変数の設計方針は次のようにまとめることができます。

• アーカイブ化に用いる公開変数・パラメータは、部品雛形作成の前段階で整理し、予めデータベースに登録しておく。公開変数が冗長とならないように留意する。
• 部品雛形の公開変数には、できるだけ登録済みの公開変数・パラメータ（と同じもの）を採用し、これらから寸法を求める計算は部品雛形の内部に記述する。
• 同じ値を意味する公開変数には同じ公開変数名を付ける。

部品雛形にはパラメトリックなモデリングが採用されており、実体化の際、あるいは図面上で、公開変数に設定するパラメータを変更することで、異なる形状をもつ部品（インスタンス）を表現することが可能です。図２３は、各層の側柱とそれに必要なパラメータを示したものです。これらのパラメータが正しい組み合わせでないと三次元モデルには不整合が起きてしまいます。公開変数に正確にパラメータを入力し不整合を避ける仕組みを踏まえた部品雛形の取り扱いについて考察したいと思います。

ArchiCADをAPIによって拡張した場合、公開変数とそのパラメータに関して参照・操作できる範囲は、図２４に示した通りです。ArhiCAD標準の状態（APIによって拡張を施さない状態）では、各インスタンスの公開変数にどのようなパラメータを入力するかは基本的に作業者に委ねられます。APIによって拡張を施し、データベースとの連携を行えるようにすると、データベース（の公開変数・パラメータ管理エンティティ）とインスタンスの公開変数間での情報のやりとりが可能になります。データベースを経由することで、図中、破線のようなやりとりもできます。

部品雛形の取り扱いは、次の３パターンで整理することができます。それぞれのパターンについて実体化する際のパラメータの与え方やその管理の観点から説明したいと思います。

• 部品雛形が形状を変えない（パターンA）
• 多くの公開変数を操作することで形状を変える（パターンB）
• キー（識別子）をもとに数通りの形状を表現する（パターンC）

ある部品雛形に属する全てのインスタンスは同じ形状となるパターンです。実体化の際に部品雛形の公開変数に値を与えず、デフォルトのパラメータのみで実体化する、あるいは部品雛形に公開変数を設計しないといった場合などはこのパターンに相当します。このパターンでは、インスタンスの形状の数だけ部品雛形が必要となるため、アーカイブ化を通して用意すべき部品雛形は最も多くなり、部品雛形の再利用性は最も低くなります。公開変数とパラメータの管理について考えてみましょう。デフォルトのパラメータのみで実体化する場合や公開変数を設計しない場合では、公開変数・パラメータの管理がしにくいため、データベースで実体化の際に入力すべく値を管理する、といった方向で考えます。上で定めた公開変数の設計方針によれば、同じ値（寸法）を意味する公開変数には同じ公開変数名が付けられているため、次の手順で入力すべきパラメータを得ることができます。

1. 部品エンティティでは、部品雛形.IDから地震の属する部品雛形を得る。
2. そのIDをもとに組み合わせエンティティに問い合わせを行う。
3. 実体化に必要な公開変数とパラメータのセットを得る。

法華経寺五重塔では、巻斗のサイズには二種類のサイズ（初～二層のものと、三～五層のもの）があり、さらに琵琶板のあるものとないものがあります（図２６）。 図２７は、この巻斗部品を例に、パターンAについて用意すべき部品雛形やその公開変数について示したものです。パターンAではこれらの巻斗インスタンスを表すために四個の部品雛形が必要になります。また、これらの部品雛形に設計される公開変数は表のようになります。

一つの部品雛形から様々な形状のインスタンスを実体化することのできるパターンです。部品雛形に操作可能な公開変数を多数持たせ、インスタンス毎にこれらのパターンを操作してそのインスタンスの形状を決定します。このパターンでは用意すべき部品雛形の総数は最も少なく、部品雛形の再利用性は高くなります。一般に三次元モデルCADの標準状態では、各ツールなどといった広義の部品雛形はこのパターンで取り扱われているということができます。

このパターンでは、インスタンス毎に公開変数にどのようなパラメータが設定されているかを管理する必要があり、管理用のスキーマを設計するのと図２８のようになるでしょう。インスタンス毎に異なるパラメータを設定することができるため、一個の部品雛形によって、四種類の巻斗の形状を表現することができます（図２９）。ただ、公開変数・パラメータの管理は煩雑になります。特に、インスタンスの実体化に際して多くの公開変数を操作する必要があり、公開変数・パラメータが正しいものかは個々のインスタンス毎に確認することになります。以上から、（他のパターンと比較して）三次元モデルの整合性を保ちにくいということができます。

ある部品雛形から実体化されるインスタンスが、数通りの形状を表すパターンであす。部品雛形を実体化する際にデータベースを参照しますが、インスタンスに設定されるパラメータ群は「キー」によって切り替わります。ここでいうキーとは、インスタンスのもつ特定の属性であり、公開変数名とともに公開変数を一意に識別するための複合キーとして作用するものです。法華経寺五重塔のアーカイブでは、インスタンスの配置された階層をキーとしています。ただ、階層そのものをキーにしてしまうと少し扱いが不安だったため、図３０のようにレイヤと階層の対応をデータベースでとるようにします。

パターンCでは図３１に示すスキーマによって、部品雛形、部品、公開変数・パラメータを管理します。各インスタンスの公開変数に設定すべきパラメータは、次の手順で得ることができます。パターンCでは、用意すべき部品雛形の総数や再利用性はパターンAとBの中間となります。四種類の巻斗は、二個の部品雛形によって表現することができます（図３２）。

1. 部品エンティティでレイヤIDから自身の属するフロアのIDを得る。
2. また、部品雛形.IDから自身の属する部品雛形を得る。
3. 部品雛形.IDとフロアIDももとに組み合わせエンティティへの問い合わせを行う。
4. 公開変数とパラメータのセットを得る。

本研究では、今のところパターンCを採用しています。法華経寺五重塔のアーカイブ化の初期段階ではパターンAを採用していました。パターンAでは部品管理は比較的簡単に行える（スキーマを見ると単純なのが分かると思います。）のですが、アーカイブ化を進めるにつれ部品雛形の総数が増えてしまい、雛形の修正に手間がかかるようになってしまいました。例えばパターンAでは、巻斗のプログラムを修正する場合、四個の部品雛形に関して修正を行う必要があります。部品雛形への修正の手間を軽減する目的で、パターンBへの変更も考えましたが、パターンBでは公開変数・パラメータの管理が煩雑であり、公開変数に設定すべきパラメータをどう管理すべきかといった問題があります。以上のような背景と、五重塔は平面的には対称性が強く、層毎の繰り返しによる構成であるという点を踏まえ、パターンCのもととなるパターンを考案し、幾つかの修正を得て、上記のような「キー（識別子）をもとに数通りの形状を表現する（パターンC）」を部品雛形の取り扱い方針を決めました。

ここで取り扱った部品雛形の取り扱い（部品雛形の実体化に際してどのようにパラメータを設定するか）は、公開変数およびパラメータ・寸法を一意に識別する識別子をどのように設計するか、という問題とも言うことができます。取り扱いパターンAでは、公開変数名のみでパラメータの識別が行われ、ある公開変数名の公開変数には常に同じ値が入るため部品雛形から実体化されるインスタンスは常に同じ形状です。パターンBでは、インスタンスと公開変数名の組み合わせによって、パラメータが識別されるため、インスタンス毎に公開変数に対して自由にパラメータを設定することができます。パターンCでは、インスタンスの特定の属性と公開変数名の組み合わせが公開変数・パラメータの識別を行います。インスタンスの公開変数に与えられるパラメータは、インスタンスの属性によって切り替えられることになります。パターンCにおいて、パラメータの切り替えのための属性を「そのインスタンスであること」とするとパターンBに近いものになります。パターンCでは、切り替えのための属性には様々な属性が考えられ、それによってアーカイブ化の工率や管理の仕方は変わると予想できます。部品雛形の取り扱いについては今後も引き続き考察を行ないたいと考えています。

記事が長くなってしまったので、模型作成の様子こちらに整理しました。ご了承ください。