3DCGソフトウェア

3DCGソフトウェアは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。 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 ドラマ ミュージック・ビデオ 3Dアニメーション 映画 CM アニメ ミュージック・ビデオ ゲームのムービーシーン パチンコ・パチスロ機のCG 3Dモーショングラフィックス（#モーショングラフィクス） CM・企業VP キネティック・タイポグラフィ タイトルCG テレビ番組のオープニングCG/ジングルCG 3Dアニメーションロゴ リアルタイム実写合成 テレビ番組のバーチャルセット（#バーチャルセット） 拡張現実 (AR)（#インタラクティブVR/拡張現実 (AR)/複合現実 (MR)） ビジュアライゼーション/ビジュアルコミュニケーション 製品ビジュアライゼーション テクニカルイラストレーション 建築パース/ウォークスルー（#建築ビジュアライゼーション） エクステリア インテリア 映像撮影のプレビジュアライゼーション 演劇舞台のデザイン 科学可視化（英語版） 地理情報システム ニュース番組の再現CG/解説CG ドーム映像（#ドーム動画作成のみ） プラネタリウム インタラクティブコンテンツ（#ゲーム及びインタラクティブコンテンツ作成） ゲーム バーチャルリアリティ (VR) - VR動画（#VR動画）およびインタラクティブVR（#インタラクティブVR/拡張現実 (AR)/複合現実 (MR)） 博物館の展示物 仮想遊園地・仮想水族館 フライト/鉄道/ドライビングシミュレータ 手術シミュレータ 防災シミュレータ バーチャルリアリティ療法（英語版） 3D仮想観光（英語版） インタラクティブウォークスルー インタラクティブ3Dコミュニケーション Web3D 出版物 (DTP) 商業ポスター 挿絵CG 漫画の背景CG 純粋芸術 アブストラクトアート/フラクタルアート（#アブストラクト） デスクトップ壁紙/スクリーンセーバー 3D印刷 シェーダーアート CG画集 キャラクター/バーチャルアイドル 写真集 ダンスCG デジタルフィギュア 3D印刷によるフィギュア作成（#3Dプリンタ出力） その他 ゲームのMOD コンセプトデザイン 犯罪捜査 CGによる囮捜査 法廷アニメーション（#法廷アニメーション向け） 3Dエフェクト 3Dトランジション 歴史的経緯により、建築業界や機械業界ではWindowsの使用が（SolidWorksやInventorやAutoCAD、3ds Maxなど）、グラフィックデザイン業界ではmacOSの使用が多い。映像業界ではWindowsだけでなくmacOSもよく使われており、ポストプロダクション会社ではUnix系ワークステーションも使われている（Autodesk Flameなど）。日本のアニメ業界ではWindowsの使用が多い。ゲーム業界では、プラットフォームによってOpenGL/Vulkan/DirectX/その他の独自APIが使われており、複数APIに対応することも多く、開発ではWindowsの使用が増えている。macOS/iOS用ゲームの開発ではmacOSも使われている。映画業界ではワークステーションや巨大なレンダーファームを必要としており、スケーラビリティの高いUnix系のOSの使用が多い。かつてはSGI IRIXが、現在はLinuxが主流となっている。業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。例えば映画向けのハイエンド・ソフトウェアではLinux版が作られたあと、他のOSに移植されている（例えば3D-EqualizerやMARI、Autodesk Flameなど）。 また視覚効果協会 (VES) の協力によってソフトウェア間の互換性を高めるための複数OS対応共通プラットフォーム「VFX Reference Platform」が定められており、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は大きく異なる。 ゲームエンジンの開発言語ではC#が良く使われており、WebGL方面ではJavaScriptが良く使われている (#ゲーム及びインタラクティブコンテンツ作成の開発言語参照)。 グラフィカルUIではQtのPythonバインディングであるPySide (または互換性のあるPyQt) が普及しており、それを提供する3DCGソフトウェアが増えている。Qt未搭載のソフトウェアにおいても、PyQtやPySideを別途インストールすることによって、同じUIを使うことができる。 なお、古くから存在するソフトウェアには独自のスクリプト言語を持つものもある。MayaはPerlやTclに似た文法のMEL（英語版）スクリプト(旧Wavefront Sophia)を持っており、3ds MaxはMAXScriptを持っており、HoudiniはC Shellに似た文法のHScriptを持っている。また、Cinema 4DはC.O.F.F.E.E.スクリプトを持っていた (R20で廃止)ほか、LightWaveもLScriptを持っていた (LightWave 2020で非推奨)。Rubyを採用したもの (SketchUp等) やAngelScript（英語版）を採用したもの (3D-Coat等) も存在する。 また、標準規格の拡張をした言語を採用しているソフトウェアや、OSに依存するという欠点があるもののOSのスクリプト機能を採用したソフトウェアも存在する。Rhinocerosは、VBScriptを拡張したRhinoscriptが使われている。Adobe After EffectsにおいてはECMAScriptを拡張したAdobe ExtendScriptが使われている。DAZ Studioでは、ECMASciptを拡張したQtScriptを更に拡張したDAZ Scriptが使われている。Softimageにおいては、Active Scriptingに対応しており、JScriptやVBScriptを使用することができた。 リアルタイムではDirectX/Vulkan 1.2以降で採用されているHLSL言語や、OpenGL/Vulkanで採用されているGLSL言語、Apple Metalで採用されているMSL言語が良く使われている。マルチプラットフォームのシェーダー言語としてはNVIDIAのCg (HLSLに近い) が存在していたものの廃止となり、シェーダー言語変換が行われるようになっている。ただしシェーダー形式によって制限が存在する (MSL言語におけるdouble型非対応など)。 エフェクト用の形式ではCg/HLSL言語を基にしたCgFX/DirectX FX形式や、GLSL言語を基にしたCOLLADA FX形式、汎用のnvFX形式が使われている。ゲームエンジンのUnityでは、HLSL言語等を内包可能なShaderLab言語が使われている。VJソフトウェアでは、GLSL派生のISF形式 (Interactive Shader Format)が普及している (VDMX、COGE 1.6.4以降、Magic 1.6以降など)。 シェーダーを中間コンパイルして中間言語バイナリにすることも行われている。 Web向けでは、HTML5のWebGLやCSS Shadersで採用されているGLSL ES言語が良く使われている。また、GLSL ES言語を基にして、音声やマルチパス処理に対応させたものとして、ShaderToyで使われているShaderToy形式(*.stoy)が存在する。かつては、Adobe Flashに採用されていたPixel Bender言語やAGAL言語も使われていた。 オフラインレンダリングでは、オープンソースのOSL言語やNVIDIAのMDL言語が良く使われている。また、C++言語によるシェーダー作成も行われている (RenderManやArnoldなど)。かつてはRenderManのRSL言語（及びその派生のHoudiniのMantraレンダラのVEX言語 (*.vfl)やNVIDIA GelatoのGSL言語）、NVIDIA mental rayのMetaSL (*.msl/*.xmsl)が良く使われていた。シェーダーの事前コンパイルが行われており、OSLは*.osoに、RSLやその派生はレンダラーに依り様々な拡張子に (RenderMan#RenderMan互換レンダラーの比較参照) ネイティブコンパイルされる。 コンポジットソフトウェアでは、 ソフトウェアにより使用可能なシェーダー言語が異なる。FlameのMatchboxではGLSL言語、Fusion 6.0以降ではCg言語、NukeはC++に似たBlink Script言語、After Effectsは独自のPixelBender言語が使われている。 使用するソフトウェアによってシェーダー形式が異なるため、シェーダー変換ソフトウェアが存在する (#シェーダー変換)。 ステレオ3Dの3DCGを作る場合、ビューポート表示からレンダリング、コンポジット、レビュー、動画ノンリニア編集 (NLE)、オーサリングに至るまでステレオ3Dワークフロー対応のものを使うことが望ましい。既に多くのソフトウェアがステレオ3Dワークフローに対応してきているが、ステレオ3Dワークフロー未対応のソフトウェアや機能も残っている。 多視点(Multi-View)ワークフローに対応するソフトウェアも存在する (Blender 2.75以降など)。マルチカメラ編集に対応するNLEソフトウェアは多いものの、多視点(マルチアングル)なDVDやBlu-rayのオーサリングに向けて、マルチトラック動画のエクスポートが可能なNLEソフトウェアはまだ少ない。多視点は、多視差動画を作成するためにも使うことができるが、多視差動画に対応するソフトウェアは少ない。 VRデバイス向け動画には、一般的な球形ステレオ3D形式と、ライトフィールド形式が存在する。360°の球形ステレオ3D形式は、全方向ステレオ (ODS)とも呼ばれる。球形ステレオ3Dの3DCGを作る場合、球形ステレオ3Dワークフローに対応するソフトウェアを使うことが望ましい。以前はワークフローで多くの問題が指摘されていたものの、その後、球形ステレオ3Dに対応するソフトウェアが増えていっており、解決に向かってきている。360°動画や360°ステレオ3D動画のファイル形式としては、GoogleによるSpatial Media仕様が一般的となっている。かつては、360°動画用としてQuickTimeのQuickTime VR形式も使われていた (3ds MaxのPanorama Exporter Utilityがその出力に対応していた)。360°動画や360°ステレオ3D動画の再生及びオーサリングについては「オーサリングツール#360度動画・VR動画」を参照。 ライトフィールドワークフローに対応するソフトウェアはまだ極少数だが、ライトフィールドへのレンダリングに対応するレンダラーが存在する(OctaneRender 3以降など)。 ソフトウェア間のデータのやりとりには主に、データ交換用の標準であるCOLLADA形式 (.dae。OpenGLと同じくKhronos Groupが制定)又はAutodeskのFBX形式 (元々MotionBuilder(旧Filmbox)で使われていた形式)が使われる。昔は事実上の標準であった3D Studio形式(.3ds)、SoftimageのdotXSI形式(.xsi)も使われていた。ソフトウェアによって仕様や実装の違いがあるため、やりとりで問題が起きることも多い。AutodeskはFBXの互換チャートを公表していた。 また、やりとりには汎用形式以外も使われている。統合型ソフトウェアと外部レンダラー間のデータのやりとりにはレンダラ独自のプラグインの使用が多い (内部的にはRIB形式(Rendermanクローンなど)、ply形式(Luxrenderなど)、ASS形式 (Arnold)、vrmesh形式(V-Ray)、Alembic形式(.abc)などが使われている)。モデルデータのやりとりには、汎用モデルフォーマットとしてWavefrontフォーマット(.obj/.mtl。Wavefront The Advanced Visualizerで使われていた形式)やLightWave Object形式(*.lwo)があるものの、様々な情報が失われるためにデータ交換用フォーマットやモデラー独自形式でやりとりすることも多い。モーションのやりとりにはBiovision Hierarchyフォーマット(.bvh)が使われることが多い。ポイントキャッシュのやりとりには、3dsMax PC2 (Point Cache 2)やLightWave MDD (Motion Designer Data)、Maya Cache (.xml/.mc)、FBX (Maya式とMAX式のキャッシュが存在)、Alembicなどの形式が使われる。ポイントクラウドのやりとりは、PTS、PTX、LAS形式などが使われる。パーティクルキャッシュのやりとりでは、Alembic形式、RenderMan PTC形式、Houdini BGEO形式、Real Flow BIN形式、Krakatoa PRT形式などが使われる。 ゲーム向けの汎用モデル形式としては、DirectXのレガシーなx形式や、可逆圧縮のOpenCTM形式が存在するものの、多くはゲームエンジン固有の形式が使われている (id TechエンジンのMDL/MD2（英語版）/MD3（英語版）/BSP（オランダ語版）形式、Source EngineのSMD/DMX形式、CryENGINEのCGF/CAF形式、 Unreal Engine 3のPSK/PSA形式 (現在はFBXパイプラインに移行)、Gamebryo/Creation EngineのNIF形式、LithTech（英語版）のABC形式、SAGE（英語版）のW3D形式、OGREのOGRE XML、Torque Game EngineのDTS/DSQ形式など)。VR向けのシーン形式では、かつてはVRML形式 (*.wrl) やOpenSceneGraph形式 (*.osg)等が良く使われていたものの、現在はゲームエンジンが普及し使われなくなった。 Web向けのアセット形式では、古くはAway3DのAWD形式やthree.jsのJSON Model format等が存在したものの、現在はKhronos Group制定のglTF形式が普及してきている。glTFは拡張として、非可逆圧縮のDraco及びmeshoptに対応している。 3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、3MF形式などが使われる。 また、3DCGソフトウェアでもノンリニア編集のファイル交換に使われるEDL（英語版）形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAAF（英語版）のインポート及びFCP XML形式のインポート/エクスポートに、Unreal EngineのSequencerがCMX EDL及びFCP XML形式のインポート/エクスポートに対応している。Pixarが中心になって開発しているオープンソースのOpenTimelineIOライブラリは、それら形式の多くに対応している。 最初のマテリアルは完全拡散反射に光沢やフレネル効果や完全鏡面反射を足すものであったが、その後、微細表面 (マイクロファセット) のラフネス (粗さ)を考慮したシェーダーが使われるようになり、その後、誘電体や導体 (金属)などの物性別のシェーダーが現れ、現在はメタルネス (金属さ)が導入されて誘電体と導体の両者に使用可能な物理ベースシェーディング (PBS)に対応するソフトウェアが増えている。 Disney式PBSシェーダーの普及により、OBJ+MTL形式やFBX形式、glTF形式などの一般的な3D形式もPBSシェーダーに対応した (物理ベースシェーディング#PBS対応の3Dファイル形式参照)。ただし、ソフトウェアによっては高速化のために近似計算を行っているため、ソフトウェア間のやりとりで見た目の変わることがある。 なお、Disney式PBSシェーダー以外の特殊シェーダー (ヘアシェーダー、ボリュームシェーダーなど) は標準が無いため、マテリアルのやりとりで問題となる。そのため、LucasfilmとIndustrial Light＆Magicがマテリアルをやりとりするための新規格であるMaterialXを開発している。 ボクセル/ボリューム形式は、流体シミュレーション、3D印刷、医療、一部のモデリングソフトウェア (3D-Coat等)などに使われている。3DCGでは、3Dテクスチャ (DDS形式、KTX形式等) や、オープンソースのOpenVDB形式 (*.vdb) が事実上の標準形式となっている。オープンソースのField3d形式 (*.f3d) に対応するソフトウェアもある。 3D印刷では、Shapewayのsvx形式や、NVIDIA及びHPの推進するGVDB形式 (*.vdx)があるものの、2017年現在普及していない。医療ではDICOM形式が使われている。 画像や映像のやりとりでは色空間が重要となる。色空間には、カメラの撮像素子の出力の色空間、圧縮のための色空間、作業のための色空間、保管のための色空間、頒布のための色空間、表示デバイスの表示素子の出力の色空間などが存在する。入出力デバイスによって表現可能な色空間が異なるため、目的によって色空間を使い分ける必要がある。 カメラの撮像素子の出力は、固有の色空間を持っており、カメラで撮られたRAW画像やRAW動画は固有の色空間となっている。ガンマは基本的にリニアとなっている。バス幅や帯域幅や保存領域などのサイズの問題から画像や動画の非可逆圧縮が必要となる場合、見た目の劣化が少なく非可逆圧縮に向く色空間への変換が行われている (DPXのLog、ProPhoto RGB、YUV 4:4:4 12bit、YUV 4:2:2 10bitなど)。 作業のための色空間では、光の物理的性質を利用した処理とアーティスティックな処理が行われるため、色差が物理的に均一で、かつ色域が人間の見える範囲により近く、かつ人間が扱いやすいRGBの色空間であるACEScg（リニア、D60ホワイトポイント）やRec.2020リニア（D65ホワイトポイント）がよく使われている。ACEScgは色域がRec.2020リニアに近い上に映画に使われてきたDCI-P3色空間を包括しているなどの利点があるものの、非物理的な色を含むなどの様々な問題が存在する。そのため、狭い色域のRec.709リニア(D65ホワイトポイント、NukeやBlenderの標準)が使われることも多い。また、法線マッピングやバンプマッピングや透過マップや深度マップやIDマップなどでは、RGBを色ではなく単なる数値として使うため、リニアなカラースペースが使われる。レイトレーシングレンダリングにおいては、RGBだけでなく、スペクトルカラー（英語版）も使われている (スペクトルレンダリング（英語版）)。コンポジット作業においては、RGB特有の処理が多用されるため、RGB色空間を使う場合が多い。編集作業では、RGBだけでなく、YUVも使われている。カラーコレクションには、RGBだけでなく、YRGBも使われている (Davinci Resolveなど)。 保管のための色空間では将来に備えたより広い色空間も使われている　(デジタルシネマの保管におけるDCDMの16bit DCI-X'Y'Z' ガンマ2.6 5900K、ACES2065-1 (別名Linear ACES、SMPTE2065-1)など)。 頒布のための色空間では、出力機器(ブラウン管(CRT)、液晶、有機EL、プロジェクター、プリンター等)の特性と人間の識別(XYZ表色系やバートンランプなど)に適したものが使われる (SDTVにおけるRec. 601、HDTVにおけるRec. 709、デジタルシネマにおけるDCI-P3、UHDTVにおけるRec.2020、WebにおけるsRGB、プリンタにおけるAdobe RGBなど)。目的とする出力機器では出せない色も出てくるため、作業では出力機器を模した色空間も使われているが、その場合でも作業用ディスプレイの色空間への変換が行われるため、完全に同一にはできない。表示デバイスの表示素子の出力の色空間はそれぞれ固有の色空間を持っており、例えばブラウン管 (CRT)のガンマ値は2.2に近く、液晶のガンマはS字カーブを描いており、プロジェクターのガンマは1.5に近かった。これらの差異を吸収するために、表示デバイスのファームウェアは、頒布のための色空間からデバイス固有の色空間への変換を行っているものの、未対応の色空間があったりズレが生じたりと完璧ではないため、OSのカラーマネージメントシステム(WindowsのWindows カラー システム (WCS)、macOSのColorSync、Linuxのcolordなど)がモニターのカラープロファイルを管理して色空間変換の補正を行っている。しかし、OSのカラーマネージメントに対応していないソフトウェアも存在する (Mac版DaVinci Resolveの12.1より前など)。また、一部のモニターは10bit表示に対応しているものの、一部のソフトウェアは8bitへのトーンマッピングを行うなどして、10bit表示に未対応となっている（Mac版DaVinci Resolveの12.1より前など）。ディスプレイ機種固有の色空間を直接出力する仕様も登場している (FreeSync 2など)。 かつてPCモニターでは、sRGBが主流であったが、その後、Adobe RGB対応のPCモニターが広まってきている。そのため、Webにおいても、従来sRGBが使われてきたが、現在Webブラウザの多くはICCプロファイルv2に対応しており、様々なカラースペースを使うことが可能となっている。しかし、Adobe RGB色空間での画像出力や、ICCプロファイルv2の埋め込みに対応していない3DCGソフトウェアも存在する。 色空間の変換方式はカラーマトリクス、1D-LUT、3D-LUT、曲線当てはめなどが存在し、色空間の変換パラメータの形式には、ICCプロファイルv2/v4、Autodeskのlut、Autodeskの3dl、Autodesk CTF、Adobe SpeedGrade（旧Iridas SpeedGrade）のlookやitxやcube、Cinespaceのcsp、Houdiniのlut、Sony Pictures Imageworksのspi1dやspi3dやspimtx、Pandora Pogleのm3dやmga、ASC CDL、ASC CCC、ACESのCTL、Nukeのvf、DaVinci Resolveのdctlなど多くの形式（LUT形式）が存在している。オープンソースのOpenColorIOは、その多くに対応している。 独自仕様にするとアプリケーション同士の連携が難しくなるため、やりとりに関わる部分においてオープンソースのミドルウェアが増えてきている。主にスタジオ側がミドルウェアをオープンソースとして開発・公開しており、商用ソフトウェアにおいてもそれらのミドルウェアを使った機能が標準で搭載されるようになってきている。2018年には映画芸術科学アカデミーにより Academy Software Foundation が設立され、当財団がオープンソースの取りまとめをすることが多くなっていった (OpenEXR、OpenColorIO、Open Shading Language、OpenVDB、MaterialXなど)。 2000年1月、Robert McNeel & Associatesは、openNURBS Initiativeを設立し、openNURBS Toolkitをリリースした。openNURBS (*.3dm)は現在、Rhinoceros、MoI 3D、modoなどに使われている。 2003年1月、オープンソースのHDRI画像フォーマットであるOpenEXR (*.exr)が、インダストリアル・ライト&マジックによって公開された。2007年11月には、OpenEXRにステレオ3D画像や多視点画像を埋め込むための仕様がWeta Digitalによって公開された。2013年4月には、Deep Data画像に対応した2.0がリリースされた。2014年8月には、DreamWorks Animationにより開発された非可逆圧縮のDWAA/DWABに対応する2.2がリリースされた。 2010年1月、Walt Disney Animation StudiosがUV展開不要のテクスチャマッピングシステムのPtex (*.ptx)をオープンソースとして公開した。 2010年1月、Sony Pictures ImageworksはGIレンダラ向けプログラマブルシェーディング言語のOpen Shading Language (OSL、*.osl)、ボクセル・データ保存ライブラリのField3d (*.f3d)などを、同年7月にはカラーマネージメントライブラリのOpenColorIO (OCIO)をオープンソースとして公開した。 2012年8月、PixerはRenderMan互換サブディビジョンサーフェスを実装するためのGPU対応ライブラリOpenSubdivを、DreamWorks Animationは疎ボリューメトリックデータ形式及びツールのOpenVDB (*.vdb)をオープンソースとして公開した。OpenVDBは各統合ソフトや各レンダラーの他、RealFlow 7.1.2.0147以降、Phoenix FD 2.2以降、FumeFX 4.0以降、Stoke MX 2.0以降などで使われている。 Sony Pictures Imageworksとインダストリアル・ライト&マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)が開発された。各統合ソフトや各コンポジットソフトの他、Unreal Engine 4.13以降、CryEngine、Poser 11以降、RealFlow、thinkingParticles 6.3以降、Vue xStream 2015以降PFTrack 2015以降、V-Ray、RenderMan、Maxwell Render V3以降、OctaneRender、Guerilla Render 1.3以降、KATANA、Esri CityEngine 2016以降など、多くのソフトウェアがAlembicに対応している。 ハードウェアメーカーがハードウェアの需要を起こすためにオープンソースで開発することもある。 2005年、Sony Computer Entertainmentの開発者によって開発された物理エンジンのBullet Physicsがオープンソースとして公開された。その後、2009年よりAMDがBullet Physicsの開発を支援している。Bullet Physicsに対応する3DCGソフトウェアは増えており、Blender、LightWave、Maya、Cheetah3D、Cinema 4D、modo、Houdini、Maya付属のMayaBulletプラグイン等が対応している (ソフトウェアによって対応具合は異なる)。 2011年7月、Intelが高速なレイトレースカーネルのEmbreeをオープンソースとして公開した。 括弧内は、搭載されているレンダラー。 統合型はシーンセットアップを基本に、モデリング、アニメーション、レンダリングなど多くの機能を備えた物である。最近はコンポジットやマッチムーブまで行えるソフトウェアが増えている。プラグインで機能を拡張できるものが多く、一つのソフトウェアだけで多くの作業が行えるほか、他のモデラー・レンダラー・モーション付けソフトウェアなどと組み合わせて作業パイプラインの中心の役割を担える。その他、モデリングなどの単機能目的のみで使われることも多い。一般的に統合ソフトは、標準機能同士の連携は優れているものの、他のソフトウェアに比べて一部の標準機能が古かったり低機能だったり直感性・操作性に乏しい場合が多々あるため、スクリプトやプラグインやソフトウェアを組み合わせて作業パイプラインを作ることが重要となる。 大きなプロジェクトでは、外部参照やアセットの軽量な代理表現、アセット管理 (#管理システムも参照)が重要となる。 OpenGLやDirectXの高機能化に伴い、ビューポートにおいてPBR (物理シェーダー)やエフェクト等によるリッチな表示が可能となった。また、3Dゲームや3D CADの可視化で使われるウォークスルー（歩行）/フライスルー（飛行）のような一人称視点ナビゲーションにも対応するソフトウェアが増えており、オーサリングせずに直接VR表示できるソフトウェアまで登場している。 GPUの汎用化（GPGPU）及びGPUに搭載されたレイトレーシングアクセラレータ（英語版）の普及によって高品質なレンダリングが高速となり、最終レンダリングと同等のインタラクティブレンダリングに対応するソフトウェアが増えている。レイアウトとレンダラーの統合は、特にライティング作業の効率化において重要となる。また、内外レンダラのビューポートへの統合も進んでいる。