3DCGソフトウェア
3DCGソフトウェアとは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。
3DCGは主に
の工程に分かれている。作業の基幹となり多くの工程の調整が行える統合型ソフトウェアの他に、個別の機能に特化したソフトウェアも存在する。モデリングが中心となっているソフトウェアは「モデラー」、レンダリングが中心となっているソフトウェアは「レンダラー」と呼ぶ。
各種工程における機能においては、破壊的なものと、非破壊的なものが存在する。非破壊的なものは過去の操作の修正がしやすく、パラメータにキーフレームやドリブンキー/IPOドライバを入れることでアニメーションさせることもできる。しかし、メモリやディスク容量を消費するため、メモリサイズの大きなものを扱ったり細かな編集を繰り返したりといったことは苦手である。互換性の問題もあるため、他のソフトウェアとのやりとりには破壊的な形式に直すことも多かったが、最近は非破壊的な交換形式というものが開発されてきている。
3次元CADソフトウェアについては「CAD」、3次元GISソフトウェアについては「地理情報システム」を、仮想地球儀については「仮想地球」を、3次元プラネタリウムソフトウェアについては「」を参照。
3DCGが発案された当初は、一部の用途にのみ用いられる技術であり、多くの処理能力を必要とするため、高価な高性能ワークステーションや専用のハードウェアの必要になることが多く、そのため市場も小さく、ソフトウェアも高価であった。しかし、時代が進むにつれコンピュータの性能が向上し、高性能なコンピュータが一般に普及する事により、3DCGの市場が拡大し、ソフトウェアの低価格化・高機能化が進んだ。
3DCGソフトウェアは、科学からエンターテイメント、純粋芸術まで様々な用途に使われており、用途により必要な機能、必要な品質、環境、納期などが異なるため、それに合わせ多くの種類が存在する。必要なレベルに達しているソフトウェアのことを「Production Ready」であると表現する。一つの用途を達成するために、複数のソフトウェアが必要になることもあり、その場合にソフトウェア同士の連携が重要となる。
3DCGソフトウェアの主な用途としては、以下がある。
業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。かつてMac OS Xは、OpenCLの対応にも問題を抱えていたが、El Capitan (10.11)で解決された。ただし、今もmacOSは、GPUドライバがOpenGL 4.1止まりとなっている。一方Windowsは、64論理コアよりも多くのCPUコアを扱うためにソフトウェアの変更が必要となるため、64論理コア以下にしか対応していないソフトウェアが残っている (VRayは3.40.01以降対応)。
歴史的経緯により、建築業界や機械業界ではWindowsの使用が多い (AutoCADやSolidWorks、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が、PCゲームは主にDirectXが使われており、両方に対応することも多く、開発では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のアーマチャーなど)。
ソフトウェアによって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など)。
また、フライスルー(飛行モード)やウォークスルー(歩行モード)などのナビゲーションに対応するソフトウェアが増えている(SketchUpのWalk Tool (歩行のみ)、3ds MaxのWalkthrough Navigation (歩行のみ)、Maya 2015以降のWalk Tool (歩行のみ)、SoftimageのWalk/Fly tool、Modo 10.0v1以降のGame Navigation (歩行のみ)、BlenderのWalk/Flyモードなど)。なお、これらの機能は3D CAD (AutoCAD、CATIA、 SolidWorksなど)では標準的に実装されている。また、Softimageは、ドライブにも対応している。
ショートカットキー(ホットキー)は基本操作を含めソフトウェアによって大きく異なっている。基本操作の移動(move/grab)-回転(rotate)-拡大縮小(scale)だけでも、Mayaや3ds MaxではW-E-R、SoftimageではV-C-X (SRT(拡大縮小-回転-変形(transform))の形でXCVと言われることが多い)、BlenderではG-R-S、LightWaveではT-Y-H、Cinema 4DではE-R-T、HoudiniではT-R-Eというように、それぞれ違ったキーが使われている。
コンテキストメニューは、円形メニューを採用するものが増えている (Maya、Modo、Blender付属のPie Menus Officialアドオン、Houdini 16以降など)。
なお、UIの配色は、近年3DCG寄りのソフトウェアでは暗い色が基調にされること多く (Maya 2011以降、3ds Max 2011以降、LightWave 10以降、Shade 11以降など)、CAD寄りのソフトウェア(SketchUpやRhinocerosなど)では明るい色が基調にされることが多い。ダークテーマとライトテーマの切り替えが可能なソフトウェアも増えている。
共通の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、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は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を使うにはGraniteやAmplify Textureが必要となる)。
レギュラー画像では、歴史的経緯により、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やなど)。近年は、再圧縮での劣化の少ないVisually Losslessな中間形式 (ProResやDNxHDなど)で直接撮影できるカメラが増えている。色空間では、効率的にHDRを記録するために、Log系の色空間 (Cineon (*.cin)、Sony S-Log、RedLogFilm、ALEXA LOG-C ProRes、BMDFilm Log、P-10Log、Canon Logなど)で撮影することが増えている。また、大きな記録容量が必要になるものの、RAW形式 (、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テレビ向けでは、形式によるハードディスク/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 ()コーデック)、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までにしか対応していなかった)。
多くの3Dソフトウェアは、3Dマウス(6軸コントローラ)に対応している。また、多くのスカルプト・3Dペイントソフトは、タブレットの筆圧感知に対応している。
MIDIデバイスに標準で対応しているソフトウェアも存在する (3ds Max、Softimage、MotionBuilder、HoudiniのMIDI In CHOPなど)。
古くから存在するソフトウェアは、それぞれ独自のスクリプト言語を持つものが多い。
MayaはPerlやTclに似た文法のスクリプト(旧Wavefront Sophia)を持っており、3ds MaxはMAXScriptを持っており、HoudiniはC Shellに似た文法のHScriptを持っており、LightWaveはC言語に似た文法のLScriptを持っており、3D-CoatはC++に似た文法のを持っている。また、Cinema 4DはC++に似た文法のC.O.F.F.E.E.スクリプトを持っていた (R20で廃止)。
また、標準規格の拡張をした言語を採用しているソフトウェアや、OSに依存するという欠点があるもののOSのスクリプト機能を採用したソフトウェアも存在する。Rhinocerosは、VBScriptを拡張したRhinoscriptが使われている。Adobe After EffectsにおいてはECMAScriptを拡張したAdobe ExtendScriptが使われている。DAZ Studioでは、ECMASciptを拡張したQtScriptを更に拡張したDAZ Scriptが使われている。Softimageにおいては、Active Scriptingに対応しており、JScriptやVBScriptを使用することができた。
現在はPythonなどの一般的なスクリプト言語を使うことが増えている。しかし、APIの標準化などはされておらず、ソフトウェアによってAPIは大きく異なる。
リアルタイムではDirectXで採用されているCg/HLSL言語や、OpenGL/Vulkanで採用されているGLSL言語が良く使われている。また、Apple Metalで採用されているMetal Shading Languageも使われ始めている。エフェクト用の形式では、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言語や、NVIDIA mental rayのMetaSL (*.msl/*.xmsl)が良く使われていたほか、HoudiniのMantraレンダラのVEX言語 (*.vfl、RSL派生)やNVIDIA GelatoのGSLなどのレンダラー独自のシェーディング言語も存在していた。シェーダーの事前コンパイルが行われており、OSLは*.osoに、RSLはレンダラーに依り様々な拡張子に (RenderMan#互換レンダラー (RenderMan 20以前)参照) 、VEXは*.otlにネイティブコンパイルされる。
コンポジットソフトウェアでは、 ソフトウェアにより使用可能なシェーダー言語が異なる。Flame及びSmokeの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 で使われていた形式)や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///形式、Source EngineのSMD/DMX形式、CryENGINEのCGF/CAF形式、 Unreal Engine 3のPSK/PSA形式 (現在はFBXパイプラインに移行)、Gamebryo/Creation EngineのNIF形式、のABC形式、の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は拡張として、非可逆圧縮のOpen3DGCやDracoに対応している。
3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、形式などが使われる。
ノンリニア編集ではCMX3600ややなどの形式がやりとりに使われている。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における、HDTVにおける、デジタルシネマにおける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より前など)。
かつてPCモニターでは、sRGBが主流であったが、現在Adobe RGB対応のPCモニターが広まってきている。そのため、Webにおいても、従来sRGBが使われてきたが、現在Webブラウザの多くはICCプロファイルv2に対応しており、様々なカラースペースを使うことが可能となっている。しかし、Adobe RGB色空間での画像出力や、ICCプロファイルv2の埋め込みに対応していない3DCGソフトウェアも存在する。
色空間の変換方式は主にカラーマトリクス、1D-LUT、3D-LUTの三種類が存在し、色空間の変換パラメータの形式には、ICCプロファイルv2、ICCプロファイル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など多くの形式が存在している。オープンソースの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はMaya 2015 Extension 1以降、Houdini 16以降、Blender 2.64以降、Nuke 6.3v7以降、Mari 1.4以降、Modo 801以降、Vegas Pro 12以降、V-Ray 3.0以降、Clarisse iFX 2.0以降、Fusion 7以降、Krita 2.6以降などで使われている。
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とインダストリアル・ライト%26マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)の開発が進んでいる。各統合ソフトの他、Clarisse iFX、Unreal Engine 4.13以降、CryEngine、Poser 11以降、RealFlow、thinkingParticles 6.3以降、Vue xStream 2015以降、Nuke、Fusion、Flame/Smoke、HitFilm 4以降、PFTrack 2015以降、V-Ray、RenderMan、Maxwell Render V3以降、OctaneRender、Guerilla Render 1.3以降、KATANA、Esri CityEngine 2016以降など、多くのソフトウェアがAlembicに対応している。
スクリプトにおいては、以前は各ソフトで独自のスクリプトを採用していたが、現在は事実上の標準としてPythonも採用されるようになっている。Pythonを使うことでスクリプトの再利用性を高めることができ、特にパイプライン構築で重要となる。
UIでは、複数ソフトウェアに跨がって同じUIを使うプラグインのために、Qt及びそのPythonバインディング(PyQtやPySide)を提供するソフトウェアが増えている。Qt未搭載のソフトウェアにおいても、PyQtやPySideを別途インストールすることによって、同じUIを使うことができる。
ハードウェアメーカーがハードウェアの需要を起こすためにオープンソースで開発することもある。
2005年、Sony Computer Entertainmentの開発者によって開発された物理エンジンのBullet Physicsがオープンソースとして公開された。その後、2009年よりAMDがBullet Physicsの開発を支援している。Bullet Physicsに対応する3DCGソフトウェアは増えており、Blender、LightWave、Maya、Cheetah3D、Cinema 4D、modo、EIAS、Houdini、Maya付属のMayaBulletプラグイン、Carrara 8以降等が対応している (ソフトウェアによって対応具合は異なる)。
2011年7月、Intelが高速なフォトリアルレイトレースカーネルのEmbree raycasterをオープンソースとして公開した。CINEMA 4D R15やStrata Design 3D 8.1以降、V-Ray、LuxRenderなどが対応している。
2013年8月、オープンソースのBlenderに含まれるGPGPU対応のレイトレースレンダラ「Cycles」が、商用再利用が難しいGPLライセンスからApacheライセンスへと変更された。
括弧内は、搭載されているレンダラー。
統合型はシーンセットアップを基本に、モデリング、アニメーション、レンダリングなど多くの機能を備えた物である。最近はコンポジットやマッチムーブまで行えるソフトウェアが増えている。プラグインで機能を拡張できるものが多く、一つのソフトウェアだけで多くの作業が行えるほか、他のモデラー・レンダラー・モーション付けソフトウェアなどと組み合わせて作業パイプラインの中心の役割を担える。その他、モデリングなどの単機能目的のみで使われることも多い。一般的に統合ソフトは、標準機能同士の連携は優れているものの、他のソフトウェアに比べて一部の標準機能が古かったり低機能だったり直感性・操作性に乏しい場合が多々あるため、スクリプトやプラグインやソフトウェアを組み合わせて作業パイプラインを作ることが重要となる。
大きなプロジェクトでは、外部参照や、アセットの軽量な代理表現 (Mayaのシーン アセンブリなど)、アセット管理 (Mayaのアセットなど。#管理システム参照)が重要となる。
OpenCLやCUDAの普及及びOpenGLやDirectXの高機能化に伴い、ビューポートにおいて、PBR (物理シェーダー)やエフェクト等によるリッチな表示や、リアルタイム(プログレッシブ)レンダリングに対応するソフトウェアが増えている。レイアウトとレンダラーの統合は、特にライティング作業の効率化において重要となる。また、多くの統合ソフトウェアが外部レンダラによるビューポートでのプレビューレンダリングに対応しており、外部レンダラのビューポートへの統合が進んでいる。
並びは順不同である。も参照のこと。
※以下▽はアニメーション対応、▼はアニメーション対応(キャラクタアニメーション有り)、■はアニメーション対応(ダイナミクス有り、キャラクタアニメーション有り)、★はアニメーション対応(キャラクタアニメーション有り、ダイナミクス有り、パーティクル有り)のソフトウェア。
キャラクターアニメーションやエフェクトが弱いものの、NURBSやベジェサーフィスに強く、建築および製品可視化に使われる3DCGソフトウェア。マルチオブジェクト、アニメーション、ライティング及びレンダリング対応の3D-CADを含む。これらの用途には、一般的な3DCGソフトウェアも使われている。シーン構築、アニメーション、ライティング、レンダリングに対応する3D可視化ソフトウェアや3Dビジュアルコミュニケーションソフトウェアなど。
標準でストーリーボード作成向けの機能を持っている統合ソフトウェアも存在する (BlenderのGrease Pencilなど)。また、Photoshopもストーリーボード用途に使われている。
ドリーカメラリグやクレーンカメラリグなどの現実に即したカメラリグは、撮影前のプレビジュアライゼーションにも使われている。標準で搭載する統合ソフトウェアも存在する (Cinema 4D R15以降のCamera Crane、Blender 2.79以降に付属のAdd Camera Rigsアドオンなど)。
を手軽に行うためのリグやスクリプトなど。
LightWave (InterSense向け)、Unreal Engine 4のVirtual Camera Pluginなどがに対応している。
多くの物理ベースレンダラーは、リアルな被写界深度 (ボケの再現) や3Dモーションブラー (流し撮りや光跡の撮影に必要となるの再現など) に対応している。ローリングシャッター再現に対応するソフトウェアも増えている (Maya 2017以降および3ds Max 2018以降に付属のArnold、LightWave 11.5以降、Blender 2.77以降のCyclesなど)。多くのソフトウェアは、三点透視投影や垂直投影 (オルソ)に対応している。VRに向けて、魚眼投影や球形投影に対応するものも増えている。しかし、その他の投影法への対応具合はまちまちとなっている。レンズ歪みはソフトウェアにより異なるアルゴリズムが使われている。例えば、3DEqualizer方式 (3DEqualizer、FusionのLensDistortノード等が対応)、PFTrack方式 (PFTrack、FusionのLensDistortノード等が対応)、Cubic方式 (3ds Max 2016以降のPhysical Camera、SynthEyes、Boujou、V-Ray等が対応)が存在する。また、歪みデータを画像化したSTマップ等のテクスチャも存在し、NukeのSTMapノード、FusionのTextureノード、3ds MaxのPhysical Camera、BlenderのコンポジットノードのMap UVノード、PFTrack 2016以降、mocha ProのLens ModuleのRender Distortion Maps、V-Rayなど、多くのソフトウェアが対応している。ティルト/シフトレンズは建築パースや製品写真などで二点透視を実現するために使われている。また、シフトは非写実レンダリングにおける2Dパンにも使われている。
シフトに対応するソフトウェアは多い (3ds Max 2016以降のPhysical Camera、Mayaのmental rayのFilm Translate、ModoのFilm Offset、LightWaveのShift Camera、Blenderなど)。ティルトに対応するレンダラーも存在する (3ds MaxのレガシーカメラのCamera Correctionモディファイア、3ds Max 2016以降のPhysical Camera、RenderMan、V-Rayなど)。テレセントリックレンズは正投影 (オルソ)に似ているものの、ピントが存在する。一部のレンダラーはテレセントリックカメラに対応している (Mitsuba Renderなど)。
は2Dゲームやドット絵で良く使われており、2.5D的な表現が可能となる。単純な斜投影では円や球なども歪むため、それらが望ましくない場合は工夫が必要となる。
斜投影に標準で対応するソフトウェアも存在する (FormZなど)。斜投影に未対応のソフトウェアでも、垂直投影 (オルソ)にLatticeデフォーマを組み合わせるという方法も存在する。
パニーニ投影 (Vedutismo投影としても知られる) は絵画に使われている投影法であり、線の歪みを抑えながら広い視野を実現できる。標準で対応するソフトウェアも存在する (Unreal Engine 4など)。
嘘パースはアニメなどのNPRレンダリングに使われている。
VRに使われる、全天周動画や360°動画を作成するためのソフトウェア。多くの統合ソフトウェアは既に360°動画の作成に対応している。プラネタリウムなどのドーム投影には、主にフィッシュアイレンズが使われている (ミラーが使われるものもある)。フィッシュアイのレンダリングに対応するソフトウェアは少なくない (V-Ray、Arnold、Maxwell Render、LightWaveのAdvanced Camera、BlenderのCyclesなど) ものの、Lat Longのレンダリングのみにしか対応しないソフトウェアも多い。ただし、Lat Longやキューブマップからフィッシュアイへの変換に対応するソフトウェアが存在する (Pano2DomeやCube2Domeなど)。ドーム映像の確認は、AMATERAS Dome Player (ORIHALCON Technologies)などで可能。
ドーム投影ではドーム内反射 (Cross-Bounce)が起こるため、そのドーム内反射のシミュレーションに対応するソフトウェアも存在する (Domemaster Stereo Shaderなど)。
全天周動画とステレオ3D動画を組み合わせた全天周3D動画というものも存在する。
標準で対応しているソフトウェアも存在する (Blender付属のLight Field Toolsアドオン、OctaneRender 3以降など)。シーンのタイムワープは、高速度撮影 (スローモーション)や低速度撮影 (ファストモーション)の再現に使われており、それらに対応する統合ソフトウェアも存在する (Maya 2011以降のScene Time Warp、LightWave 9以降のTimewarp、BlenderのTime Remappingなど)。
また、カメラのみを通常速度で動かしながら、それ以外の時間を止めるフリーズタイムや、それ以外の時間をスローモーションにするバレットタイムに標準で対応するソフトウェアも存在する (LightWave 9以降のTimewarp機能など)。フリーズタイムやバレットタイムは、モーションブラーの扱いに注意が必要となる。
モデラーはモデリング機能に特化した物である。簡易的なレンダリング機能を持つ物や、プラグインモジュール等により高度なレンダリングが可能になる物もある。
多くの統合型ソフトウェアはモデリングにも対応している。また、一部のゲームエンジンもレベルデザイン/プロトタイピング向けとして、簡易モデリングに対応している。スカルプトモデリングだけでなく、ポリゴンモデリングでもKitbashが流行した。そのため、KitbashアセットもHard Surface Kitbash Library (Mark Van Haitsma)、TFMSTYLE Asset Pack (TFMSTYLE)、Hard Surface Kitbash Pack (Andrew Averkin)、Hard Surface Kitbash (Oleg Ushenok)など多数登場した。ブーリアンに対応する統合ソフトウェアやモデラーは多く、ブーリアン時のフィレットに対応するソフトウェアもある。
また、パーツの切り分けに向けた機能が存在するソフトウェアもある (ZBrush、3D-Coat、Blender 2.78以降に付属のCarver MTアドオンなど)。MOD作成に特化したものなど。3Dモデルの簡易編集に標準で対応する開発環境も存在する (Visual Studioのモデル エディターなど)。NURBS以外のスプラインモデリングに標準で対応している3DCGソフトウェアもある　(3ds MaxのEditable PatchやEdit Patchモディファイア、modoのPatch Curves、LightWaveのMake Spline Patch、Shade、Strata Design 3D、Animation:Masterなど)。
また、フリーハンドによるスプライン作成に対応する3DCGソフトウェアもある (3ds Max 2018.2以降 (旧Boomer Labs製SplineTools)、Blender 2.78以降など)。歴史的経緯などにより、NURBSサーフィスモデリングに対応している3DCGソフトウェアは多い (3ds Max、Maya、Houdini、Blender、Shade 17以降、Ayamなど)。また、3D-CADはNRUBSベースのものが多く、主に工業デザインや建築において使われるものの、グラフィックデザインなどのCG目的で使われることもある (Rhinoceros 3D、Fusion 360など)。NURBSスカルプトに対応するソフトウェアも存在する (MayaのArtisanなど)。NURBSソリッドモデリングに対応するソフトウェアもある (Ayamなど)。標準で対応している統合ソフトウェアが多い (MayaのMeasuring Tools、3ds MaxのMeasure Distance ToolやTape Helper、LightWaveのMeasure Tool、Cinema 4DのMeasure and Constructionツール、modoのRuler ToolやDimension Tool、BlenderのRuler & Protractor機能やBlender 2.78以降付属のMeasureItアドオン、Shade3D 16以降のメジャーツールなど)。
角度の計測に対応するソフトウェアも存在する (3ds MaxのProtractor Helper、modoのProtractor Tool、Blender 2.78以降付属のMeasureItアドオンなど)。表面積の計測に対応するソフトウェアも存在する (Blender 2.78以降付属のMeasureItアドオンなど)。スカルプトモデリングにおいてはメッシュの細かさが重要となるが、細かさを調整しながら編集するためには、手動で分割やリメッシュを繰り返しながら編集するという手法や、マルチレゾで分割数を変更しながら編集するという手法や、ダイナミックテッセレーションを使って編集するという手法がある。ダイナミックテッセレーションは基本的に三角ポリゴンにのみに対応している。
リトポロジは、基本的にフェイスへのスナップを使って行うため、多くのソフトウェアが対応している。スケッチや輪切りによるリトポロジもある。自動リトポロジも存在する。
オフラインレンダリング向けソフトウェアでは、Catmull-Clark及びLinear Subdivisionに対応するソフトウェアが多い。Loop SubdivisionやDoo-Sabinに対応しているソフトウェアも存在する (SoftimageのXSI-Doo-Sabin及びLoop Subdivision、TopMod、RenderMan 12以降のLoop Subdivisionなど)。一方、ゲームエンジンでは、 PN-Trianglesやフォンテッセレーション (Unity等)やPN-AEN (Unreal Engine、MayaのShaderFX等)などのアルゴリズムが使われている。
現在のところ、細分化ではC2連続性までしか作ることしかできない (4-8 Subdivisionを除く)ため、C3連続性 (で使われる)が必要な場合はNURBSモデリングに対応したソフトウェアが必要となる。標準で逆細分割に対応しているソフトウェアも存在する (BlenderのDecimate ModifierのUn-Subdivideなど)。
標準で法線の転送(転写)に対応するソフトウェアもある (SoftimageのGATOR、Mayaの「アトリビュートの転送」、BlenderのData Transferモディファイア、HoudiniのAttrib Transfer SOPなど)。また、Raycastノードを使って、法線転送を実現できるソフトウェアもある。法線の転送に未対応のソフトウェアにおいても、法線のベイクを使うことで似たようなことが可能。
また、頂点編集に標準で対応するソフトウェアもある (MODO 10.0v1以降など)。
標準で対応しているモデラーもある (ZBrushのMicroMeshなど)。
テクスチャにはいくつかの手法が使われる。従来はUV展開してAOなどのアタリをベイクしてから画像を書いたり、素材画像を元にUV展開することが多かった。しかし、UVの切れ目や歪みの問題などがあり、現在では3Dペイントを使ってオブジェクトに直接テクスチャを書いたり、画像を変形しながら貼り付けたりするのも一般的となってきている。また、解像度を気にしないで3Dペイントができる、Ptexという技術も登場している。
近年は物理ベースシェーディング (PBS)の普及により、従来とテクスチャの種類が異なる物理ベースシェーダー用のテクスチャ作成に対応したソフトウェアが増えている。
立体的なテクスチャの製作には2.5Dペイントも使われている。また、マットペイントでもテクスチャと同様に描画だけでなく、クローンブラシ(コピースタンプ、スタンプで描画、クローンツール)や修復ブラシ、ワープ変形などを使った写真の変形・加工・合成が使われている。マット絵自体は2D的であるが、被写界深度や視点変更のために深度が必要となるため、レイヤを使ったり、深度をペイントしたり、3Dモデルにカメラプロジェクションしたりといった手法が使われている。マットはテクスチャと異なり、コンポジットソフトウェアで合成されることも多い。
カラーマネージメントの普及に伴い、テクスチャには線形空間の浮動小数点画像(HDR画像)を使うことが増えており、2DペイントでもHDR画像やカラーマネージメントに対応しているソフトウェアを使うことが増えている。
ペイント以外では、パラメーターからテクスチャを生成するプロシージャルテクスチャというものが使われている。画像をタイル状に繰り返すタイルテクスチャでは、元画像を作るために画像をタイルテクスチャ向けに加工したり、タイルテクスチャ向けの画像を作成するためのソフトウェアがある。また、ノードを使ってテクスチャを非破壊編集できるソフトウェアもある。
その他、レンダラーを使ってレンダーパスをテクスチャ化するテクスチャベイク(法線焼き付けやAO焼き付けなど)も使われている。
統合型ソフトウェアやモデラーにも3Dペイント機能の搭載されているものがある (modo、Cinema4D、Maya、3ds MaxのViewport Canvas、Blender、Carrara、Cheetah3D、ZBrush、Mudbox、3D-Coatなど)。
標準で対応するソフトウェアも存在する(Unreal Engine 4.13以降のMesh Paintなど)。
統合型ソフトウェアやモデリングツールにも2Dペイント機能の搭載されているものがある (modo、Cinema4D、Maya、3ds MaxのViewport Canvasの2D View、BlenderのUV/Image Editor、Cheetah3D、ZBrush、Mudbox、3D-Coatなど)。
フローマップのペイントに対応する3Dペイントソフトウェア (MARI 1.6以降、Substance Painterなど)や、2Dペイントソフトウェア (KritaのTangentNormalBrushなど)も存在する。また、Flowmap生成に対応する統合ソフトウェアも存在する (Houdini 16.5以降のGame Development ToolsetのFlowmapノードなど)。
統合型ソフトウェアにもノードベースのテクスチャ作成の搭載されているものがある (Blenderのテクスチャノードなど)。
PBRでは、旧来のディフューズマップからライティングを取り除いてアルベドマップを生成する必要がある。デライティングの手法は、画像処理でハイライトと影を除去する手法や、メッシュ再構築して3Dモデルを生成した後にグレーボール/ミラーボールの撮影画像を使ってデライティングする手法、再構築した3Dモデルから法線マップとベント法線マップとAOマップと位置マップを生成してデライティングする手法 (UnityのDe-Lighting Tool等) などがある。
また、テクスチャ撮影時に、偏光フィルタを光源とレンズに使って交差偏光の状態にし、スペキュラ成分を除外して撮影するという手法や、メッシュ再構築向けの写真撮影時に、フラッシュを焚いて影を除去した物を用意するという手法もある。
ソフトウェアによって生成されるマップの品質に大きな違いが存在する。
ほぼ全ての統合型ソフトウェアはUV展開に対応しているものの、UV展開に特化したソフトウェアも存在する。展開アルゴリズムにおいては、かつてLSCMが主流であったが、ABFに対応するソフトウェアが増えており (Blender、Cinema4D R10.5、Lightwave 11.5、Cheetah3D 6.2など)、それよりも高品質とされるISOMAPに対応するソフトウェア (RizomUV、Softimage、Maya)や、その他のアルゴリズムを実装したソフトウェア (3D-CoatのGU (Globally Uniform)展開)も現れている。また、マルチタイルUVテクスチャに対応するソフトウェアが増えており、タイル間のUV島の移動が容易となっている。
UVスカルプトに対応しているソフトウェアもある (Maya 2018以降搭載のUnfold3D、Modo、Blenderなど)。
多くの統合ソフトウェアは標準でマテリアル編集機能を持っている。一部のレンダラーは、マテリアル編集に対応するGUIを備えている (V-RayのV-Ray Standalone Material Editor、Maxwell RenderのMaxwell Studio、Indigo Rendererなど)。
モディファイア (3ds Max、Blender、MODO 10.1以降、LightWave 2016以降など)や、ノード (Maya、3ds Max 2016以降のMax Creation Graph、Softimage 7.0以降のSoftimage ICE、HoudiniのSOP、Rhinoceros 3D 6以降に標準搭載の (旧Explicit History)など)によって、プロシージャルモデリング/アニメーションを行うことのできる統合ソフトウェアが増えている。
多彩なプリセットやアセットを使って、パラメータからオブジェクトを生成してモデリングするソフトウェア。他のモデラーで作ったモデルをインポートできるものや、簡単なレンダリング・アニメーションに対応しているものもある。
なお、サーフェスモデラーにおいても、プリセットをベースに組み合わせてモデリングしたり (Kitbash)、モディファイアスタックやコンストラクションヒストリやプロシージャルモデリングなどを使ってパラメトリックなオブジェクトを作ることはできる(Blender Animation Toolkitなど)。ただし、UIなどの問題からプラグインやアドオンが使われることも多い。
また、後からの変更は困難ではあるが、近年はスカルプトモデラーにおいても、アセットの合成が簡単に行えるようになってきている (meshmixerや3D-Coat V4のキットバッシングツールなど)。キャラクター作成に標準対応する3DCGソフトウェアもある (Poser、DAZ Studioなど)。
VueやTerragenなどの景観作成ソフトウェアは、マットペイントにも使われている。内部でL-systemを使っているものがある。植物生成向けの機能を持つ統合ソフトウェアや景観作成ソフトウェアもある (MayaのPaint Effects、HoudiniのL-system SOP、Blender内蔵のSaplingアドオン、VueのSolidGrowthなど)。草生成機能を持つレンダラーも存在する (Maxwell Renderなど)。また、草にはヘア・ファー向け機能も使われる。
標準で対応するソフトウェアも存在する (MayaのPaint Effectsなど)。スキャッターやリプリケータはオブジェクトを複製して配置するものであるが、その多くはオブジェクトのインスタンス化を行いメモリーを節約する。また、インスタンスのままレンダリングすることが行われており、それに対応するレンダラーが多い。
スキャッタリングやリプリケーティングに標準で対応する統合ソフトウェアは多い (MayaのXgen、Maya 2017 Update 3以降のMASHのWorld、Cinema 4DのCloner Object、LightWaveのInstance Generator、CarraraのReplicator、modoのリプリケータ、Houdini、Shade3Dのリプリケータ、Blenderのヘアパーティクルなど)。インスタンス化未対応の統合ソフトウェアに向けて、それに対応するツールを付属したレンダラーも存在する (V-Ray for 3ds Max付属のVRayInstancerプラグイン、Corona RendererのCorona Scatterツールなど)。階層的スキャッタリングに対応するソフトウェアも存在する (Houdini 17以降など)。ノードベースのものは#プロシージャルモデリングや#モーショングラフィクスを参照。
標準で対応する統合ソフトウェアも存在する (Maya 2017 Update 3以降のMASHのPlacerなど)。
道生成→建物生成を行う。生成にL-Systemを使用しているものがある (CityEngineなど)。
道路の生成に未対応のもの。
Interior Mappingを使ったものなど。#プロシージャルモデリングソフトウェアの中にも、道路作成用のプリセットを持つものが存在する (RailCloneなど)。
ケーブルは一般的にカテナリー曲線 (懸垂線)を描くため、リアルなケーブルの作成にはその考慮が必要となる。ケーブル作成に標準で対応するソフトウェアも存在する (3ds MaxのHose Extended Primitives、HoudiniのWire Object、Blender 2.79以降に付属のAdd Advanced ObjectsアドオンのPhysics Tools (旧Rope Creatorアドオン)、Unreal Engine 4のCable Componentプラグイン、CRYENGINEのRope Toolなど)。ケーブルの物理に標準対応するものも存在する (MayaのnHair、Cinema 4DのSpline Dynamics、HoudiniのWire Object、Unreal Engine 4のCable Componentプラグイン、CRYENGINEのRope Toolなど)ほか、ケーブルの物理に剛体、布もしくは軟体シミュレータを使用する方法も存在する。標準でプロシージャルな地形生成に対応しているソフトウェアも存在する (Houdini 16以降、Blender 2.79以降に付属のA.N.T.Landscapeなど)。
一部のツールはディティールマップ (セカンダリーマップ)にも対応している。地形ペイントを行うためのUnity用アセットが多数存在する (Terrain Former、Erosion Brush、Multiple Terrain Brush、Terrain Pressure Paint、Ramp Brushなど)。
標準で対応する統合ソフトウェアも存在する (3ds MaxのGarment Maker Modifier、Cinema 4DのDress-O-Matic、Blenderなど)。なお、アパレル産業向けは、CAD#服飾デザイン用CAD (アパレルCAD)を参照。
標準で建物作成向け機能を持っている統合ソフトウェアもある (3ds MaxのArchitectural Objects、Cinema 4D R16以降のContent BrowserのHouse BuilderやStaircases、Blender 2.78以降に付属のArchimeshアドオン、Blender 2.79以降に付属のArchipackアドオンなど)。SF映画などで使われるを行うもの。
フラクタル、ストレンジアトラクター、立体リサジュー図形、3Dスピログラフ、3Dセルオートマトンなど。なお、ノードベースのジェネレーティブアート作成は#プロシージャルモデリング参照。
分岐形成は雷、氷晶、地衣類、サンゴ、植物などのモデリングに使われている。分岐形成のアルゴリズムには、一般的な拡散律速凝集、雷の生成に使われる (DBM、拡散律速凝集と電界の組み合わせ)、高速なLaplacian Growth、自由なルールが作成可能で植物の生成にも向くL-Systemなどが存在する。L-Systemのルールが標準で使えるソフトウェアも存在する (HoudiniのL-System SOP、Cinema 4DのMoSplineのTurtleなど)。植物生成については#植物・植生生成も参照。
標準で雷生成に対応しているソフトウェアも存在する (MayaのCreate Lightning、Blender 2.79以降に付属のAdd Advanced ObjectsアドオンのLaplacian Lightning (旧Blender Lightning Generatorアドオン)など)。また、確率的L-System (HoudiniのL-system SOPなど)やパーティクルノード (3ds MaxのParticle Flowなど)によって雷を生成することも可能。
3Dスキャンには、レーザースキャナーを用いたレーザースキャン、一般的なカメラやステレオカメラを用いたイメージベースモデリング、カメラ及びプロジェクターを用いたなどの手法がある。
イメージベースモデリングは写真測量法を用いた3Dスキャンの一種で、複数の画像や動画から自動的又は半自動的にモデル生成を行うことができる。実物モデルはマッチムーブに良く使われるため、トラッキングソフトウェアにはイメージベースモデリング機能を持つものがある (boujouやPFTrackなど)。
Kinect等の深度カメラは内部で構造光3Dスキャンを用いているものの、そのデータは深度画像へと変換されて外部に渡される。
LiDARスキャンしたデータなどを取り込むためのもの。標準でポイントクラウドに対応する統合ソフトウェアもある (3ds Max 2015以降のPoint Cloud Object、Houdiniなど)。他用途のソフトウェアでも、ポイントクラウドの読み込みに対応するソフトウェアが存在する (Houdini 16以降のLIDAR Import SOP、3ds Max (Autodesk ReCapのRCS/RCP形式のみ対応)、Krakatoa 2.4以降のPRT Loader (PRT形式以外にも対応)、Autodesk ReCap 360など)。
大規模な3Dスキャンは、建築方面だけなく、科学捜査や法廷アニメーション、VFXでも行われている。
再メッシュ化に対応するソフトウェアには、BlenderのRemeshモディファイア、MeshLabの「Remeshing, Simplification and Reconstruction」、NetFabbのRemeshなどが存在する。
テクスチャの取り込みには、写真を画像処理で変換する手法、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パッケージなど)。いくつかのレンダラーにも独自のノードベースのシェーダー構築ツールが付属している (Arnold for Cinema 4DのArnold Shader Network Editor (ASNE)など)。
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のシェーダー デザイナーなど)。
シェーダーには、多くの形式が存在する (#シェーダー形式参照)。様々なシェーダー形式が存在するため、シェーダーの変換を行うソフトウェアが存在する。
標準でシェーダー変換ツールを提供している統合ソフトウェアやレンダーもある (Houdiniのslo2otl.py (旧rmands)やsdl2otl.pyやmids (MetaSLからOTL)、Unreal EngineのHLSL Cross Compiler (HLSLからGLSL)など)。
なお、オフラインレンダラー向けRSLシェーダーのコンパイルについては、RenderMan#互換レンダラー (RenderMan 20以前)を参照。
ポリゴンリダクションは多くの統合ソフトウェアに搭載されている (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以降など)。
Imposterはビルボードの発展形であり、ポッピングの起こらない八面体的Impostorが登場してLoDの延長として使われはじめた。
標準で旧式のImposter生成に対応するソフトウェアも存在する(HoudiniのGameDev Tools、Unreal Engine 4など)。
三角ストリップは古いGPUで有用であった。
これらのソフトウェアは主にゲームやリアルタイムレンダリング向けである。オフラインレンダリング向けでは、OpenEXRの圧縮機能を使うことが多い。
テクスチャ圧縮に使用可能な方式は、使用するAPIやGPUによって異なっており、モバイル向けとデスクトップ向けで異なる圧縮が使われている。また、2018年6月時点で、OpenGL ES 3.0未満にのみ対応するGPUを使っている消費者がまだ残っているため、レガシーな圧縮方式も未だ使われている。一方、デスクトップでは既にDirectX 11以降にほぼ移行した。
デスクトップ向けでは、Direct3D 10以前で主流となっていたDXTn (S3TC、BC1～3)がレガシーとなりつつあり、Direct3D 11で採用されたBPTC (BC6H/BC7)が普及しはじめている。モバイル向けでは、当初GPUベンダー毎に異なる圧縮方式しか使うことができなかった (Qualcomm製GPU専用のATC (ATITC)、PowerVR専用のPVRTC、NVIDIA製GPU用のDXTnなど) ものの、2010年のAndroid 2.2の登場により、GPUに依存しない圧縮方式として透明度非対応のETC1が使えるようになった。その後、OpenGL ES 3.0とMetalでETC1の後継であるETC2が採用され、透過度にもETC2+EACで対応した。
法線マップなどの互いのチャンネルに相関性がないテクスチャの圧縮では、法線マップをDXT5に詰める方式であるDXT5n (DXT5nm、BC3n)が存在したものの、その後、法線マップ向けのATI2 (3Dc、BC5、RGTC2、DXN2)がDirect3D 10やOpenGL 3.0に採用されて普及し、デスクトップで使われている。モバイルではQualcomm製GPUやNVIDIA製GPUなどの3Dcに対応する実装もあるが標準化されておらず、OpenGL ES 3.0ではEAC圧縮を使うのが標準となっている。
1chテクスチャ (高さマップなど) 向け圧縮では、デスクトップ向けのATI1 (3Dc+、DXT5A、BC4、RGTC1、DXN1)と、モバイル向けのEACが存在する。
なお、Android 5.0及びiPhone 6以降では、最新の圧縮方式であるASTCが使えるようになっている。ASTCは、1chテクスチャ、法線マップ等の2chテクスチャ、3Dテクスチャにも対応している。今後デスクトップにも導入される予定。
多くのレンダラーは、タイル化したMIPMAP(多解像度)テクスチャ生成ツールを含んでいる (V-Rayのimg2tiledexr、RenderManのtxmake、HoudiniのMantraのicp、3Delightのtdlmakeなど)。タイル化画像形式では、タイル化されたTiff形式やOpenEXR形式が良く使われている。
オープンソースのOpenImageIOにもMIPMAPテクスチャ生成ツールのmaketxが含まれており、それを採用しているレンダラーも存在する (Arnold Rendererなど)。
ドローコールの削減や、ライトマップの作成などに使われる。標準でUVアトラス作成に対応するソフトウェアも存在する (ModoのCreate UV ToolのAtlas/Atlas2、Blender付属のTextureAtlasアドオンなど)。標準で空洞を埋めるような高度なUVパッキングに対応するソフトウェアも存在する (Maya (Unfold3Dベース)、Houdini 16.5以降など)。Webやデモシーンなどにおいて、バイナリサイズや通信量を減らすためにシェーダーの縮小化 (minify) が行われている。複雑なデフォーマー等により生成された頂点アニメーションから、ボーン生成、スキニングウェイト生成、アニメーション生成を行うことで、ボーンアニメーションに変換できる。既存のボーン及びスキニングウェイトを使ってアニメーションのみ生成することや、既存のボーンを使ってスキニングウェイト及びアニメーション生成のみを行うことに対応するソフトウェアも存在する。
一部に標準で対応する統合ソフトウェアも存在する (Maya 2017 Update 3以降のBakeDeformerTool (スキニングウェイト及びアニメーション生成のみ)、Houdini 16.5以降のGame Development ToolsetのSkinning Converterなど)。また、Maya SOuPにもbake arbitrary deformationsやbake deformations to fk skeletonとして実装されている。インタラクティブコンテンツはゲームや、データ可視化などに使われている。インタラクティブなWeb向け3Dマルチメディア形式としてHTML5 (WebGL) がある。過去にはAdobe Shockwave形式 (Shockwave 3D)やAdobe Flash形式 (Stage3D)も存在した。
多くのゲームエンジンはリアルタイムでGIレンダリングが可能だが、その手法には、ラジオシティ法ベースのもの (Unity搭載/Unrel Engine対応のEnlightenなど)、Light Propagation Volume法 (Unreal EngineのLPVなど)、画面空間レイトレーシング (UNIGINEのSSRTGIなど)、ボクセルGI (CryENGINEのSVOTI、UNIGINEのVoxel GI、NVIDIA VXGI、Unity用アセットのSEGIなど) など様々なアルゴリズムが存在し、速度や正確性などに差異がある。ミドルウェアについては、3Dライブラリ#グローバルイルミネーション(GI) ライブラリを参照。
昔はゲームムービー（Cut Scene）に事前レンダリング（プリレンダリング）の映像を使用することが多かったが、その後、リアルタイムレンダリングによる演出映像（In-game Cinematics）が普及したため、昨今のゲームエディタには映像作成向けの機能が存在している（Unreal EngineのSequencer (Matineeの後継)、CryENGINEのCinematicレイヤー、UnityのTimelineやCinemachineパッケージ (元Cinemachine製) など)。一部のゲームエディタはVR動画の出力にも対応している (Unreal Engine 4.11以降に搭載のStereo Panoramic Movie Captureプラグイン、Unity 2018.1以降のUnity Recorderアセットなど)。その一方で、ゲームエンジンを付属する統合ソフトウェアも存在する (3ds Max Interactive (旧Autodesk Stingray) 付属の3ds Max 2018.1以降、 (BGE) 内蔵のBlenderなど)。
ゲーム環境では、PC、据え置きゲーム機、携帯ゲーム機、スマートフォンなどが存在し、それぞれ技術的制約が異なる (例えば非Microsoft環境でのDirectX非対応、iPhoneやXbox 360での実行時(JIT)コンパイラ禁止、Web環境でのJavascript言語/WebAssembly以外非対応など)ものの、現代のゲームエンジンはシェーダー変換(#シェーダー変換)や開発言語変換(IL2CPPやEmscriptenなど)などの技術によって、その多くに対応している。
昨今のゲームエンジンは、アセットストアを備えているものが多い (Unity Asset Store、UE4 Marketplace、CryEngine Marketplace、Creative MarketのStingray Resourcesなど)。
多くのゲームエンジンは標準で遮蔽カリングに対応しているものの、遮蔽カリングに特化したミドルウェアも存在する。
多くのゲームエンジンは標準でUI機能を持っている。3DのUIに対応するものも存在する。これらのプラグインに向けてUIを作成するためには、Adobe Animate (旧Adobe Flash Professional)が必要となる。
開発環境はGPUプロファイラやグラフィックデバッガーを搭載するものが増えている (Visual StudioのGPU Usageツール/Graphics Diagnosticsツール、Xcodeの、Visual Studio/Eclipse用プラグインのNVIDIA Nsightなど)。モダンなゲームエンジンの多くも独自のプロファイラを搭載している (Unity、Unreal Engine、CryENGINEなど) ほか、グラフィックデバッガーを搭載するものもある (UnityのFrame Debuggerなど)。また、プロファイラ内蔵の統合ソフトウェアも存在する (Maya 2016以降のパフォーマンス プロファイラ、Houdiniのパフォーマンスモニターペインなど)。
ヘッドマウントディスプレイ(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に使うトラッカーデバイスなどの入力機器には、主にプロトコルが使われている。
標準で対応するソフトウェアも存在する (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 ()、Plutonium/Neon (←Hybrid)、XPression (Ross Video)、Reality Virtual Studio (Zero Density)などのソリューションが存在する。国産では、3D-NIXUS (北海道日興通信)が存在する。
2018年現在、バーチャルセットシステムにゲームエンジンの一つUnreal Engineを組み込むことが流行している。
ノードベースのリギングが可能な統合ソフトウェアが存在する。標準で自動リグ (オートリグ)に対応する統合ソフトウェアもある。自動リグは、キャラクターピッカーの用意されているものが多い。運動学ソルバーには、順運動学ソルバー(FK Solver)と逆運動学ソルバー(IK Solver)があり、その二つの混ぜ合わせ(IK/FK Blending)が行われている。動く範囲を制限するために、拘束(コンストレイント)が使われる。IK/FKスイッチによって、IKソルバーとFKソルバーを切り替えながら、モーションを手付けすることが行われている。物理シミュレーションを行う場合は、ラグドールソルバーが必要となる (Bulletのラグドール、PhysXのDynamic Ragdollなど)。
ドリブンキーやスクリプト(IPOドライバ)によるリグ制御も行われている。Cinema 4Dに実装されていたSoft IKを模したもの (Cinema 4D R12以後はDynamic IKに置き換えられている)。C4Dの他にも標準で実装しているソフトウェアが存在している (LightWave 9.5以降、messiahStudio 3.1以降など)。
スキニングでは、幾つかの手法が使われる。ボーンとウェイトペイントが基本であり、ボーンは複数の頂点に影響を与える。自動でウェイトを割り当てる機能を持つソフトウェアも増えており、Heatmap Skinning(Bone Heat Weighting)に対応しているもの(Blender、Modo、Cheetah3D、Maya、3ds Max 2016 Extension 1以降)や、Geodesic Voxel bindingに対応しているもの (Maya 2015以降、3ds Max 2016 Extension 1以降)が存在する。多くのゲームエンジンでは、頂点あたりの変形ウェイト数に制限がある(2ウェイト、4ウェイト、8ウェイト)。単純なリグだと関節が破綻しやすいため、補助ボーンを使うことが一般的だが、軸毎のウェイトマップ (DAZ StudioのTriAx)、スフィリカルディフォームを使った補間 (MikotoやkeynoteやMMDのSDEFなど)、 (二重四元数) を使った補間、Delta Mushによる補正、モーフ変形連動による補正、ラティス(フリーフォーム)変形やケージ(ラップ)変形を連動させる手法 (Mayaのリジッド スキニングのラティス フレクサ、3ds Maxのギズモロールアウトのジョイントアングルデフォーマー/バルジアングルデフォーマー、BlenRigなど)、クラスタ変形を連動させる手法(Mayaのリジッド スキニングのクラスタ フレクサ、Cinema4D及びMaya 2016以降のクラスタ デフォーマなど)、テンションマップ (ストレスマップ)によるディスプレイスメントを使った皺の再現(Lightwave、Blender、modo 901以降など)、ジグルデフォーマ (MayaやC4Dなど)やソフトボディシミュレーションなどを使った揺れの再現、筋肉シミュレーションも使われている。ただし、これらのソフトウェア同士の互換性は低い。
標準でRBFによる補間に対応するソフトウェアも存在する (Unreal Engine 4のPose Driverノードなど)。多くの統合ソフトウェアは、モディファイア等により変形アニメーションが可能である。また、プロシージャルモデリング (#プロシージャルモデリング) ツールの多くは、アニメーションに使うことも可能となっている。一方、ゲームエンジンは、変形アニメーションへの対応があまり進んでいない。
ラティス(フリーフォーム)変形 (Maya、3ds MaxのFFDモディファイア、Softimage、Cinema 4DのFFD Deformer、MODOのLattice Effector、Houdini、ShadeのLattice Deformer、Strata DesignのDeformation lattice、BlenderのLatticeモディファイアなど)やケージ(ラップ)変形 (3ds MaxのSkin Wrapモディファイア、MayaのWrap Deformer、SoftimageのCage deformer、Cinema 4DのMesh Deformer、MODOのWrap Effector、HoudiniのLattice SOPのPoints deformer、ShadeのCage Modeling、BlenderのMesh Deformモディファイアなど)は、スキニングに使われているため、多くのソフトウェアが対応している。
トラッキングソフトウェアの中にもモーションキャプチャーに対応するものが存在する (PFTrack、Autodesk MatchMoverなど)。標準でオニオンスキニング (Ghosting)に対応している統合ソフトウェアもある (3ds Max、Maya、Cinema4D R11以降、modo 801以降、Houdini 15以降、messiahStudioなど)。また、ボーンのみのGhostingに対応するソフトウェアもある (LightWaveのIK Booster、3ds MaxのCATBone、Blenderなど)。
顔の自動リグに対応するソフトウェアも存在する (Houdini 17以降など)。
標準で対応するソフトウェアも存在する (Unreal Engine 4のWheeled Vehicle Movementコンポーネントなど)AIが重要となるゲームエンジンや多くの群集シミュレーションは、基本的にノードベースの状態機械(ステートマシン)やビヘイビアツリーを備えている (UnityのMecanim、Unreal EngineのAnimation Blueprints、CryENGINEのModular Behavior Treeなど)。
統合ソフトウェアは、基本的な群集シミュレーションにのみ対応しているものが多い (3ds MaxのCharacter StudioのCrowdコンポーネント、3ds Max 2014以降のPopulate機能 (旧Project Geppetto)、SoftimageのICE CrowdFX、LightwaveのFlocking、Houdini 14以降、BlenderのBoidsパーティクルなど)。
クロスシミュは布だけでなく金属板やプラスチックなどの可塑性物質にも使われているが、クロスシミュには力学ベースのものと、位置ベースのもの(PhysX、Havok Cloth、Maya nCloth、Bulletなど)が存在する。位置ベースの手法は、正確性が劣るものの、高速かつロバストである。
なお、ソフトウェアによっては、クロス上クロス(cloth-on-cloth)の相互作用を上手く扱えないものや、破けに未対応のものが存在する。また、ソフトボディでは風船などの再現が可能な体積保存に対応するものがある。リアルタイムクロスシミュレーションは、ゲームに使われるほか、ボディスキャンとの組み合わせでファッション可視化にも使われる方向に向かっている。高速なボロノイ分割などを使った事前分割による破壊のみに対応したソフトウェアが多い(MayaのCreate Shatter、Lightwave 11以降のFractureツール、ModoのShatter、Cinema 4D R18以降のFracture Voronoi object、HoudiniのVoronoi Fracture SOP、Houdini 17以降のRBD Material Fracture、Blender付属のCell Fractureアドオンなど)。正確な有限要素法(FEM)に対応しているソフトウェアも存在する (HoudiniやDMMなど)。基本的なものとして、変形を起こさずに衝突を再現する剛体シミュレーション、開いたメッシュに対し衝突と変形を再現するクロスシミュレーション、閉じたメッシュに対し衝突と変形を再現するソフトボディシミュレーションが存在する。衝突判定では、突き抜けを起こすアルゴリズムと、突き抜けを起こさないアルゴリズムが存在し、ソフトウェアによって対応具合が異なる。クロスシミュレーションやソフトボディシミュレーションでは高速なマススプリングモデルにのみ対応するソフトウェアがほとんどであるが、より正確な有限要素法(FEM)によるソフトボディシミュレーションに対応するソフトウェアも存在する (Houdiniなど)。
流体シミュレーションには複数の実装方法があり、パーティクルを流体のように動かす流体パーティクル (SPH法) に対応するものと、3D格子(グリッド)を使う流体シミュレーション (格子法)に対応するものがある。また、現在はパーティクルと格子を組み合わせたハイブリッド流体シミュレーションの一つであるFLIP法に対応するソフトウェアが増えており、FLIP法より安定したAPIC法に対応するソフトウェアも出始めている (Houdini 15以降のSwirly Kernelなど)。液体を扱うものではパーティクルベースであれどグリッドベースであれどメッシュ化が必要となり、メッシュ化のための専用プラグインも存在している (#メッシュ化)。気体(炎や煙)を扱うものでは、ボクセルの生成されるものが多い(FumeFXやCinema 4DのTurbulenceなど)。また、海洋の近似的生成 (Mayaの海洋シェーダ/テクスチャ、Houdini Ocean Toolkit、RealFlowのOcean Statistical Spectrumなど)や、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ソフトウェアにおける物理シミュレーションには頂点ベース・エッジベース・サーフェスベースのものがあり主に芸術性を重視しているため、物理的な解析が必要な場合には連成解析に対応した解析ソフトウェアを使った方が良い。
パーティクルからメッシュを生成するプラグイン。標準で対応しているソフトウェアも多い (MayaのnParticle to Polygons、HoudiniのParticle Fluid Surface SOPなど)。#景観生成ソフトウェアのいくつかは、 海洋のアニメーションにも対応している (VueやDreamScapeなど)。また、統合ソフトウェアやシミュレーションソフトウェアの中にも、標準で海洋のアニメーションに対応しているソフトウェアが存在する (Mayaの海洋シェーダ/テクスチャ、Maya 2017以降のBifröst Ocean Simulation System (BOSS)、HoudiniのOceans、BlenderのOcean Modifier、RealFlowのOcean Statistical Spectrumなど)。
ヘアやファーはモデリング、ダイナミクス、レンダリングに至るまで独自に扱われることが多く、多くの統合ソフトウェアが標準で対応している (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ツールなど)。
標準でモーショングラフィクス向け機能を持つ統合ソフトウェアもある (Cinema 4DのMoGraph、Maya 2016 Extension 2以降のMASH (元Mainframe North製)など)。また、下記の他、プロシージャルモデリングに対応するもの(#プロシージャルモデリング)の多くは、アニメーションも可能である。
標準で高度なテキストアニメーションに対応する統合ソフトウェアもある (3ds Max 2016 Extension 1以降のTextPlus!、Maya 2016 Extension 1以降の3D Type、Cinema 4DのMoTextなど)。
PSR (Position-Scale-Rotation)へのベイクと、PLA (Point Level Animation)へのベイクがある。また、PLAでは、頂点数の増減に対応するものとしないものがある。#ジオメトリーキャッシュも参照。
ライティングは、統合ソフトウェアで行うことも多いが、ライティングに特化したソフトウェアも存在する。Alembicパイプラインでは、レンダリング及びコンポジットするソフトウェア側でライティングを行うことがある (Clarisse iFXやV-Ray for NUKE、OctaneRender for NUKEなど)。
ライティング設定に対応したGUIを持つレンダリングソフトウェアも存在する (Maxwell RenderのMaxwell Studio、Guerilla RenderのGuerilla Render GUIなど)。ソフトボックスやアンブレラなどの現実の機材を模したもの。撮影前のプレビジュアライゼーションにも使われる。
標準で対応している統合ソフトウェアも存在する (3ds Max、Maya 2016 Extension 2以降のLight Editor、Blender付属のProperty Chartアドオン、UnityのLighting Explorerなど)。ライトリスターの付属するレンダラーも存在する (V-Ray Light Listerなど)。
標準で対応する統合ソフトウェアも存在する (MODO、3ds Max 2017以降のSun Positionerなど)。標準で対応するレンダラーも存在する(V-RayのVRayGeoSunなど)。
イメージベースドライティング(IBL)においては360°パノラマHDR画像が使われている。そのため、通常は、円周魚眼レンズやミラーボールなどを使って撮影したものを、スティッチソフトウェアで繋ぎ合わせる必要がある。近年は360度で撮影できるカメラも存在する (Ricoh Thetaなど)が、それらのカメラにおいても内部では二つ以上のレンズでの撮影となっているためスティッチが行われている。また、本体を動かすことでスティッチしながら360°パノラマ画像を撮れるスマートフォンアプリも存在する(Android 4.2以降に標準搭載されているPhoto Sphere モード、iPhone版Photosynthなど)。
また、IBLでは一般的なHDR画像よりも広いダイナミックレンジの画像が必要となる。そのため、光の強い場所では、露光ブラケット撮影を行い (Ricoh Thetaなど)、露光の異なる複数の画像をHDRマージする必要がある。地球上においては太陽光のエネルギーが場合によって24EV近くまで達するため、通常、屋外ではNDフィルターを組み合わせて撮影する必要が出てくる。しかし、屋外のIBL用HDR画像の直接撮影に耐えられる360度カメラも存在する (SpheroCam HDRなど) 。
なお、動画によるIBLも行われていなくはないが、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では、拡散反射向け、鏡面反射向け、背景向けで望ましい解像度が異なるため、複数のHDR画像を生成することが行われている。また、小さくて強い光源である太陽は、サンプリングの問題からIBLとは別に扱うことが望ましいため、HDR画像と併せて太陽光源の情報を保存することも行われている。これらを纏めて管理するものがsIBLである。HDRIに存在する環境光以外の光源を再現するために、HDR画像からのライト抽出が行われている。
ゲームエンジンに向けて、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など)も存在する。サーフィスベースであるため、下以外から見た雲などの再現はできない。
画像ベースのため、動く雲などの再現はできない。ライトペイントには、環境光源のIBL用画像に放射光を直接ペイントするものや、受光物の反射位置にペイントすることで面光源を追加するものなどがある。標準で前者に対応するソフトウェアも存在する (KeyShotのHDRI-EditorのPin機能など)。標準でライトレイヤーに対応しているレンダラーが存在する (V-RayのLight Select、Corona Renderer 1.5以降のLightMixer、Indigo、LuxRenderのLight Groups、Maxwell RenderのMultilight、ArionのLightMixerなど)。ライトレイヤーに未対応のレンダラーでも、ライトグループ毎のレンダリングを行い、コンポジットに渡すことで同等のことを行うことができる。
ポストプロセスで、より細かくライティングを弄りたい場合、マルチパスレンダリングが使われている (多くのレンダラが対応)。より細かなパスを作ることができるLPE (Light Path Expressions)に対応するレンダラも存在する (RenderMan、Iray、Arnold、Mantraなど)。
法線パスを使ったリライティングに対応するコンポジットソフトウェアも存在する (NUKEのRelight nodeなど)。
ジオメトリキャッシュなどを修正するソフトウェア。
ショットスカルプトは、破綻したシミュレーションの修正や、変形する物へのマッチムーブなどに使われている。レンダラーはレンダリング機能を提供する物である。単体動作可能なアプリケーションだけでなく、プラグインモジュールとして提供されている物も存在する。
レンダラーには、動画に向くものと、向かないものが存在する。動画に向くものは、フリッカー(ちらつき)が起こりにくく、高品質なモーションブラーにも対応している。また、レンダリング法により、マテリアルの表現できる範囲が異なる。それもあり、レンダラーにはあまり物理的でないものと、より物理的なものが存在する。物理ベースを謳うものであっても、幾何光学にのみ対応するものが殆どであり、光の分散やフルスペクトラルレンダリングに対応していないものも存在する。偏光・干渉・回折などの物理光学(波動光学)に対応するレンダラーは殆ど存在しない (Oceanが偏光に対応している)。
また、省メモリで大規模シーン向けのもの (RenderMan、Arnold等)、複雑なライティングに強いもの (Corona Renderer等)、高速なプレビュー向けのもの (Autodesk Raytracer等)、マテリアルプリセットの豊富なデジタルプロトタイピング向けのもの (KeyShot等)、エフェクト向けのもの (Krakatoa等)などが存在する。
3DCG統合ソフトウェアのレンダリングエンジンのいくつかは、3DCADなど別分野のソフトウェアにも提供されている (MODOやCinema4Dなど)。
エクステリア向きの単方向パストレース (PT)及び、インテリア向きのVCM (Vertex Connection and Merging)、BDPT+MLT又はLight Cacheの両方に対応し、かつモーションブラー対応するもの。
単方向パストレース対応で、かつモーションブラー及びディープ画像へのレンダリングに対応のもの。上述のV-Ray及びRenderManも参照。
単方向パストレース対応及び、VCM、BDPT+MLT又はLight Cache未対応で、かつモーションブラー対応及びディープ画像へのレンダリング未対応のもの。
プレビューレンダラーや、のビジュアライゼーションで使われるレンダラーなど。また、リアルタイムレンダラーはライティングやルックデブでも重要となる。
多くのプロダクションレンダラー (統合ソフトやCADソフト搭載のものを含む) は、プログレッシブ (漸進的) レンダリングにも対応している (対応表参照)。独自のレンダリングエンジンを搭載する3D可視化ソフトウェアもある (VRED、KeyShot、nStylerなど)。可視化向けレンダラーを搭載するソフトウェアも存在する (3ds Max 2017以降やAutoCADやRevitやFusion 360に搭載のAutodesk Raytracer (別名RapidRT、元Opticore製)など)。
ラスタライズベースの高度なハードウェアレンダリングに対応するソフトウェアも登場している (Autodesk製品に使われているOne Graphics System (3ds MaxのNitrous/QuicksilverやMayaのViewport 2.0/Hardware 2.0など)、Blender 2.8以降のEEVEE、各ゲームエンジンなど)。標準でベイク向けのレンダラーを持っているソフトウェアも存在する (MayaのTurtle、Unity 5.6以降のProgressive Lightmapperなど)。#UVアトラス/パッキングや#レンダリングミドルウェアも参照。近年は一般的なレンダラーがOpenVDBに対応してきており (対応表参照)、エフェクトのレンダリングに多用されはじめている。
学術を目的としているため、最適化よりも実装しやすさが優先されている。GPU未搭載のスーパーコンピュータで算出したデータの可視化は、昔は別途レンダリング用コンピュータ・クラスタを用意して行っていたが、現在はスーパーコンピュータで直接CPUレンダリングすることも行われている。3Dモーションブラーに対応していないレンダラーであっても、中間のフレームをレンダリングして合成することでモーションブラーをかけたり (3ds Maxのマルチパス レンダリング効果、Cinema4DのSub-Frame Motion Blur、Blender InternalのSampled 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、BlenderのBlender Internal、EIASのEIAS Cameraなど) も残っている。その中には、ラジオシティに対応するものもある (3ds MaxのScanline (Lightscape Technologie製Lightscape由来)、BlenderのBlender Internalなど)。
標準でエッジレンダリングに対応する統合ソフトウェアが多い (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アドオンなど)。
レイトレーシング処理ではノイズやファイアフライなどの誤差やアーティファクトが生じるため、デノイズやファイアフライ除去などが必要となる。
実写のデノイズと異なり3DCGのデノイズ処理では、拡散反射パスや鏡面反射パスなどの各レンダリングパスを別処理することが可能であるほか、ノイズの無いアルベド(カラー)パスや深度パスや法線パスをガイドとして使用することや、レイのヒストグラムの類似性を使うこともできる。また、不偏レンダリング (Unbiased rendering) では推定量に偏りが生じないため、その予測誤差は分散に起因する所が大きく、デノイズ処理に各パスの分散推定量や誤差推定量を使用したり (RenderMan等)、二組のレンダリング結果を使用したり (Altus等) といったことも行われている。
標準で高度なデノイザーを搭載するレンダラーが増えている (RenderMan 20以降、V-Ray 3.40以降、Corona Renderer 1.4以降、Guerilla Render 1.4.0b26以降、Maxwell Render 4.1以降 (Altusベース)、Blender 2.79以降のCycles、Arnold 5.1以降のNoice、appleseed 1.9以降 (ベース)、LuxCoreRender 2.1以降 (ベース)など)。
これらのデノイズはバイアスを発生させるため、動画ではフレームを跨いだデノイズ処理が必要となる (RenderManのDenoiseのCross-Frame Filtering、V-Rayの独自デノイザーなど)。なお、レンダラーによってはデノイズの他に分散推定量の大きい所でサンプリング数を増やす適応サンプリング (adaptive sampling) が使えるものの、適応サンプリングも局所的収束に陥った場合にバイアスが生じるため注意が必要となる。
また、機械学習を使用したデノイザーも登場している (NVIDIA OptiXのAI-accelerated denoiserなど)。機械学習ベースのデノイザーはサンプリング数が少ない時に強いため、プレビューレンダリングを中心に使われている。標準で搭載するレンダラーもある (finalRender Drop 1以降 (OptiXベース)、Arnold 5.1以降 (OptiXベース)、V-Ray Next以降 (OptiXベース)、Octane Render 4以降、Houdini 17以降 (OptiXベース)など)。
3DCG動画の後処理では、コンポジット、ノンリニア動画編集、カラーグレーディングが行われており、それら複数の工程に対応するソフトウェアも存在している。また、統合ソフトウェアの中には、これらの工程に対応するものもある (SoftimageのIllusion、HoudiniのCOP、BlenderのコンポジットノードやVSEなど。後述)。
コンポジットでは、レンダー済み素材や実写や生成エフェクトの調整及び合成、視覚(網膜、虹彩、脳など)やカメラ(レンズ、レンズフィルタ、フィルム、受光素子、転送回路、現像など)の再現、演出のための加工などを行う。カメラの再現は、レンダリング時にフィジカルカメラを使って行うこともある。
コンポジットはリニアなカラースペースの32bpc浮動小数点カラーが使われることが多い(リニアワークフロー)が、速度やサイズの関係からより低い色深度や非リニアな色空間が使われることもある。現実の光の強さを元にHDRレンダリングをした場合は、LDRに変換する際に、フィルムや眼球を模したトーンマッピングを行う必要がある。カラー調整はカラーコレクションやカラーグレーディングと呼ばれているが、色を補正する場合にカラーコレクション、色合いを加工する場合にカラーグレーディングと使い分けて呼ぶことも多い。独自のトーンマッピングが施されたデジカメ写真の場合は、カラーチャートなどを参考にトーンマッピングを逆変換してリニアカラースペースに戻す必要がある。また、写真フィルムをスキャンして使う場合は、フィルムの分光色素濃度曲線 (CMYカラースペース、補色波長のRGBとのズレ、吸収スペクトルの重複)や特性曲線 (露光量における濃度)、潜像退行・色褪せ、スキャナの特性などを参考にリニアカラースペースに戻す必要がある。
レンダーパスにおけるRGBA画像、ベロシティ(スピードベクトル)、Z深度、法線、UVなどの情報を劣化少なくコンポジットソフトウェアに渡すために、ロスレスの16bpc画像や16bpc/32bpc浮動小数階調画像が用いられる。また、オブジェクトIDやマテリアルIDも画像化されて渡される。なお、Z深度やIDなどの特殊なパスはアンチエイリアスすることができなく(又は出来たとしても品質が落ちる)、画像にアンチエイリアスをかけるとこれらのパスとのズレが生じる。この問題を避けるため、2倍もしくは4倍でレンダリングしておき、コンポジット後に縮小するという方法が使われている。より良い手法として、レンダリング時にアンチエイリアスにおける全てのサンプルを保存しておき、コンポジット処理した後にフィルタ合成するという Full Sample Anti-aliasing (FSA) に対応しているソフトウェアも存在する (Blenderなど)。
カメラデータの受け渡しには、汎用のFBX形式 (NUKEのCameraノードなどが読み込みに対応)、固有フォーマットのカメラベイク済みMayaプロジェクト(*.ma)や3ds MaxのRLA/RPF形式 (AEが読み込みに対応)の他、OpenEXRのメタデータ (NFXPluginsのEXRCameraや、vfxpipeのCamera Data from EXR (Vray)などが読み込みに対応)等が用いられる。コンポジットソフトウェアとの連携に標準で対応する統合ソフトウェアも存在する (3ds MaxのCompositor Link、Maya 2016 Extension 2以降のSend to AE、LightWaveのGoAEなど)。また、その逆に、統合ソフトウェアとの連携に対応するコンポジットソフトウェアも存在する (After EffectsのCINEWAREなど)。
3Dと実写合成のためには、クロマキー合成やロトスコープの機能が使われる。ロトスコープのために、ベクトルマスク作成に対応しているソフトが多い。また、トラッキング機能を搭載するものも増えており、トラッキングによってベクトルマスクを変形させることもできるようになっている。
近年ローリングシャッターを持つスチルカメラによる動画撮影も増えており、ローリングシャッターを修復できるソフトウェアも存在している(After Effects、FoundryのROLLINGSHUTTERプラグイン(ディスコン)など)が、修復には限界があるためVFXには不向きである。どうしてもローリングシャッターを持つ映像を素材として使う場合は、ローリングシャッター除去してトラッキングした後、合成する3DCG素材のレンダリングでローリングシャッターの再現を行うのが良いとされる。
キーヤーには、2D色空間ベースのキーヤー (FlameのDiamond Keyer、NukeやAfter EffectsのKeylightなど) と、3D色空間ベースのキーヤー (Primatteや、Flame/SmokeのModular Keyer及びMaster Keyerなど) が存在する。2D色空間ベースのキーヤーのKeylight等は、原色以外の色のキーイングに弱い。
また、コンポジットを馴染ませるためにはライトラップが必要となる。これらはエフェクト集にも含まれている。
Z深度は、コンポジットに役立つほか、ステレオ3D動画への変換にも使われる。深度生成に対応するトラッキングソフトウェアやコンポジットソフトウェアも存在する (NUKEXのDepthGeneratorノード、PFTrack 2017以降 (旧PFDepth)など)。詳しくは動画編集ソフトウェアを参照。一般的に複数シーンやオーディオとの合成や編集フィニッシング(最終的なカラーコレクションやミキシングなどの映像・オーディオ調整)はこの段階で行われる。編集は画質を落とした状態で行い、後で高画質なものに適用することができる (プロキシ編集)。操作を効率化するために、独自のハードウェアが使われることもある。
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トラッキングソフトウェアは、静止画や三脚固定ショットにも対応している (SynthEyesのTripod and Lock-off Shot Alignment、PFTrackのEstimate Focalなど)。また、近年は統合ソフトウェアでも、それらに標準で対応するものが現れている (3ds Max 2014以降のPerspective Match、Cinema 4D R14以降のCamera Calibrator、LightWave 2015以降のMatch Perspective、modo 902以降のCamera Matcher、SketchUpのMatch Photoなど)。
2Dソフトウェアはプロジェクションマッピングを参照。
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ツールなど)。
CAM向けの機能を標準で対応しているソフトウェアも存在する (Fusion 360など)。
3Dモデルから、ペーパークラフトの出力ができる。複雑にならないようにするためには、ポリゴン数の削減が必要になる。標準で対応するソフトウェアも存在する (Blender 2.79以降に付属のExport Paper Modelアドオンなど)。
カッティングマシンを用いることで、切る手間を減らすことができる。
糊代を生成しないもの。標準で対応するソフトウェアも存在する (RhinocerosのUnrollSrfやSmashなど)。Facebookなど一部のSNSサイトも3Dモデル投稿に対応してきている。
多くの統合ソフトウェアは既にテキストエディタを持っており、シンタックスハイライトなどに対応している (MayaやSoftimageのスクリプトエディタ、3ds MaxのMAXScript エディタ、BlenderのText Editorなど)。コード自動補完に対応しているものも存在する (Maya、3ds Maxなど)。
Pythonスクリプトの開発では、外部のPython向けIDE (PyCharm、EclipseのPyDev、Wing IDEなど)やデバッガー(Winpdbなど)からでも、リモートデバッギングが可能。標準でデバッガーを搭載するソフトウェアもある (Softimage付属のPyWin Debuggerなど)。シェーダー開発については、#シェーダー構築/ルックデブを参照。
プロジェクト管理 (手順計画、日程計画、タスク管理、報告・通知管理、メモ管理、自動集計)、モデルやショットなどのデジタルアセット管理 (バージョン管理、異形管理、依存管理、レビュー、パブリッシング)など。レビューのための機能として、タグ付け機能、コメント機能、動画ストリーミング、自動的なターンテーブル動画の生成などが搭載されているものもある。レビュー用動画作成のために、レンダーファーム管理ソフトと連携できるシステムもある。
ファイル内部でのバージョン管理や異形管理に標準で対応している統合ソフトウェアも存在する (3ds MaxのScene States、modoのRender Passes、HoudiniのTakes、Cinema 4D R17以降のTakeシステムなど)。openEXR、DPX、Cineonなどの画像シーケンスの再生、デジタルシネマカメラ形式の再生など。また、レビューソフトウェアでは、アノテーション付けや動画比較など。ショット管理では、バージョン管理など。
標準で対応しているソフトウェアも存在する (DaVinci ResolveのPostgreSQLサーバーによる共有 (同時作業はStudio版のみ)、Fusion Studio付属のStudio Player (Generationの後継)、SCRATCHのSCRATCH Remote機能、Autodesk FlameのStone及びWireなど)。
シーケンス再生ツールが付属するソフトウェアは多い (MayaのFCheck、3ds MaxのRAM Player、SoftimageのSoftimage Flipbook、Cinema 4DのPicture Viewer、HoudiniのMPlay、BlenderのAnimation Playbackウインドウ (blender -a)、RenderManのit、3delightのi-display、Nuke 9以降のNative Flipbookなど)。その中には、動画のA/B比較に対応するものも存在する (3ds MaxのRAM Player、HoudiniのMPlay、NukeのNative Flipbookなど)。
静止画のみの独自のフレームバッファーに対応するレンダラーも多い (V-RayのV-Ray Frame Buffer、ArnoldのArnold RenderViewなど)。シーケンス再生にも対応するものは#シーケンス再生のみ参照。
アセットのプレビュー付きブラウズには、標準で対応する統合ソフトウェアが多い (Maya 2016以前のVisor、Maya 2017以降のContent Browser、3ds MaxのAsset Browser、SoftimageのBrowserのThumbnailモード、modoのPreset Browser、Cinema 4DのContent Browser、BlenderのFile BrowserのThumbnailsモードなど)。
一部のアセットの管理に標準で搭載するレンダラーも存在する (RenderMan for Maya 21以降のRenderMan Preset Browserなど)。
複数のプロジェクト間に跨るシェーダー及びマテリアルの管理機能を標準で搭載するソフトウェアも存在する (Blender 2.79以降に搭載のMaterial Libraryアドオン (旧Matlib VXアドオン)など)。
標準で多くのプリセットマテリアルを含むレンダラー (Corona Renderer 1.7以降、RenderMan (MERL BRDFデータベース及びインクレディブル・ファミリーベース)、Radeon ProRenderのAMD Material Libraryなど)や、公式サイト上で多数のマテリアルを無料提供しているレンダラー (RenderManのThe Big RenderMan 20 Library (ライトリグを含む)やRenderMan 21 Material Library、V-RayのV-Ray|Materials、Thea RenderのThea Libraries、mental rayのMetaSL Material Libraryなど)も存在する。また、統合ソフトウェアに付属するものもある (3ds Max/Inventor/AutoCAD/Revit等に付属のAutodesk Material Library、KeyShotなど)。
公式のマテリアル/テクスチャ等リソース共有サイトが用意されているソフトウェアもある (Substance Painter/DesignerのSubstance Share、ZBrushのMatCap/Alpha/Texture Library、RenderManのRenderMan Community、Indigo RendererのMaterial database、LuxRenderのMaterials DB、Maxwell RenderのFREE resources libraryなど)。レンダーファーム管理ソフトウェアは、3DCGやコンポジットのレンダリングだけでなく、シミュレーションやファイル変換等にも使うことができる。
一部の統合ソフトウェアやレンダラーは独自の分散処理機能を持っている (modo、Cinema 4DのTeam Render、HoudiniのHQueue Render/HQueue Simulation、Blender付属のNetwork Renderアドオン、V-RayのV-Ray DR/V-Ray Swarm、Maxwell RenderのFloating版のMaxwell Manager、Keyshotなど) ものの、他のソフトウェアの調整に難のあるものが多い。
標準でクラウドレンダリングに対応する統合ソフトウェアも存在する (3ds MaxのA360 Rendering、HoudiniのHQueue RenderのCloudなど)。また、独自のクラウドレンダリングサービスを用意しているレンダリングソフトウェアも存在する (OctaneRenderのOctaneRender Cloud、V-RayのV-Ray Cloudなど)。高度なスクリプト/プラグイン管理に標準で対応するものも存在する (SketchUp 2017以降のExtension Managerなど)。
3DCGソフトウェアには標準、もしくはプラグインを入れることによって様々なファイル形式でインポートやエクスポートすることができる。しかし、ソフトウェアによって対応形式や対応具合が異なるため、作業パイプラインによっては、単体コンバータを使ったり、使っているソフトウェアとは別の3DCGソフトウェアをファイルコンバータとして使う必要が出てくる。
ポイントクラウドについては#ポイントクラウド取り込み・編集を参照
多くの統合ソフトウェアは、標準で一部のCADファイル形式のインポートに対応している (Mayaや3ds Max等に搭載されていたAutodesk DirectConnect、Maya 2016 Extension 2及び3ds Max 2016以降に搭載のAutodesk Translation Framework、Cinema 4D R20以降、LightWaveやCinema 4DやmodoやHoudiniのDXFインポータ、modoの3DMインポータ、Blender付属のDXF Importerアドオン、Carrara ProのCADインポータ (旧CadStyle、Amapi用CADanceの後継)など) ものの、互換性の問題も大きい。
Adobe Illustrator 8までの形式に対応しているソフトウェアは多い (Maya、3ds Max、Softimage、Houdini、LightWave、modo、Cinema 4D、Strata 3Dなど)。ただし、それ以降のPDF互換形式にも対応するものは少ない。
数値標高モデル(DEM)には様々な形式がある。3ds Maxは標準でLandXML形式 (*.xml)、DEM形式 (*.dem)、SDTS DEM形式 (*.ddf)の読み込みに対応している。Vue xStream 2015以降は標準で、、/DDF及びGeoTIFF形式の読み込みに対応している。HoudiniはGame Development ToolsetでOpenStreetMap形式の読み込みに対応している。OSに標準で付属するものも存在する (Windows 10 Creators Update以降の3D Viewer (旧Mixed Reality Viewer←View 3D)など)。以前は連番objファイルなどが使われていたが、現在はオープンソースのAlembic形式が普及してきている。標準で対応する統合ソフトウェアやレンダラーもある (3ds Max 2017以降のScene converter、Maya 2017以降のmrShadersToArnold.py、Blender 2.78以降に付属のMaterials Utils Specialsアドオン、V-RayのVRmat Converter、Maxwell RenderのCinema Convert Materials、NOX RendererのVrayToNox.ms、Octane RenderのOctane Material Converter、LuxRender 1.6以降のConvert Cycles Sceneなど)。
標準でソフトウェア連動(Live Linking)に対応するソフトウェアも存在する(Maya 2017 Update 3以降とAfter Effects、After EffectsとCinema 4D、Unreal Engine 4.19以降とMaya/MotionBuilderなど)。
色弱(色覚異常)シミュレータが標準で内蔵されているソフトウェアもある (Unreal Engine 4、Photoshopなど)。色弱者対応のデザインの標準として、カラーユニバーサルデザインが存在する。3DCGアプリケーションの遠隔操作には、GPUに対応した遠隔操作ソフトウェアが必要となる。
3DCGアプリケーションのスクリーンキャストには、GPUに対応したスクリーンキャストソフトウェアが必要となる。標準でスクリーンキャストに対応している統合ソフトウェアも存在する (Blenderなど)。また、3DCGでは複雑な操作を行うため、ユーザーの操作を表示することが望ましく、そのために別のソフトウェアが必要になる場合もある。
3DCGソフトウェアのフローティングライセンスの管理には、ライセンス管理ツールのFLEXlm (Autodesk、Thinkbox、Esri等が採用) や (Foundry、Solid Angle等が採用) が使われており、それらの一括監視のためにライセンスモニタリングツールが使われている。ライセンスモニタリングツールについてはソフトウェア資産管理#ソフトウェア資産管理 (SAM) ソフトウェアを参照。
このセクションにある物は、特定用途での利用に特化された物である。
一部のエンターテイメント作品においても、科学可視化ソフトウェアが使われている。
建築ビジュアライゼーションには、3ds Maxなどの統合ソフトウェアや、Unreal Engineなどのゲームエンジンが使われているが、建築ビジュアライゼーションに特化したソフトウェアも存在する。地形作成、植生作成、季節の設定、人混み及び都市交通シミュレーション、それらのためのアセットライブラリの含まれているものが多い。
物理ベースのレンダラーは現実をシミュレーションするため、照明解析に使うことができ、それに対応するソフトウェアも存在する (、irayのIrradianceレンダーエレメント、V-RayのVRayLightMeterヘルパー及びV-Ray NextのVRayLightingAnalysisレンダーエレメント、Luxrender 1.5以降のIRRADIANCE AOVなど)。
標準で照明解析に対応するソフトウェアも存在した (3ds Maxの照明分析アシスタント (mental ray必須) など)。Poserや3ds Maxなどが使われている。
可視化やバーチャルトレーニングの作成など。