記事の目次

    みなさんこんにちは。先日、GitHubがMicrosoftに買収されるという大ニュースが世界を駆け巡りました。ちょうど前回でもご紹介したようにGitHub上では多くのオープンソースソフトウェア（OSS）が公開され、世界中のプログラマから親しまれています。そのサービスがMicrosoft に買収されるということで大きな衝撃が走っています。Microsoftと言えば昔のイケイケだったときはそれはそれは各方面に............と、昔話が長くなりそうなので止めますが最近は丸くなってOSSに対しても共存路線を取っているので、GitHubがMicrosoftに買収されることでどのような変化が起こるのかは興味半分、恐ろしさ半分で今後も注視していきたいと思います。

    TEXT_痴山紘史 / Hiroshi Chiyama（日本CGサービス）
    EDIT＿尾形美幸 / Miyuki Ogata（CGWORLD）

    まずは先人の知恵を拝借

    さて、私が好き勝手に技術情報をご紹介する本連載は、今回から本格的な内容に入っていきます。前回の予告通り、今回はVisual Effects Society（VES）のTechnology CommitteeがVFX Reference Platformで策定している最新バージョン、CY2018環境を使えるようにします。この記事を読めば世界のVFX会社が導入している環境を我々の手元につくることができます。

    ところで前回も少し触れましたが、CY2019 DRAFTが公開されています。こちらはまだDRAFTですし、PySide（Qt for Python）（※）の変更がメインのようなので、CY2018に対応できればCY2019への移行も比較的簡単にできるのではないかとおもいます。正式なアナウンスが行われて必要になったら対応を考えましょう。もちろん「早速環境つくったぜヒャッハー！！」という人のタレコミは大歓迎です :-)

    ※　PySideは衣替えをしてQt for Pythonというブランドになるというアナウンスがありました。プログラマとして心配なのは、またモジュール名が変わるの！？また互換性を考えないといけないの！？というところですが、モジュール名はPySide2のままになるようです。これはとても助かります。

    ............とは言っても、自前で一から環境を構築するのはものすっっっっっごく大変なことです。皆さんの会社で使われているLinuxマシンがCYなんちゃら準拠でなんちゃらみたいな話になっていたら、システム管理者は本当にものすごく、ものすごーーーく苦労をして環境をつくったんだと思って感謝しながら飴ちゃんのひとつでもあげてください。

    一から環境構築をすると紙面がいくらあっても足りないので、まずは先人の知恵を拝借してCY2018環境を用意してみます。そして、事前にお詫びをしておくのですが今回の記事は分量の関係でLinuxや使用するツールの説明などをかなり省略しています。多分、全部解説をしているとそれだけで数回費やすことになってしまって話が進まなくなってしまうのですみません............。

    CY2018の概要確認

    まずはCY2018の概要を確認してみます。下図はVESのWebサイト内にある表をキャプチャしたものです。

    ▲VFX Reference Platformより引用


    リストアップされているライブラリは「VFX関連のツールであればよく使うよね」というものばかりです。いくつか注釈がついているので見てみましょう。gccには以下のような注釈があります。

    Note - gcc 6

    UPDATED November 26th 2017 - CY2018 changed from gcc 5 to gcc 6 due to integration issues discovered with the older version.

    Redhat/CentOS systems can obtain gcc 6.3.1 by installing Redhat DTS 6.1.

    Since gcc 5.1, libstdc++ introduced a new library ABI that includes new implementations of std::string and std::list. In order to maintain backwards compatibility the old implementations are still supported in parallel with the new ones. The choice of implementation is made using the _GLIBCXX_USE_CXX11_ABI macro, and the VFX Reference Platform is still using the older option so the compiler setting should be _GLIBCXX_USE_CXX11_ABI=0. The Platform will move to the newer implementations in a future year once the major Linux distributions have made the transition. RHEL/CentOS 7 and Redhat DTS still use the original implementations by default.

    引用元：VFX Reference Platform

    2017年9月27日更新 - CY2018では古いバージョンで見つかった問題に対応するためにgcc 5からgcc 6に変更した。

    Redhat/CentOSシステムでは、Redhat DTS6.1をインストールすることでgcc6.3.1を使用することができる。

    （以下、後方互換性と今後の対応に関する注釈）

    引用元：VFX Reference Platform

    ふむふむ。DTS 6.1をインストールすればいいようです。ソースコードからインストールしなくていいのは助かります。ここまでわかればgoogle先生に教えを乞うことで何とかなりそうです。もうひとつ、Qtにも注釈がついています。

    Note - Qt modifications

    The major change for CY2016 was a move to Qt 5 which required a port of PySide and modifications to vanilla Qt. In November 2015 CY2016 version of Qt was upped from 5.5.x to 5.6.x with agreement from the community that it was preferable to align with a Long Term Support release. In May 2016 it was updated again to 5.6.1 to incorporate some critical bug fixes.

    These modifications are required to avoid the introduction of functional UI regressions impacting DCC tools and consist only of backported bug fixes and critical changes that have not yet been accepted into the mainline Qt distribution. The need for these modifications is not new, currently some software vendors ship their own differently modified Qt so CY2016 represented a significant step forward with the goal of all software vendors sharing an identically modified Qt. We are working with the Qt Company to eliminate the need for these modifications entirely in a future release, potentially as soon as CY2019.

    These Qt 5.6 modifications are available on Github from these forks of qtbase, qtx11extras and qtdeclarative. These modifications to Qt 5.6.1 should be used by anyone who wishes to build Qt applications against the Platforms from CY2016 through to CY2018.

    引用元：VFX Reference Platform

    最後の段落内の一文がとても大事です。

    これらのQtの変更はGithubにあるqtbase、 qtx11extras、qtdeclarativeの fork版として取得できます。

    引用元：VFX Reference Platform

    オリジナル版を使わず、一部差し換えて使いなさいと。この情報を知らないとハマるやつです。あぶないあぶない............。そしてリンク先を辿るとautodesk-forksとなっています。はい。天下のAutodesk様もGithubにリポジトリを公開しています。ほかのリポジトリも色々気になるものが並んでいます。が、ここでよそ見していると戻って来れなくなるので見ないようにしておきます（涙）。

    さて、必要な情報もそろったことですし環境をつくってみたいところなのですが、前述の通り一から環境をつくるのはものすごく大変です。この記事を執筆した時点（2018年6月上旬）ではCY2018はまだ本格的に普及していないようでGithubなどでもあまり情報がないです。CY2016環境を構築するためのヒントはいくつか見つかります。がんばって自力で環境をつくるのであれば、先人のCY2016環境構築の成果を足がかりに行うのが良いでしょう。

    CY2018対応Dockerイメージを配布している人がいた！！

    そこで今回は以下で公開されているCY2018対応のDockerイメージを使用することにします。

    ptigas/vfxplatform

    ここで注意なのですが、ptigas/vfxplatformには作成済みイメージしかないのでどのような手順で環境をつくったのか知ることができません。もしかしたらバックドアやウイルスが仕込まれている可能性がないとは言えないですし、そうでなくても何かあった時に自分でメンテナンスすることができない可能性もあります。そのため、業務で使うのであれば、きちんとした手順で環境を構築するべきだと考えます。

    とは言ってもとりあえず手元で動かしてみることができるのは助かります。公開してくれているptigasさんに感謝しつつ使ってみましょう。

    Docker？

    ここでDockerについて簡単にご紹介をします。

    これまで環境の仮想化に使われてきたVMWareやVirtualbox、KVMといった仮想化ソフトウェアは馴染みがあるかとおもいます。これらの仮想化技術はホストになるOSの上で更に仮想化されたPCを動かし、その上でOSやアプリケーションを動かしています。そのため、本来動かしたいアプリケーションとは関係のないOSやサービスを動かす必要があるのでリソースを多く必要とします。

    それに対してDockerの採用しているコンテナ技術はホストになるOSに間借りをしてアプリケーションを動かすことができます。この時、実行したアプリケーションはDocker外の環境から隔離されていて、一見すると独立したコンピュータ上で動作しているように見えます。

    例えるなら従来の仮想化技術は家の中に更に家を建てて住んでいるのに対し、コンテナ技術では家の中を部屋で区切ってそこで生活しているイメージでしょうか。玄関や水回りといった部分を共有しているので、家の中に家を建てるよりも効率的に住むことができます。

    また、誰かが事前にパッケージ化した環境をDocker Hubに登録することで、誰でも入手することができるようになっています。今回使用するptigas/vfxplatformもそのうちのひとつです。

    より詳細な説明はほかの技術系サイトを参照してください。例えばさくらのナレッジでDocker入門という連載解説がされていますし、@ITでは超入門Dockerという連載があります。それ以外にも流行りの技術なので検索するとわかりやすいドキュメントがたくさん見つかります。

    Dockerのインストール

    CentOS7上にDockerのインストールを行います。このWebページを参照してそのまま実行すれば環境構築ができます。

    その前にOSの準備をします。 

    $ sudo yum -y update
$ sudo yum -y groupinstall "GNOME Desktop"
$ sudo yum -y install libX11-devel
$ sudo systemctl set-default graphical.target

    そしてDockerのインストール。 

    $ sudo yum install -y yum-utils device-mapper-persistent-data lvm2
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum -y install docker-ce
$ sudo systemctl start docker
$ sudo systemctl enable docker

    ptigas/vfxplatformを使って環境構築

    標準の設定ではコンテナ内のストレージ容量が足りなくなるようなので、設定を変更します。daemon.jsonを書いた後sudo systemctl restart dockerをします。 

    $ cat /etc/docker/daemon.json
{
"storage-driver": "devicemapper",
"storage-opts": [
"dm.basesize=50G"
]
}
$

    CY2018 Dockerイメージを取得 

    $ sudo docker pull ptigas/vfxplatform:CY2018

    CY2018環境の実行 

    $ sudo docker run --rm -ti ptigas/vfxplatform:CY2018 -e DISPLAY=$DISPLAY -v /tmp/.X11-unix/:/tmp/.X11-unix　bash

    Docker上のGUIアプリケーションを立ち上げるためにいくつかオプションを追加しています。この方法についてはDockerコンテナの中でGUIアプリケーションを起動させるを参考にさせていただきました。

    Qt Designerの起動 

    bash-4.2# /usr/local/Qt-5.6.1/bin/designer


    めでたくQt Designerを起動することができました！！

    え！？これだけ！？という感じです。公式のドキュメント通りに環境をつくって、標準で問題になる部分もGoogle先生に教えていただくことで対応できました。先人の努力の成果を利用できるって素晴らしいです！！

    ちなみに、自前で一からCY2018環境の構築をしようとすると1週間くらいはかかるのではないかとおもいます。情報収集、ひとつひとつビルド手順を確認してビルド、エラーになったらありとあらゆる手を尽くして原因究明と対応をするというのは本当に骨が折れる作業です。これが更にWindowsだったら一体どれだけかかるのか............考えたくもありません............。

    動作確認

    本当にCY2018に準拠しているか、確認をしてみます。

    動作確認をするにあたってライブラリ関連のパスが通っていないのでパスを通します。 

    bash-4.2# cat /etc/ld.so.conf.d/usr_local.conf
/usr/local/lib
bash-4.2#
bash-4.2# cat /etc/ld.so.conf.d/tbb.conf
/opt/intel/tbb2017_20170412oss/lib/intel64/gcc4.7
bash-4.2#
bash-4.2# ldconfig
bash-4.2#

    Qtの確認です。きちんとAutodeskのパッチが当たっているようです。 

    bash-4.2# cd /workdir/qt5/qtbase/
bash-4.2# git remote -v
origin	https://github.com/autodesk-forks/qtbase.git (fetch)
origin	https://github.com/autodesk-forks/qtbase.git (push)
bash-4.2#

    gccのバージョン 

    bash-4.2# gcc --version
gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    一番気になるPythonはいかがでしょうか。 

    bash-4.2# python
    
Python 2.7.5 (default, Aug  4 2017, 00:39:18)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.version.version
'1.12.1'
>>> import PySide2
>>> PySide2.__version__
'2.0.0~alpha0'
>>>

    Pythonがgcc5.3.1でビルドされていないようですが、NumPyやPySide2はドキュメントに書かれているバージョンと同じようです。Pythonは自前ビルドしないものなんでしょうかね？

    OpenVDBはインストールされておらず、/workdir/openvdbディレクトリ以下にバイナリがあるようです。必要に応じてインストールをするか、パスを通せば良さそうです。今回は一時的に有効にしてみます。 

    bash-4.2# LD_LIBRARY_PATH=/workdir/openvdb;python
>>> import sys
>>> sys.path.append('/workdir/openvdb')
>>> import pyopenvdb as vdb
__main__:1: RuntimeWarning: to-Python converter for std::shared_ptr, 4u>, 5u> > > > > already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for std::shared_ptr, 4u>, 5u> > > > > already registered; second conversion method ignored.
__main__:1: RuntimeWarning: to-Python converter for std::shared_ptr, 3u>, 4u>, 5u> > > > > already registered; second conversion method ignored.
>>> cube = vdb.FloatGrid()
>>> cube.fill(min=(100, 100, 100), max=(199, 199, 199), value=1.0)
>>>

    pyopenvdbもいくつかWarningは出ていますが、動いているようです。

    大丈夫そうな感じがしますね。これでめでたくCY2018準拠の環境を手元につくることができました。いきなり世界の標準環境を手元につくることができるのも、公開していただけている先人の功績とそれを生かすことのできる環境をベースにしていることが大きいです。その威力を少しでも実感していただけたでしょうか？

    次回は一からCY2016環境をつくり、Pixar Animation StudiosのUSDが動作するところまでをやってみたい思います。現在、そのために鋭意がんばっているのでご期待ください。ただ、色々とハードルのある内容なので間に合わない可能性もあります。その際は別の内容をお送りします。



    第3回の公開は、2018年8月を予定しております。

    プロフィール

    • 痴山紘史
      日本CGサービス（JCGS） 代表
      大学卒業後、株式会社IMAGICA入社。放送局向けリアルタイムCGシステムの構築・運用に携わる。その後、株式会社リンクス・デジワークスにて映画・ゲームなどの映像制作に携わる。2010年独立、現職。映像制作プロダクション向けのパイプラインの開発と提供を行なっている。新人パパ。娘かわいい。
      @chiyama