3DCGソフトウェア
3DCGソフトウェアは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。
プリプロダクション(ストーリー/コンセプトアート/コンセプトモデリング/ストーリーボード/プレビズ/R&D)
映像素材作成(撮影/LiDARスキャン/フィルムスキャン/3Dトラッキング)
3Dスキャン/テクスチャスキャン (3D再構築/テクスチャ抽出/ライティング除去)
アセット制作(モデリング/UV展開/テクスチャリング/Surfacing/シェーダー作成/シェーダー割り当て/リギング/キャラクターセットアップ)
アセット配置(レイアウト)
動作付け(アニメーション/キャラクターFX/群集/エフェクト)
ポストアニメーション(ショットスカルプト)
画像化(ライティング/レンダリング)
映像素材の下処理(フィルムクリーンアップ/ワイヤーリムーバブル/ステレオフッテージ修正/ロトスコープ)
画像合成及び調整(ペイントフィックス/コンポジット/マットペインティング/ポストエフェクト/カラーグレーディング)
2D-3D変換、ポストプロダクション(コンフォーム/フィニッシング/エンコード/オーサリング)
の工程に分かれている。作業の基幹となり多くの工程の調整が行える統合型ソフトウェアの他に、個別の機能に特化したソフトウェアも存在する。モデリングが中心となっているソフトウェアは「モデラー」、レンダリングが中心となっているソフトウェアは「レンダラー」と呼ぶ。
各種工程における機能においては、破壊的なものと、非破壊的なものが存在する。非破壊的なものは過去の操作の修正がしやすく、パラメータにキーフレームやドリブンキー/IPOドライバを入れることでアニメーションさせることもできる。しかし、メモリやディスク容量を消費するため、メモリサイズの大きなものを扱ったり細かな編集を繰り返したりといったことは苦手である。互換性の問題もあるため、他のソフトウェアとのやりとりには破壊的な形式に直すことも多かったが、最近は非破壊的な交換形式というものが開発されてきている。
3次元CADソフトウェアについては「CAD」、3次元GISソフトウェアについては「地理情報システム」を、仮想地球儀については「仮想地球」を、3次元プラネタリウムソフトウェアについては「プラネタリウムソフトウェア」を参照。
3DCGが発案された当初は一部の用途にのみ用いられる技術であり、多くの処理能力に高価な高性能ワークステーションや専用のハードウェアが必要となることが多いために市場も小さく、ソフトウェアも高価であった。しかし、時代が進むにつれてコンピュータの性能が向上し、高性能なコンピュータが一般に普及することにより、3DCGの市場が拡大してソフトウェアの低価格化・高機能化が進んだ。
3DCGソフトウェアは、科学からエンターテイメント、純粋芸術までさまざまな用途に使われており、用途によって必要な機能、必要な品質、環境、納期などが異なるため、それに合わせて多くの種類が存在する。必要なレベルに達しているソフトウェアのことを「Production Ready」であると表現する。1つの用途を達成するために複数のソフトウェアが必要になることもあり、その場合にソフトウェア同士の連携が重要となる。
3DCGソフトウェアの主な用途としては、以下のものがある。
実写合成映像 (VFX)
CM・企業VP
ミュージック・ビデオ
ミュージック・ビデオ
パチンコ・パチスロ機のCG
3Dモーショングラフィックス(#モーショングラフィクス)
CM・企業VP
テレビ番組のオープニングCG/ジングルCG
テレビ番組のバーチャルセット(#バーチャルセット)
拡張現実 (AR)(#インタラクティブVR/拡張現実 (AR)/複合現実 (MR))
ビジュアライゼーション/ビジュアルコミュニケーション
建築パース/ウォークスルー(#建築ビジュアライゼーション)
ニュース番組の再現CG/解説CG
ドーム映像(#ドーム動画作成のみ)
インタラクティブコンテンツ(#ゲーム及びインタラクティブコンテンツ作成)
バーチャルリアリティ (VR) - VR動画(#VR動画)およびインタラクティブVR(#インタラクティブVR/拡張現実 (AR)/複合現実 (MR))
仮想遊園地・仮想水族館
フライト/鉄道/ドライビングシミュレータ
出版物 (DTP)
アブストラクトアート/フラクタルアート(#アブストラクト)
デスクトップ壁紙/スクリーンセーバー
キャラクター/バーチャルアイドル
3D印刷によるフィギュア作成(#3Dプリンタ出力)
法廷アニメーション(#法廷アニメーション向け)
歴史的経緯により、建築業界や機械業界ではWindowsの使用が(SolidWorksやInventorやAutoCAD、3ds Maxなど)、グラフィックデザイン業界ではmacOSの使用が多い。映像業界ではWindowsだけでなくmacOSもよく使われており、ポストプロダクション会社ではUnix系ワークステーションも使われている(Autodesk Flameなど)。日本のアニメ業界ではWindowsの使用が多い。ゲーム業界では、プラットフォームによってOpenGL/Vulkan/DirectX/その他の独自APIが使われており、複数APIに対応することも多く、開発ではWindowsの使用が増えているかつては、コンシューマー向けのゲーム開発でUnix系ワークステーションが使われていた時期もあった(スーパーファミコンでのSONY NEWS、NINTENDO64でのSGI IRIX、PlayStation 2でのLinuxなど)。macOS/iOS用ゲームの開発ではmacOSも使われている。映画業界ではワークステーションや巨大なレンダーファームを必要としており、スケーラビリティの高いUnix系のOSの使用が多い。かつてはSGI IRIXが、現在はLinuxが主流となっている。業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。例えば映画向けのハイエンド・ソフトウェアではLinux版が作られたあと、他のOSに移植されている(例えば3D-EqualizerやMARI、Autodesk Flameなど)。
また視覚効果協会 (VES) の協力によってソフトウェア間の互換性を高めるための複数OS対応共通プラットフォーム「VFX Reference Platform」が定められており当初はLinuxのみであったが、2020年以降はWindowsやmacOSの互換性についても規定されている。、3DCGソフトウェアではその規定にあるプログラミング環境およびライブラリの使用が一般的となっている。この VFX Reference Platform は複数のソフトウェアにまたがる製作パイプラインの構築を簡単にするほか、レンダリング共通API「Hydra Render Delegate」での連携時の互換性確保にも重要となっている。
なおデスクトップ/ラップトップの3DグラフィックスAPIは長らくマルチプラットフォームで使えるOpenGLを採用したものが多く、今もその後継のVulkanがマルチプラットフォームで使えるものとして存在しているものの、WindowsはDirect3D APIを、AppleのmacOSはMetal APIを重視するようになっており(AppleのOpenGL対応は4.1止まりで非推奨)、それぞれのAPIに対応するソフトウェアも増えている。一方、モバイルデバイスの3DグラフィックスAPIは長らくOpenGLの簡易版であるOpenGL ESが標準となっていたものの、その後継ではデスクトップ同様Vulkanが使われるようになったほか、AppleのiOSでもデスクトップ同様のMetal APIが使われるようになっている。
また3DCGに使われる異種汎用計算のAPIではホストとゲストの分かれた汎用のOpenCLがだんだん使われなくなり、ホストとゲストの連携の密なCUDA/HIP/Intel oneAPI SYCLの使用が広がっている。なおAppleはその領域でもMetal APIを推し進めている(OpenCLは非推奨化され、CUDAはmacOS対応を終了した)。
デスクトップ/ラップトップのCPUではx64アーキテクチャが、モバイルデバイスのCPUではARMアーキテクチャが一般的となっており、CPUアーキテクチャによる分断も存在した。しかしながら2012年にはMicrosoft Surfaceと共にARM版Windowsが登場し、また2020年にはAppleがデスクトップ向けCPUにもARMアーキテクチャを採用し、非モバイル向けソフトウェアでもARMアーキテクチャにネイティブで対応するものが増えていった。
OS間の進む分断化によってmacOS版の提供を取りやめるソフトウェアも登場している一方、モバイルデバイスがデスクトップに近づくにつれてモバイルデバイスに対応するデスクトップソフトウェアも登場している。
ソフトウェアによって用語の違いが存在する。アメリカ英語とイギリス英語の違い(ColorとColourなど)をはじめ、訳語の違い(ノーマルと法線、シームと継ぎ目など)や、呼び方が違うもの(カラーランプ〈Rampは傾斜〉とグラデーション、モーフとモーフィングとブレンドシェイプとShape Interpとモーフターゲットとシェイプキー、エクスプレッションとドライバ、ShellとSolidifyとThickness、BMesh(Maya SoUP) とSkin Modifier(Blender) とアーマチャー (Metasequoia)、マグネットとAffect RegionとProportional Editなど)がある。
また、同じ用語でもソフトウェアによって意味するものが異なる場合(例えば、3ds MaxのSkin ModifierとBlenderのSkin Modifier、Maya SoUPのBMeshとBlenderのBMesh、BlenderのArmatureとMetasequoiaのアーマチャーなど)がある。
ソフトウェアによってUIやショートカットは異なるが、共通点も多い。
3Dビューの視点の操作では、ポインティングデバイスとキーボードが使われている。ポインティングデバイス用UIでは、Autodesk製品が3DCG/3D CAD/3D GISの共通UIとして「ViewCube」を採用している (3ds Max、Maya 2008以降、Softimage 2011 SAP以降、Mudbox 2013以降、MotionBuilder 2009以降、Inventor 2009以降、Revit 2009以降、Fusion 360、InfraWorks 360など)。
ショートカットキー(ホットキー)は基本操作を含めソフトウェアによって大きく異なっていた。基本操作の移動-回転-拡大縮小だけでも、Mayaや3ds MaxやModoではW-E-R、SoftimageではV-C-X 、BlenderではG-R-S、LightWaveではT-Y-H、Cinema 4DではE-R-T、HoudiniではT-R-Eというように、それぞれ異なるキーが使われている。ゲームエンジンなどでは他のソフトウェアのショートカットに似せることが多く (Unity、UNIGINEなど)、Blenderも2.8で業界互換のキーマップが追加された。
コンテキストメニューは、円形メニューを採用するものが増えている (Maya、Modo、Blender 2.81以降、Houdini 16以降など)。
なお、UIの配色は、3DCG寄りのソフトウェアでは標準で暗い色が基調にされること多く (Maya 2011以降、3ds Max 2011以降、LightWave 10以降など)、CAD寄りのソフトウェアでは標準で明るい色が基調にされることが多い (SketchUpやRhinocerosなど)。近年ではOSにも標準でダークテーマとライトテーマの両方が搭載されるようになってきている (macOS Mojave以降、Windows 10 May 2019 Update以降など)。
共通の3D APIが登場する前にソフトウェアが発展したという歴史的な経緯により、ソフトウェアによって使われる座標系が異なっている。3DCGでは、主に空間を前提に考えた右手系Z-upや左手系Z-upと、視点を前提に考えた右手系Y-upや左手系Y-upが使われている。なお、空間の座標系がZ-upのソフトウェアであっても、スクリーン座標系においては奥行きにZが使われている。
Z-upとY-upを変換するにはX軸で90度回転する必要があり、右手系と左手系を変換をするには負のスケールを使って一軸を反転する必要がある。
また、ボーンの座標系(ボーンの長さ軸/主軸(Primary Axis)/ボーンの方向(Direction)、及び補助軸(Secondary Axis)/ボーンの軸(Axis))もソフトウェアによって異なる (modoやMayaは自由に指定可能、3ds Maxは主軸がX axisもしくはZ axis、Softimageは主軸がX axisもしくはY axisもしくはZ axis、Blenderは主軸がY axis)。
法線マップにおいては、画像の緑チャンネルを+Yにマッピングしたソフトウェアと、-Yにマッピングしたソフトウェアが存在し、緑チャンネルの反転が必要になる場合がある。接線空間法線マップの標準としては、MikkTspace (Mikk tangent space)が存在し、modo 901以降、Blender 2.57以降、Xnormal 3.17.5以降、Unreal Engine 4.7以降、Unity 5.3以降、Knald、Substance Painter 1.3以降、3D-Coat、Marmoset Toolbag、3ds Max 2021以降、Maya 2024以降、Houdini用プラグインのCompute Tangents SOPなどが採用している。
画像の座標は、DirectXやGDIが左上原点、OpenGLやCore Graphicsが左下原点となっているため、3DCGソフトウェア及びそれに関連した2DCGソフトウェアにおいても、画像座標は統一されていない。
スクリーン空間の座標も基本的に画像座標と同じものの、DirectX 9以前には半ピクセルオフセットがあったため、古いシェーダーやDirectX 9以前のシステム等で互換問題の起きることがある。また、スクリーン空間のZ座標は、手前から奥にかけて、DirectXならば0.0~1.0に、OpenGLならば-1.0~1.0にマップすることが標準となっている。現在、深度の精度を改善するため、手前から奥にかけて1.0~0.0にマップするReversed-Zが普及してきている (Unreal Engine 4、Unity 5.5以降、CRYENGINE 3.8.1以降など)。
レンダリング高速化のための背面カリングにおいて、ポリゴンの表面は頂点順序によって決定されるが、ソフトウェアによって表面の指定が右回りと左回りで異なる。また、ファイル形式においても、法線方向が頂点順序によって決定されるものが多い。そのため、この方向の違いによって、モデルのやりとりで法線の反転する問題が発生する場合がある。
3DCGにおいては、CADに比べて長さの正確性があまり必要とされてこなかった。しかし、物理演算や物理ベースのレンダリング、実写合成などが普及し、正確な長さの必要な場合が増えている。また、座標が浮動小数点数で表されるため、設定された単位と単位スケールによって表せる範囲や精度が異なり、それがモデリングやシーン配置にも影響を与えうる。そのため、多くのソフトウェアでは長さの単位と単位スケールが設定できるようになっている。
3DCGソフトウェアではそれぞれ汎用単位を持っており、Generic Unit (GU)と呼ばれる。独自の名前が付いているGeneric Unitも存在する (XSIのSI unit (SoftImage Unit)、BlenderのBU (Blender Unit)、PoserのPNU (Poser Native Unit)、Unreal EngineのUU (Unreal Units)など)。汎用単位の標準の単位設定はソフトウェアによってバラバラに異なっている。
一つの単位と単位スケールだけでは表現できるシーン範囲に限界があるため、オープンワールドのゲームなど広い地形を必要する場合にはタイル化された地形を動的に読み込むという手法が用いられる。
内部計算に単精度を採用するソフトウェア (3ds MaxやBlenderなど)と、倍精度を採用するソフトウェア(CINEMA 4D v12以降など)が存在する。両方に対応するソフトウェアも存在する (UNIGINEなど)。単精度は高速だが、巨大なデータを扱う場合に問題が起きる。演算のアクセラレーションを行うGPUは、ゲーム用に単精度で速いもの(GeForceシリーズ)と、業務用で倍精度が得意なもの(Quadroシリーズ)に分かれている。
また、距離の計算においては、高速なsqrt(a*a+b*b)や高速な比較のためのa*a+b*bを使っているか、オーバーフローの起こしにくい低速なhypot(a,b)を使っているかでも、問題の起きる範囲が異なる。Blenderでは、通常-5000.0から5000.0の範囲の値が信用できるとされている。
3DCGに使われるオブジェクトには幾つかの種類がある。ソフトウェアは通常、複数の種類に対応している。
画像は内部で浮動小数点として扱うことが多いため、リニアカラースペースの32bpc浮動小数階調(float)画像が多く用いられているが、16bpc(half float)が使われる場合もある。フォーマット形式としては、OpenEXR (*.exr)、TIFF、DDS、KTX形式が良く使われている。歴史的経緯によりRadiance HDR (*.hdr)が使われることもあるが、Radiance HDR形式はOpenEXR形式に比べ色の正確性に劣る。また、float画像の非可逆圧縮形式としては、OpenEXRのDWAA/DWABコーデックがある。half-float画像の非可逆圧縮形式ではDirectX及びOpenGL向けのBC6H (BPTC_FLOAT)形式やOpenGL及びDirectX 11.3以降向けのASTC形式も存在する。なお、ASTCは3Dモードも持っており、三次元テクスチャを効率的に圧縮することもできる。
ステレオ3D画像や多視点画像では、それらに標準で対応するOpenEXR形式が多く用いられており、その拡張子は一般的な.exrのほか、ステレオ画像で.sxr、多視点画像で.mxrが使われている。また、画像を独立したペアの画像ファイル(例えば*_L.pngと*_R.png)として保存することも行われている。ステレオ3D画像では、フレームパッキングやインタレースやサイドバイサイドやトップアンドボトムなどの3D方式に変換してステレオ3D未対応の画像形式で保存することも行われている。
素材には16bpcレギュラー画像(Photoshop PSDなど)やLogカラースペースの10bpc画像(CineonやDPXなど)、デジタルカメラのRAW形式などが使われることもある。
テクスチャサイズは時代と共に拡大しており、DirectX 11世代以降、16Kテクスチャ (16384x16384) までが一般的となっているものの、32Kテクスチャ (32768x32768)に対応するソフトウェアも現れている (Mari、Substance Designer 6以降、xNormalなど)。また、メガテクスチャ#仮想テクスチャ(OpenGLではSparse Texture、DX11ではTiled Resources)により、256Kテクスチャ(Graniteなど)や2Mテクスチャ(Amplify Texture2など)に対応することを謳うものも現れている。標準で仮想テクスチャに対応しているゲームエンジンもある (Unity 4.5以降など)。また、マルチタイルテクスチャーのUDIMに対応するソフトウェアも増えている。UDIMに対応するゲームエンジンも登場した (Unreal Engine 4.23以降など)。
レギュラー画像では、歴史的経緯により、Truevision TGA (別名Targa。Truevision社のグラフィックボード由来)、SGI (SGIワークステーション由来。16bpc対応)、Maya IFF (Autodesk Maya由来。16bpc対応)、Windows bitmap (BMP)なども使われていた。しかし、最近ではPNG (16bpc対応)のような一般的な形式を使うことも多い。
ゲーム用途でのテクスチャは、DDS形式 (Windowsが標準で対応)、KTX形式 (Khronos Groupが制定)、PVR形式 (iOSが標準で対応)、PKM形式 (Androidが標準で対応)などが使われている。
画像サイズは、B0サイズ/150dpiの静止画ポスターの場合、6083px*8598pxとなる。駅ナカ広告などでは、複数枚の大判ポスターを連貼りして一枚にすることが行われており、B0サイズ/150dpi/5連貼・2段の場合、12166px*42990pxとなる。一部のソフトウェアでは、大きな画素数に未対応となっている。
ベクター画像は、テクスチャとして使う場合、事前にラスター画像化する必要のある場合が多い。しかし、ベクター画像のままテクスチャとして使えるソフトウェアも存在する (modo 901以降など)。
アルファチャンネル付きの画像には通常のストレート(非事前乗算)なものと、アルファをRGBに事前乗算したものとがあり、画像形式によってアルファ値の扱いが異なっている。例えば、PNG形式ではストレートアルファにのみ対応しており、一般的にアルファの事前乗算には対応していない。一方、OpenEXRではアルファの事前乗算が標準となっている。
3DCGソフトウェアやコンポジットソフトウェアなどにおいてはレンダリングやコンポジットにアルファオーバーが多用されるため、それを高速化するために事前乗算した画像が良く使われている。
事前乗算形式にすると、RGBの情報が不可逆的に失われ、RGBがアルファに依存するようになるが、浮動小数点画像においては逆変換での精度の問題は起こりにくい。
精度や速度やカラースペースの問題もあり、コンポジットの中間形式にはHDR画像の連番が使われることが多い (OpenEXRの連番など)。容量の大きさから、圧縮効率の良いYUV色空間で10ビット~12ビットの色深度を採用した非可逆な中間形式が使われることもある (Apple ProResやAvid DNxHD (VC-3)、GoPro CineForm (VC-5)など)。これらの動画形式は編集の容易さのために、圧縮率の高い予測フレーム(インターフレーム)を使わずに、キーフレーム(イントラフレーム)のみで構成されているものが多い。
実写素材においてもキーフレームのみの形式が使われることが多かったが(AVC-Intraなど)、記録媒体の容量や速度が制約となるために、圧縮率の高い予測フレームを使った動画形式が使われることも増えた (AVCHDやXAVCなど)。近年は、再圧縮での劣化の少ないVisually Losslessな中間形式 (ProResやDNxHDなど)で直接撮影できるカメラが増えている。色空間では、効率的にHDRを記録するために、Log系の色空間 (Cineon (*.cin)、Sony S-Log、RedLogFilm、ALEXA LOG-C ProRes、BMDFilm Log、P-10Log、Canon Logなど)で撮影することが増えている。また、大きな記録容量が必要になるものの、RAW形式 (CinemaDNG、ARRIRAW、Sony RAW MXFなど)での撮影も行われている。
一部のプロ向けカメラを除いて、多くのカメラではクロマ間引き(YUV 4:2:2やYUV 4:2:0など)が行われているものの、クロマ間引きはクロマキーで抜く場合やカラーコレクションを行う場合などに、ノイズやアーティファクトを発生させる要因となる。同様に、編集時にもクロマ間引きを行わないことが望ましいが、一部の手順はクロマ間引きを行ってしまう (例えば中間コーデックにYUV 4:2:2なApple ProRes 422やGrass Valley HQXを使うなど)。
オーサリングでは、メディアによって異なるフォーマットが用いられる。HDテレビ向けにおいては、以前はテープメディア (HDV、HDCAM、HDCAM-SR、HD-D5、DVCPRO HDなど)が主流だったものの下火となっていき、現在は光学ディスクのXDCAM HD (MPEG HDコーデック)や、フラッシュメモリのSRMASTER (MPEG-4 SStPコーデック)、P2-HD (AVC-Intraコーデック)、XDCAM EX (MPEG HDコーデック)などが伸びている。4Kテレビ向けでは、XAVC形式によるハードディスク/SSD納品やネットワーク経由での納品が行われている。コンシューマー向けには、ブルーレイディスクムービー (Full HD解像度まで、Rec.709色空間、8bit、59.94iまで、H.264コーデック)、ブルーレイ3D (Full HD解像度まで、Rec.709色空間、8bit、Full HDで24p/HDで60pまで、H.264 Annex H (MVC)コーデック)、Ultra HD Blu-ray (UHD BD。4K解像度、Rec.709色空間またはRec.2020色空間、SMPTE ST 2084 EOTFまたはDolby PQ EOTF、10bit、60pまで、H.265コーデック)が使われている。デジタル映画向けには、未圧縮のデジタルシネマディストリビューションマスター(DCDM)形式 (4K解像度、XYZ色空間、16bit、TIFF)と、配布のために非可逆圧縮したデジタルシネマパッケージ(DCP)形式 (2K又は4K解像度、XYZ色空間、12bit、JPEG2000コーデック)が使われている。映画のフィルム配信向けには、DPX/ADX形式 (ADX-10又はADX-16色空間、10bit又は16bit、DPX)が使われている。ネット配信では、Netflixが、MPEG­-2のNetflix Profile、Apple ProResのiTunes Profile、SMPTE IMF App 2e+での納品を採用している。
3DCGではサブフレームを使った処理が行われているため、ソフトウェアによって異なる総フレーム数制限が存在する。例えば、Blenderでは最大500,000フレームまでしか対応しておらず、60fpsの場合に2時間18秒までの動画しか作ることができない。一方、Mayaはほぼ無制限となっている。
実験的には120fps以上のハイフレームレート(HFR)動画も作られているが、一部のソフトウェアはHFR動画に未対応となっている (例えばAfter Effects 2017.2より前では99FPSまでにしか対応していなかった)。
多くの3Dソフトウェアは、3Dマウス(6軸コントローラ)に対応している。また、多くのスカルプト・3Dペイントソフトは、タブレットの筆圧感知に対応している。
MIDIデバイスに標準で対応しているソフトウェアも存在する (3ds Max、Softimage、MotionBuilder、HoudiniのMIDI In CHOPなど)。
スクリプト言語としてはPythonが良く使われており、多くの3DCGソフトウェアがそれに対応している。Pythonを使うことでスクリプトの再利用性を高めることができ、特にパイプライン構築で重要となる。ただしAPIの標準化などはされておらず、ソフトウェアによってAPIは大きく異なる。