3DCGソフトウェア

3DCGソフトウェアは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。
3DCGは主に
の工程に分かれている。作業の基幹となり多くの工程の調整が行える統合型ソフトウェアの他に、個別の機能に特化したソフトウェアも存在する。モデリングが中心となっているソフトウェアは「モデラー」、レンダリングが中心となっているソフトウェアは「レンダラー」と呼ぶ。
各種工程における機能においては、破壊的なものと、非破壊的なものが存在する。非破壊的なものは過去の操作の修正がしやすく、パラメータにキーフレームやドリブンキー/IPOドライバを入れることでアニメーションさせることもできる。しかし、メモリやディスク容量を消費するため、メモリサイズの大きなものを扱ったり細かな編集を繰り返したりといったことは苦手である。互換性の問題もあるため、他のソフトウェアとのやりとりには破壊的な形式に直すことも多かったが、最近は非破壊的な交換形式というものが開発されてきている。
3次元CADソフトウェアについては「CAD」、3次元GISソフトウェアについては「地理情報システム」を、仮想地球儀については「仮想地球」を、3次元プラネタリウムソフトウェアについては「プラネタリウムソフトウェア（英語版）」を参照。
3DCGが発案された当初は一部の用途にのみ用いられる技術であり、多くの処理能力に高価な高性能ワークステーションや専用のハードウェアが必要となることが多いために市場も小さく、ソフトウェアも高価であった。しかし、時代が進むにつれてコンピュータの性能が向上し、高性能なコンピュータが一般に普及することにより、3DCGの市場が拡大してソフトウェアの低価格化・高機能化が進んだ。
3DCGソフトウェアは、科学からエンターテイメント、純粋芸術までさまざまな用途に使われており、用途によって必要な機能、必要な品質、環境、納期などが異なるため、それに合わせて多くの種類が存在する。必要なレベルに達しているソフトウェアのことを「Production Ready」であると表現する。1つの用途を達成するために複数のソフトウェアが必要になることもあり、その場合にソフトウェア同士の連携が重要となる。
3DCGソフトウェアの主な用途としては、以下のものがある。
歴史的経緯により、建築業界や機械業界ではWindowsの使用が（SolidWorksやInventorやAutoCAD、3ds Maxなど）、グラフィックデザイン業界ではmacOSの使用が多い。映像業界ではWindowsだけでなくmacOSもよく使われており、ポストプロダクション会社ではUnix系ワークステーションも使われている（Autodesk Flameなど）。日本のアニメ業界ではWindowsの使用が多い。ゲーム業界では、プラットフォームによってOpenGL/Vulkan/DirectX/その他の独自APIが使われており、複数APIに対応することも多く、開発ではWindowsの使用が増えている。macOS/iOS用ゲームの開発ではmacOSも使われている。映画業界ではワークステーションや巨大なレンダーファームを必要としており、スケーラビリティの高いUnix系のOSの使用が多い。かつてはSGI IRIXが、現在はLinuxが主流となっている。業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。例えば映画向けのハイエンド・ソフトウェアではLinux版が作られたあと、他のOSに移植されている（例えば3D-EqualizerやMARI、Autodesk Flameなど）。
また視覚効果協会 (VES) の協力によってソフトウェア間の互換性を高めるための複数OS対応共通プラットフォーム「VFX Reference Platform」が定められており、3DCGソフトウェアではその規定にあるプログラミング環境およびライブラリの使用が一般的となっている。この VFX Reference Platform は複数のソフトウェアにまたがる製作パイプラインの構築を簡単にするほか、レンダリング共通API「Hydra Render Delegate」での連携時の互換性確保にも重要となっている。
なおデスクトップ/ラップトップの3DグラフィックスAPIは長らくマルチプラットフォームで使えるOpenGLを採用したものが多く、今もその後継のVulkanがマルチプラットフォームで使えるものとして存在しているものの、WindowsはDirect3D APIを、AppleのmacOSはMetal APIを重視するようになっており（AppleのOpenGL対応は4.1止まりで非推奨）、それぞれのAPIに対応するソフトウェアも増えている。一方、モバイルデバイスの3DグラフィックスAPIは長らくOpenGLの簡易版であるOpenGL ESが標準となっていたものの、その後継ではデスクトップ同様Vulkanが使われるようになったほか、AppleのiOSでもデスクトップ同様のMetal APIが使われるようになっている。
また3DCGに使われる異種汎用計算のAPIではホストとゲストの分かれた汎用のOpenCLがだんだん使われなくなり、ホストとゲストの連携の密なCUDA/HIP/Intel oneAPI SYCLの使用が広がっている。なおAppleはその領域でもMetal APIを推し進めている（OpenCLは非推奨化され、CUDAはmacOS対応を終了した）。
デスクトップ/ラップトップのCPUではx64アーキテクチャが、モバイルデバイスのCPUではARMアーキテクチャが一般的となっており、CPUアーキテクチャによる分断も存在した。しかしながら2012年にはMicrosoft Surfaceと共にARM版Windowsが登場し、また2020年にはAppleがデスクトップ向けCPUにもARMアーキテクチャを採用し、非モバイル向けソフトウェアでもARMアーキテクチャにネイティブで対応するものが増えていった。
OS間の進む分断化によってmacOS版の提供を取りやめるソフトウェアも登場している一方、モバイルデバイスがデスクトップに近づくにつれてモバイルデバイスに対応するデスクトップソフトウェアも登場している。
ソフトウェアによって用語の違いが存在する。アメリカ英語とイギリス英語の違い（ColorとColourなど）をはじめ、訳語の違い（ノーマルと法線、シームと継ぎ目など）や、呼び方が違うもの（カラーランプ〈Rampは傾斜〉とグラデーション、モーフとモーフィングとブレンドシェイプとShape Interpとモーフターゲットとシェイプキー、エクスプレッションとドライバ、ShellとSolidifyとThickness、BMesh(Maya SoUP) とSkin Modifier(Blender) とアーマチャー (Metasequoia)、マグネットとAffect RegionとProportional Editなど）がある。
また、同じ用語でもソフトウェアによって意味するものが異なる場合（例えば、3ds MaxのSkin ModifierとBlenderのSkin Modifier、Maya SoUPのBMeshとBlenderのBMesh、BlenderのArmatureとMetasequoiaのアーマチャーなど）がある。
ソフトウェアによってUIやショートカットは異なるが、共通点も多い。
3Dビューの視点の操作では、ポインティングデバイスとキーボードが使われている。ポインティングデバイス用UIでは、Autodesk製品が3DCG/3D CAD/3D GISの共通UIとして「ViewCube」を採用している (3ds Max、Maya 2008以降、Softimage 2011 SAP以降、Mudbox 2013以降、MotionBuilder 2009以降、Inventor 2009以降、Revit 2009以降、Autodesk Fusion、InfraWorks 360など)。
ショートカットキー(ホットキー)は基本操作を含めソフトウェアによって大きく異なっていた。基本操作の移動-回転-拡大縮小だけでも、Mayaや3ds MaxやModoではW-E-R、SoftimageではV-C-X 、BlenderではG-R-S、LightWaveではT-Y-H、Cinema 4DではE-R-T、HoudiniではT-R-Eというように、それぞれ異なるキーが使われている。ゲームエンジンなどでは他のソフトウェアのショートカットに似せることが多く (Unity、UNIGINEなど)、Blenderも2.8で業界互換のキーマップが追加された。
コンテキストメニューは、円形メニューを採用するものが増えている (Maya、Modo、Blender 2.81以降、Houdini 16以降など)。
なお、UIの配色は、3DCG寄りのソフトウェアでは標準で暗い色が基調にされること多く (Maya 2011以降、3ds Max 2011以降、LightWave 10以降など)、CAD寄りのソフトウェアでは標準で明るい色が基調にされることが多い (SketchUpやRhinocerosなど)。近年ではOSにも標準でダークテーマとライトテーマの両方が搭載されるようになってきている (macOS Mojave以降、Windows 10 May 2019 Update以降など)。
共通の3D APIが登場する前にソフトウェアが発展したという歴史的な経緯により、ソフトウェアによって使われる座標系が異なっている。3DCGでは、主に空間を前提に考えた右手系Z-upや左手系Z-upと、視点を前提に考えた右手系Y-upや左手系Y-upが使われている。なお、空間の座標系がZ-upのソフトウェアであっても、スクリーン座標系においては奥行きにZが使われている。
Z-upとY-upを変換するにはX軸で90度回転する必要があり、右手系と左手系を変換をするには負のスケールを使って一軸を反転する必要がある。
また、ボーンの座標系(ボーンの長さ軸/主軸(Primary Axis)/ボーンの方向(Direction)、及び補助軸(Secondary Axis)/ボーンの軸(Axis))もソフトウェアによって異なる (modoやMayaは自由に指定可能、3ds Maxは主軸がX axisもしくはZ axis、Softimageは主軸がX axisもしくはY axisもしくはZ axis、Blenderは主軸がY axis)。
法線マップにおいては、画像の緑チャンネルを+Yにマッピングしたソフトウェアと、-Yにマッピングしたソフトウェアが存在し、緑チャンネルの反転が必要になる場合がある。接線空間法線マップの標準としては、MikkTspace (Mikk tangent space)が存在し、modo 901以降、Blender 2.57以降、Xnormal 3.17.5以降、Unreal Engine 4.7以降、Unity 5.3以降、Knald、Substance Painter 1.3以降、3D-Coat、Marmoset Toolbag、3ds Max 2021以降、Maya 2024以降、Houdini用プラグインのCompute Tangents SOPなどが採用している。
画像の座標は、DirectXやGDIが左上原点、OpenGLやCore Graphicsが左下原点となっているため、3DCGソフトウェア及びそれに関連した2DCGソフトウェアにおいても、画像座標は統一されていない。
スクリーン空間の座標も基本的に画像座標と同じものの、DirectX 9以前には半ピクセルオフセットがあったため、古いシェーダーやDirectX 9以前のシステム等で互換問題の起きることがある。また、スクリーン空間のZ座標は、手前から奥にかけて、DirectXならば0.0～1.0に、OpenGLならば-1.0～1.0にマップすることが標準となっている。現在、深度の精度を改善するため、手前から奥にかけて1.0～0.0にマップするReversed-Zが普及してきている (Unreal Engine 4、Unity 5.5以降、CRYENGINE 3.8.1以降など)。
レンダリング高速化のための背面カリングにおいて、ポリゴンの表面は頂点順序によって決定されるが、ソフトウェアによって表面の指定が右回りと左回りで異なる。また、ファイル形式においても、法線方向が頂点順序によって決定されるものが多い。そのため、この方向の違いによって、モデルのやりとりで法線の反転する問題が発生する場合がある。
3DCGにおいては、CADに比べて長さの正確性があまり必要とされてこなかった。しかし、物理演算や物理ベースのレンダリング、実写合成などが普及し、正確な長さの必要な場合が増えている。また、座標が浮動小数点数で表されるため、設定された単位と単位スケールによって表せる範囲や精度が異なり、それがモデリングやシーン配置にも影響を与えうる。そのため、多くのソフトウェアでは長さの単位と単位スケールが設定できるようになっている。
3DCGソフトウェアではそれぞれ汎用単位を持っており、Generic Unit (GU)と呼ばれる。独自の名前が付いているGeneric Unitも存在する (XSIのSI unit (SoftImage Unit)、BlenderのBU (Blender Unit)、PoserのPNU (Poser Native Unit)、Unreal EngineのUU (Unreal Units)など)。汎用単位の標準の単位設定はソフトウェアによってバラバラに異なっている。
一つの単位と単位スケールだけでは表現できるシーン範囲に限界があるため、オープンワールドのゲームなど広い地形を必要する場合にはタイル化された地形を動的に読み込むという手法が用いられる。
内部計算に単精度を採用するソフトウェア (3ds MaxやBlenderなど)と、倍精度を採用するソフトウェア(CINEMA 4D v12以降など)が存在する。両方に対応するソフトウェアも存在する (UNIGINEなど)。単精度は高速だが、巨大なデータを扱う場合に問題が起きる。演算のアクセラレーションを行うGPUは、ゲーム用に単精度で速いもの(GeForceシリーズ)と、業務用で倍精度が得意なもの(Quadroシリーズ)に分かれている。
また、距離の計算においては、高速なsqrt(a*a+b*b)や高速な比較のためのa*a+b*bを使っているか、オーバーフローの起こしにくい低速なhypot(a,b)を使っているかでも、問題の起きる範囲が異なる。Blenderでは、通常-5000.0から5000.0の範囲の値が信用できるとされている。
3DCGに使われるオブジェクトには幾つかの種類がある。ソフトウェアは通常、複数の種類に対応している。
画像は内部で浮動小数点として扱うことが多いため、リニアカラースペースの32bpc浮動小数階調(float)画像が多く用いられているが、16bpc(half float)が使われる場合もある。フォーマット形式としては、OpenEXR (*.exr)、TIFF、DDS、KTX形式が良く使われている。歴史的経緯によりRadiance HDR (*.hdr)が使われることもあるが、Radiance HDR形式はOpenEXR形式に比べ色の正確性に劣る。また、float画像の非可逆圧縮形式としては、OpenEXRのDWAA/DWABコーデックがある。half-float画像の非可逆圧縮形式ではDirectX及びOpenGL向けのBC6H (BPTC_FLOAT)形式やOpenGL及びDirectX 11.3以降向けのASTC（英語版）形式も存在する。なお、ASTCは3Dモードも持っており、三次元テクスチャを効率的に圧縮することもできる。
ステレオ3D画像や多視点画像では、それらに標準で対応するOpenEXR形式が多く用いられており、その拡張子は一般的な.exrのほか、ステレオ画像で.sxr、多視点画像で.mxrが使われている。また、画像を独立したペアの画像ファイル(例えば*_L.pngと*_R.png)として保存することも行われている。ステレオ3D画像では、フレームパッキングやインタレースやサイドバイサイドやトップアンドボトムなどの3D方式に変換してステレオ3D未対応の画像形式で保存することも行われている。
素材には16bpcレギュラー画像(Photoshop PSDなど)やLogカラースペースの10bpc画像(CineonやDPXなど)、デジタルカメラのRAW形式などが使われることもある。
テクスチャサイズは時代と共に拡大しており、DirectX 11世代以降、16Kテクスチャ (16384x16384) までが一般的となっているものの、32Kテクスチャ (32768x32768)に対応するソフトウェアも現れている (Mari、Substance Designer 6以降、xNormalなど)。また、仮想テクスチャ（英語版）(OpenGLではSparse Texture、DX11ではTiled Resources)により、256Kテクスチャ(Graniteなど)や2Mテクスチャ(Amplify Texture2など)に対応することを謳うものも現れている。標準で仮想テクスチャに対応しているゲームエンジンもある (Unity 4.5以降など)。また、マルチタイルテクスチャーのUDIMに対応するソフトウェアも増えている。UDIMに対応するゲームエンジンも登場した (Unreal Engine 4.23以降など)。
レギュラー画像では、歴史的経緯により、Truevision TGA (別名Targa。Truevision社のグラフィックボード由来)、SGI (SGIワークステーション由来。16bpc対応)、Maya IFF (Autodesk Maya由来。16bpc対応)、Windows bitmap (BMP)なども使われていた。しかし、最近ではPNG (16bpc対応)のような一般的な形式を使うことも多い。
ゲーム用途でのテクスチャは、DDS形式 (Windowsが標準で対応)、KTX形式 (Khronos Groupが制定)、PVR形式 (iOSが標準で対応)、PKM形式 (Androidが標準で対応)などが使われている。
画像サイズは、B0サイズ/150dpiの静止画ポスターの場合、6083px*8598pxとなる。駅ナカ広告などでは、複数枚の大判ポスターを連貼りして一枚にすることが行われており、B0サイズ/150dpi/5連貼・2段の場合、12166px*42990pxとなる。一部のソフトウェアでは、大きな画素数に未対応となっている。
ベクター画像は、テクスチャとして使う場合、事前にラスター画像化する必要のある場合が多い。しかし、ベクター画像のままテクスチャとして使えるソフトウェアも存在する (modo 901以降など)。
アルファチャンネル付きの画像には通常のストレート(非事前乗算)なものと、アルファをRGBに事前乗算したものとがあり、画像形式によってアルファ値の扱いが異なっている。例えば、PNG形式ではストレートアルファにのみ対応しており、一般的にアルファの事前乗算には対応していない。一方、OpenEXRではアルファの事前乗算が標準となっている。
3DCGソフトウェアやコンポジットソフトウェアなどにおいてはレンダリングやコンポジットにアルファオーバーが多用されるため、それを高速化するために事前乗算した画像が良く使われている。 事前乗算形式にすると、RGBの情報が不可逆的に失われ、RGBがアルファに依存するようになるが、浮動小数点画像においては逆変換での精度の問題は起こりにくい。
精度や速度やカラースペースの問題もあり、コンポジットの中間形式にはHDR画像の連番が使われることが多い (OpenEXRの連番など)。容量の大きさから、圧縮効率の良いYUV色空間で10ビット～12ビットの色深度を採用した非可逆な中間形式が使われることもある (Apple ProResやAvid DNxHD (VC-3)、GoPro CineForm (VC-5)など)。これらの動画形式は編集の容易さのために、圧縮率の高い予測フレーム(インターフレーム)を使わずに、キーフレーム（イントラフレーム）のみで構成されているものが多い。
実写素材においてもキーフレームのみの形式が使われることが多かったが(AVC-Intraなど)、記録媒体の容量や速度が制約となるために、圧縮率の高い予測フレームを使った動画形式が使われることも増えた (AVCHDやXAVCなど)。近年は、再圧縮での劣化の少ないVisually Losslessな中間形式 (ProResやDNxHDなど)で直接撮影できるカメラが増えている。色空間では、効率的にHDRを記録するために、Log系の色空間 (Cineon (*.cin)、Sony S-Log、RedLogFilm、ALEXA LOG-C ProRes、BMDFilm Log、P-10Log、Canon Logなど)で撮影することが増えている。また、大きな記録容量が必要になるものの、RAW形式 (CinemaDNG（英語版）、ARRIRAW、Sony RAW MXFなど)での撮影も行われている。
一部のプロ向けカメラを除いて、多くのカメラではクロマ間引き(YUV 4:2:2やYUV 4:2:0など)が行われているものの、クロマ間引きはクロマキーで抜く場合やカラーコレクションを行う場合などに、ノイズやアーティファクトを発生させる要因となる。同様に、編集時にもクロマ間引きを行わないことが望ましいが、一部の手順はクロマ間引きを行ってしまう (例えば中間コーデックにYUV 4:2:2なApple ProRes 422やGrass Valley HQXを使うなど)。
オーサリングでは、メディアによって異なるフォーマットが用いられる。HDテレビ向けにおいては、以前はテープメディア (HDV、HDCAM、HDCAM-SR、HD-D5、DVCPRO HDなど)が主流だったものの下火となっていき、現在は光学ディスクのXDCAM HD (MPEG HDコーデック)や、フラッシュメモリのSRMASTER (MPEG-4 SStPコーデック)、P2-HD (AVC-Intraコーデック)、XDCAM EX (MPEG HDコーデック)などが伸びている。4Kテレビ向けでは、XAVC形式によるハードディスク/SSD納品やネットワーク経由での納品が行われている。コンシューマー向けには、ブルーレイディスクムービー (Full HD解像度まで、Rec.709色空間、8bit、59.94iまで、H.264コーデック)、ブルーレイ3D (Full HD解像度まで、Rec.709色空間、8bit、Full HDで24p/HDで60pまで、H.264 Annex H (MVC)コーデック)、Ultra HD Blu-ray (UHD BD。4K解像度、Rec.709色空間またはRec.2020色空間、SMPTE ST 2084 EOTFまたはDolby PQ EOTF、10bit、60pまで、H.265コーデック)が使われている。デジタル映画向けには、未圧縮のデジタルシネマディストリビューションマスター(DCDM)形式 (4K解像度、XYZ色空間、16bit、TIFF)と、配布のために非可逆圧縮したデジタルシネマパッケージ（英語版）(DCP)形式 (2K又は4K解像度、XYZ色空間、12bit、JPEG2000コーデック)が使われている。映画のフィルム配信向けには、DPX/ADX形式 (ADX-10又はADX-16色空間、10bit又は16bit、DPX)が使われている。ネット配信では、Netflixが、MPEG­-2のNetflix Profile、Apple ProResのiTunes Profile、SMPTE IMF App 2e+での納品を採用している。
3DCGではサブフレームを使った処理が行われているため、ソフトウェアによって異なる総フレーム数制限が存在する。例えば、Blenderでは最大500,000フレームまでしか対応しておらず、60fpsの場合に2時間18秒までの動画しか作ることができない。一方、Mayaはほぼ無制限となっている。
実験的には120fps以上のハイフレームレート(HFR)動画も作られているが、一部のソフトウェアはHFR動画に未対応となっている (例えばAfter Effects 2017.2より前では99FPSまでにしか対応していなかった)。
多くの3Dソフトウェアは、3Dマウス(6軸コントローラ)に対応している。また、多くのスカルプト・3Dペイントソフトは、タブレットの筆圧感知に対応している。
MIDIデバイスに標準で対応しているソフトウェアも存在する (3ds Max、Softimage、MotionBuilder、HoudiniのMIDI In CHOPなど)。
スクリプト言語としてはPythonが良く使われており、多くの3DCGソフトウェアがそれに対応している。Pythonを使うことでスクリプトの再利用性を高めることができ、特にパイプライン構築で重要となる。ただしAPIの標準化などはされておらず、ソフトウェアによってAPIは大きく異なる。
ゲームエンジンの開発言語ではC#が良く使われており、WebGL方面ではJavaScriptが良く使われている (#ゲーム及びインタラクティブコンテンツ作成の開発言語参照)。
グラフィカルUIではQtのPythonバインディングであるPySide (または互換性のあるPyQt) が普及しており、それを提供する3DCGソフトウェアが増えている。Qt未搭載のソフトウェアにおいても、PyQtやPySideを別途インストールすることによって、同じUIを使うことができる。
なお、古くから存在するソフトウェアには独自のスクリプト言語を持つものもある。MayaはPerlやTclに似た文法のMEL（英語版）スクリプト(旧Wavefront Sophia)を持っており、3ds MaxはMAXScriptを持っており、HoudiniはC Shellに似た文法のHScriptを持っている。また、Cinema 4DはC.O.F.F.E.E.スクリプトを持っていた (R20で廃止)ほか、LightWaveもLScriptを持っていた (LightWave 2020で非推奨)。Rubyを採用したもの (SketchUp等) やAngelScript（英語版）を採用したもの (3D-Coat等) も存在する。
また、標準規格の拡張をした言語を採用しているソフトウェアや、OSに依存するという欠点があるもののOSのスクリプト機能を採用したソフトウェアも存在する。Rhinocerosは、VBScriptを拡張したRhinoscriptが使われている。Adobe After EffectsにおいてはECMAScriptを拡張したAdobe ExtendScriptが使われている。DAZ Studioでは、ECMASciptを拡張したQtScriptを更に拡張したDAZ Scriptが使われている。Softimageにおいては、Active Scriptingに対応しており、JScriptやVBScriptを使用することができた。
リアルタイムではDirectX/Vulkan 1.2以降で採用されているHLSL言語や、OpenGL/Vulkanで採用されているGLSL言語、Apple Metalで採用されているMSL言語が良く使われている。マルチプラットフォームのシェーダー言語としてはNVIDIAのCg (HLSLに近い) が存在していたものの廃止となり、シェーダー言語変換が行われるようになっている。ただしシェーダー形式によって制限が存在する (MSL言語におけるdouble型非対応など)。
エフェクト用の形式ではCg/HLSL言語を基にしたCgFX/DirectX FX形式や、GLSL言語を基にしたCOLLADA FX形式、汎用のnvFX形式が使われている。ゲームエンジンのUnityでは、HLSL言語等を内包可能なShaderLab言語が使われている。VJソフトウェアでは、GLSL派生のISF形式 (Interactive Shader Format)が普及している (VDMX、COGE 1.6.4以降、Magic 1.6以降など)。
シェーダーを中間コンパイルして中間言語バイナリにすることも行われている。
Web向けでは、HTML5のWebGLやCSS Shadersで採用されているGLSL ES言語が良く使われている。また、GLSL ES言語を基にして、音声やマルチパス処理に対応させたものとして、ShaderToyで使われているShaderToy形式(*.stoy)が存在する。かつては、Adobe Flashに採用されていたPixel Bender言語やAGAL言語も使われていた。
オフラインレンダリングでは、オープンソースのOSL言語やNVIDIAのMDL言語が良く使われている。また、C++言語によるシェーダー作成も行われている (RenderManやArnoldなど)。かつてはRenderManのRSL言語（及びその派生のHoudiniのMantraレンダラのVEX言語 (*.vfl)やNVIDIA GelatoのGSL言語）、NVIDIA mental rayのMetaSL (*.msl/*.xmsl)が良く使われていた。シェーダーの事前コンパイルが行われており、OSLは*.osoに、RSLやその派生はレンダラーに依り様々な拡張子に (RenderMan#RenderMan互換レンダラーの比較参照) ネイティブコンパイルされる。
コンポジットソフトウェアでは、 ソフトウェアにより使用可能なシェーダー言語が異なる。FlameのMatchboxではGLSL言語、Fusion 6.0以降ではCg言語、NukeはC++に似たBlink Script言語、After Effectsは独自のPixelBender言語が使われている。
使用するソフトウェアによってシェーダー形式が異なるため、シェーダー変換ソフトウェアが存在する (#シェーダー変換)。
ステレオ3Dの3DCGを作る場合、ビューポート表示からレンダリング、コンポジット、レビュー、動画ノンリニア編集 (NLE)、オーサリングに至るまでステレオ3Dワークフロー対応のものを使うことが望ましい。既に多くのソフトウェアがステレオ3Dワークフローに対応してきているが、ステレオ3Dワークフロー未対応のソフトウェアや機能も残っている。
多視点(Multi-View)ワークフローに対応するソフトウェアも存在する (Blender 2.75以降など)。マルチカメラ編集に対応するNLEソフトウェアは多いものの、多視点(マルチアングル)なDVDやBlu-rayのオーサリングに向けて、マルチトラック動画のエクスポートが可能なNLEソフトウェアはまだ少ない。多視点は、多視差動画を作成するためにも使うことができるが、多視差動画に対応するソフトウェアは少ない。
VRデバイス向け動画には、一般的な球形ステレオ3D形式と、ライトフィールド形式が存在する。360°の球形ステレオ3D形式は、全方向ステレオ (ODS)とも呼ばれる。球形ステレオ3Dの3DCGを作る場合、球形ステレオ3Dワークフローに対応するソフトウェアを使うことが望ましい。以前はワークフローで多くの問題が指摘されていたものの、その後、球形ステレオ3Dに対応するソフトウェアが増えていっており、解決に向かってきている。360°動画や360°ステレオ3D動画のファイル形式としては、GoogleによるSpatial Media仕様が一般的となっている。かつては、360°動画用としてQuickTimeのQuickTime VR形式も使われていた (3ds MaxのPanorama Exporter Utilityがその出力に対応していた)。360°動画や360°ステレオ3D動画の再生及びオーサリングについては「オーサリングツール#360度動画・VR動画」を参照。
ライトフィールドワークフローに対応するソフトウェアはまだ極少数だが、ライトフィールドへのレンダリングに対応するレンダラーが存在する(OctaneRender 3以降など)。
ソフトウェア間のデータのやりとりには主に、データ交換用の標準であるCOLLADA形式 (.dae。OpenGLと同じくKhronos Groupが制定)又はAutodeskのFBX形式 (元々MotionBuilder(旧Filmbox)で使われていた形式)が使われる。昔は事実上の標準であった3D Studio形式(.3ds)、SoftimageのdotXSI形式(.xsi)も使われていた。ソフトウェアによって仕様や実装の違いがあるため、やりとりで問題が起きることも多い。AutodeskはFBXの互換チャートを公表していた。
また、やりとりには汎用形式以外も使われている。統合型ソフトウェアと外部レンダラー間のデータのやりとりにはレンダラ独自のプラグインの使用が多い (内部的にはRIB形式(Rendermanクローンなど)、ply形式(Luxrenderなど)、ASS形式 (Arnold)、vrmesh形式(V-Ray)、Alembic形式(.abc)などが使われている)。モデルデータのやりとりには、汎用モデルフォーマットとしてWavefrontフォーマット(.obj/.mtl。Wavefront The Advanced Visualizerで使われていた形式)やLightWave Object形式(*.lwo)があるものの、様々な情報が失われるためにデータ交換用フォーマットやモデラー独自形式でやりとりすることも多い。モーションのやりとりにはBiovision Hierarchyフォーマット(.bvh)が使われることが多い。ポイントキャッシュのやりとりには、3dsMax PC2 (Point Cache 2)やLightWave MDD (Motion Designer Data)、Maya Cache (.xml/.mc)、FBX (Maya式とMAX式のキャッシュが存在)、Alembicなどの形式が使われる。ポイントクラウドのやりとりは、PTS、PTX、LAS形式などが使われる。パーティクルキャッシュのやりとりでは、Alembic形式、RenderMan PTC形式、Houdini BGEO形式、Real Flow BIN形式、Krakatoa PRT形式などが使われる。
ゲーム向けの汎用モデル形式としては、DirectXのレガシーなx形式や、可逆圧縮のOpenCTM形式が存在するものの、多くはゲームエンジン固有の形式が使われている (id TechエンジンのMDL/MD2（英語版）/MD3（英語版）/BSP（オランダ語版）形式、Source EngineのSMD/DMX形式、CryENGINEのCGF/CAF形式、 Unreal Engine 3のPSK/PSA形式 (現在はFBXパイプラインに移行)、Gamebryo/Creation EngineのNIF形式、LithTech（英語版）のABC形式、SAGE（英語版）のW3D形式、OGREのOGRE XML、Torque Game EngineのDTS/DSQ形式など)。VR向けのシーン形式では、かつてはVRML形式 (*.wrl) やOpenSceneGraph形式 (*.osg)等が良く使われていたものの、現在はゲームエンジンが普及し使われなくなった。
Web向けのアセット形式では、古くはAway3DのAWD形式やthree.jsのJSON Model format等が存在したものの、現在はKhronos Group制定のglTF形式が普及してきている。glTFは拡張として、非可逆圧縮のDraco及びmeshoptに対応している。
3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、3MF形式などが使われる。
また、3DCGソフトウェアでもノンリニア編集のファイル交換に使われるEDL（英語版）形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAAF（英語版）のインポート及びFCP XML形式のインポート/エクスポートに、Unreal EngineのSequencerがCMX EDL及びFCP XML形式のインポート/エクスポートに対応している。Pixarが中心になって開発しているオープンソースのOpenTimelineIOライブラリは、それら形式の多くに対応している。
最初のマテリアルは完全拡散反射に光沢やフレネル効果や完全鏡面反射を足すものであったが、その後、微細表面 (マイクロファセット) のラフネス (粗さ)を考慮したシェーダーが使われるようになり、その後、誘電体や導体 (金属)などの物性別のシェーダーが現れ、現在はメタルネス (金属さ)が導入されて誘電体と導体の両者に使用可能な物理ベースシェーディング (PBS)に対応するソフトウェアが増えている。
Disney式PBSシェーダーの普及により、OBJ+MTL形式やFBX形式、glTF形式などの一般的な3D形式もPBSシェーダーに対応した (物理ベースシェーディング#PBS対応の3Dファイル形式参照)。ただし、ソフトウェアによっては高速化のために近似計算を行っているため、ソフトウェア間のやりとりで見た目の変わることがある。
なお、Disney式PBSシェーダー以外の特殊シェーダー (ヘアシェーダー、ボリュームシェーダーなど) は標準が無いため、マテリアルのやりとりで問題となる。そのため、LucasfilmとIndustrial Light＆Magicがマテリアルをやりとりするための新規格であるMaterialXを開発している。
ボクセル/ボリューム形式は、流体シミュレーション、3D印刷、医療、一部のモデリングソフトウェア (3D-Coat等)などに使われている。3DCGでは、3Dテクスチャ (DDS形式、KTX形式等) や、オープンソースのOpenVDB形式 (*.vdb) が事実上の標準形式となっている。オープンソースのField3d形式 (*.f3d) に対応するソフトウェアもある。
3D印刷では、Shapewayのsvx形式や、NVIDIA及びHPの推進するGVDB形式 (*.vdx)があるものの、2017年現在普及していない。医療ではDICOM形式が使われている。
画像や映像のやりとりでは色空間が重要となる。色空間には、カメラの撮像素子の出力の色空間、圧縮のための色空間、作業のための色空間、保管のための色空間、頒布のための色空間、表示デバイスの表示素子の出力の色空間などが存在する。入出力デバイスによって表現可能な色空間が異なるため、目的によって色空間を使い分ける必要がある。
カメラの撮像素子の出力は、固有の色空間を持っており、カメラで撮られたRAW画像やRAW動画は固有の色空間となっている。ガンマは基本的にリニアとなっている。バス幅や帯域幅や保存領域などのサイズの問題から画像や動画の非可逆圧縮が必要となる場合、見た目の劣化が少なく非可逆圧縮に向く色空間への変換が行われている (DPXのLog、ProPhoto RGB、YUV 4:4:4 12bit、YUV 4:2:2 10bitなど)。
作業のための色空間では、光の物理的性質を利用した処理とアーティスティックな処理が行われるため、色差が物理的に均一で、かつ色域が人間の見える範囲により近く、かつ人間が扱いやすいRGBの色空間であるACEScg（リニア、D60ホワイトポイント）やRec.2020リニア（D65ホワイトポイント）がよく使われている。ACEScgは色域がRec.2020リニアに近い上に映画に使われてきたDCI-P3色空間を包括しているなどの利点があるものの、非物理的な色を含むなどの様々な問題が存在する。そのため、狭い色域のRec.709リニア(D65ホワイトポイント、NukeやBlenderの標準)が使われることも多い。また、法線マッピングやバンプマッピングや透過マップや深度マップやIDマップなどでは、RGBを色ではなく単なる数値として使うため、リニアなカラースペースが使われる。レイトレーシングレンダリングにおいては、RGBだけでなく、スペクトルカラーも使われている (スペクトルレンダリング（英語版）)。コンポジット作業においては、RGB特有の処理が多用されるため、RGB色空間を使う場合が多い。編集作業では、RGBだけでなく、YUVも使われている。カラーコレクションには、RGBだけでなく、YRGBも使われている (Davinci Resolveなど)。
保管のための色空間では将来に備えたより広い色空間も使われている (デジタルシネマの保管におけるDCDMの16bit DCI-X'Y'Z' ガンマ2.6 5900K、ACES2065-1 (別名Linear ACES、SMPTE2065-1)など)。
頒布のための色空間では、出力機器(ブラウン管(CRT)、液晶、有機EL、プロジェクター、プリンター等)の特性と人間の識別(XYZ表色系やバートンランプなど)に適したものが使われる (SDTVにおけるRec. 601、HDTVにおけるRec. 709、デジタルシネマにおけるDCI-P3、UHDTVにおけるRec.2020、WebにおけるsRGB、プリンタにおけるAdobe RGBなど)。目的とする出力機器では出せない色も出てくるため、作業では出力機器を模した色空間も使われているが、その場合でも作業用ディスプレイの色空間への変換が行われるため、完全に同一にはできない。表示デバイスの表示素子の出力の色空間はそれぞれ固有の色空間を持っており、例えばブラウン管 (CRT)のガンマ値は2.2に近く、液晶のガンマはS字カーブを描いており、プロジェクターのガンマは1.5に近かった。これらの差異を吸収するために、表示デバイスのファームウェアは、頒布のための色空間からデバイス固有の色空間への変換を行っているものの、未対応の色空間があったりズレが生じたりと完璧ではないため、OSのカラーマネージメントシステム(WindowsのWindows カラー システム (WCS)、macOSのColorSync、Linuxのcolordなど)がモニターのカラープロファイルを管理して色空間変換の補正を行っている。しかし、OSのカラーマネージメントに対応していないソフトウェアも存在する (Mac版DaVinci Resolveの12.1より前など)。また、一部のモニターは10bit表示に対応しているものの、一部のソフトウェアは8bitへのトーンマッピングを行うなどして、10bit表示に未対応となっている（Mac版DaVinci Resolveの12.1より前など）。ディスプレイ機種固有の色空間を直接出力する仕様も登場している (FreeSync 2など)。
かつてPCモニターでは、sRGBが主流であったが、その後、Adobe RGB対応のPCモニターが広まってきている。そのため、Webにおいても、従来sRGBが使われてきたが、現在Webブラウザの多くはICCプロファイルv2に対応しており、様々なカラースペースを使うことが可能となっている。しかし、Adobe RGB色空間での画像出力や、ICCプロファイルv2の埋め込みに対応していない3DCGソフトウェアも存在する。
色空間の変換方式はカラーマトリクス、1D-LUT、3D-LUT、曲線当てはめなどが存在し、色空間の変換パラメータの形式には、ICCプロファイルv2/v4、Autodeskのlut、Autodeskの3dl、Autodesk CTF、Adobe SpeedGrade（旧Iridas SpeedGrade）のlookやitxやcube、Cinespaceのcsp、Houdiniのlut、Sony Pictures Imageworksのspi1dやspi3dやspimtx、Pandora Pogleのm3dやmga、ASC CDL、ASC CCC、ACESのCTL、Nukeのvf、DaVinci Resolveのdctlなど多くの形式（LUT形式）が存在している。オープンソースのOpenColorIOは、その多くに対応している。
独自仕様にするとアプリケーション同士の連携が難しくなるため、やりとりに関わる部分においてオープンソースのミドルウェアが増えてきている。主にスタジオ側がミドルウェアをオープンソースとして開発・公開しており、商用ソフトウェアにおいてもそれらのミドルウェアを使った機能が標準で搭載されるようになってきている。2018年には映画芸術科学アカデミーにより Academy Software Foundation が設立され、当財団がオープンソースの取りまとめをすることが多くなっていった (OpenEXR、OpenColorIO、Open Shading Language、OpenVDB、MaterialXなど)。
2000年1月、Robert McNeel & Associatesは、openNURBS Initiativeを設立し、openNURBS Toolkitをリリースした。openNURBS (*.3dm)は現在、Rhinoceros、MoI 3D、modoなどに使われている。
2003年1月、オープンソースのHDRI画像フォーマットであるOpenEXR (*.exr)が、インダストリアル・ライト&マジックによって公開された。2007年11月には、OpenEXRにステレオ3D画像や多視点画像を埋め込むための仕様がWeta Digitalによって公開された。2013年4月には、Deep Data画像に対応した2.0がリリースされた。2014年8月には、DreamWorks Animationにより開発された非可逆圧縮のDWAA/DWABに対応する2.2がリリースされた。
2010年1月、Walt Disney Animation StudiosがUV展開不要のテクスチャマッピングシステムのPtex (*.ptx)をオープンソースとして公開した。
2010年1月、Sony Pictures ImageworksはGIレンダラ向けプログラマブルシェーディング言語のOpen Shading Language (OSL、*.osl)、ボクセル・データ保存ライブラリのField3d (*.f3d)などを、同年7月にはカラーマネージメントライブラリのOpenColorIO (OCIO)をオープンソースとして公開した。
2012年8月、PixerはRenderMan互換サブディビジョンサーフェスを実装するためのGPU対応ライブラリOpenSubdivを、DreamWorks Animationは疎ボリューメトリックデータ形式及びツールのOpenVDB (*.vdb)をオープンソースとして公開した。OpenVDBは各統合ソフトや各レンダラーの他、RealFlow 7.1.2.0147以降、Phoenix FD 2.2以降、FumeFX 4.0以降、Stoke MX 2.0以降などで使われている。
Sony Pictures Imageworksとインダストリアル・ライト&マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)が開発された。各統合ソフトや各コンポジットソフトの他、Unreal Engine 4.13以降、CryEngine、Poser 11以降、RealFlow、thinkingParticles 6.3以降、Vue xStream 2015以降PFTrack 2015以降、V-Ray、RenderMan、Maxwell Render V3以降、OctaneRender、Guerilla Render 1.3以降、KATANA、Esri CityEngine 2016以降など、多くのソフトウェアがAlembicに対応している。
ハードウェアメーカーがハードウェアの需要を起こすためにオープンソースで開発することもある。
2005年、Sony Computer Entertainmentの開発者によって開発された物理エンジンのBullet Physicsがオープンソースとして公開された。その後、2009年よりAMDがBullet Physicsの開発を支援している。Bullet Physicsに対応する3DCGソフトウェアは増えており、Blender、LightWave、Maya、Cheetah3D、Cinema 4D、modo、Houdini、Maya付属のMayaBulletプラグイン等が対応している (ソフトウェアによって対応具合は異なる)。
2011年7月、Intelが高速なレイトレースカーネルのEmbreeをオープンソースとして公開した。
括弧内は、搭載されているレンダラー。
統合型はシーンセットアップを基本に、モデリング、アニメーション、レンダリングなど多くの機能を備えた物である。最近はコンポジットやマッチムーブまで行えるソフトウェアが増えている。プラグインで機能を拡張できるものが多く、一つのソフトウェアだけで多くの作業が行えるほか、他のモデラー・レンダラー・モーション付けソフトウェアなどと組み合わせて作業パイプラインの中心の役割を担える。その他、モデリングなどの単機能目的のみで使われることも多い。一般的に統合ソフトは、標準機能同士の連携は優れているものの、他のソフトウェアに比べて一部の標準機能が古かったり低機能だったり直感性・操作性に乏しい場合が多々あるため、スクリプトやプラグインやソフトウェアを組み合わせて作業パイプラインを作ることが重要となる。
大きなプロジェクトでは、外部参照やアセットの軽量な代理表現、アセット管理 (#管理システムも参照)が重要となる。
OpenGLやDirectXの高機能化に伴い、ビューポートにおいてPBR (物理シェーダー)やエフェクト等によるリッチな表示が可能となった。また、3Dゲームや3D CADの可視化で使われるウォークスルー（歩行）/フライスルー（飛行）のような一人称視点ナビゲーションにも対応するソフトウェアが増えており、オーサリングせずに直接VR表示できるソフトウェアまで登場している。
GPUの汎用化（GPGPU）及びGPUに搭載されたレイトレーシングアクセラレータ（英語版）の普及によって高品質なレンダリングが高速となり、最終レンダリングと同等のインタラクティブレンダリングに対応するソフトウェアが増えている。レイアウトとレンダラーの統合は、特にライティング作業の効率化において重要となる。また、内外レンダラのビューポートへの統合も進んでいる。
並びは順不同である。
※以下▽はアニメーション対応、▼はアニメーション対応(キャラクタアニメーション有り)、■はアニメーション対応(ダイナミクス有り、キャラクタアニメーション有り)、★はアニメーション対応(キャラクタアニメーション有り、ダイナミクス有り、パーティクル有り)のソフトウェア。
3Dキャラクターはメタバースを含むソーシャルVRでも使われており、VRChatではUnity向けのHumanoid互換FBX形式が、Virtual CastやClusterではVR向けのVRM形式がキャラクター入力形式として使われている。
キャラクターアニメーションやエフェクトが弱いものの、NURBSやベジェサーフィスに強く、建築および製品可視化に使われる3DCGソフトウェアも存在する。また、マルチオブジェクト、アニメーション、ライティング及びレンダリング対応の3D-CADもある。これら用途には一般的な3DCGソフトウェアも使われている。
可視化に向けてオフラインレンダリング後にライトやテクスチャを変更できるソフトウェアも登場した（Motiva COLIMOやColorwayなど）が、リアルタイムレンダリングの進化と共に終了していった。
シーン構築、アニメーション、ライティング、レンダリングに対応する3D可視化ソフトウェアや3Dビジュアルコミュニケーションソフトウェアなど。
建築可視化には旧来3ds Maxなどの統合ソフトウェアが使われてきたが、2022年現在Unreal EngineなどのゲームエンジンやLumion、Twinmotion、Enscape、D5 Render、Chaos Vantageなどの専用ソフトウェアや専用プラグインが使われることも増えている。専用ソフトウェアには地形作成、植生作成、季節の設定、人混み及び都市交通シミュレーション、それらのためのアセットライブラリの含まれているものが多い。
物理ベースのレンダラーは現実をシミュレーションするため、照明解析に使うことができ、それに対応するソフトウェアも存在する (Radiance（英語版）、irayのIrradianceレンダーエレメント、V-RayのVRayLightMeterヘルパー及びVRayLightingAnalysisレンダーエレメント、Luxrender 1.5以降のIRRADIANCE AOVなど)。
建物作成には ArchiCAD のような建物向け3D CADが強いものの、標準で建物作成向け機能を持っている統合3DCGソフトウェアも存在する。
アセットの付属する統合ソフトウェアやレンダラー（Thea RenderやLuxCoreRender 2.4以降など）も存在する。
パッケージ折り曲げ機能のあるものもある (Cinema 4D内蔵のFold My Design!機能など)。
VueやTerragenなどの景観作成ソフトウェアは、マットペイントにも使われている。スキャッタリングについては#プロシージャル / モーショングラフィックス / アブストラクトを参照。
内部でL-systemを使っているものもある。草生成機能を持つレンダラーも存在する (Maxwell Renderなど)。また、草にはヘア・ファー向け機能も使われる。
なお、植物アセットの提供は3DMentorやMaxtree、Globe Plantsも行っている。
標準で対応するソフトウェアも存在する (MayaのPaint Effectsなど)。
標準で搭載されている統合ソフトウェアも存在する（Blender付属のReal Snowアドオン、HoudiniのLabs Snow Buildupなど）。
道生成→建物生成を行う。生成にL-Systemを使用しているものがある (CityEngineなど)。
Interior Mappingを使ったものなど。標準で対応しているソフトウェアも存在する（Houdini 20以降のKarma Room Map VOPなど）
道路作成に標準対応する統合ソフトウェアやプロシージャルモデリングプラグインも存在する (HoudiniのLabs Road Generator、RailCloneなど)。
ケーブルは一般的にカテナリー曲線 (懸垂線)を描くため、リアルなケーブルの作成にはその考慮が必要となる。ケーブル作成に標準で対応するソフトウェアも存在する (3ds MaxのHose Extended Primitives、HoudiniのWire Object及びLabs Cable Generator、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、Ramp Brushなど)。
数値標高モデル(DEM)には様々な形式がある。
標準でプリプロダクション向けの機能を持つ3DCGソフトウェアも存在している（BlenderのStorypencil addonなど）が、ストーリーボードにはPhotoshopなどの一般的な画像編集ソフトウェアも使われている。またビデオコンテには一般的な3DCGソフトウェアも使われている。詳しくはプリプロダクション#プリプロダクションソフトウェアの例を参照。
ドリーカメラリグやクレーンカメラリグなどの現実に即したカメラリグは、撮影前のプレビジュアライゼーションにも使われている。標準で搭載する統合ソフトウェアも存在する (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、Houdini 18.5以降のPhysical Lens VOPなど)。
カメラ投影では初期CGや航空写真などに使われているオルソ（垂直投影）、一般的な物理カメラのパースペクティブ（透視投影）、パノラマ写真作成のための魚眼レンズに用いられる等距離射影（Equidistance）や等立体角射影（Equisolid）、円柱状投影、環境マッピングに用いられる正距円筒図法（Lat-Long）などが使われている。 一部の映画に用いられるアナモルフィックレンズもある。
立体映画および3Dテレビ向けのステレオカメラ、VRで使われるステレオ360°動画向けのVRカメラなども存在する（#VR動画も参照）。
またティルト/シフトレンズは建築パースや製品写真などで二点透視を実現するために使われている。これらはシフトは非写実レンダリングにおける2Dパンにも使われている。
特殊な投影では線の歪みを抑えながら広い視野を実現できるパニーニ投影 (別名Vedutismo投影。Unreal Engine 4、UnityのSRP 6.0.0以降などが対応)、実写との環境比較に用いられるミラーボール投影（Blenderなどが対応）、正投影 (オルソ)にピントのあるテレセントリックレンズ（Mitsuba Renderなどが対応）、2.5Dゲームで使われる斜投影などもある。
レンズ歪みの適用/補正はソフトウェアにより異なるアルゴリズムが使われている。アルゴリズムには放射状歪みの適用/補正だけでなく、接線歪みや薄プリズム歪みの適用/補正に対応するものもある。代表的なものには単純な二次式補正、SynthEyesやBoujouで使われている三次式補正、libmvの多項式モデル及びDivisionモデル (OpenCVのopencv_sfmモジュール、Blender等が対応)、3DEqualizer方式 (3DEqualizer、FusionのLensDistortノード等が対応)、PFTrack方式 (PFTrack、FusionのLensDistortノード等が対応)、Nuke/Natron方式 (Blender 2.90以降等が対応)、写真測量ソフトウェアで良く使われているBrown-Conrady歪みモデル、PTLensの独自モデル (Hugin等が対応)、Adobe Camera Model (PTLens等が対応)、OpenCVの独自モデルなどが存在する。
また、歪みデータを画像化したSTマップ等のテクスチャも存在し、NukeのSTMapノード、FusionのTextureノード、Flame 2025以降のSTMapノード、PFTrack 2016以降、mocha ProのLens ModuleのRender Distortion Maps、V-Rayなど、多くのソフトウェアが対応している。
斜投影（英語版）は2Dゲームやドット絵で良く使われており、2.5D的な表現が可能となる。単純な斜投影では円や球なども歪むため、それらが望ましくない場合は工夫が必要となる。
斜投影に標準で対応するソフトウェアも存在する (FormZなど)。斜投影に未対応のソフトウェアでも、垂直投影 (オルソ)にLatticeデフォーマを組み合わせるという方法も存在する。
嘘パースはアニメなどのNPRレンダリングに使われている。
プラネタリウムなどのドーム投影には、主に魚眼レンズが使われている (ミラーが使われるものもある)。魚眼レンズでのレンダリングに未対応なソフトウェアも残っているが、Lat Longやキューブマップからフィッシュアイへの変換用ソフトウェアも存在する (Pano2DomeやCube2Domeなど)。ドーム映像の確認は、AMATERAS Dome Player (ORIHALCON Technologies)などで可能。
ドーム投影ではドーム内反射 (Cross-Bounce)が起こるため、そのドーム内反射のシミュレーションに対応するソフトウェアも存在する (Domemaster Stereo Shaderなど)。
全天周動画とステレオ3D動画を組み合わせた全天周3D動画というものも存在する。
ドーム動画の編集にはAfter Effectsとプラグインの組み合わせ（Navegar FoundationのNavegar Fulldome、エバンス・アンド・サザランドのDigistar Virtual Projector、Société des Arts TechnologiquesのCAMSPHEREなど）が良く使われていたが、After Effects 2018以降はMettle SkyBoxが統合され標準でドーム動画の作成に対応している。
標準で対応しているソフトウェアも存在する (Blender付属のLight Field Toolsアドオン、OctaneRender 3以降など)。
シーンのタイムワープは、高速度撮影 (スローモーション)や低速度撮影 (ファストモーション)の再現に使われており、それらに対応する統合ソフトウェアも存在する (Maya 2011以降のScene Time Warp、LightWave 9以降のTimewarp、BlenderのTime Remappingなど)。
また、カメラのみを通常速度で動かしながら、それ以外の時間を止めるフリーズタイムや、それ以外の時間をスローモーションにするバレットタイムに標準で対応するソフトウェアも存在する (LightWave 9以降のTimewarp機能など)。フリーズタイムやバレットタイムは、モーションブラーの扱いに注意が必要となる。
モディファイアやノードなどによりプロシージャルなモデリング/レイアウト/アニメーションを行える統合ソフトウェアが増えている。またプロシージャル編集した上から手編集できるものもある (3ds MaxのEdit Polyモディファイアなど)。プロシージャルなデータの仕様はツール毎に異なっており互換性は基本的に無いものの、他ツールでHoudiniアセットを使うためのHoudini Engineや、Unreal EngineでBlender Geometry Nodesアセットを使うためのAlterMesh、UnityでBlender Geometry Nodesアセットを使うためのBEngine For Unityなどは存在している。
規則的なオブジェクトの複製はリプリケーティング（繰り返し複製）と呼ばれ、複製先をリサンプリングしてのオブジェクトの複製はスキャッタリング（散布）と呼ばれる。多くのソフトウェアではプロシージャルで増やしたオブジェクトをインスタンスとして扱うことができ、メモリーを節約して大量のオブジェクトを扱うことが可能である。またインスタンスのままレンダリングすることも行われており、それに対応するレンダラーが多い。
スキャッタリングなどのプロシージャルなレイアウトに対応するツールを付属したレンダラーも存在する (V-Ray 6以降/Chaos Corona付属のChaos Scatterツール（Corona Scatterの後継）など)。階層的スキャッタリングに対応するソフトウェアも存在する (Houdini 17以降など)。#ヘア・ファーも参照。
標準でモーショングラフィクス向け機能を持つ統合ソフトウェアもある。また、下記の他、プロシージャルモデリングに対応するもの(#プロシージャル / モーショングラフィックス / アブストラクト)の多くは、アニメーションも可能である。
SF映画などで使われるディティールアップを行うもの。
フラクタル、ストレンジアトラクター、立体リサジュー図形、3Dスピログラフ、3Dセルオートマトンなど。なお、ノードベースのジェネレーティブアート作成は#プロシージャル / モーショングラフィックス / アブストラクト参照。また、一部のレンダラーもフラクタルなどの直接レンダリングが可能となっている (POV-Ray、OctaneRender 2018.1以降のVectron、Blender 2.8以降のEEVEE等)。
分岐形成は雷、氷晶、地衣類、サンゴ、植物などのモデリングに使われている。分岐形成のアルゴリズムには、一般的な拡散律速凝集、雷の生成に使われる絶縁破壊モデル（英語版） (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アドオン)、HoudiniのLabs Lightning、Cinema 4D 2025.2以降のElectric Spline Modifierなど)。また、確率的L-System (HoudiniのL-system SOPなど)やパーティクルノード (3ds MaxのParticle Flowなど)によって雷を生成することも可能。
統合型やプロシージャルソフトウェアにもノードベースのテクスチャ作成の搭載されているものがある (Substance 3D Designerなど)。
多くの統合ソフトウェアは、標準でノードベースのシェーダー構築に対応している (対応表参照)。多くのレンダラーもノードによるシェーダー構築が可能となっている。
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#互換レンダラーを参照。
モデラーはモデリング機能に特化した物である。簡易的なレンダリング機能を持つ物や、プラグインモジュール等により高度なレンダリングが可能になる物もある。
多くの統合型ソフトウェアはモデリングにも対応している。また、一部のゲームエンジンもレベルデザイン/プロトタイピング向けとして、簡易モデリングに対応している。
角の処理 (ベベル/面取り (チャンファー)/角丸め (フィレット))、ブーリアン処理など。標準でボックスカットに対応するソフトウェアも存在する（HoudiniのLabs Boxcutterなど）。
標準で対応しているソフトウェアも存在する (3ds MaxのAutoGridなど)。
ブーリアンに対応する統合ソフトウェアやモデラーは多く、ブーリアン時のフィレットに対応するソフトウェアもある。
また、パーツの切り分けに向けた機能が存在するソフトウェアもある (ZBrush、3D-Coat、Blender 2.78以降に付属のCarver MTアドオン、3ds Max 2024以降など)。
MOD作成に特化したものなど。3Dモデルの簡易編集に標準で対応する開発環境も存在する (Visual Studioのモデル エディターなど)。
その他のスプラインモデリング対応のものにはShade、Strata Design 3D、Animation:Masterなどがある。
歴史的経緯などにより、NURBSサーフィスモデリングに対応している3DCGソフトウェアは多い (3ds Max、Maya、Houdini、Blender、Shade 17以降、LightWave + LWCAD、Ayamなど)。また、3D-CADはNRUBSベースのものが多く、主に工業デザインや建築において使われるものの、グラフィックデザインなどのCG目的で使われることもある (Rhinoceros 3D、Autodesk Fusionなど)。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アドオンなど)。
スカルプトモデリングにおいてはメッシュの細かさが重要となるが、細かさを調整しながら編集するためには、手動で分割やリメッシュを繰り返しながら編集するという手法や、マルチレゾで分割数を変更しながら編集するという手法や、ダイナミックテッセレーションを使って編集するという手法がある。ダイナミックテッセレーションは基本的に三角ポリゴンにのみに対応している。
リトポロジは、基本的にフェイスへのスナップを使って行うため、多くのソフトウェアが対応している。スケッチや輪切りによるリトポロジもある。自動リトポロジも存在する。トポロジ転送に対応するソフトウェアもある (Houdini 18.5以降のTopoTransferなど)。
縫い合わせにのみ対応する統合ソフトウェアも存在する (Cinema 4DのDress-O-Maticなど)。クロススカルプトにのみ対応するソフトウェアもある (Houdini 18.5以降のVellum Brushなど)。なお、アパレル産業向けは、CAD#服飾デザイン用CAD (アパレルCAD)を参照。
オフラインレンダリング向けソフトウェアでは、多くがCatmull-Clark及びLinear Subdivisionに対応しており、三角メッシュ向けのLoop Subdivisionに対応するものもある (OpenSubdivでも対応)。また、Doo-Sabinに対応するソフトウェアもある (Softimage、TopModなど)。一方、ゲームエンジンでは、 PN-Trianglesやフォンテッセレーション (Unity等)やPN-AEN (Unreal Engine、MayaのShaderFX等)などのアルゴリズムが使われている。
現在のところ、細分化ではC2連続性までしか作ることしかできない (4-8 Subdivisionを除く)ため、C3連続性 (クラスAサーフェス（英語版）で使われる)が必要な場合はNURBSモデリングに対応したソフトウェアが必要となる。
法線転写の代わりに法線のベイクを使うこともある。
テクスチャにはいくつかの手法が使われる。従来は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、Cheetah3D、ZBrush、Mudbox、3D-Coat、Substance 3D Painterなど)。
標準で対応するソフトウェアも存在する(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以降のLabs Flowmapノードなど)。
PBRでは、旧来のディフューズマップからライティングを取り除いてアルベドマップを生成する必要がある。デライティングの手法は、画像処理でハイライトと影を除去する手法、機械学習でハイライトと影を除去する手法 (Substance 3D SamplerのDelight、メッシュ再構築して3Dモデルを生成した後にグレーボール/ミラーボールの撮影画像を使ってデライティングする手法、再構築した3Dモデルから法線マップとベント法線マップとAOマップと位置マップを生成してデライティングする手法 (UnityのDe-Lighting Tool等)などがある。また複数角度の写真から各種マップを生成できるもの（Substance 3D SamplerのMultiangle To Material）や、機械学習で各種マップを生成できるものも存在する（Substance 3D SamplerのImage to Materialなど）。
また、テクスチャ撮影時に、偏光フィルタを光源とレンズに使って交差偏光の状態にし、スペキュラ成分を除外して撮影するという手法や、メッシュ再構築向けの写真撮影時に、フラッシュを焚いて影を除去した物を用意するという手法もある。
ソフトウェアによって生成されるマップの品質に大きな違いが存在する。
ほぼ全ての統合型ソフトウェアはUV展開に対応しているものの、UV展開に特化したソフトウェアも存在する。展開アルゴリズムにおいては、かつてLSCMが主流であったが、ABFに対応するソフトウェアが増えており (Blender、Cinema4D R10.5、Lightwave 11.5、Cheetah3D 6.2など)、それよりも高品質とされるISOMAPに対応するソフトウェア (RizomUV、Softimage、Maya)や、その他のアルゴリズムを実装したソフトウェア (3D-CoatのGU (Globally Uniform)展開、Blender 4.3以降のSLIM)も現れている。また、マルチタイルUVテクスチャに対応するソフトウェアが増えており、タイル間のUV島の移動が容易となっている。
UVスカルプトに対応しているソフトウェアもある (Maya 2018以降搭載のUnfold3D、Modo、Blenderなど)。
多くの統合ソフトウェアは標準でマテリアル編集機能を持っている。一部のレンダラーは、マテリアル編集に対応するGUIを備えている (V-RayのV-Ray Standalone Material Editor、Maxwell RenderのMaxwell Studio、Indigo Rendererなど)。
3Dスキャンには、レーザースキャナーを用いたレーザースキャン、一般的なカメラやステレオカメラを用いたイメージベースモデリング、カメラ及びプロジェクターを用いた構造光3Dスキャニング（英語版）などの手法がある。
イメージベースモデリングは写真測量法を用いた3Dスキャンの一種で、複数の画像や動画から自動的又は半自動的にモデル生成を行うことができる。実物モデルはマッチムーブに良く使われるため、トラッキングソフトウェアにはイメージベースモデリング機能を持つものがある (boujouやPFTrackなど)。
標準で3Dスキャンに対応するOSも存在する（iOS 17以降のObject Captureなど）。
Substance 3D Samplerも参照。
Kinect等の深度カメラは内部で構造光3Dスキャンを用いているものの、そのデータは深度画像へと変換されて外部に渡される。
LiDARスキャンしたデータなどを取り込むためのもの。
大規模な3Dスキャンは、建築方面だけでなく、科学捜査や法廷アニメーション、VFXでも行われている。
再メッシュ化に対応するソフトウェアには、BlenderのRemeshモディファイア、MeshLabの「Remeshing, Simplification and Reconstruction」、NetFabbのRemeshなどが存在する。メッシュ修正は3ds Max 2021.3以降のMesh Cleaner Modifierなどがある。
テクスチャの取り込みには、写真を画像処理で変換する手法、3Dスキャンからテクスチャ抽出する手法、マテリアルスキャナーを使う手法などがある。前者二つについては#マップ生成を参照。
マテリアルスキャナーでは、測定したマテリアル (MERL BRDF database形式、X-riteのAxF形式、MDLのMBSDF形式、V-RayのVRscans形式など) をそのままレンダリングで使ったり、別のシェーダーにフィッティングすることが行われている (#測定マテリアル参照)。マテリアルスキャナーは市販のものも存在する (X-rite TACなど) が、簡易的なものは自作することもできる。
GPU向けのモデル最適化にはGPUの特性に合わせて最適化する頂点キャッシュ最適化、オーバードロー最適化、頂点先取りキャッシュ最適化などの手法がある。
ポリゴンリダクションは多くの統合ソフトウェアに搭載されている (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以降、Cinema 4D R19以降、HoudiniのLabs LOD Create/Labs LOD Hierarchyなど)。
Imposterはビルボードの発展形であり、ポッピングの起こらない八面体的Impostorが登場してLoDの延長として使われはじめた。
標準で旧式のImposter生成に対応するソフトウェアも存在する(HoudiniのLabs Impostor Texture、Unreal Engine 4など)。
これらのソフトウェアは主にゲームやリアルタイムレンダリング向けである。オフラインレンダリング向けでは、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で対応した。Android 5.0及びiPhone 6以降では、最新の圧縮方式であるASTCが使えるようになっている。
デスクトップとモバイルの両方への互換性を保つため、各種圧縮テクスチャへのリアルタイム変換が可能な圧縮テクスチャ形式も登場しており、KTX2形式で使用可能になる予定となっている (ETC1サブセットのETC1S、ASTCサブセットのUASTCなど)。
法線マップなどの互いのチャンネルに相関性がないテクスチャの圧縮では、法線マップを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が存在する。ASTCは、1chテクスチャ、法線マップ等の2chテクスチャ、3Dテクスチャにも対応している。今後デスクトップにも導入される予定。
またテクスチャ圧縮の上に通常の可逆圧縮を追加することが可能である (スーパー圧縮)。KTX2形式で採用されたスーパー圧縮方式として、BasisLZ、zlib、Zstandardが存在する。
多くのレンダラーは、タイル化したMIPMAP(多解像度)テクスチャ生成ツールを含んでいる (V-Rayのimg2tiledexr、RenderManのtxmake、HoudiniのMantraのicp及び18.5以降のimaketx、3Delightのtdlmakeなど)。タイル化画像形式では、タイル化されたTiff形式やOpenEXR形式が良く使われている。
オープンソースのOpenImageIOにもMIPMAPテクスチャ生成ツールのmaketxが含まれており、それを採用しているレンダラーも存在する (Arnold Rendererなど)。
ドローコールの削減や、ライトマップの作成などに使われる。標準でUVアトラス作成向けの機能を持つソフトウェアも存在する (ModoのCreate UV ToolのAtlas/Atlas2、Blender 2.8以降やCinema 4D R23以降のマルチオブジェクトのUVパッキングなど)。標準で空洞を埋めるような高度なUVパッキングに対応するソフトウェアも存在する (3ds Max 2022.2以降 (Unfold3Dベース)、Maya (Unfold3Dベース)、Houdini 16.5以降、Cinema 4D (Ministry of Flatベース)、Blender 3.6以降 (xatlasベース) など)。
Webやデモシーンなどにおいて、バイナリサイズや通信量を減らすためにシェーダーの縮小化 (minify) が行われている。
複雑なデフォーマー等により生成された頂点アニメーションから、ボーン生成、スキニングウェイト生成、アニメーション生成を行うことで、ボーンアニメーションに変換できる。既存のボーン及びスキニングウェイトを使ってアニメーションのみ生成することや、既存のボーンを使ってスキニングウェイト及びアニメーション生成のみを行うことに対応するソフトウェアも存在する。
一部に標準で対応する統合ソフトウェアも存在する (Maya 2017 Update 3以降のBakeDeformerTool (スキニングウェイト及びアニメーション生成のみ)、Houdini 16.5以降のLabs 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など)、レイトレーシングGI (下の表参照)など様々なアルゴリズムが存在し、速度や正確性などに差異がある。ミドルウェアについては、3Dライブラリ#グローバルイルミネーション(GI) ライブラリを参照。
昔はゲームムービー（Cut Scene）に事前レンダリング（プリレンダリング）の映像を使用することが多かったが、その後、リアルタイムレンダリングによる演出映像（In-game Cinematics）が普及したため、昨今のゲームエディタには映像作成向けの機能が存在している。一部のゲームエディタはVR動画の出力にも対応している。その一方で、ゲームエンジンを付属する統合ソフトウェアも存在する (3ds Max Interactive (旧Autodesk Stingray) 付属の3ds Max 2018.1以降、UPBGE (Blender派生品) など)。
ゲーム環境では、PC、据え置きゲーム機、携帯ゲーム機、スマートフォンなどが存在し、それぞれ技術的制約が異なる (例えば非Microsoft環境でのDirectX非対応、iPhoneやXbox 360での実行時(JIT)コンパイラ禁止、Web環境でのJavaScript言語/WebAssembly以外非対応など)ものの、現代のゲームエンジンはシェーダー変換(#シェーダー変換)や開発言語変換(IL2CPPやEmscriptenなど)などの技術によって、その多くに対応している。
多くのゲームエンジンは標準でUI機能を持っている。3DのUIに対応するものも存在する。
開発環境はGPUプロファイラやグラフィックデバッガーを搭載するものが増えている (Visual StudioのGPU Usageツール/Graphics Diagnosticsツール、XcodeのInstruments（英語版）、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以降など)。以前は機種によって使われるミドルウェアが異なっていたが、OpenXR及びWebVRの登場により統一された。
VRにおいて多数のディスプレイやプロジェクターを使う場合、マルチGPUによってPC1台から16画面以上の出力を行うことが可能 (Unityでは8画面まで)ではあるものの、処理能力の関係から、複数台のPCより成るコンピュータ・クラスターも使われている。VRに使うトラッカーデバイスなどの入力機器には、主にVRPN（英語版）プロトコルが使われている。
TriCaster (NewTek)、InfinitySet (Brainstorm)、Maestro | Virtual Set (旧ProSet。Avid Technology←Orad Hi-Tec Systems)、Viz Virtual Studio (Vizrt（英語版）)、PRIME VSAR (Plutonium/Neonの後継。ChyronHego（英語版）←Hybrid)、XPression (Ross Video)、Reality Engine (旧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ドライバ)によるリグ制御も行われている。
スキニングでは、幾つかの手法が使われる。ボーンとウェイトペイントが基本であり、ボーンは複数の頂点に影響を与える。自動でウェイトを割り当てる機能を持つソフトウェアも増えており、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のLattice Flexor、3ds MaxのJoint Angle及びBulge Angle Deformer、BlenRigなど)、クラスタ変形を連動させる手法(Mayaのリジッド スキニングのクラスタ フレクサ、Cinema4D及びMaya 2016以降のクラスタ デフォーマなど)、テンションマップ (ストレスマップ)によるディスプレイスメントを使った皺の再現(Lightwave、Blender、modo 901以降など)、ジグルデフォーマ (MayaやC4Dなど)やソフトボディシミュレーションなどを使った揺れの再現、筋肉シミュレーションも使われている。ただし、これらのソフトウェア同士の互換性は低い。
標準でRBFによる補間に対応するソフトウェアも存在する (Unreal Engine 4のPose Driverノードなど)。
多くの統合ソフトウェアは、モディファイア等により変形アニメーションが可能である。また、プロシージャルモデリング (#プロシージャル / モーショングラフィックス / アブストラクト) ツールの多くは、アニメーションに使うことも可能となっている。一方、ゲームエンジンは、変形アニメーションへの対応があまり進んでいない。
ラティス(自由形状)変形やケージ(ラップ)変形は、スキニングに使われているため、多くのソフトウェアが対応している。
トラッキングソフトウェアの中にもモーションキャプチャーに対応するものが存在する (PFTrack、Autodesk MatchMoverなど)。
動画からのものと、深度付きカメラからのものがある。
顔の自動リグに対応するソフトウェアも存在する (対応表参照)。
標準で対応するソフトウェアも存在する (Unreal Engine 4のWheeled Vehicle Movementコンポーネントなど)
AIが重要となるゲームエンジンや多くの群集シミュレーションは、基本的にノードベースの状態機械(ステートマシン)やビヘイビアツリーを備えている (UnityのMecanim、Unreal EngineのAnimation Blueprints、CryENGINEのModular Behavior Treeなど)。
統合ソフトウェアは、基本的な群集シミュレーションにのみ対応しているものが多い (3ds MaxのCharacter StudioのCrowdコンポーネント、SoftimageのICE CrowdFX、LightwaveのFlocking、Houdini 14以降、BlenderのBoidsパーティクルなど)。
クロスシミュは布だけでなく金属板やプラスチックなどの可塑性物質にも使われているが、クロスシミュには力学ベースのものと、位置ベースのもの(PhysX、Havok Cloth、Maya nCloth、Bulletなど)が存在する。位置ベースの手法は、正確性が劣るものの、高速かつロバストである。
なお、ソフトウェアによっては、クロス上クロス(cloth-on-cloth)の相互作用を上手く扱えないものや、破けに未対応のものが存在する。また、ソフトボディでは風船などの再現が可能な体積保存に対応するものがある。粘着性に対応するものもある（Cinema 4D 2023以降など）。
リアルタイムクロスシミュレーションは、ゲームに使われるほか、ボディスキャンとの組み合わせでファッション可視化にも使われる方向に向かっている。
基本的なものとして、変形を起こさずに衝突を再現する剛体シミュレーション、開いたメッシュに対し衝突と変形を再現するクロスシミュレーション、閉じたメッシュに対し衝突と変形を再現するソフトボディシミュレーションが存在する。衝突判定では、突き抜けを起こすアルゴリズムと、突き抜けを起こさないアルゴリズムが存在し、ソフトウェアによって対応具合が異なる。クロスシミュレーションやソフトボディシミュレーションでは高速なマススプリングモデルにのみ対応するソフトウェアがほとんどであるが、より正確な有限要素法(FEM)によるソフトボディシミュレーションに対応するソフトウェアも存在する (Houdiniなど)。
流体シミュレーションには複数の実装方法があり、パーティクルを流体のように動かす流体パーティクル (SPH法など)、3D格子(グリッド)を使う流体シミュレーション (格子法)、パーティクルと格子を組み合わせたハイブリッド流体シミュレーション（FLIP法など）に対応するソフトウェアがある。また、FLIP法より安定したAPIC法に対応するソフトウェアも出始めている。液体を扱うものではパーティクルベースであれグリッドベースであれメッシュ化が必要となるため、メッシュ化のための専用プラグインも存在している (#メッシュ化)。気体(炎や煙)を扱うものでは基本的にボクセルが生成される (標準形式としてOpenVDBがある)。また、海洋の近似的生成や、2Dの波エフェクト (BlenderのDynamic Paintなど)をサポートするソフトウェアもある。
ソフトウェアによって、水飛沫や泡の再現、表面張力の再現、浮力の再現 (3ds MaxのmParticlesなど)、伝熱の再現、可変粘度による融解や凝固の再現 (IoMeltやHoudiniなど)、粒状流への対応、混相流への対応 (RealFlow 2015.1以降など)、超弾性への対応 (Houdini 18以降のFEMのNeo-Hookeanモデル、thinkingParticles 7.1以降のMPMソルバーなど)、流体のシェイプ形成力への対応 (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ソフトウェアにおける物理シミュレーションには頂点ベース・エッジベース・サーフェスベースのものがあり主に芸術性を重視しているため、物理的な解析が必要な場合には連成解析に対応した解析ソフトウェアを使った方が良い。
パーティクルからメッシュを生成するプラグイン。
景観生成ソフトウェアのいくつかは、 海洋のアニメーションにも対応している (VueやDreamScapeなど)。また、統合ソフトウェアやシミュレーションソフトウェアの中にも、標準で海洋のアニメーションに対応しているソフトウェアが存在する (上記表参照)。
高速なボロノイ分割などを使った事前分割による破壊のみに標準対応する統合ソフトウェアが多いものの、正確な有限要素法(FEM)に対応しているソフトウェアも存在する (Houdiniなど)。
ヘアやファーはモデリング、ダイナミクス、レンダリングに至るまで独自に扱われることが多く、多くの統合ソフトウェアが標準で対応している (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ツールなど)。
PSR (Position-Scale-Rotation)へのベイクと、PLA (Point Level Animation)へのベイクがある。また、PLAでは、頂点数の増減に対応するものとしないものがある。#ジオメトリーキャッシュも参照。
ジオメトリキャッシュなどを修正するソフトウェア。
ショットスカルプトは、破綻したシミュレーションの修正や、変形する物へのマッチムーブなどに使われている。統合ソフトウェアに搭載されたものもある（LightWave 2023以降のChronoSculpt（元は単体ソフト）など）。
ライティングは、統合ソフトウェアで行うことも多いが、ライティングに特化したソフトウェアも存在する。Alembic/USDパイプラインでは、レンダリング及びコンポジットするソフトウェア側でライティングを行うことがある (ClarisseやHoudini 18以降のSolaris、V-Ray for NUKE、OctaneRender for NUKEなど)。
ライトの一覧表示 (ライトリスター)に対応するソフトウェアが多く、また一部のレンダラーも独自のライトリスターを持っている (V-Ray、Chaos Coronaなど)。ライティング設定に対応したGUIを持つレンダリングソフトウェアも存在する (Maxwell RenderのMaxwell Studio、Guerilla RenderのGuerilla Render GUIなど)。
ソフトボックスやアンブレラなどの現実の機材を模したもの。撮影前のプレビジュアライゼーションにも使われる。
標準で対応する統合ソフトウェアも存在する (MODO、3ds Max 2017以降のSun Positioner、LightWave 2019以降、Blender 2.82以降に付属のSun Positionアドオンなど)。標準で対応するレンダラーも存在する(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アドオン、Unreal Engine 4のSkyAtmosphere、Unreal Engine 4.26以降のVolumetric Cloudsなど)。
虹の表示に対応しているもの (Cinema 4DのPhysical Skyなど)、薄明光線に対応しているもの (Cinema 4DのPhysical Skyなど)、月に対応しているもの (LightWaveのSkyTracer、Cinema 4DのPhysical Skyなど)、星や星座の表示に対応しているもの (Cinema 4DのPhysical Skyなど)も存在する。
サーフィスベースであるため、下以外から見た雲などの再現はできない。
画像ベースのため、動く雲などの再現はできない。
ライトペイントには、環境光源のIBL用画像に放射光を直接ペイントするものや、受光物の反射位置にペイントすることで面光源を追加するものなどがある。標準で前者に対応するソフトウェアも存在する (KeyShotのHDRI-EditorのPin機能、Substance Designer 2019.2以降など)。後者対応の物にはMaverickなどがある。
標準でライトミキサーに対応しているレンダラーが存在する (レンダラーの対応表参照)。ライトミキサーに未対応のレンダラーでも、ライトグループ毎のレンダリングを行いコンポジットに渡すことで同等のことを行うことができる。
ポストプロセスで、より細かくライティングを弄りたい場合、マルチパスレンダリングが使われている (多くのレンダラが対応)。より細かなパスを作ることができるLPE (Light Path Expressions)に対応するレンダラも存在する (レンダラーの対応表参照)。
法線パスを使ったリライティングに対応するコンポジットソフトウェアも存在する (NUKEのRelight nodeなど)。
レンダラーはレンダリング機能を提供する物である。単体動作可能なアプリケーションだけでなく、プラグインモジュールとして提供されている物も存在する。またレンダリング標準APIとしてUniversal Scene Description（USD）のHydraがあり、それに対応するソフトウェアが増えている（Katana 3.0以降、Houdini 18以降のSolaris、Nuke 13.0以降、Maya 2024.1以降など）。なおHydraは標準で簡易リアルタイムレンダラーのHdStorm（旧HdStream）と簡易レイトレーシングレンダラーのHdEmbreeを備えている。
レンダラーには、動画に向くものと、向かないものが存在する。動画に向くものは、フリッカー(ちらつき)が起こりにくく、高品質なモーションブラーにも対応している。また、レンダリング法により、マテリアルの表現できる範囲が異なる。それもあり、レンダラーにはあまり物理的でないものと、より物理的なものが存在する。物理ベースを謳うものであっても、幾何光学にのみ対応するものが殆どであり、光の分散やフルスペクトラルレンダリングに対応していないものも存在する。偏光・干渉・回折などの物理光学(波動光学)に完全に対応するレンダラーは殆ど存在しない (Oceanが偏光と回折に対応している)。
また、省メモリで大規模シーン向けのもの (RenderMan、Arnold等)、複雑なライティングに強いもの (Chaos Corona等)、マテリアルプリセットの豊富なデジタルプロトタイピング向けのもの (KeyShot等)、エフェクト向けのもの (Krakatoa等)などが存在する。また可視化などに向けてプリセットモデルの搭載してるものも増えている (KeyShotのKeyShot Cloud Library、V-Ray 5以降およびChaos Corona 8以降のChaos Cosmos、LuxCoreRender 2.4以降のLuxCore Online Libraryなど)。
3DCG統合ソフトウェアのレンダリングエンジンのいくつかは、3DCADなど別分野のソフトウェアにも提供されている (MODOやCinema4Dなど)。
また、レンダリングにはインタラクティブ (リアルタイム) なものと非インラタクティブ (非リアルタイム) なものが存在する。非インラタクティブなレンダリング手法にはキャッシュ効率を上げるためのタイルレンダリングが存在していたものの、マイクロジッターサンプリング (Scramble Distance) の登場でタイル化が不要となりインタラクティブなレンダラーが増えていった（なおタイルレンダリングはメモリの容量越えを防ぐためにはまだ使われている）。その他、GPUによる汎用計算 (GPGPU) 及びレイトレーシングアクセラレータ (NVIDIAのRTX等) の普及によってレンダリングのインタラクティブ性はより増していった。このインタラクティブ性はライティングやルックデブなどでのプレビューレンダリングや、デジタルプロトタイピング（英語版）の可視化などで重要となる。3D可視化向けソフトウェアについては#建築および製品可視化ソフトウェアの例を参照。
大規模なエクステリア向きの単方向パストレース (PT)及び、複雑なライティング向きのレンダリング手法 (VCM、BDPT+MLT、Light Cache又はパスガイディング）の両方に対応し、かつモーションブラー対応するもの。
コンポジットに使われるディープ画像へのレンダリング又はCryptomatte出力に対応のもの。上述のV-Ray、RenderMan、Maxwell Render、Redshift及びOctane Renderも参照。
なお色合わせ（カラーマッチング）の容易なスペクトルレンダリングもVFXに使われてきている。
標準でベイク向けのレンダラーを持っているソフトウェアも存在する (MayaのTurtle、Unity 5.6以降のProgressive Lightmapperなど)。#UVアトラス/パッキングや3Dライブラリ#大域照明 (GI) ライブラリも参照。
近年は一般的なレンダラーがOpenVDBに対応してきており (対応表参照)、エフェクトのレンダリングに多用されはじめている。
学術を目的としているため、最適化よりも実装しやすさが優先されている。
GPU未搭載のスーパーコンピュータで算出したデータの可視化は、昔は別途レンダリング用コンピュータ・クラスタを用意して行っていたが、現在はスーパーコンピュータで直接CPUレンダリングすることも行われている。
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など) も残っている。その中には、ラジオシティに対応するものもある (3ds MaxのScanline (Lightscape Technologie製Lightscape由来)など)。
標準でエッジレンダリングに対応する統合ソフトウェアが多い (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のFreestyle及びLine Artなど)。また、標準でベクターレンダリングが可能な統合ソフトウェアも存在する (MayaのMaya Vector、Blender付属のFreestyle SVG Exporterアドオンなど)。
標準で多くのマテリアルを含むマテリアルライブラリを持つレンダラーも増えている (対応表参照)。また、統合ソフトウェアに付属するものもある (3ds Max/Inventor/AutoCAD/Revit等に付属のAutodesk Material Library、KeyShotなど)。
公式のマテリアル/テクスチャ等リソース共有サイトが用意されているソフトウェアもある (Substance 3DのSubstance Share、ZBrushのMatCap/Alpha/Texture Library、RenderManのRenderMan Community、Indigo RendererのMaterial database、LuxRenderのMaterials DB、Maxwell RenderのFREE resources libraryなど)。
3DCG動画の後処理では、コンポジット、ノンリニア動画編集、カラーグレーディングが行われており、それら複数の工程に対応するソフトウェアも存在している。また、統合ソフトウェアの中には、これらの工程に対応するものもある (SoftimageのIllusion、HoudiniのCOP、BlenderのコンポジットノードやVSEなど。後述)。
コンポジットでは、レンダー済み素材や実写や生成エフェクトの調整及び合成、視覚(網膜、虹彩、脳など)やカメラ(レンズ、レンズフィルタ、フィルム、受光素子、転送回路、現像など)の再現、演出のための加工などを行う。カメラの再現は、レンダリング時にフィジカルカメラを使って行うこともある。
コンポジットはリニアなカラースペースの32bpc浮動小数点カラーが使われることが多い(リニアワークフロー)が、速度やサイズの関係からより低い色深度や非リニアな色空間が使われることもある。現実の光の強さを元にHDRレンダリングをした場合は、LDRに変換する際に、フィルムや眼球を模したトーンマッピングを行う必要がある。カラー調整はカラーコレクションやカラーグレーディングと呼ばれているが、色を補正する場合にカラーコレクション、色合いを加工する場合にカラーグレーディングと使い分けて呼ぶことも多い。独自のトーンマッピングが施されたデジカメ写真の場合は、カラーチャートなどを参考にトーンマッピングを逆変換してリニアカラースペースに戻す必要がある。また、写真フィルムをスキャンして使う場合は、フィルムの分光色素濃度曲線 (CMYカラースペース、補色波長のRGBとのズレ、吸収スペクトルの重複)や特性曲線 (露光量における濃度)、潜像退行・色褪せ、スキャナの特性などを参考にリニアカラースペースに戻す必要がある。
レンダーパスにおけるRGBA画像、ベロシティ(スピードベクトル)、Z深度、法線、UVなどの情報を劣化少なくコンポジットソフトウェアに渡すために、ロスレスの16bpc画像や16bpc/32bpc浮動小数階調画像が用いられる。また、オブジェクトIDやマテリアルIDも画像化されて渡される。なお、Z深度やIDなどの特殊なパスはアンチエイリアスすることができなく(又は出来たとしても品質が落ちる)、画像にアンチエイリアスをかけるとこれらのパスとのズレが生じる。この問題を避けるため、2倍もしくは4倍でレンダリングしておき、コンポジット後に縮小するという方法が使われている。
カメラデータの受け渡しには、汎用の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と実写合成のためには、クロマキー合成やロトスコープの機能が使われる。ロトスコープのために、ベクトルマスク作成に対応しているソフトが多い。また、トラッキング機能を搭載するものも増えており、トラッキングによってベクトルマスクを変形させることもできるようになっている。
近年ローリングシャッターを持つスチルカメラによる動画撮影も増えており、ローリングシャッターを修復できるソフトウェアも存在している(AfterEffectsやPFTrackなど)が、修復には限界があるためVFXには不向きである。どうしてもローリングシャッターを持つ映像を素材として使う場合は、ローリングシャッター除去してトラッキングした後、合成する3DCG素材のレンダリングでローリングシャッターの再現を行うのが良いとされる。
キーヤーには、2D色空間ベースのキーヤー (FlameのDiamond Keyer、NukeやAfter EffectsのKeylightなど) と、3D色空間ベースのキーヤー (Primatteや、FlameのModular Keyer及びMaster Keyerなど) が存在する。2D色空間ベースのキーヤーのKeylight等は、原色以外の色のキーイングに弱い。またAIベースのキーヤーも存在する。
また、コンポジットを馴染ませるためにはライトラップが必要となる。これらはエフェクト集にも含まれている。
ステレオ3D動画への変換に対応するトラッキングソフトウェアも存在する (PFTrack 2017以降など)。
一般的に複数シーンやオーディオとの合成や編集フィニッシング(最終的なカラーコレクションやミキシングなどの映像・オーディオ調整)はこの段階で行われる。詳しくは動画編集ソフトウェアを参照。
ステレオ3D動画の編集にはAutodesk Flame、Avid Media Composer、DaVinci Resolve Studio、Vegas Pro、Final Cut Pro 、NUKE STUDIO + OCULAプラグインなどが、VR動画の編集にはNUKE STUDIO、Adobe Premiere Pro、Vegas Pro、Final Cut Proなどが対応している。
統合ソフトにおいても、シーン内でのオーディオ合成の対応 (Mayaのカメラシーケンサなど) や、3Dオーディオへの対応 (CINEMA 4D、Blender、Shade、各種ゲームエンジンなど) や、アニメーションとオーディオの連携に対応(3ds Max ProSound、Blenderなど)してきており、その段階で音声やSEを合成することもできるようになっている。動画編集に対応する統合ソフトも存在する (BlenderのVideo Sequencer Editorなど)。
3Dトラッキングは、動画から特徴的な部分をトラッキングして、カメラやオブジェクトの位置や動作を算出でき、マッチムーブやデジタルメイクアップなどに必要となる。3Dトラッキングに対応するコンポジットソフトウェア (NUKE X/NUKE STUDIO、Autodesk Flame、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印刷に特化したAMF形式、3MF形式などが使われている。3D印刷可能なモデルの作成のために、メッシュの検証やクリーンアップに対応する3DCGソフトウェアが増えている（下記の表参照）。支持構造の追加に対応するものもあった (Meshmixerなど)。
3D印刷ソフトウェアでは、プリントする複数のオブジェクトを、プリントしやすい角度に回転して、プリント可能な範囲に詰め込む(多い場合は複数回に分ける)。また、素材の設定もこの段階で行う。大きなものをプリントする場合、ジョイント付きで部品を複数に分ける必要があり、これを行うためにブーリアン機能を持つソフトウェアが使われる。また、そのための専用機能を持つソフトウェアも存在する (3D-CoatのSplit&Jointsツールなど)。
RepRapなどの熱溶解積層(FDM)式3Dプリンタ向けではG-codeジェネレータ(スライサー)を使ってSTLからG-Codeを生成して、それをプリンタに送信する。FDM式の場合、異なった色や素材(ABSやPLAなど)をプリントするために、複数のノズルが使われている。ノズルや素材によって温める温度や温度上昇速度(Ramp Rate)、押し出し速度が異なる。また、プリント中に倒れないように土台や支柱を追加したり、柔らかいうちに重ねて崩れてしまわないように冷却時間や冷却ファンを考慮してG-codeを生成する必要がある。
3Dモデルから、ペーパークラフトの出力ができる。複雑にならないようにするためには、ポリゴン数の削減が必要になる。
カッティングマシンを用いることで、切る手間を減らすことができる。
糊代を生成しないもの。標準で対応するソフトウェアも存在する (RhinocerosのUnrollSrfやSmashなど)。
Facebookなど一部のSNSサイトも3Dモデル投稿に対応してきている。
多くの統合ソフトウェアは既にテキストエディタを持っている。なおPythonスクリプトの開発では、外部のPython向けIDE（PyCharm、EclipseのPyDev（英語版）、Wing IDE（英語版）など）からでもリモートデバッギングなどが可能となっている。またシェーダー開発については、#シェーダー構築を参照。
プロジェクト管理 (手順計画、日程計画、タスク管理、報告・通知管理、メモ管理、自動集計)、モデルやショットなどのデジタルアセット管理 (バージョン管理、異形管理、依存管理、レビュー、パブリッシング)など。レビューのための機能として、タグ付け機能、コメント機能、動画ストリーミング、自動的なターンテーブル動画の生成などが搭載されているものもある。レビュー用動画作成のために、レンダーファーム管理ソフトと連携できるシステムもある。
ファイル内部でのバージョン管理や異形管理に標準で対応している統合ソフトウェアも存在する (3ds MaxのScene States、modoのRender Passes、HoudiniのTakes、Cinema 4D R17以降のTakeシステムなど)。
2022年現在、3DCGソフトウェアと管理システムを結ぶための標準APIである OpenAssetIO が Academy Software Foundation で開発中となっている（元Foundry製）。
openEXR、DPX、Cineonなどの画像シーケンスの再生、デジタルシネマカメラ形式の再生など。また、レビューソフトウェアでは、アノテーション付けや動画比較、リモート再生など。ショット管理では、バージョン管理など。
シーケンス再生ツールが付属するソフトウェアは多く (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など) ものの、レビューに特化したシーケンス再生ソフトウェアも存在している。
標準で対応しているソフトウェアも存在する (DaVinci ResolveのPostgreSQLサーバーによる共有 (同時作業はStudio版のみ)、Fusion Studio付属のStudio Player (Generationの後継)、Adobe Creative Cloudのグループ版以上のPremiere Pro/After Effects/Preludeで使用可能なTeam Projects、SCRATCHのSCRATCH Remote機能、Autodesk FlameのStone及びWireなど)。
静止画のみの独自の仮想フレームバッファーに対応するレンダラーも多い (V-RayのV-Ray Frame Buffer、ArnoldのArnold RenderViewなど)。
レンダーファーム管理ソフトウェアは、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のRNDR/OctaneRender Cloud、V-RayのChaos Cloud (旧V-Ray Cloud)、Maxwell 5以降など)。独自デスクトップクライアントのあるレンダーファームも存在する（Fox Renderfarmなど）。
3DCGソフトウェアには標準、もしくはプラグインを入れることによって様々なファイル形式でインポートやエクスポートすることができる。しかし、ソフトウェアによって対応形式や対応具合が異なるため、作業パイプラインによっては、単体コンバータを使ったり、使っているソフトウェアとは別の3DCGソフトウェアをファイルコンバータとして使う必要が出てくる。
CADファイル形式の取り込みは#建築および製品可視化ソフトウェアの例及び#モデル最適化を参照。ポイントクラウドについては#ポイントクラウド取り込み・編集のみを参照。USDZ形式への変換にはUniversal Scene Description#オーサリング形式としての使用を参照。
OSに標準で付属するものも存在する (Windows 10 Creators Update以降の3D Viewer (旧Mixed Reality Viewer←View 3D)、macOS及びiOSのAR Quick Lookなど)。
以前は連番objファイルなどが使われていたが、現在はオープンソースのAlembic形式が普及してきている。
標準で対応する統合ソフトウェア (3ds Max 2017以降のScene Converter、Maya 2017以降のmrShadersToArnold.py、Blender 2.78以降に付属のMaterials Utils Specialsアドオンなど)やレンダラー (V-Ray、Maxwell Render、Octane Render、Corona Render付属のCorona Converterスクリプト (Racoon Artworks製) など) もある。
標準でソフトウェア連動(Live Linking)に対応するソフトウェアも存在する(Maya 2017 Update 3以降とAfter Effects、After EffectsとCinema 4D、Unreal Engine 4.19以降とMaya/MotionBuilderなど)。
色弱(色覚異常)シミュレータが標準で内蔵されているソフトウェアもある (Unreal Engine 4、Photoshopなど)。色弱者対応のデザインの標準として、カラーユニバーサルデザインが存在する。
3DCGアプリケーションの遠隔操作には、OpenGL等に対応した一般的な遠隔操作ソフトウェアを使うことができる (リモートデスクトップ参照)
3DCGアプリケーションのスクリーンキャストには、GPUに対応したスクリーンキャストソフトウェアが必要となる。標準でスクリーンキャストに対応している統合ソフトウェアも存在する (Blenderなど)。また、3DCGでは複雑な操作を行うため、ユーザーの操作を表示することが望ましく、そのために別のソフトウェアが必要になる場合もある。
3DCGソフトウェアのフローティングライセンスの管理には、ライセンス管理ツールのFLEXlm (Autodesk、Thinkbox、Esri等が採用) やRLM（英語版） (Foundry、MAXON、Solid Angle等が採用) が使われており、それらの一括監視のためにライセンスモニタリングツールが使われている。ライセンスモニタリングツールについてはソフトウェア資産管理#ソフトウェア資産管理 (SAM) ・IT資産管理（ITAM）を支援するソフトウェアを参照。
このセクションにある物は、特定用途での利用に特化された物である。
一部のエンターテイメント作品においても、科学可視化ソフトウェアが使われている。
Poserや3ds Maxなどが使われている。
可視化やバーチャルトレーニングの作成など。