包囲網から

アニメ制作事情の未来は、できるだけ簡潔にまとめると、

 

人件費の高騰

制作環境維持費の増大

高画質化の波

 

‥‥の3方向から包囲された状態と言えます。

 

ですから、数兆円の市場だ何だと壮大なロマンを語るよりも以前に、現場的には、包囲網から脱出して活路を見出すことが求められるでしょう。

 

単純に考えて、

 

人が絵を描いたり塗ったりするための人件費が上がり

人が作業するためのソフトウェアがサブスクリプションに移行して維持費が上がり

人が絵を描いたり塗ったりする絵の細かさ(クオリティ要求)が上がり

 

‥‥となるのに、

 

作業する物量(例えば枚数や人足)は以前と同じかそれ以上

 

‥‥だったら、どうやったって、破綻します。いわゆる深夜のテレビ枠の予算で収まるわけもなく、たとえ制作費が2倍になってもテレビはキツいんじゃないでしょうか。電卓を弾いてみれば、誰でもわかることです。

 

上述の3要素に当てはめると、

 

作業報酬がアップしなければ、細かい絵柄なんてとてもじゃないが描けない

作業環境が更新されなければ、いくら作業費を貰えてもマシンの性能不足

絵のクオリティがアップしなければ、作業環境と報酬をアップしても見合う価値がない

 

‥‥という抜け出せない負のループに突入します。どれかだけを改善して‥‥なんて無理です。

 

じゃあ、どこにしわ寄せがいくか‥‥というと、そっくりそのまま、3要素に反映して

 

人件費を据え置きか

作業環境をアップデートせずに切り詰めるか

高画質化を諦めるか

 

‥‥となります。

 

このままの感じでいくと、3要素全て据え置き‥‥なんていう未来もありそうです。つまり、未来と決別して過去の世界のまま生きることを選ぶ‥‥ということです。

 

でもそれで、アニメ制作の将来は成り立つでしょうか。

 

 

 

簡単に答えや解決方法が導き出せる問いではないです。だから、

 

目を背けるのか

直視するのか

 

‥‥は、まさに当人の生き方そのもの、制作集団の意思決定そのものです。

 

 

 

今回は「前回」のように、尻馬に乗るのは困難かと思われます。動きが激しすぎて振り落とされます。日和っていたら、ごっそり淘汰された‥‥なんてことも起こり得ます。

 

だって、社会的な立場ゆえの人件費の問題や、サブスクリプションや、世界規模の映像品質アップデートが、同時多発で押し寄せるのですヨ。何度も書くけど、かなりキツいです。フィルム撮影台とセルがコンピュータへと移り変わった2005年前後の状況とは全く違います。同じだと思ってたら、認識・分析不足も甚だしい。

 

人間は、「自分だけは死なない」と思う生き物らしいです。

 

今回の「地盤シフト」で、いつもの正常性バイアスに委ねちゃうか否か‥‥は、もう、本人次第の危機管理能力としかいいようがなく、結果、生き残った人間で新しい世界を築いていくようにも予感します。

 

 


604800

Mac版のESTKはひっそりと提供が終了しており、昔のフォルダから移植して使っている状態です。

 

去年の終わり頃に、ESTKでアラートが出て動作しないトラブルがありましたが、私は最近まで対処しないままでした。絵を描く方がメインになって、ESTKは使う機会が減っていたので。

 

ESTKのappのパッケージを掘っていって「604800000」を「604800」に書き換えれば終了‥‥なのですが(説明を端折ってスミマセン。詳細はネットで検索してください。)、あくまで当座ローカルにあるESTK.appが書き換わっただけで、他の環境でも同じことをせねばなりません。

 

う〜ん。覚えてられない。階層も深いし。

 

なので、さくっとスクリプト。AppleScriptで動作する「6048自動書き換えスクリプト」です。このスクリプトをクラウドに保存しておいて、未処置のESTKと遭遇した場合に実行すれば、どこにいても解決できます。

 

 

tell application "Finder"

    set estk to choose file with prompt "ExtendScript Toolkit.appを指定してください"

    if (name of estk) is not "ExtendScript Toolkit.app" then

        beep

        return false

    end if

    set targetFile to (estk as Unicode text) & "Contents:SharedSupport:Required:cdic:11BTBackend.jsx"

end tell

do shell script "sed -i'-bak' -e 's/604800000/604800/' " & (quoted form of POSIX path of targetFile)

 

 

最後の1行はAppleScriptというよりは、sed。

 

最後の1行が肝心の部分です。それより前はESTKを指定するまでの前置きです。

 

sedは初めて使ってみましたが、便利ですネ。

 

一応バックアップを取った後で書き換えています。バックアップがiオプションでできるのも便利ですネ。AppleScriptでは全部自分でサブルーチンを作らねばならんスから。

 

AppleScriptは、シェルコマンドも実行できるし、Adobeのスクリプトも実行できるので、今でも現役です。今から大掛かりな新しい何かをAppleScriptで作ろうとは思いませんが、文房具のテープやカッターくらいの気持ちで気軽に使えるのが今でも現役の理由です。

 

 

 

 


CS問題

アニメ業界のAdobe製品普及率は高いものの、現在リアルタイムで支払っている額はCCの普及率の低さから見て、あまり多くない‥‥かも知れませんよネ。ゆえに、アニメ業界のAdobeへの発言力も相応に低い‥‥と言わざる得ないとも思えます。

 

最近Adobeの買収劇があったようで、「Adobeにこれでまた縛られ続ける」‥‥と言っても、そもそもAdobeにソフトウェアの対価を支払ったのはいつ? 現在CCのサブスクリプション費用を支払い続けているのなら話もわかりますが、今でもCS5〜6止まりの人々まで「Adobeの支配が」とか言うのは、便乗に過ぎないか?‥‥と思います。

 

一度製品を買ったら、メンテナンスやアップデートは永遠に無償で受けられる‥‥なんて、あり得ません。OSのバージョン更新はセキュリティ対策面で必須になりますが、CS6が未来のOSに必ず完全に動作するなんて保証はどこにもありません。

 

修正とアップデートは無償??? ‥‥そんなことしたら、そこらじゅうのアニメ作品はDVD/BDリテークの嵐でしょう。

 

 

 

未来、アニメ業界全体はCS6から、CCに移行できるのでしょうか。

 

西陣織は以前フロッピーディスク問題があったようですが、今は何と、SDカードに乗り換えたとの記事を目にしました。リムーバブルディスク基準なのが何とも‥‥ではありますが、SDカードの容量はフロッピーとは段違いですし当分は生産が続けられるでしょうから、まずはひと安心でしょうネ。いまどきだったら、サーバでデータを管理‥‥って言っても、誰がそのサーバの面倒見るのか、コストは?‥‥と考えれば、SDカードというメディアを選択したことは、実は案外手堅いのかも知れませんネ。バックアップを取る手間と時間も維持費も、フロッピーよりは雲泥の差でしょう。

 

話を戻して、アニメ業界。

 

アニメ業界の場合は、フロッピー問題ならぬ、CS問題と言えましょう。

 

CS6を使い続けて何年もソフトウェア更新の対価を支払ってこなかった作業集団が、いきなり全作業者アカウント分のCCのサブスクリプション費用を捻出できるようになるのでしょうか。‥‥相当、危ない感じはします。

 

 

 

私はね‥‥。以前にも書きましたが、「昭和の作り方」の「引き際」だと思うんですよ。色々な面で。

 

引き際‥‥と言っても、昭和から継承し続けたメインユニットA、B、C(仮に)を、新しい時代に合わせて、一気に入れ替えるのは、さすがにリスキーでしょう。ですから、段階的に「A、NewB、C」「A、NewB、NewC」「NewA、NewB、NewC」と入れ替えて「体質を馴らす」ことも必要だと感じます。それこそ5〜10ヵ年計画であっても、です。

 

古い昭和時代の方法論は、さすがに耐用年数を経過して、交換が必要です。今はもう、テレビを16ミリフィルムで作る時代ではないのですから。

 

今後、人件費の高騰は免れませんよね。加えてAdobe CS/CCだけでなく色々なソフトウェアがサブスクリプションに移行し始めています。ぶっちゃけ、アニメ本編の制作費が向上しようと、現在の大所帯=昭和平成の大所帯を引きずったままでは、差し引きゼロどころかマイナスに転じるでしょう。

 

 

CS6、そしてRetas。

 

アニメ業界のコスト抑制に多大な貢献をしてきたソフトウェアが、そろそろ終わりを迎えようとしている今、それでもなお、CS6とRetasを使い続けるのか。

 

Adobe CCを使うにしても、どのような導入の方法があるのか。他のソフトウェアの選択肢はあるのか。自分たちの欲するクオリティを実現するための、コスト効果の高い方法論とはいかなるものか。

 

そもそも、自分ら映像制作集団が成し得たい到達点とは、現時点でどのようなものなのか。どれほどリアルに見極められているか。

 

4K時代にも生き残っていける品質ののびしろはあるか。

 

アニメ制作現場各々の未来を占う選択は、各現場の主導者に委ねられています。

 

 


オブジェクト指向といえば

前回、アニメ制作はクラスベースのオブジェクト指向だ‥‥と書きましたが、実は私、クラスベースに限界を感じております。プロトタイプベースのオブジェクト指向に移行したいと考えています。

 

なぜかというと、クラスベースの「静的な型」で考える方法が、未来のアニメ制作にあまり向かないと思っているからです。

 

Wikipediaからの引用。私が感じているクラスベースの限界を代弁してくれています。

 

 

クラス = 構造化されたデータ + それに所属するメソッド、という考え方はプログラムの整理に劇的な威力を発揮する。しかし、全てがクラスベースであるという前提は時に物事を複雑化してしまう。

 

問題となるのはクラスが静的な構造と結びついているという点である。

 

例えばメソッドが必ず何らかのクラスに所属するという前提は強すぎる場合がある。クラスベースでは委譲や代理(プロキシ)によって動作にバリエーションを与えるが、初めからバリエーションをもったインスタンスを作成できればそのような機構は必要ない。

 

 

レイアウトがあって、原画があって、動画があって‥‥という決め型では収まらない、もっと広く自由な組み合わせで、未来のアニメは制作可能と考えています。そして、それはカットごとに多くのバリエーションを許容します。‥‥現在のアニメ制作の常識とは大きくかけ離れた思想ですが‥‥ネ。

 

オブジェクト指向を「目的ではなく、手段」として活用したいのです。クラスベースに羽交い締めにされるのを、何とか抜け出したいです。

 

ただ私、頭が結構クラスベースに染まっていまして、なかなかプロトタイプベースのなんたるかを理解できておりません。

 

そうしたことも踏まえて、似たような意志とビジョンを持つ人々と、新しい共同体を形成できたらな‥‥とは思うておるのです。

 

 


配列、オブジェクト指向

私は昔、「レイヤー」という考えに馴染めず、Photoshopを仕事で使い始めて半年くらいはレイヤーを使っていませんでした。プレステのゲーム攻殻のOPで、素子の周辺に火花が飛び散るカットがありますが、あれはAnimoから出力した連番画像ファイルに直描き(レイヤーとか使わずに)でエフェクトを描き足しました。

 

まあ、後になって考えれば、レイヤーを使わない分、効率的だったとも言えますが、頭が固かったとも思います。現在、レイヤーを使わずにPhotoshopを使うなんて、普通に考えてありえません。

 

‥‥そもそもアニメ制作ではAセルBセルと素材を重ねて絵を作るのですから、なぜ自分が馴染めなかったのか、考えてみると「レイヤーという用語に呑まれていた」とさえ思えます。我ながら。

 

1996年当時の私はコンピュータのコの時も知らない人間で、Photoshopが起動している画面の前に座れば「自分の扱える機能」だけは使えてましたが、Quadra650の電源の入れかた・落とし方すら知らず、当時同じ作業部屋にいたねこまたやさん(原画でもあり演出でもありデザイナーでもありプログラマでもある)に毎朝電源をいれてもらっていたほどの未開人でした。そんな人間なので、「レイヤー」という前世紀のアニメ現場では聞き慣れない言葉に恐れおののいたのも無理からぬことでしょう。

 

 

‥‥で、「配列」。

 

プログラムを覚え始めて、一番最初に「なんだか難しげ」に思えたのが、配列です。特に「連想配列」なんて言葉を聞くと、いかにも難しそうで、妙に怖気付いたものです。

 

現在、なぜ「配列」が難しそうに思えたのか、自分自身、実はあまりよくわかっていないのですが、「配列という考え方を、改めて、自分の思考の中で明確化する」のが「難しいと錯覚した原因」かなと思います。

 

配列って、日常、そこらじゅうにゴロゴロ転がっている、ありきたりなものです。

 

冷蔵庫の中身=[卵、鶏肉、豚肉、キャベツ、にんじん、牛乳]

6話のカット番号一覧=[1,2,3,4,5,6,7a,7b,8,9,10,11...]

自分の趣向=[音楽:ロック、絵画:象徴派、飲料:カルピスソーダ、酒:氷結]

 

‥‥と、現実世界にありふれています。要は、0個以上の何らかの要素の集合体を、「配列」と「もったいぶって」呼ぶのです。手の中に握りしめたコインも配列になりますし、「から=空」という0個だって配列たり得ます。冷蔵庫は中身が空っぽでも冷蔵庫ですもんネ。

 

ちなみに「自分の趣向」という配列は「連想配列」で、配列の各要素にラベル・見出しがついたものです。連想配列なんて言葉は難しげですが、ぶっちゃけ大したことはなく、ごく日常で考えているようなことです。

 

アニメ制作現場は、それこそ隅から隅まで配列の塊のようなものです。

 

制作会社が制作中の作品群=作品の配列があり、作品の中に話数やシーンという配列があり、話数の中にはカット番号という配列があり、カット番号〜カットの中には作業工程という配列があり、作画という作業工程の中には作業担当者という配列、AセルBセルという素材の配列、枚数の配列など、挙げればきりがないほど配列だらけです。

 

日頃、私らが理解して取り扱っているものを、わざわざコンピュータ用語にすると、配列とか連想配列とかアレイとかハッシュとかになるだけです。言葉の聞き慣れなさに呑まれがちですが、意味していることは難しくはなく、むしろ誰でも合点がいくことです。

 

前回書いた「カット番号」も、配列という考えで捉えれば、「作品名、話数、カット番号」という要素によって構成されていることは、アニメ業界のスタッフならば誰でも理解できるでしょう。作品「アニメの日常」作品略号「an」、話数「6」、カット「20」なら以下のように配列が構成されます。

 

カット名の配列要素
作品略号 シーン・パート・話数 カット番号
an 06 020

 

何も難しいことはないです。「配列」という使い慣れない言葉以外は。

 

 

そして、「オブジェクト指向」。プログラムを習得する初歩段階から次へ進む際のハードルとも言えます。まず、なにより、言葉が一層、難しげ‥‥ですよネ。

 

でも実は全然難しいことではないです。やはり「言葉の魔力」に呑まれているだけです。

 

特にアニメ制作現場でアニメを作っているスタッフなら、誰でもオブジェクト指向を実践しています。

 

それは「カット袋」です。

 

制作現場で1カット単位で制作を開始する際に、いちいち1カットについて、まっさらな状態から定義を始めるでしょうか? ‥‥そんな非効率なことはしていませんよネ。カット袋が示す通り、

 

カットの構成

作品名

話数

カット番号

レイアウト

レイアウトチェック

原画

原画チェック

動画

動画チェック

動画枚数

美術

美術チェック

兼用素材の有無

仕上げ

仕上げ枚数

指定

仕上げ検査

撮影

etc...

 

‥‥のように、あらかじめ定義した「決め型」を作っておいて、そこから各カットの作業を開始しますよネ。それこそがクラスベースのオブジェクト指向です。

 

作業の1カットごと、カットの構成要素はなんぞや、カットの作業工程とはいかなるものか、‥‥なんて定義していたらきりがないです。ゆえに、カットの定型をあらかじめ作っておいて、その型から新しいカットをどんどん生成していきます。

 

アニメ制作現場で作業をしている人は、たとえ無自覚であっても、配列にもオブジェクト指向にも関係した作業をしているわけです。

 

これはカットだけでなく、作品全体にも言えて、テレビシリーズを作る際の「型」はある程度決まっていますから、例えば「テレビシリーズの定義」に基づいてオブジェクト指向で制作している‥‥とも言えるわけです。

 

 

実は私は20年前、オブジェクト指向というものがどうにもわからなくて、プログラム独特の難しげな言い回しに惑わされて、理解が進まない時期がありました。オブジェクトで思考する利点が見えなかったのです。そもそも「オブジェクト」という概念がわかりませんでした。

 

しかし、ふと、アニメ制作現場のレイアウト用紙、タイムシート、そしてカット袋を見ると、すべて違うカット内容なのに、使う物品はすべて共通していることに「今更ながらに」気づきました。

 

決して、「Cut20専用のレイアウト用紙やタイムシート」ではなく、Cut1だろうが20だろうが145だろうが、すべて同じ用紙や袋を使って制作されます。

 

JavaScript風に表現すれば、

 

var theCut = new CutFolder("an_06_020");//新しくカットを生成する(=インスタンス)

theCut.addTimeSheet(24,3);//24fpsで3秒の尺のタイムシートを追加する(=メソッド)

theCut.users.genga="ezura";//カットの原画担当者を"ezura"に設定(=プロパティ)

//原画作業者をカット袋のプロパティとするか、カットに内包される「原画」クラスでインスタンスとするかは、実装の内容によります。

//1原2原が通常仕様となった現在は、インスタンスで扱ったほうが「融通」が利きますネ。

 

‥‥みたいに。

 

つまり、作品中のカットそれぞれは、「カット」という型を受け継いだ上で新規に作成されたものだと、明示的に気がつきました。全くの新規の作業形態を毎回作っているわけではないのです。

 

「身の回りのものは結構多くがオブジェクト指向の産物や行為なんだな‥‥。なぜ、気づかなかったのか‥‥」と思いました。

 

それを理解してからは、プログラムでのオブジェクト指向の使い方も加速しました。現実世界での効率的な取り回し方を、プログラムの内部で実践すれば良いんだ‥‥と。

 

 

 

コンピュータを扱って自分の役職として生きる人の中には、さもプログラムを難しいものであるかのように振舞って、門前払いするような人もいましょう。まあ、実際、簡単に説明できるものではないのは確かですし、話が噛み合わなくて面倒ということもありましょう。

 

ただ、そこで途切れたままでは、現場のコンピュータ活用は、いつまで経っても借り物のままです。

 

ちょっとコンピュータの深い話題になると、その人=現場の「デジタル相談役」を経由しないと話が一向に進まず、自由に現場の効率化を実践できないままで、本当に良いのでしょうか。相談役、ワルなイメージで言えば用心棒の助けがないと、ちょっとした弱みでも解決できない体質は、言い換えれば、用心棒に急所を握られている‥‥ということでもあります。

 

しかし、何よりも、まずは自分のコンピュータに対する知識の低さが原因なのです。キンタマ(失敬)を握られるのは、握られるままに放置している当人も悪いのです。

 

制作現場に「デジタル相談役」「デジタル用心棒」がいる時点で、その現場はコンピュータ活用のスキルが低く、「デジタル」は「非正規」のままの扱いです。‥‥だってさ、正規軍に用心棒なんていないでしょ? 正規軍に存在するのは例えば「戦闘工兵」ですヨ。

 

他人事ではなく自分たちで状況を解決するために、色々と試行錯誤し研究し実践するようになれば、いつしか「デジタル」なんて言葉は使わなくなります。

 

全員が全員詳しい‥‥と言うのは無理でしょうが、だからと言って、フロアのほぼ全員がプログラムに疎いのも、マズいです。コンピュータに無知な集団で本当に良いのか?‥‥ということです。

 

 

 

私の望むアニメ制作共同体の未来は、プランテーションと農奴たちではありません。

 

作業集団が独自のシステムを持ち、独自の作業形態で創作し、結果物で流通するエコシステムです。

 

Retasの次は何が主流のソフトになるか?‥‥なんて考えるのではなく、作業結果物の流通における標準仕様を決めて、各自・各集団が自らの特性を最大限活かせる自由な作業形態をいかに選択できるかを考えるべきです。

 

新しいソフトウェアの束縛に、また今度も、業界全体で自らハマりにいくのでしょうか。

 

どんなソフトウェアを使っていようが、受け渡しの規則を決めて条件を満たしていればいいじゃん。

 

必要なのはソフトウェアの確定ではなく、特定のソフトウェアに依存しない、MIDIのような標準規格の制定です。

 

どんなソフトを使うかを議論する‥‥なんて、島国根性丸出しで冴えないオっさんの集まりなのか?‥‥と言っても言い過ぎじゃないですヨ。どうせシンポジウムを開くのなら、もっと根本的な内容=標準流通仕様について話せば良いのにネ。

 

 

 


Cの習慣

思うに、コンピュータがどんどん制作現場に入るようになって、コンピュータありきで制作が運用されるようになると、当然のことながら、コンピュータの知識や経験が現場にも常時必要となります。コンピュータを総称して「デジタル」と呼んでいるようでは、まだ「他人事」「聞きかじり」のレベルであって、実際にコンピュータでスクリプトやプログラム、ネットワークを活用したシステムを自分たちで作ったり運用したりすると、「デジタル」なんて言葉は紛らわしくて面倒なので使わないようになります。最近「デジタルソフト」なんて言葉を目にしましたが、思うに、現場が「デジタル」という言葉を自然と使わなくなる日が来たら、コンピュータが「根についた」証かも知れませんネ。

 

コンピュータの、特にプログラムを知らない現場の人間だけで、コンピュータ運用の規則を作ると、これまた面倒なことになります。‥‥実は、私が歩んできた道のりでもあり、「現場の人間にプログラムを知る人がいないことの不利益」は、身に沁みて実感しています。

 

かといって、制作現場を全く知らないプログラマー畑の人をいきなり呼んでも、制作現場にはありとあらゆる事情がひしめいていますから、融通が利かないのも困りものです。プログラムの都合のために、制作運用がやり辛くなるのは本末転倒ですもんネ。

 

つまり、「コンピュータ導入と制作運用の狭間で、双方が譲歩できる着地点」を見つけ出すことになります。

 

 

例えば、「カット」。

 

「カット」とは、アニメの本編における、何らかの被写体を捉えた映像の切り替わり(アニメは絵ですが、便宜上「被写体」と表現しておきます)の1単位を指します。もともとは、カメラの1ショットから部分的にカット=切り出した映像を紡いで編集したことに因ると思いますが、アニメの場合はショットという概念は希薄なので、どちらかというとマンガのコマ割りに近いでしょう。

 

まあ、由来はともかく、アニメ制作現場では「カット何々」という感じで、作業単位は「カット単位」になります。表記は、以下のように、

 

Cut 101

c101

 

と記述されます。

 

私は20年以上前、プログラムを習得するまでは、何の疑いもなく、カット番号を表記するときは、「C」を添字として使っていました。しかし、プログラムを覚えて、実際のアニメ制作作業に用いるようになると、「C」の必要性に疑問を抱くようになりました。

 

例えば、作品「アニメの日常=略号an」、話数「6話」、「カット20」を、アニメ業界の慣習で文字列として表記すると、

 

an#06c020

 

‥‥になりがちです。セル&フィルム時代から、「話数は#、カットはc」で書き表していたからです。

 

さて、これをプログラムで処理する際に、作品略号と話数とカット番号を抽出する時、結構面倒なことになります。例えば、JavaScriptですと、

 

//作品略号の抽出

"an#06c020".split("#")[0];

 

//話数の抽出

"an#06c020".split("#")[1].split("c")[0];

 

//カット番号の抽出

"an#06c020".split("#")[1].split("c")[1];

 

‥‥というようになります。

 

作品名(略号)、話数、カット番号を取得するのに、#やcを使って文字列を分解して抽出しています。

 

「全然面倒じゃないじゃん。このくらいやってよ。」と思う人もいるでしょうが、‥‥う〜ん、読みが甘いなあ。テレビのことしか考えてない。アニメには色々な公開形態がありますよネ。

 

劇場作品の場合、話数ではなく、シーンやパートで区切ることがありますから、例えば、劇場作品「アニメの日常=略号anm」、「Cパート」、「カット20」を文字列化すると、

 

anm#cc020

 

‥‥となり、CパートのCと、カット番号の添字のCが並んでしまいます。人間の目視でもややこしいですし、先ほどのプログラムでも問題が生じます。「cで区切る方法が通用しなく」なり、作品の状況に合わせてプログラムをいちいち変更し、使用者に再配布しなければなりません。

 

「c」という「あちらこちらで使われそうな文字」を使って文字列を分割すること自体が危ういです。もし作品略号に「c」が使われていたらアウトです。

 

そもそも‥‥

 

話数やカット番号に、#やcは必要??

 

‥‥ってことです。コンピュータの中まで持ち込む必要性は本当にあるでしょうか

 

なので、私らの作業班では10年以上前から、

 

作品名_話数・シーン・パート_カット番号

 

‥‥という基本規則を定めて運用しています。この方法ならば、

 

an_06_020

anm_c_020

ccc_c_020c

 

‥‥と、「区切り文字を除いたどんな文字でも」使用可能になります。‥‥まあ実は、OSのファイルシステム的にNGな文字は使えませんが、アニメ制作現場で用いる文字なら対応できます。実際、この方法で困ったことが全くありません。

 

アンダースコアで分解して、配列の第1要素は作品略号、第2要素は話数・シーン・パート、第3要素はカット番号という決まりを作れば、テレビだろうがPVだろうが劇場だろうがゲーム用ムービーだろうが対応できます。もし仮に「Cパートのシーン2」なんていう細切れが発生するような作品でも「an_c-2_020」と記述すれば対応可能です。

 

こうした文字列を要素で区切る文字を、デリミタとかセパレータと呼びます。「カット名やファイル名は単に名前であるに留まらず、基本情報を直列で文字連結して表したものだ」と考えれば、自ずと、デリミタで文字列を連結する発想に繋がります。

 

つまり、

 

プログラムの経験がないと、区切り文字と添字を混同して運用しがち

 

‥‥になります。作業カットの名前の付け方一つで、現場のコンピュータ活用スキルがバレてしまうわけです。

 

これは知識不足を非難しているわけではなく、前述した通り、私もプログラムを習得して使うようになるまでは「無自覚」でしたので、マズいのは「プログラムを扱える人間が存在しない現場で、コンピュータの運用を決めてしまう」ことです。

 

プログラムでの処理を知らないのに、なぜファイル名やカット番号の命名規則が決められるんですか?‥‥という話です。

 

プログラムを度外視して、単に作業習慣を文字列に置き換えるだけなら、作品の都度の都合に合わせて、延々と手作業でファイル名を打ち替えていくしかありません。さらには、大量の情報処理も全部エクセルで手書きで更新していくしかありません。プロジェクトマネージメント(PM)のソリューションで制作運用と進捗管理を支援‥‥なんて夢のまた夢です。

 

カット番号の「c」に特別な情報(バージョンや種別などのメタ情報)があるのならともかく、単に慣習で「c」をつけているだけなら、そんな慣習をわざわざ無理してまでコンピュータに持ち込む必要はあるでしょうか。

 

コンピュータを導入するときに、まさかカット番号を2進法や16進法に変えろ!‥‥という話ではないのです。

 

 

なので、現場の人間は、とっとと、プログラムを覚えてしまいましょ。

 

プログラマーとして飯を食うレベルになろうというわけではないのです。例えば、5000個のファイル名を一部変更するとか、EDLのテキストファイルを読み取って、編集点を抽出してAfter Effectsのキーフレームに変換するなんてことは、1〜3年のうちにできるようになります。

 

今のアニメ制作現場の弱点は、作業者がプログラムにあまりにも弱く、ソフトウェアをどう使うかだけに偏り過ぎていることです。プログラムに関しては、与えてもらうだけで、自分からは作れない。

 

誰かに頼り切るのではなく、自分でも多少のプログラムを作れるようになる。‥‥それがまず何よりも必要です。これから先、コンピュータを現場でもっと有効に機能させたいのなら‥‥です。コンピュータを知らずして、ソフトウェアのTipsだけ覚えて、どうやって、根本から効率的な制作運用が可能になりましょうか。

 

MacもWinも、色々なスクリプト・プログラムの入門があります。AdobeのPhotoshopやAfter Effectsを使っているのなら、JavaScriptくらいから始めるのも良いですよネ。

 

 

 


筆圧と肩こり

今から20年近く前、アニメ制作現場にいわゆる「板タブ」が導入され始めた時に、筆圧の強い人が何人も肩を痛めたことがありました。共通していたのは、大きめの板タブを使用し、かつ、筆圧設定が標準のままかやや強めにしてあることでした。

 

考えてみれば理由は歴然です。強く力を込めて、腕を大きく振る動作を続けていれば、肩に負担がかかるのは当然の結果とも言えます。特に板タブは、鉛筆や筆と違って、どんなに力を込めても芯先が折れることはないので、野放図に力を込めがちになります。

 

*最近のProcreateは、フリーハンドで円や多角形を描くツールが実装されたので、こうした模式図を描くのは超ラクです。変形ツールもかなり強力になりました。

 

 

大きなタブレットは、パッと見た印象だと「大きくて書きやすそうでリッチ」に思えますが、実は絵を描くこと自体は必要最低限の大きさを確保してあれば十分で、タブレットの性能的には分解能のほうが重要です。

 

iPad Proは最大でも12.9インチで、液タブとしてみれば、最小限の大きさです。ぶっちゃけ、iOSのまま、16インチくらいのが欲しいですが、ないものねだりしてもしょうがないので、13インチでずっと描いていますが、それでも縦4フレームくらいの大判は普通にこなせます。ピンチインアウトのジェスチャは必須になりますけどネ。

 

私は、常用するProcreateにおいては、「線画を楽に描く」ために筆圧を軽くしています。

 

このくらい。

 

 

 

右上のポイントをもっと左によせれば、インクペンのような「触れたら染まる」ような書き味になりますが、私の場合はこの程度にしておいて、あとはペンのプリセットごとに反応を変えています。

 

「強弱が出にくいから」と筆圧を強くする(=反応を鈍感にする)のではなく、自分自身の筆圧を敏感に制御することで、常時軽い筆圧=体に負担のかからない状態で、絵を描き続けることができます。

 

設定次第で、鉛筆を使う時よりも弱い力で濃い線が描けるのは、液タブやiPadの大きな利点でしょう。

 

 

 

 

上の写真は、昨日変えたばかりのチップです。普段は金属が露出する前に気づくのですが、絵を描く方に忙しくて、「ゾゾッ」とした妙な感触でようやく気づきました。よく見ると、金属が露出したあと、しばらく描いていたのか、金属まで消耗していますネ。

 

液晶に損傷はないか‥‥というと、筆圧が低いおかげで特に傷はついていません。書き味向上フィルムを貼ってあることもあり、本体は無傷で異常なしです。もし、筆圧が強い描き方をしてたら、引っ掻き傷をつけていたかも知れません。

 

 

私はギターでも、ネックを握っちゃうんじゃなくて、親指の腹をネックの後ろに軽くあてて、指先をごく軽く指板に触れるようにしてフレーズを弾きます。強くネックを握っても強い音がでるわけじゃないので(どちらかというと気分の問題です)、あくまで指板を押さえる指は軽く、音の強弱はピックでコントロールします。ギターのセッティングは重要で、フレットのびびりがないキワキワまで(サスティンが失われないように)、弦高調整をします。

 

道具を使いこなすには、まず道具のセッティングを自分の使い方に最適化することですが、右も左もわからない頃は自分の体の負担でカバーしがちです。

 

絵を描いてて肩が凝るのは、多くの場合、筆圧の強さが原因ではないか‥‥と思いますので、まずは自分の筆圧を下げて体の負担を減らした上で、道具のセッティングを最適化するのが「プロ=職業として描き続ける秘訣」と言えます。

 

一見、手しか使っていないように見える絵描きとて、結局は体が資本‥‥ですもんネ。

 

筆圧を強いまま描いて「体を壊した」なんていうのは、本人の「体の使いかた」にも原因があります。年長で経験が豊富な人は、若年の人に「筆圧を軽くするアドバイス」をするのも役目の1つですヨ。

 

 


プロクリの上にも3年。

アニメ業界では、作画に使うソフトは、やれクリスタが良いとか、TVPだ、CACANiだと、賑やかですが、私はiPad Proを買ってから今まで3年間、ずっとProcreateです。

 

今日も原画をProcreateで描いてます。今の仕事が終わったら、今度はCO/KFアニメーションの原画作業にすぐに復帰します。もちろんレイアウトも共通してProcreateで描いてます。

 

Procreateはアレができない、コレができないと言う人もいますが、一体、どんな絵を描こうとしているのか。Procreateだと絵が描けない‥‥なんて言う人は、もともと絵があまり上手ではないのではないか‥‥とすら思います。

 

ストラトだと弾けるけど、レスポールだと弾けない‥‥とか言っちゃう人みたいに。

 

まあ、たしかに、Procreateにはクイックアクションレコーダー=QARはないです。でもさ、前後の絵は透明度でいくらでも透けさせられるんだから、動きは描けますよ。

 

どこかのツイートで見かけましたが、QARに頼りすぎると、QARがないと動きが描けない人になっちゃいますよネ。頭の中の「脳内QAR」を確立しておくと、アニメの作画だけでなく、実写や別ジャンルのCGでも、随分役に立ちますよ。編集の感覚の基礎にもなりますし。

 

動きの答え合わせがしたければ、After Effectsで線撮をすれば良いです。まあ、After Effectsを常備していない人も多いでしょうから、クリスタは月額1000円で安いし、All in Oneで使いやすいことはあるでしょうネ。GIFアニメのソフトでタイミングを操作して書き出すのも安く済む手です。

 

QARがなくても原画が描ける人は、Procreateのとことん画面が広く使えて(クリスタはツールが並んでて狭いのが弱点)、ジェスチャで様々な操作が可能な利点が活きると思います。

 

 

ただし、Procreateには1つ問題があって、4Kでの作画をする時に、SDRで8bitなのは線画なので良いとして、キャンバスサイズの限界が低いのが悩みの種です。もう少し正確に言えば、キャンバスサイズを広げると、どんどんレイヤー数が減る‥‥のが現バージョンの欠点です。

*2K以下の作品なら、よほどの大判でもない限り、もしくは何から何までレイヤーを分けておきたいとか思わない限り、レイヤー数が足りなくなることは防げます。

 

4Kサイズのアニメ制作ともなると、横2フレームのPANをかましただけで、いきなり8000ピクセルです。実際は10%の断ち切り(ペイントフレームとも呼ぶ)を追加するので、9000ピクセルくらいになります。

 

実写と比べてアニメが不利なのは、カメラを大きく振れば振るほど、素材のピクセル寸法が巨大になることです。反面、トラッキングやマスク抜きが極めて楽‥‥というか、実質不要なのは大きな利点ではあります。スタイビライズなんて全く不要で、そもそも逆にカメラを故意に揺らしたりするくらいですから。

 

話を戻して。

 

Procreateはピクセル寸法の増大に反比例して抱えられるレイヤー数がどんどん減っていきます。この上限はなんとかならないかな‥‥と性能改善に期待する日々です。

 

Procreateのレイヤー上限に対抗するため、以前から分割作画で凌いでいますが、やっぱり分割しないで描くのが一番楽だし見通しもしやすいです。

 

 

そこでPhotoshop。今度出るというiOSのフルバージョンPhotoshopは、そこそこ期待しています。Procreateのような軽快さまでは期待していませんが、デモを見る限り、結構エグいことまでできそうな予感です。「曲がる」と不評のiPad Pro 3型も、ようやく8コアのCPU、7コアのGPUの出番‥‥かも知れませんネ。

 

iPad Proに、プロクリ、クリスタ、そしてフル版Photoshopを揃えておけば、できることは掛け算で増えていきます。

 

そう言えば、「Project Gemini」も楽しみにしています。

 

 

 

‥‥思いだした。

 

Procreateから書き出したPSDファイルの「レイヤー名の文字化け」はなんとかしてほしいものです。ものすごく単純なUTFとかSJISなどの文字エンコードの不備だと思われますので、対応してくれる気になればすぐに対応できると思うんですけどネ‥‥。

 

今のところ、日本語(2バイト文字)を使わなければ文字化けしませんが、ラフは「Rough」でいいものの、「参考」「アタリ」「修正」は、Sample、Guide、Modefy、Adjust‥‥とか書く? いやまて‥‥、ラフはRoughで良いのかな? Draftとか?

 

実は、新しいアニメーション技術においては、用語を全て英語でも表せるように制定し始めています。日本語でしか表現できないのでは、今後、色々と限界があるので‥‥。

 

ちなみに、いわゆる「デジタル作画」を扱う際は、原画は「GENGA」、動画は「DOUGA」と命名して、「それが従来の作画スタイルであること」を明示しています。キーとかインビトウィーンとか言わずに、「かわいい=KAWAII」と同じようにそのまま英字にしちゃえば良い‥‥と考えてます。

 

 

 


iPad Pro 第3世代のその後。

iPad Pro 12.9の第1、第2、第3世代をそれぞれ「描き」作業の仕事で使い分けていますが、一番使いやすいのは私個人の実感だと「第2世代」です。残念ながら第3世代は、小型化やホームボタン廃止が、純粋に描く目的で邪魔になります。

 

第3世代は、見た目の小型化(薄さも含めて)のために、より一層カメラの出っ張りが強調されてしまい、何らかの対策を施さなければ、机の上に置いた時の傾きが気になります。以前の記事でも書いた通りです。しかも、本体が曲がる障害もあるらしく、傾き解消と強度強化のためにハードケースに収めると、1〜2世代よりも厚さが増してしまいます。

 

第1〜2世代に慣れてしまうと、ハードケースに入れた3型の厚みは、結構気になります。もちろん、普通に描けますが、たまにイラッとすることがあります。ハードケースに入れているので、ケースの角(=本体を挟みこむためのコの字の出っ張り)が手にあたるんですよネ‥‥。

 

描きにくいことはないです。至って普通に描けます。しかし、第1〜2世代の滑らかな手触りを知っていると、違和感を感じます。ハードケースに入れた第3世代は小指側の手の側面にいちいち当たるのがごく小さなストレスになります。だからと言ってケースに入れないと傾くので困ってしまいます。

 

第3世代はもっと描きやすくなっているか‥‥というと、「微妙」なのです。

 

 

そしてホームボタンの廃止。画面外からスワイプするとホームに戻れる‥‥と言いますが、私は百発百中(特にProcreate)で「1回目は画面のスクロール、2回目のやり直しでホームに戻れる」という動作になってしまい、結局4本指スワイプでホームに戻るようにしています。4本指スワイプなら1発でホームに戻れますが、それは第3世代だけでなく旧世代機も同じです。

*おそらく、書き味向上フィルムの貼っているのもタッチの誤動作の原因なんでしょうネ。書き味向上フィルムを貼ると、タッチ操作が明らかに鈍くなります。

 

例えば画像のアイコンが沢山並んでいる場合、そのアイコンを一覧する際のスワイプ動作に間違えられるんですよネ。ちゃんと画面外からスワイプしているのに、なぜか1回目は必ず画面のスワイプになって、やり直しの2回目にホームに戻れます。この動作がいちいち面倒です。

 

顔認証も、画面に顔が収まって(かつ、そこそこ明るい場所で)ないと機能しませんし、私は横置きで使うことが多いので、机に置いた手の指先でカメラを覆い隠してしまうこともあり、顔認証でのロック解除の利便性を今のところ感じません。ホームボタンの指紋認証で良いです。

 

12.9インチは、もともとデカいので、ホームボタン程度の面積削減は大して効果を感じないです。持ち運びに絶大な効果があるわけでもなし。

 

 

ついで‥‥ですが、いまのところ、UCB-Cのケーブルは太くて固いのが多いので、ケーブルの取り回しも以前より自由が利きません。ケーブルを挿したまま本体を移動すると、机の上の色んなものをなぎ倒します。実際に使ってみるとわかりますが、ケーブルの「R」〜曲線の半径が大振りになりやすい(=机の物品の隙間を縫うような配線が難しい)んですよネ。ケーブルの取り回しはLightningケーブルの方がやりやすいです。

 

でもまあ、ケーブルを外して使うのも良いかとは思います。ケーブルを外して使う習慣も必要かな‥‥と思ってます。以前、iPad Airを満充電状態=ケーブル挿しっぱなしで使ってたらバッテリーが膨らんで液晶画面が持ち上げられ破損し、1万円の修理代金を支払ったことがあります。

*「液晶画面の損傷」だと3万円くらい請求されるようですが、「バッテリーの膨張による液晶画面の浮き」はバッテリーの損傷=1万円の扱いになります。‥‥AppleのWebにはどこにも書いてませんけどネ。ちなみにバッテリーの膨張で画面が浮いてしまった場合、私の事例だと本体交換になりました。

 

 

 

とまあ、難点ばかり書きましたが、おそらく、絵を描く用途以外なら、第3世代の良さも活きるのでしょう。4K60pやHDR撮影が可能でカメラの性能は高いし、顔をトラッキングする機能ゆえにミー文字でFaceTimeで会話するのも楽しそうです。作画の資料として、例えば120〜240fpsで高速度撮影をして、動きの研究にも使えますネ。身近なところでは、液体(コーヒーカップのコーヒーとか)を撮影すると、フォルムがくっきりと撮影できて、原画の参考になります。

 

ただ、持ち運びに難点があるので(曲がるのはホントに勘弁してほしい。持ち運ぶの怖い。)、なんだか中途半端な製品になっちゃったな‥‥とは思います。持ち運びに不安があるようでは、屋外での色んな撮影もできないでしょうしネ。

 

第3世代ならではの高性能(=CPU, GPU)が活きるのは、iPad版のPhotoshopフル版を使う時だろうか‥‥と思いつつ、今のところは欠点のほうが目立つ第3世代。

 

といったわけで、2〜3ヶ月使ってみた今のところ、第3世代のiPad Pro 12.9は、同業の知人友人に勧め辛いのです。ウソはつけないス。

 

絵を描く「だけ」なら、第2世代がオススメでしょうかネ。第2世代は、第1世代のままで性能アップしているので、純粋に良いです。

 

 

第4世代が待ち遠しい‥‥とは、気が早いかな。

 

 


パスポート10年。

パスポートに2種類あるのを、最近まで知りませんでした。

 

日本のパスポートは、日の丸の赤をテーマにして、赤いパスポートだけだと思ってました。「5年は青で、10年が赤」と言われて、今さらながら気がつく次第。

 

なので、期限が曖昧な場合は、パスポートの表紙の色を思い出せば、大まかに期限切れか否かが判断できる‥‥みたいですよ。

 

私は生涯今まで、パスポートを使ったのは3回だけです。なので、ほとんど何も知識がなくて、前回使った日時も忘れて、てっきり期限が切れていると思ってたら、2024年までは使えるみたいで「面倒な手間と出費」がなくてちょっと安心しました。

 

思い起こせば、赤以外のパスポートを持ったことがないので、結局は10年パスポートしか持ったことがなかった‥‥のですネ。手続きに必要な金額の差額が、5年と10年で2倍になることはなく、割安なので、赤い10年パスポートをたまたま毎回取得したんでしょう。

 

 

昔よりは面倒や手続き時間が減ったとは聞きますが、戸籍の書類が必要だったり、管轄の都府県別の窓口に出向いたり、写真を自前で用意したり、意外に申請手続きと取得に1万円(12000円と16000円くらいだったはず)以上かかったりと、やっぱり段取りは面倒です。

 

ちなみに私は、記載の顔写真を、自前で無地のふすまの前で三脚を立てて自撮りして、高画質光沢紙に印刷して提出しました。実寸の寸法が規格を満たせば良い‥‥との事なので。

 

照明が窓外の自然光のみでクオリティにやや難があったのですが、Photoshopで光量不足を補ってレタッチしてプリントしたので、なんとか受理されました。「顔の寸法は頭頂からあごまで32mm〜36mm」との規格をキッチリPhotoshopで合わせて印刷したものの、「イマイチ、写りが悪い(=不鮮明)」みたいな小言は窓口で言われましたけどネ‥‥。今度申請するときは大人しく専用のソリューション(写真を撮るボックスとか)で処理しよう‥‥。

 

 

どうせパスポートがあるのだから、プライベートで使ってみたいとは思うものの、海外旅行をする時間など今はないですし、まずなによりも言葉の壁をブチ破る度胸がないです。行ってみたい国や都市や街や村はいっぱいあるんですけどネ。

 

 



calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
2425262728  
<< February 2019 >>

selected entries

categories

archives

profile

search this site.

others

mobile

qrcode

powered

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