3DCGソフトウェア
ゲームエンジンの開発言語ではC#が良く使われており、WebGL方面ではJavaScriptが良く使われている (#ゲーム及びインタラクティブコンテンツ作成の開発言語参照)。
グラフィカルUIではQtのPythonバインディングであるPySide (または互換性のあるPyQt) が普及しており、それを提供する3DCGソフトウェアが増えている。Qt未搭載のソフトウェアにおいても、PyQtやPySideを別途インストールすることによって、同じUIを使うことができる。
なお、古くから存在するソフトウェアには独自のスクリプト言語を持つものもある。MayaはPerlやTclに似た文法のMaya Embedded Languageスクリプト(旧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ソフトウェアでもノンリニア編集のファイル交換に使われるEdit decision list形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAdvanced Authoring Formatのインポート及び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)をオープンソースとして公開した。OCIOは各統合ソフト、Nuke 6.3v7以降、Vegas Pro 12以降、V-Ray 3.0以降、Clarisse iFX 2.0以降、Fusion 7以降などで使われている。
2012年8月、PixerはRenderMan互換サブディビジョンサーフェスを実装するためのGPU対応ライブラリOpenSubdivを、DreamWorks Animationは疎ボリューメトリックデータ形式及びツールのOpenVDB (*.vdb)をオープンソースとして公開した。OpenVDBは各統合ソフトや各レンダラーの他、Clarisse iFX 2.0以降、emFluid 5以降、RealFlow 7.1.2.0147以降、Phoenix FD 2.2以降、FumeFX 4.0以降、Stoke MX 2.0以降などで使われている。
Sony Pictures Imageworksとインダストリアル・ライト%26マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)が開発された。各統合ソフトや各コンポジットソフトの他、Clarisse、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に搭載されたレイトレーシングハードウェアの普及によって高品質なレンダリングが高速となり、最終レンダリングと同等のインタラクティブレンダリングに対応するソフトウェアが増えている。レイアウトとレンダラーの統合は、特にライティング作業の効率化において重要となる。また、内外レンダラのビューポートへの統合も進んでいる。
並びは順不同である。
※以下▽はアニメーション対応、▼はアニメーション対応(キャラクタアニメーション有り)、■はアニメーション対応(ダイナミクス有り、キャラクタアニメーション有り)、★はアニメーション対応(キャラクタアニメーション有り、ダイナミクス有り、パーティクル有り)のソフトウェア。
★3ds Max(オートデスク←ディスクリート・ロジック←Kinetix)
Windows専用。NPR向けプラグインのPencil+に定評があり、アニメ業界で使われている。
ポイントクラウド、パラメトリックなアーキテクチャルオブジェクト、他のCG/CAD/CFDソフトウェアとの連携機能(ファイルリンク、ATF、CFD Data Object)、AutoCAD Civil 3D (土木設計向け)等との連携が可能なCivil View (旧DynamiteVSP)機能、2Dエフェクト (レンダリング効果)、簡易コンポジット機能 (ビデオポスト及びステートセット)、Exposure照明シミュレーションも内蔵している。2018.1では、VR向けとしてゲームエンジンの3DS Max Interactive (旧Autodesk Stingray)が付属された。
エフェクトでは、イベントベースのParticle Flowや液体シミュレーションのBifrostが搭載されている。また、エフェクト用のプラグインが豊富に存在しており、ルールベースのthinkingParticlesや、気体流体シミュレーションのFumeFXなどが良く使われている。
ポリゴンモデリングだけでなく、NURBSによるパッチモデリングにも対応しているものの長らく更新されておらず、制限がある。外部プラグインとしてPowerNURBSも存在する。
使用するプロジェクトの年間総収入に制限のある廉価な3ds Max Indieも存在する。過去には無料の簡易版であるGmaxや、可視化向けの3ds Max Designも存在した。
★Maya(オートデスク←エイリアス・システムズ)
クロスプラットフォームのハイエンド3DCGソフトウェア。映画業界のデファクトスタンダードとなっている。ゲーム業界でも使われている。CAD形式のインポートにも対応している(ATF)。