紙のシートのスキャンデータに書き込む

‥‥というのが、わたし的にはとてもストレスです。

 

しかし、作業標準が全く整っていない「デジタル作画」においては、今は忍耐の時期としかいいようがないです。

 

タイムシートのデータ化はそれこそ20年規模で試行されてきましたが、未だに標準フォーマットが存在しません。

 

紙のタイムシートの完全再現だけでなく、これから発展するであろう新しい技術に対応する拡張性まで考えると、相当クレバーにフォーマットを規定する必要があり、どんどん肥大化して完成できないのです。

 

 

 

原画も演出も作監も動画も動検も、みなクリスタを使って共通できている作業チームが羨ましい。

 

4KHDRの時は私らもそれ(=クリスタフロー)が出来たのですが、一般的なテレビや2K劇場作品になると全然足並みは整いません。クリスタで統一できていた頃が、恋しいです。

 

横書きのタイムラインが使いにくいなんて言ってるのは、まだ視野が狭いです。そんな程度のストレスなど慣れれば負担にもならんです。

 

様々な作業環境のケースに対応できるように、いくつものファイルフォーマットで書き出して、タイムシートは紙のスキャンデータにドローソフトで番号や指示を書き込んで、クイックチェック用のmp4まで用意して‥‥なんて手間が大きくて、作画自体は終了しているのに、提出の整形で渋滞してしまいます。そのいくつもの手間が延々と続いて、カットの数だけ、積み上がります。

 

私はアクション系・エフェクト系の作画を担当することが多いので、原画枚数が多くなりがちです。シートのセル番号のタイミングを頭で記憶するには限界があり、作画用のiPad Proとは別に、タイムシートに数字を「ドロー」するためのiPadまで使い始めました。‥‥なんだそれ‥‥って感じですが、しょうがないス。

 

現物の紙はネットで送ませんから、何らかのデータにしなければなりません。最悪、それが画像データでも。

 

 

 

タイムシートのデータフォーマット化は、その複雑な内容から、どんどん大袈裟になって、風呂敷が広がり過ぎて、逆に汎用性や編集性、そして互換性に欠けてしまい、決定版と言えるタイムシートデータフォーマットは出現していません。

 

デスクトップOSしか視野に入っていなかったり、デスクトップOSでもWindowsだけだったり、テキストデータで表現できることをわざわざバイナリデータで格納したり、カメラワークや注意書きのデータ化に迷走したり‥‥と、20年間の経緯を見てて、私も一時は独自のタイムシートデータを運用していたこともあったりで、実は恐ろしく難しい問題なのです。

 

私が去年まで作画作業をしていた、4KHDRのプロジェクトがどれだけオンラインにおける運用性に優れていたかを痛感します。旧来作画はクリスタ、カットアウトなどの新方式はスプレッドシート‥‥と、全てデータ化できていました。

 

タイムシートのデータ化って、紙時代を真面目に再現しようとすればするほど、未来技術への対応力を失うように思います。下手をすれば、タイムシートのデータフォーマットが旧態依然とするがあまりに、アニメの未来技術が停滞して骨董化することも容易に想像できます。

 

 

液タブやiPadで原画を描いて、何らかのフォーマットのタイムシートをつければ、クイックチェックのムービーまで書き出すようなプログラムも欲しいんですが、実際、それは無理なんですよネ。

 

原画は同じ紙(キャンバスやレイヤー)に、ABCセルを同時に描くことがあるので(顔A1・目と眉B1・セリフC3とか)、動画と違ってセルワークのタイムラインが交錯して、整然と処理できません。

 

しかし、動画作業時のことを考えて、原画作業時にデータのタイムシートを作成しておくこと自体は有用です。

 

もしくは、原画作業時においても、1枚の絵には1つのセルしか描いちゃいけないタイムライン重視の新ルールにするとか。‥‥嫌がる人はかなり多そうですけどネ。

 

思い起こせば、私がクリスタで原画を描く時は、自然とタイムラインのセルのレイヤーごとに絵を描いていました。(最近、またプロクリばかり使う日々なので忘れてましたが‥‥。)

 

 

 

何か良い方法を考えないと‥‥。

 

延々とこの「グローバルなタイムシート不在」の時期が続くと、せっかくのテレワーク装備も活きてきません。

 

むしろ、今は欲張らず、セルワークの部分だけをテキスト書式にするだけのフォーマットから始めて、策定を先行するくらいの潔さのほうが良いかも知れません。後に何かに組み込むにしても、です。

 

表計算でも自作のエディタでも、それこそメールの本文に一部コピペできるくらいの、平易で単純な書式でまずはタイムシートのセルタイミング部分だけでも運用して、段階的に肉付けするのが一番手堅いような気もします。

 

特定のソフトウェアじゃないと開けない、危ういフォーマットなんかにせずに、テキストデータでタブか何かで区切って。‥‥あれ?‥‥それだったら、TSVかCSVで良いよね‥‥。

 

欲を出すと、一向にフォーマットが定まらないです。

 

0か100か‥‥ではなく、0からまず1に進むことが必要なのかも知れません。

 

 

 

なまじ紙のタイムシートのルックに似せようとして、二兎を追って一兎も得ない状況が今までの20年間のように思います。いっそのこと、タイムシートは横書きにしてタイムラインのルックに合わせても良いと思います。(というか、縦書きでも横書きでも、スタイルシート次第で対応できるのをデフォルトにするのが良いですね)

 

アニメーションタイムシートフォーマット(ATSF)ではなく、アニメーションタイムラインフォーマット(ATLF)のほうが、トラックを自由に拡張できて未来の状況に対応できます。タイムシートって、開発の多くが「シート」であることにがんじがらめになって、主役であるはずのタイムラインがシート書式の風下に置かれているようにすら感じるのです。

 

原画のトラック、動画のトラック、仕上げで新規作成されたマスクなどのトラック、セリフのトラック、カメラワークやトランジションのトラック‥‥など、主役はあくまでトラック(レイヤー)が並んだタイムラインであるはずです。

 

トラックという基本クラスを元にすれば、どんな種類のトラックでもそれこそタグで増やせますよね。タグイメージ(Tagged Image F〜TIFF)ならぬ、タグトラックのファイルフォーマットです。

 

いつまでも紙のタイムシートのルック・見た目にこだわり過ぎているのは、実は、開発する側よりも、使う側が「タイムシートの見た目じゃないとイヤだ」みたいな態度であることも大きな原因でしょう。

 

ハンコ文化ならではの日本人の性質がタイムシートにも表れているのかも‥‥。

 

紙の書類で今でもやりとりするお役所とかを、決して笑っていられないのが、アニメのタイムシートを使う人々‥‥と言えます。

 

コンテを書けば尺の集計が自動でおこなわれ、原画を描くこと自体が枚数集計やクイックチェックムービーへとシームレスに繋がるような、データオンラインの思想を、アニメ業界もそろそろ持つべきです。

 

 

 



calendar

S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 
<< July 2020 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM