3DCGソフトウェア

OS及びプラットフォーム

業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。macOSはGPUドライバのOpenGL対応が4.1止まりとなっているうえ、Mojave (10.14) でOpenGLおよびOpenCLが非推奨化されており、macOS版の提供を取りやめるソフトウェアも登場し始めている。一方、Windowsは64論理コアよりも多くのCPUコアを扱うためにソフトウェアの変更が必要となるため、64論理コア以下にしか対応していないソフトウェアが残っている（Mayaや3ds Maxを含む）。
歴史的経緯により、建築業界や機械業界ではWindowsの使用が多い（SolidWorksやInventorやAutoCAD、3ds Maxなど）。映像業界ではWindowsだけでなくmacOSもよく使われており、ポストプロダクション会社ではUnix系ワークステーションも使われている（Autodesk Flameなど）。日本のアニメ業界ではWindowsの使用が多く、グラフィックデザイン業界ではmacOSの使用が多い。
映画業界ではワークステーションや巨大なレンダーファームを必要としており、スケーラビリティの高いUnix系のOSの使用が多い。かつてはSGI IRIXが、現在はLinuxが主流となっている。Linuxディストリビューションとしては、CentOSとUbuntuの両方がよく使われている。ディストリビューション間の互換性の問題を減らすため、視覚効果協会 (VES) の協力によってVFX Reference Platformが定められている。映画向けのハイエンド・ソフトウェアはLinux版が作られたあと、他のOSに移植される場合が多い（例えば3D-EqualizerやMARI、Autodesk Smokeなど）。
ゲーム業界では、プラットフォームによってOpenGL/Vulkan/DirectX/その他の独自APIが使われており、複数APIに対応することも多く、開発ではWindowsの使用が増えている。iPhone用ゲームの開発ではmacOSも使われている。かつては、コンシューマー向けのゲーム開発でUnix系ワークステーションが使われていた時期もあった（スーパーファミコンでのSONY NEWS、NINTENDO64でのSGI IRIX、PlayStation 2でのLinuxなど）。

用語

ソフトウェアによって用語の違いが存在する。アメリカ英語とイギリス英語の違い（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のアーマチャーなど）がある。

画像座標/スクリーン空間座標

画像の座標は、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の範囲の値が信用できるとされている。

画像形式

画像は内部で浮動小数点として扱うことが多いため、リニアカラースペースの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 2017 Update 2以前では時間を1/6000秒単位の32bit整数で管理していたため、約±50時間まで対応していた。Maya 2017 Update 3以降では時間処理が改善され総フレーム数制限がほぼ無くなったものの、互換性の問題から古い時間制限の使用を推奨している。
実験的には120fps以上のハイフレームレート(HFR)動画も作られているが、一部のソフトウェアはHFR動画に未対応となっている (例えばAfter Effects 2017.2より前では99FPSまでにしか対応していなかった)。

I/O

多くの3Dソフトウェアは、3Dマウス(6軸コントローラ)に対応している。また、多くのスカルプト・3Dペイントソフトは、タブレットの筆圧感知に対応している。
MIDIデバイスに標準で対応しているソフトウェアも存在する (3ds Max、Softimage、MotionBuilder、HoudiniのMIDI In CHOPなど)。

スクリプト

スクリプト言語としてはPythonが良く使われており、多くの3DCGソフトウェアがそれに対応している。Pythonを使うことでスクリプトの再利用性を高めることができ、特にパイプライン構築で重要となる。しかし、Python 2系と3系で互換性が低い。また、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を持っており、LightWaveはC言語に似た文法のLScriptを持っている。また、Cinema 4DはC++に似た文法のC.O.F.F.E.E.スクリプトを持っていた (R20で廃止)。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を使用することができた。

ステレオ3D/多視点

ステレオ3Dの3DCGを作る場合、ビューポート表示からレンダリング、コンポジット、レビュー、動画ノンリニア編集 (NLE)、オーサリングに至るまでステレオ3Dワークフロー対応のものを使うことが望ましい。既に多くのソフトウェアがステレオ3Dワークフローに対応してきているが、ステレオ3Dワークフロー未対応のソフトウェアや機能も残っている。
多視点(Multi-View)ワークフローに対応するソフトウェアも存在する (Blender 2.75以降など)。マルチカメラ編集に対応するNLEソフトウェアは多いものの、多視点(マルチアングル)なDVDやBlu-rayのオーサリングに向けて、マルチトラック動画のエクスポートが可能なNLEソフトウェアはまだ少ない。多視点は、多視差動画を作成するためにも使うことができるが、多視差動画に対応するソフトウェアは少ない。

VR動画

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に対応している。
3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、3MF形式などが使われる。
また、3DCGソフトウェアでもノンリニア編集のファイル交換に使われるEDL形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAAFのインポート及びFCP XML形式のインポート/エクスポートに、Unreal EngineのSequencerがCMX EDL及びFCP XML形式のインポート/エクスポートに対応している。Pixarが中心になって開発しているオープンソースのOpenTimelineIOライブラリは、それら形式の多くに対応している。

マテリアル形式

最初のマテリアルは完全拡散反射に光沢やフレネル効果や完全鏡面反射を足すものであったが、その後、微細表面 (マイクロファセット) のラフネス (粗さ)を考慮したシェーダーが使われるようになり、その後、誘電体や導体 (金属)などの物性別のシェーダーが現れ、現在はメタルネス (金属さ)が導入されて誘電体と導体の両者に使用可能な物理ベースシェーディング (PBS)に対応するソフトウェアが増えている。
PBSシェーダーの普及により、FBX形式やglTF形式などもPBSシェーダーに対応したが、古いソフトウェアでは未対応のままとなっている。また、ソフトウェアによっては高速化のために近似計算を行っているため、ソフトウェア間のやりとりで見た目の変わることがある。
なお、PBSシェーダー以外の特殊シェーダー (スキンシェーダーやヘアシェーダー、ボリュームシェーダーなど) は標準が無いため、マテリアルのやりとりで問題となる。そのため、2017年現在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ホワイトポイント)がよく使われている。歴史的経緯から、狭い色域のRec.709リニア(D65ホワイトポイント、NukeやBlenderの標準)が使われることもある。また、法線マッピングやバンプマッピングや透過マップや深度マップやIDマップなどでは、RGBを色ではなく単なる数値として使うため、リニアなカラースペースが使われる。レイトレーシングレンダリングにおいては、RGBだけでなく、スペクトルカラーも使われている (スペクトルレンダリング)。コンポジット作業においては、RGB特有の処理が多用されるため、RGB色空間を使う場合が多い。編集作業では、RGBだけでなく、YUVも使われている。カラーコレクションには、RGBだけでなく、YRGBも使われている (Davinci Resolveなど)。
保管のための色空間では、将来に備えてより広い色空間が使われている　(デジタルシネマの保管におけるDCDMの16bit X'Y'Z' ガンマ2.6 5900Kなど)。
頒布のための色空間では、出力機器(ブラウン管(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は、その多くに対応している。

互換性に関わるオープンソース

独自仕様にするとアプリケーション同士の連携が難しくなるため、やりとりに関わる部分においてオープンソースのミドルウェアが増えてきている。主にスタジオ側がミドルウェアをオープンソースとして開発・公開しており、商用ソフトウェアにおいてもそれらのミドルウェアを使った機能が標準で搭載されるようになってきている。
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をオープンソースとして公開した。
2012年8月、DreamWorks Animationは、疎ボリューメトリックデータ形式及びツールのOpenVDB (*.vdb)を公開した。各統合ソフトや各レンダラーの他、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とインダストリアル・ライト&マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)の開発が進んでいる。各統合ソフトや各コンポジットソフトの他、Clarisse iFX、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をオープンソースとして公開した。CINEMA 4D R15やStrata Design 3D 8.1以降、V-Ray、LuxRenderなどが搭載している。

商用製品

※以下▽はアニメーション対応、▼はアニメーション対応(キャラクタアニメーション有り)、■はアニメーション対応(ダイナミクス有り、キャラクタアニメーション有り)、★はアニメーション対応(キャラクタアニメーション有り、ダイナミクス有り、パーティクル有り)のソフトウェア。

バーチャルカメラ

LightWave (InterSense向け)、Unreal Engine 4のVirtual Camera Pluginなどがバーチャルカメラシステムに対応している。

テレセントリックレンズ

テレセントリックレンズは正投影 (オルソ)に似ているものの、ピントが存在する。一部のレンダラーはテレセントリックカメラに対応している (Mitsuba Renderなど)。

パニーニ投影

パニーニ投影 (Vedutismo投影としても知られる) は絵画に使われている投影法であり、線の歪みを抑えながら広い視野を実現できる。標準で対応するソフトウェアも存在する (Unreal Engine 4、UnityのSRP 6.0.0以降など)。

VR動画作成向け

VRに使われる、全天周動画や360°動画を作成するためのソフトウェア。多くの統合ソフトウェアは既に360°動画の作成に対応している。

ブーリアンモデリング

ブーリアンに対応する統合ソフトウェアやモデラーは多く、ブーリアン時のフィレットに対応するソフトウェアもある。
また、パーツの切り分けに向けた機能が存在するソフトウェアもある (ZBrush、3D-Coat、Blender 2.78以降に付属のCarver MTアドオンなど)。

ゲーム向け簡易モデラー

MOD作成に特化したものなど。3Dモデルの簡易編集に標準で対応する開発環境も存在する (Visual Studioのモデル エディターなど)。

テクスチャ作成

テクスチャにはいくつかの手法が使われる。従来はUV展開してAOなどのアタリをベイクしてから画像を書いたり、素材画像を元にUV展開することが多かった。しかし、UVの切れ目や歪みの問題などがあり、現在では3Dペイントを使ってオブジェクトに直接テクスチャを書いたり、画像を変形しながら貼り付けたりするのも一般的となってきている。また、解像度を気にしないで3Dペイントができる、Ptexという技術も登場している。
近年は物理ベースシェーディング (PBS)の普及により、従来とテクスチャの種類が異なる物理ベースシェーダー用のテクスチャ作成に対応したソフトウェアが増えている。
立体的なテクスチャの製作には2.5Dペイントも使われている。また、マットペイントでもテクスチャと同様に描画だけでなく、クローンブラシ(コピースタンプ、スタンプで描画、クローンツール)や修復ブラシ、ワープ変形などを使った写真の変形・加工・合成が使われている。マット絵自体は2D的であるが、被写界深度や視点変更のために深度が必要となるため、レイヤを使ったり、深度をペイントしたり、3Dモデルにカメラプロジェクションしたりといった手法が使われている。マットはテクスチャと異なり、コンポジットソフトウェアで合成されることも多い。
カラーマネージメントの普及に伴い、テクスチャには線形空間の浮動小数点画像(HDR画像)を使うことが増えており、2DペイントでもHDR画像やカラーマネージメントに対応しているソフトウェアを使うことが増えている。
ペイント以外では、パラメーターからテクスチャを生成するプロシージャルテクスチャというものが使われている。画像をタイル状に繰り返すタイルテクスチャでは、元画像を作るために画像をタイルテクスチャ向けに加工したり、タイルテクスチャ向けの画像を作成するためのソフトウェアがある。また、ノードを使ってテクスチャを非破壊編集できるソフトウェアもある。
その他、レンダラーを使ってレンダーパスをテクスチャ化するテクスチャベイク(法線焼き付けやAO焼き付けなど)も使われている。

マテリアルエディタ

多くの統合ソフトウェアは標準でマテリアル編集機能を持っている。一部のレンダラーは、マテリアル編集に対応するGUIを備えている (V-RayのV-Ray Standalone Material Editor、Maxwell RenderのMaxwell Studio、Indigo Rendererなど)。

キャラクター作成

キャラクター作成に標準対応する3DCGソフトウェアもある (Poser、DAZ Studioなど)。

植物・植生生成

内部でL-systemを使っているものがある。植物生成向けの機能を持つ統合ソフトウェアや景観作成ソフトウェアもある (MayaのPaint Effects、HoudiniのL-system SOP、Blender内蔵のSaplingアドオン、VueのSolidGrowthなど)。草生成機能を持つレンダラーも存在する (Maxwell Renderなど)。また、草にはヘア・ファー向け機能も使われる。

分岐形成

分岐形成は雷、氷晶、地衣類、サンゴ、植物などのモデリングに使われている。分岐形成のアルゴリズムには、一般的な拡散律速凝集、雷の生成に使われる絶縁破壊モデル (DBM、拡散律速凝集と電界の組み合わせ)、高速なLaplacian Growth、自由なルールが作成可能で植物の生成にも向くL-Systemなどが存在する。L-Systemのルールが標準で使えるソフトウェアも存在する (HoudiniのL-System SOP、Cinema 4DのMoSplineのTurtleなど)。植物生成については#植物・植生生成も参照。

ポイントクラウド取り込み・編集

LiDARスキャンしたデータなどを取り込むためのもの。標準でポイントクラウドに対応する統合ソフトウェアもある (3ds Max 2015以降のPoint Cloud Object、Houdiniなど)。他用途のソフトウェアでも、ポイントクラウドの読み込みに対応するソフトウェアが存在する (Houdini 16以降のLIDAR Import SOP、3ds Max、Krakatoa 2.4以降のPRT Loader (PRT形式以外にも対応)、Autodesk ReCap 360など)。
大規模な3Dスキャンは、建築方面だけなく、科学捜査や法廷アニメーション、VFXでも行われている。

テクスチャスキャン

テクスチャの取り込みには、写真を画像処理で変換する手法、3Dスキャンからテクスチャ抽出する手法、マテリアルスキャナーを使う手法などがある。前者二つについては#マップ生成を参照。
マテリアルスキャナーでは、測定したマテリアル (MERL database形式、X-riteのAxF形式、MDLのMBSDF形式、V-RayのVRscans形式など) をそのままレンダリングで使ったり、別のシェーダーにフィッティングすることが行われている (#測定マテリアル参照)。マテリアルスキャナーは市販のものも存在する (X-rite TACなど) が、簡易的なものは自作することもできる。

シェーダー構築

多くの統合ソフトウェアは、標準でノードベースのシェーダー構築に対応している (MayaのHypershadeやNode EditorやShaderFX (元Lumonix製、HLSL及びGLSL向け)、3ds MaxのSlate Material Editor (旧NodeJoe、元Thinking Apes製)やShaderFX、modoのNodal Shading、HoudiniのSHOP、Blenderのマテリアルノード、Unreal EngineのMaterial Nodes、Unity 2018.1以降のShader Graphなど)。多くのレンダラーもノードによるシェーダー構築が可能となっている。
OSLシェーダーのコード編集に対応する統合ソフトウェアやルックデブソフトウェアも存在する (3ds Max 2019以降のOSL Map、BlenderのText Editor、GafferのOSLCode Nodeなど)。
多くのゲームエンジンはリアルタイムシェーダーのコード編集に対応している。一部の開発環境にもリアルタイムシェーダー作成補助機能が搭載されている (Graphics Tools for XcodeのOpenGL Shader Builder、Visual Studio/Eclipse用プラグインのNVIDIA NsightのDynamic Shader Editing機能、PowerVR Tools and SDKのPVRShaman/PVRShaderEditorなど)。その中には、ノードベースのシェーダー構築に対応するものも存在する (Visual Studioのシェーダー デザイナーなど)。

ポリゴンリダクション及びLoD

ポリゴンリダクションは多くの統合ソフトウェアに搭載されている (3ds MaxのProOptimizer Modifier、MayaのReduce、SoftimageのPolygon Reduction、modoのPolygon Reduce、LightWaveのReduce Polys及びReduce Polys+ (旧Marvin Landis製qemLOSS2)、HoudiniのPolyReduce、Cinema 4DのPolygon Reduction Tool、Shade 15以降のポリゴンリダクション、BlenderのDecimate Modifierなど)。幾らかのモデラーにも搭載されている (3D-CoatのSurface ModeのDecimate、ZBrush付属のDecimation Masterプラグインなど)。その他のソフトウェアにも搭載されているものがある (MeshlabのQuadratic Edge Collapse Detection、PhotoshopのSimplify 3D Meshなど)。
LoDの自動生成に対応するソフトウェアも存在する (Maya LT 2016 Extension 2以降、Unreal Engine 4.14以降、Cinema 4D R19以降など)。

MIPMAPテクスチャ生成

多くのレンダラーは、タイル化したMIPMAP(多解像度)テクスチャ生成ツールを含んでいる (V-Rayのimg2tiledexr、RenderManのtxmake、HoudiniのMantraのicp、3Delightのtdlmakeなど)。タイル化画像形式では、タイル化されたTiff形式やOpenEXR形式が良く使われている。
オープンソースのOpenImageIOにもMIPMAPテクスチャ生成ツールのmaketxが含まれており、それを採用しているレンダラーも存在する (Arnold Rendererなど)。

複雑なアニメーションからボーンアニメーションへの変換

複雑なデフォーマー等により生成された頂点アニメーションから、ボーン生成、スキニングウェイト生成、アニメーション生成を行うことで、ボーンアニメーションに変換できる。既存のボーン及びスキニングウェイトを使ってアニメーションのみ生成することや、既存のボーンを使ってスキニングウェイト及びアニメーション生成のみを行うことに対応するソフトウェアも存在する。
一部に標準で対応する統合ソフトウェアも存在する (Maya 2017 Update 3以降のBakeDeformerTool (スキニングウェイト及びアニメーション生成のみ)、Houdini 16.5以降のGame Development ToolsetのSkinning Converterなど)。また、Maya SOuPにもbake arbitrary deformationsやbake deformations to fk skeletonとして実装されている。

インタラクティブVR/拡張現実 (AR)/複合現実 (MR)

ヘッドマウントディスプレイ(HMD)やビデオウォール、CAVE(マルチスクリーンシステム)、全天周 (Fulldome)向けのインタラクティブコンテンツを作成するためのソフトウェア。標準でHMD型のVRデバイスに対応するゲームエンジンが増えている (Unity 5.1以降、Unreal Engine 4以降、CryENGINE 3.8.1以降、3ds Max Interactive、Unigine 2.0以降など)。2017年現在、HMD向けのミドルウェアはGPUやプラットフォームや機器毎に異なるものとなっているため、ゲームエンジンにより対応する機器が異なる。Webにおいても、WebVR APIやWebXR Device APIによってHMD型VRデバイスを使用することができ、それに対応するゲームエンジンは多い (Blend4Web 15.12以降、Babylon.js、PlayCanvas、three.jsなど)。
VRにおいて多数のディスプレイやプロジェクターを使う場合、マルチGPUによってPC1台から16画面以上の出力を行うことが可能 (Unityでは8画面まで)ではあるものの、処理能力の関係から、複数台のPCより成るコンピュータ・クラスターも使われている。VRに使うトラッカーデバイスなどの入力機器には、主にVRPNプロトコルが使われている。

VRビューポート・VR編集

標準で対応するソフトウェアも存在する (MODO 12.1以降、Unreal Engine 4.12以降など)

バーチャルセット

TriCaster (NewTek)、Infinity Set (Brainstorm)、Maestro | Virtual Set (旧ProSet。Avid Technology←Orad Hi-Tec Systems)、Viz Virtual Studio (Vizrt)、Plutonium/Neon (ChyronHego←Hybrid)、XPression (Ross Video)、Reality Virtual Studio (Zero Density)などのソリューションが存在する。国産では、3D-NIXUS (北海道日興通信)が存在する。
2018年現在、バーチャルセットシステムにゲームエンジンの一つUnreal Engineを組み込むことが流行している。

シミュレーション及びエフェクト

基本的なものとして、変形を起こさずに衝突を再現する剛体シミュレーション、開いたメッシュに対し衝突と変形を再現するクロスシミュレーション、閉じたメッシュに対し衝突と変形を再現するソフトボディシミュレーションが存在する。衝突判定では、突き抜けを起こすアルゴリズムと、突き抜けを起こさないアルゴリズムが存在し、ソフトウェアによって対応具合が異なる。クロスシミュレーションやソフトボディシミュレーションでは高速なマススプリングモデルにのみ対応するソフトウェアがほとんどであるが、より正確な有限要素法(FEM)によるソフトボディシミュレーションに対応するソフトウェアも存在する (Houdiniなど)。
流体シミュレーションには複数の実装方法があり、パーティクルを流体のように動かす流体パーティクル (SPH法) に対応するものと、3D格子(グリッド)を使う流体シミュレーション (格子法)に対応するものがある。また、現在はパーティクルと格子を組み合わせたハイブリッド流体シミュレーションの一つであるFLIP法に対応するソフトウェアが増えており、FLIP法より安定したAPIC法に対応するソフトウェアも出始めている (Houdini 15以降のSwirly Kernelなど)。液体を扱うものではパーティクルベースであれどグリッドベースであれどメッシュ化が必要となり、メッシュ化のための専用プラグインも存在している (#メッシュ化)。気体(炎や煙)を扱うものでは基本的にボクセルが生成される (標準形式としてOpenVDBがある)。また、海洋の近似的生成や、2Dの波エフェクト (BlenderのDynamic Paintなど)、擬似的な炎・煙エフェクト (AfterBurn、pyroCluster、StormTracerなど)をサポートするソフトウェアもある。
ソフトウェアによって、水飛沫や泡の再現、表面張力の再現、浮力の再現 (3ds MaxのmParticlesなど)、伝熱の再現、可変粘度による融解や凝固の再現 (IoMeltやHoudiniなど)、粒状流への対応、混相流への対応 (RealFlow 2015.1以降など)、粘弾性への対応 (thinkingParticles 6 Drop 4以降のFluid Solver SPH VEなど)、流体のシェイプ形成力への対応 (BlenderのFluid Control、Houdini 16以降のSuction Fluid、Phoenix FD 3.0以降のBody Forceなど)、燃焼などの化学反応の再現、破壊・破れの再現、空気圧の再現、シミュレーション同士の相互作用の対応などに差異がある。また、帯電・磁力・分子間力などの電磁場に対応するものも存在している (BlenderのForce Fieldsなど)。流体と剛体等との相互作用に対応するマルチフィジクスプラグインが増えている (thinkingParticle 6以降、Effex 2.5以降など)。
パーティクルでは、パラメータベースのものやエクスプレッションベースのものが多かったが、現在はノードベースのパーティクルシステムが増えている (Houdini、3ds MaxのPFlow、SoftimageのICE、modoのパーティクルシステム、thinkingParticlesなど)。ノードベースのパーティクルシステムには、イベントドリブンのもの (PFlow)と、ルールベースのもの (Houdini、thinkingParticles、modoのパーティクルシステムなど)がある。パーティクルは、キーで動かしたり、物理演算を適用したり、簡易AIを適用できる。簡易AIは群集シミュレーションと呼ばれ、主に鳥、魚群、昆虫などの単純な生物の群集の再現に使われており、パーソナルスペースを保ちながら衝突回避して自然に動くことができる。また、動物や人間などの高度な動作の群集に適用できるシステムも存在し (SoftimageのCrowdFXや3ds Maxのcharacter studioのBipedやPopulateなど)、ノードベースのステートマシンの使えるものが増えている (#群集シミュレーション・人工知能(AI)シミュレーション)。
3DCGソフトウェアにおける物理シミュレーションには頂点ベース・エッジベース・サーフェスベースのものがあり主に芸術性を重視しているため、物理的な解析が必要な場合には連成解析に対応した解析ソフトウェアを使った方が良い。

ヘア・ファー

ヘアやファーはモデリング、ダイナミクス、レンダリングに至るまで独自に扱われることが多く、多くの統合ソフトウェアが標準で対応している (ZBrushのFiberMesh、3ds MaxのHair and Fur、MayaのnHairやXGen (元Walt Disney Pictures製)、SoftimageのXSI HairやICE Strands、CINEMA 4DのHair、HoudiniのFurオブジェクト、LightwaveのFiberFX、modoのHair Tools、Shadeのヘアーサロン、Blenderのパーティクルヘアーなど)。また、単独でファーを生成できるレンダラーもある (VRayのVRayFurなど)。
ソフトウェアによっては、ヘア同士の相互作用に未対応なものがある (3ds MaxのHair and Furなど)。
ゲームエンジンではメッシュベースのヘアが使われており、ヘアからメッシュへと変換可能なソフトウェアも存在する (Houdini 17以降のGenerate Hair Cardsツールなど)。

HDR合成のみ

IBLでは、露光ブラケット撮影されたRAW画像群からHDRマージ (HDR結合) を行い、その後、リニアな色空間のままHDR画像として保存することが行われている。そのため、HDRマージを行った後にトーンマッピングやガンマ変換を行わないでHDR画像のまま保存できるHDR合成ソフトウェアが必要となる。
RAW画像の読み込みが可能なHDR合成ソフトウェアにはHDRsoftのPhotomatix ProやSkylumのAurora HDR、オープンソースのLuminance HDR (旧qfpfsgui) など存在する。RAW現像ソフトウェアもHDR合成に対応してきている (Adobe Lightroom、Darktable (補正未対応)など)。

キューブマップ作成

ゲームエンジンに向けて、IBL用画像からSkyboxを生成したり、IBL用画像やSkyboxから拡散光 (Diffuse)、鏡面光 (Specular)、放射照度 (Irradiance)、放射輝度 (Radiance)などのキューブマップ(Lightprobe)を作成するためのツール。

大気・空

#景観生成ソフトウェアの多くは、空の生成にも対応している (Vue、Terragenなど)。多くの統合ソフトウェアも太陽と空の生成に対応している。雲の生成に対応しているものも多い (MayaのFluid ExamplesのCloudsAndFog、HoudiniのCloud FX、LightWaveのSkyTracer、Cinema 4DのPhysical Sky、Blender付属のCloud Generatorアドオン、Blender 2.79以降付属のDynamic Skyアドオンなど)。
虹の表示に対応しているもの (Cinema 4DのPhysical Skyなど)、薄明光線に対応しているもの (Cinema 4DのPhysical Skyなど)、月に対応しているもの (LightWaveのSkyTracer、Cinema 4DのPhysical Skyなど)、星や星座の表示に対応しているもの (Cinema 4DのPhysical Skyなど)も存在する。

ポストアニメーション製品の例

ジオメトリキャッシュなどを修正するソフトウェア。

エクステリア・インテリア両用の動画向けプロダクションレンダラー

大規模なエクステリア向きの単方向パストレース (PT)及び、複雑なライティング向きのレンダリング手法 (VCM、BDPT+MLT、Light Cache又は学習ベースの手法 (Path Guiding、AI Light等)) の両方に対応し、かつモーションブラー対応するもの。

VFX向きのプロダクションレンダラー

ディープ画像へのレンダリング又はCryptomatteに対応のもの。上述のV-Ray、RenderMan、Maxwell Render、Redshift及びOctane Renderも参照。

エクステリア向きの動画向けプロダクションレンダラー

単方向パストレース及びモーションブラー対応かつ前述の項に当てはまらないもの。

その他・不明

3Dモーションブラーに対応していないレンダラーであっても、中間のフレームをレンダリングして合成することでモーションブラーをかけたり (3ds Maxのマルチパス レンダリング効果、Cinema4DのSub-Frame Motion Blurなど)、スピードベクトルを使って2Dモーションブラーをかけること (Mayaの2D Motion Blur、Cinema 4DのVector Motion Blur、BlenderのコンポジットノードのVector Blurなど)は可能。ただし、速度や品質は3Dモーションブラーに劣る。
また、以前はラスタライザ(含スキャンライン及びREYES)とレイトレースのハイブリッドレンダリングが主流であったものの、その後、パストレースレンダリングが台頭した。しかし、標準でREYESスキャンラインレンダリングに対応するソフトウェア (PoserのFirefly、DAZ Studio搭載の3delightのREYESモード、HoudiniのMantraのREYESモードなど)や、スキャンライン/レイトレーシングハイブリッドレンダラーを搭載するソフトウェア (3ds MaxのScanline、MayaのMaya Software、EIASのEIAS Cameraなど) も残っている。その中には、ラジオシティに対応するものもある (3ds MaxのScanline (Lightscape Technologie製Lightscape由来)など)。

NPR向けレンダラー/シェーダー

標準でエッジレンダリングに対応する統合ソフトウェアが多い (3ds MaxのInk'n Paintマテリアル、3ds MaxのQuicksilverのVisual Style、MayaのMaya SoftwareのpfxToonシェーダ、Maya及び3ds Maxに搭載のArnold 5.1以降のToonシェーダー、Cinema 4DのSketch And Toon、LightWave 2018以降のCel Integrator (Super Cel Shader及びBESMシェーダーの後継)、BlenderのEdge RenderingやFreestyleなど)。また、標準でベクターレンダリングが可能な統合ソフトウェアも存在する (MayaのMaya Vector、Blender付属のFreestyle SVG Exporterアドオンなど)。

動画ノンリニア編集のみ

詳しくは動画編集ソフトウェアを参照。一般的に複数シーンやオーディオとの合成や編集フィニッシング(最終的なカラーコレクションやミキシングなどの映像・オーディオ調整)はこの段階で行われる。編集は画質を落とした状態で行い、後で高画質なものに適用することができる (プロキシ編集)。操作を効率化するために、独自のハードウェアが使われることもある。
VSTやAUなどのオーディオ編集 (DAW) ソフト向けプラグインを使える動画編集ソフトウェアが多い (Premiere Pro (VSTのみ)、DaVinci Resolve 12以降、Vegas Pro (VSTのみ)、Final Cut Pro (AUのみ)、EDIUS (VSTのみ)) ほか、近年はオーディオ編集にも強い動画編集ソフトウェアが増えている (Vegas Pro、Premiere Pro CC 2017.1以降のAudition統合、DaVinci Resolve 14以降のFairlight統合など)。なお、統合ソフトにおいても、シーン内でのオーディオ合成の対応 (Mayaのカメラシーケンサなど) や、3Dオーディオへの対応 (CINEMA 4D、Blender、Shade、各種ゲームエンジンなど) や、アニメーションとオーディオの連携に対応(3ds Max ProSound、Blenderなど)してきており、その段階で音声やSEを合成することもできるようになっている。
編集フィニッシングの後は、目的に合わせてテープレスシステム、エンコードソフトウェア、映画用オーサリングソフトウェア、光学ディスクオーサリングソフトウェア、ストリーミング向けフラグメント化ツールなどが使われる。

マッチムーブ

3Dトラッキングは、動画から特徴的な部分をトラッキングして、カメラやオブジェクトの位置や動作を算出でき、マッチムーブやデジタルメイクアップなどに必要となる。3Dトラッキングに対応するコンポジットソフトウェア (NUKE X/NUKE STUDIO、Autodesk Flame/Smoke、After Effect CC、HitFilm Pro (mocha搭載)、DaVinci Resolve 12など)も多い。3Dトラッキングに対応する統合ソフトウェアもある (Maya 2010以前のMaya Live、Blender、Cinema4Dなど)。
3Dトラッキングには点トラッキング、面トラッキング、ジオメトリートラッキングがある。LIDARスキャンしたデータに対応しているものもある(PFTrack 2012.3以降など)。また、影の表示や物理演算などに必要なマットオブジェクトの作成や、ジオメトリートラッキングやデジタルメイクアップなどを簡単にするために、動画や複数の写真からジオメトリやテクスチャを抽出するイメージベースモデリングに対応しているソフトウェアもある。
遮蔽物によるトラッキングミスを防ぐために、遮蔽物にマスクを切ることができるロトスコープ(ロトマスク)に対応しているソフトウェアが多い。ロトスコープ自体もトラッキングに連動して動かせるため、トラッキングソフトウェアではロトスコープを効率的に作ることができる。
撮影時に特徴点が足りなくて追加したトラッキングマーカーを除去するにはコンポジットソフトウェアが使われることが多いが、マーカー除去に対応しているマッチムーブソフトウェアも存在する。また、同様の手法によってワイヤーアクションで使ったワイヤーなどの不要な要素も削除することができる。
カメラの情報は正しく入力することが好ましいが、写真のexifに含まれているカメラ情報を読んだり、自動推定をサポートしているものも存在する。
また、光学式モーションキャプチャーとして使えるソフトウェアも存在する。変形するものはトラッキングしにくいため、反射材(パッシブマーカー)やLED(アクティブマーカー)などを装着した全身タイツを身に着けて撮影することが多い。マーカーが不要なマーカーレスモーションキャプチャもあるが、それに対応しているトラッキングソフトウェアは少ない。

3Dプリンタ出力

3Dプリンタへの出力は、閉じたサーフェスを持つSTL形式やVRML形式の使われることが多い。3D印刷可能なモデルの作成のために、メッシュの検証やクリーンアップに対応する3DCGソフトウェアが増えている (BlenderのMesh Analysis機能や3D Printing Toolboxアドオン、Shade3Dの3Dプリントアシスタント、LightWave 11.6以降のジオメトリクリーンアップツール、Cinema 4D R16以降のMesh Check機能、Meshmixerの3D Print Preview機能 (旧Autodesk 3D Print Utility)、ZBrush付属の3D Print Hubプラグイン (3D Print Exporterの後継) など)。支持構造の追加に対応するものもある (Meshmixerなど)。
3D印刷ソフトウェアでは、プリントする複数のオブジェクトを、プリントしやすい角度に回転して、プリント可能な範囲に詰め込む(多い場合は複数回に分ける)。また、素材の設定もこの段階で行う。
RepRapなどの熱溶解積層(FDM)式3Dプリンタ向けではG-codeジェネレータ(スライサー)を使ってSTLからG-Codeを生成して、それをプリンタに送信する。FDM式の場合、異なった色や素材(ABSやPLAなど)をプリントするために、複数のノズルが使われている。ノズルや素材によって温める温度や温度上昇速度(Ramp Rate)、押し出し速度が異なる。また、プリント中に倒れないように土台や支柱を追加したり、柔らかいうちに重ねて崩れてしまわないように冷却時間や冷却ファンを考慮してG-codeを生成する必要がある。
大きなものをプリントする場合、ジョイント付きで部品を複数に分ける必要あり、これを行うためにブーリアン機能を持つソフトウェアが使われる。また、そのための専用機能を持つソフトウェアが存在する (3D-CoatのSplit&Jointsツールなど)。

ショット管理・レビュー・画像シーケンス再生

openEXR、DPX、Cineonなどの画像シーケンスの再生、デジタルシネマカメラ形式の再生など。また、レビューソフトウェアでは、アノテーション付けや動画比較など。ショット管理では、バージョン管理など。

シェーダー管理及び共有

複数のプロジェクト間に跨るシェーダー及びマテリアルの管理機能を標準で搭載するソフトウェアも存在する (Blender 2.79以降に搭載のMaterial Libraryアドオン (旧Matlib VXアドオン)など)。

マテリアル集

標準で多くのプリセットマテリアルを含むレンダラー (Corona Renderer 1.7以降、RenderMan (MERL BRDFデータベース及びインクレディブル・ファミリーベース)など)や、公式サイト上で多数のマテリアルを無料提供しているレンダラー (RenderManのMaterial Pack、V-RayのV-Ray|Materials、Thea RenderのThea Libraries、Radeon ProRenderのProRender Material Libraryなど)も存在する。また、統合ソフトウェアに付属するものもある (3ds Max/Inventor/AutoCAD/Revit等に付属のAutodesk Material Library、KeyShotなど)。

遠隔操作

3DCGアプリケーションの遠隔操作には、OpenGL等に対応した一般的な遠隔操作ソフトウェアを使うことができる (リモートデスクトップ参照)

ライセンス監視

3DCGソフトウェアのフローティングライセンスの管理には、ライセンス管理ツールのFLEXlm (Autodesk、Thinkbox、Esri等が採用) やRLM  (Foundry、MAXON、Solid Angle等が採用) が使われており、それらの一括監視のためにライセンスモニタリングツールが使われている。ライセンスモニタリングツールについてはソフトウェア資産管理#ソフトウェア資産管理 (SAM) ソフトウェアを参照。

特定機能特化製品の例

このセクションにある物は、特定用途での利用に特化された物である。

科学可視化

一部のエンターテイメント作品においても、科学可視化ソフトウェアが使われている。