hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
ケーニヒスフェルト (オーバーフランケン)
ケーニヒスフェルト (ドイツ語: Königsfeld) は、ドイツ連邦共和国バイエルン州オーバーフランケン行政管区のバンベルク郡に属す町村（以下、本項では便宜上「町」と記述する）で、シュタインフェルト行政共同体を形成する。
ケーニヒスフェルト (オーバーフランケン) 地理
ケーニヒスフェルトは、オーバーフランケン西部バンベルクとバイロイトの間、フレンキシェ・シュヴァイツ周縁部に位置し、フランケン・ジュラ山地中にはアウフゼス川の水源が湧出する。
ケーニヒスフェルト (オーバーフランケン) 自治体の構成
ケーニヒスフェルトは、公式には以下の7つの集落からなる。
ケーニヒスフェルトは、ヴァッテンドルフおよびシュターデルホーフェンとともにシュタインフェルト行政共同体を形成する。行政共同体の本部はシュタインフェルト地区（シュターデルホーフェン）に置かれている。
ケーニヒスフェルトは、現行の紋章を1973年の市町村再編時から用いている。赤地に、斜めにクロスした2本の銀の戦棍、その上に金の王冠、下に金のホタテ貝。
王冠は自治体の名前に由来する。2つの戦棍は、ケーニヒスフェルトを治めたバンベルクの陪臣トルーエンディング伯家の紋章。ホタテ貝は、カトリックの聖ヤーコプ教区教会のパトロンを示す。
ケーニヒスフェルト (オーバーフランケン) 歴史
8世紀には、この村は、カロリング王室領であり "Chunigeshofen in montibus versus Bohemiam"と呼ばれ、741年のヴュルツブルク司教への贈与証明書に初めてその名が記されている。カロリング王室は、アウフゼス川の水源近くに王室領を有し、フランク王国の国境警備にあたらせていた。カール大帝は、東部のスラブ民族との国境を点検し、ハルシュタット、シェスリッツをその勢力下に組み込んだ。16世紀になるまで、ハウプツモールヴァルトはケーニヒスフェルト付近まで広がっていた。
経済区域はケーニヒスフェルトの西周縁部にあった。一方、第2の入植地がアウフゼス川沿いの東周縁部にできていった。この付近からはスラブ人の生活土器が見つかっている。
ケーニヒスフェルト付近の鉄鉱石の鉱脈は、前史時代から採掘、精錬され、ケーニヒスフェルトを経済的な重要地域にしていた。探鉱坑跡、鉱滓の山、あるいは、たとえばアルツベルク（エルツベルク=鉱山）といった農地の名前が往事を偲ばせる。
ケーニヒスフェルト (オーバーフランケン) 歴史
アウストラシア王国の宮宰カールマンは、741年または742年にケーニヒスフェルトを新たに創設されたヴュルツブルク司教に分け与えた。1008年には、皇帝ハインリヒ2世が、その王領（私有地）をバンベルク司教に贈った。1121年にバンベルクの家人で司教の陪臣がこの地を治めていたことが証明されている。バンベルク司教領創設後も、ヴュルツブルク司教が十分の一税徴収権を保持した集落は、ポックスドルフ、ブルンおよびフォイツマンスドルフであった。ヴュルツブルク司教は、その後も14世紀まで、ケーニヒスフェルトのキリアン教会の後ろ盾であり続けた。
14世紀にケーニヒスフェルトは、アウフゼス家の所領となった。三十年戦争では1632年にスウェーデン軍の焼き討ちを受けた。この攻撃によって、主任司祭フンクがアウフゼス川の水源近くで殺害された。水源近くには、彼の殉難を記念するプレートが建てられている。
ケーニヒスフェルトは、バンベルク司教本部領の一部として、1803年の帝国代表者会議主要決議によってバイエルン領となった。バイエルン王国の行政改革の時代、1818年の自治体令により現在の自治体が生まれた。
ケーニヒスフェルト (オーバーフランケン) 歴史
第一次世界大戦では、ケーニヒスフェルトおよびその周辺地域に大きな被害は受けなかった。第二次世界大戦末期、ケーニヒスフェルトはアメリカ軍の砲撃に長時間さらされることになった。アメリカ軍に負傷者が増え、部隊が撤収したため最悪の事態は免れた。
1978年5月の自治体再編以後、ケーニヒスフェルトは、シュターデルホーフェンおよびヴァッテンドルフとシュタインフェルト行政共同体を形成した。行政共同体本部は、シュタインフェルト（シュターデルホーフェン内）に置かれた。
17世紀頃のこの村の人口は約1,000人程度であった。三十年戦争でその数は大きく減少し、村の機構を維持することもできなくなった。1945年以後しばらくは、難民などで人口は増加したが、十分な雇用先がなかったために多くの人が立ち去っていった。現在は、6つの自治体を合併し、ケーニヒスフェルト全体の人口は1,400人ほどである。
ケーニヒスフェルト (オーバーフランケン) ケーニヒスフェルトの教区
すでに1340年から1345年には、ケーニヒスフェルトはヴュルツブルク司教下に独自の教区を設立しており、ヴュルツブルクの司教聖人である聖キリアンを守護聖人としていた。カトリックの聖ヤーコプス＝カタリナ自衛教会の防衛壁は、その一部が現存している。現在は、バンベルク司教区ハルシュタット／シェスリッツ教区に属するケーニヒスフェルト小教区として位置づけられている。
3DCGソフトウェア
3DCGソフトウェアは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。
3DCGは主に
の工程に分かれている。作業の基幹となり多くの工程の調整が行える統合型ソフトウェアの他に、個別の機能に特化したソフトウェアも存在する。モデリングが中心となっているソフトウェアは「モデラー」、レンダリングが中心となっているソフトウェアは「レンダラー」と呼ぶ。
各種工程における機能においては、破壊的なものと、非破壊的なものが存在する。非破壊的なものは過去の操作の修正がしやすく、パラメータにキーフレームやドリブンキー/IPOドライバを入れることでアニメーションさせることもできる。しかし、メモリやディスク容量を消費するため、メモリサイズの大きなものを扱ったり細かな編集を繰り返したりといったことは苦手である。互換性の問題もあるため、他のソフトウェアとのやりとりには破壊的な形式に直すことも多かったが、最近は非破壊的な交換形式というものが開発されてきている。
3次元CADソフトウェアについては「CAD」、3次元GISソフトウェアについては「地理情報システム」を、仮想地球儀については「仮想地球」を、3次元プラネタリウムソフトウェアについては「プラネタリウムソフトウェア」を参照。
3DCGソフトウェア 概要
3DCGが発案された当初は一部の用途にのみ用いられる技術であり、多くの処理能力に高価な高性能ワークステーションや専用のハードウェアが必要となることが多いために市場も小さく、ソフトウェアも高価であった。しかし、時代が進むにつれてコンピュータの性能が向上し、高性能なコンピュータが一般に普及することにより、3DCGの市場が拡大してソフトウェアの低価格化・高機能化が進んだ。
3DCGソフトウェアは、科学からエンターテイメント、純粋芸術までさまざまな用途に使われており、用途によって必要な機能、必要な品質、環境、納期などが異なるため、それに合わせて多くの種類が存在する。必要なレベルに達しているソフトウェアのことを「Production Ready」であると表現する。1つの用途を達成するために複数のソフトウェアが必要になることもあり、その場合にソフトウェア同士の連携が重要となる。
3DCGソフトウェアの主な用途としては、以下のものがある。
3DCGソフトウェア 概要
ビジュアライゼーション/ビジュアルコミュニケーション
製品ビジュアライゼーション
テクニカルイラストレーション
建築パース/ウォークスルー（#ビジュアライゼーション向け）
エクステリア
インテリア
映像撮影のプレビジュアライゼーション
演劇舞台のデザイン
科学可視化
地理情報システム
ニュース番組の再現CG/解説CG
ドーム映像（#ドーム動画作成）
プラネタリウム
インタラクティブコンテンツ（#ゲーム及びインタラクティブコンテンツ作成）
ゲーム
バーチャルリアリティ (VR) - VR動画（#VR動画）およびインタラクティブVR（#インタラクティブVR/拡張現実 (AR)/複合現実 (MR)）
博物館の展示物
仮想遊園地・仮想水族館
フライト/鉄道/ドライビングシミュレータ
手術シミュレータ
防災シミュレータ
バーチャルリアリティ療法
3D仮想観光
インタラクティブウォークスルー
インタラクティブ3Dコミュニケーション
Web3D
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など）。
3DCGソフトウェア ソフトウェア毎の差異
また視覚効果協会 (VES) の協力によってソフトウェア間の互換性を高めるための複数OS対応共通プラットフォーム「VFX Reference Platform」が定められており、3DCGソフトウェアではその規定にあるプログラミング環境およびライブラリの使用が一般的となっている。この VFX Reference Platform は複数のソフトウェアにまたがる製作パイプラインの構築を簡単にするほか、レンダリング共通API「Hydra Render Delegate」での連携時の互換性確保にも重要となっている。
3DCGソフトウェア ソフトウェア毎の差異
なおデスクトップ/ラップトップの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対応を終了した）。
3DCGソフトウェア ソフトウェア毎の差異
デスクトップ/ラップトップのCPUではx64アーキテクチャが、モバイルデバイスのCPUではARMアーキテクチャが一般的となっており、CPUアーキテクチャによる分断も存在した。しかしながら2012年にはMicrosoft Surfaceと共にARM版Windowsが登場し、また2020年にはAppleがデスクトップ向けCPUにもARMアーキテクチャを採用し、非モバイル向けソフトウェアでもARMアーキテクチャにネイティブで対応するものが増えていった。
OS間の進む分断化によってmacOS版の提供を取りやめるソフトウェアも登場している一方、モバイルデバイスがデスクトップに近づくにつれてモバイルデバイスに対応するデスクトップソフトウェアも登場している。
3DCGソフトウェア ソフトウェア毎の差異
ソフトウェアによって用語の違いが存在する。アメリカ英語とイギリス英語の違い（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やショートカットは異なるが、共通点も多い。
3DCGソフトウェア ソフトウェア毎の差異
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で業界互換のキーマップが追加された。
3DCGソフトウェア ソフトウェア毎の差異
コンテキストメニューは、円形メニューを採用するものが増えている (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度回転する必要があり、右手系と左手系を変換をするには負のスケールを使って一軸を反転する必要がある。
3DCGソフトウェア ソフトウェア毎の差異
また、ボーンの座標系(ボーンの長さ軸/主軸(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などが採用している。
3DCGソフトウェア ソフトウェア毎の差異
画像の座標は、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ソフトウェア ソフトウェア毎の差異
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)など)。汎用単位の標準の単位設定はソフトウェアによってバラバラに異なっている。
一つの単位と単位スケールだけでは表現できるシーン範囲に限界があるため、オープンワールドのゲームなど広い地形を必要する場合にはタイル化された地形を動的に読み込むという手法が用いられる。
3DCGソフトウェア ソフトウェア毎の差異
内部計算に単精度を採用するソフトウェア (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に使われるオブジェクトには幾つかの種類がある。ソフトウェアは通常、複数の種類に対応している。
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モードも持っており、三次元テクスチャを効率的に圧縮することもできる。
3DCGソフトウェア ソフトウェア毎の差異
ステレオ3D画像や多視点画像では、それらに標準で対応するOpenEXR形式が多く用いられており、その拡張子は一般的な.exrのほか、ステレオ画像で.sxr、多視点画像で.mxrが使われている。また、画像を独立したペアの画像ファイル(例えば*_L.pngと*_R.png)として保存することも行われている。ステレオ3D画像では、フレームパッキングやインタレースやサイドバイサイドやトップアンドボトムなどの3D方式に変換してステレオ3D未対応の画像形式で保存することも行われている。
素材には16bpcレギュラー画像(Photoshop PSDなど)やLogカラースペースの10bpc画像(CineonやDPXなど)、デジタルカメラのRAW形式などが使われることもある。
3DCGソフトウェア ソフトウェア毎の差異
テクスチャサイズは時代と共に拡大しており、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以降など)。
3DCGソフトウェア ソフトウェア毎の差異
レギュラー画像では、歴史的経緯により、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以降など)。
3DCGソフトウェア ソフトウェア毎の差異
アルファチャンネル付きの画像には通常のストレート(非事前乗算)なものと、アルファをRGBに事前乗算したものとがあり、画像形式によってアルファ値の扱いが異なっている。例えば、PNG形式ではストレートアルファにのみ対応しており、一般的にアルファの事前乗算には対応していない。一方、OpenEXRではアルファの事前乗算が標準となっている。
3DCGソフトウェアやコンポジットソフトウェアなどにおいてはレンダリングやコンポジットにアルファオーバーが多用されるため、それを高速化するために事前乗算した画像が良く使われている。
事前乗算形式にすると、RGBの情報が不可逆的に失われ、RGBがアルファに依存するようになるが、浮動小数点画像においては逆変換での精度の問題は起こりにくい。
3DCGソフトウェア ソフトウェア毎の差異
精度や速度やカラースペースの問題もあり、コンポジットの中間形式にはHDR画像の連番が使われることが多い (OpenEXRの連番など)。容量の大きさから、圧縮効率の良いYUV色空間で10ビット～12ビットの色深度を採用した非可逆な中間形式が使われることもある (Apple ProResやAvid DNxHD (VC-3)、GoPro CineForm (VC-5)など)。これらの動画形式は編集の容易さのために、圧縮率の高い予測フレーム(インターフレーム)を使わずに、キーフレーム（イントラフレーム）のみで構成されているものが多い。
3DCGソフトウェア ソフトウェア毎の差異
実写素材においてもキーフレームのみの形式が使われることが多かったが(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など)での撮影も行われている。
3DCGソフトウェア ソフトウェア毎の差異
一部のプロ向けカメラを除いて、多くのカメラではクロマ間引き(YUV 4:2:2やYUV 4:2:0など)が行われているものの、クロマ間引きはクロマキーで抜く場合やカラーコレクションを行う場合などに、ノイズやアーティファクトを発生させる要因となる。同様に、編集時にもクロマ間引きを行わないことが望ましいが、一部の手順はクロマ間引きを行ってしまう (例えば中間コーデックにYUV 4:2:2なApple ProRes 422やGrass Valley HQXを使うなど)。
3DCGソフトウェア ソフトウェア毎の差異
オーサリングでは、メディアによって異なるフォーマットが用いられる。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ソフトウェア ソフトウェア毎の差異
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は大きく異なる。
3DCGソフトウェア ソフトウェア毎の差異
ゲームエンジンの開発言語では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等) も存在する。
3DCGソフトウェア ソフトウェア毎の差異
また、標準規格の拡張をした言語を採用しているソフトウェアや、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型非対応など)。
3DCGソフトウェア ソフトウェア毎の差異
エフェクト用の形式では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言語も使われていた。
3DCGソフトウェア ソフトウェア毎の差異
オフラインレンダリングでは、オープンソースの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言語が使われている。
使用するソフトウェアによってシェーダー形式が異なるため、シェーダー変換ソフトウェアが存在する (#シェーダー変換)。
3DCGソフトウェア ソフトウェア毎の差異
ステレオ3Dの3DCGを作る場合、ビューポート表示からレンダリング、コンポジット、レビュー、動画ノンリニア編集 (NLE)、オーサリングに至るまでステレオ3Dワークフロー対応のものを使うことが望ましい。既に多くのソフトウェアがステレオ3Dワークフローに対応してきているが、ステレオ3Dワークフロー未対応のソフトウェアや機能も残っている。
多視点(Multi-View)ワークフローに対応するソフトウェアも存在する (Blender 2.75以降など)。マルチカメラ編集に対応するNLEソフトウェアは多いものの、多視点(マルチアングル)なDVDやBlu-rayのオーサリングに向けて、マルチトラック動画のエクスポートが可能なNLEソフトウェアはまだ少ない。多視点は、多視差動画を作成するためにも使うことができるが、多視差動画に対応するソフトウェアは少ない。
3DCGソフトウェア ソフトウェア毎の差異
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以降など)。
3DCGソフトウェア ソフトウェア毎の差異
ソフトウェア間のデータのやりとりには主に、データ交換用の標準であるAutodeskのFBX形式 (元々MotionBuilder(旧Filmbox)で使われていた形式)、USD形式が使われる。昔は標準や事実上の標準であったCOLLADA形式 (.dae。OpenGLと同じくKhronos Groupが制定)、3D Studio形式(.3ds)、SoftimageのdotXSI形式(.xsi)も使われていた。ソフトウェアによって仕様や実装の違いがあるため、やりとりで問題が起きることも多い。
3DCGソフトウェア ソフトウェア毎の差異
また、やりとりには汎用形式以外も使われている。統合型ソフトウェアと外部レンダラー間のデータのやりとりにはレンダラ独自のプラグインの使用が多い (内部的には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形式などが使われる。
3DCGソフトウェア ソフトウェア毎の差異
ゲーム向けの汎用モデル形式としては、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に対応している。
3DCGソフトウェア ソフトウェア毎の差異
3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、3MF形式などが使われる。
また、3DCGソフトウェアでもノンリニア編集のファイル交換に使われるEDL形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAAFのインポート及びFCP XML形式のインポート/エクスポートに、Unreal EngineのSequencerがCMX EDL及びFCP XML形式のインポート/エクスポートに対応している。Pixarが中心になって開発しているオープンソースのOpenTimelineIOライブラリは、それら形式の多くに対応している。
最初のマテリアルは完全拡散反射に光沢やフレネル効果や完全鏡面反射を足すものであったが、その後、微細表面 (マイクロファセット) のラフネス (粗さ)を考慮したシェーダーが使われるようになり、その後、誘電体や導体 (金属)などの物性別のシェーダーが現れ、メタルネス (金属さ)が導入されて誘電体と導体の両者に使用可能な物理ベースシェーディング (PBS)に対応するソフトウェアが増加していった。
3DCGソフトウェア ソフトウェア毎の差異
巨大 (Uber) シェーダーではDisney式PBSシェーダーが普及することによって、OBJ+MTL形式やFBX形式、glTF形式などの一般的な3D形式でもPBSシェーダーへの対応が進んでいった (物理ベースシェーディング#PBS対応の3Dファイル形式参照)ものの、そのシェーダーに規定されてない表現が問題となり、それらの代わりとして柔軟にマテリアルを記述できる NVIDIA の MDL 形式や Lucasfilm 及び Industrial Light＆Magic の MaterialX 形式も登場していった（後者は後にAcademy Software Foundationへと移管）。
しかしながら、NVIDIA MDL形式に向けてはAdobe Standard Materialが、FBX形式やMaterialX形式に向けては Autodesk Standard Surface (MaterialX Standard Surface) が、glTF形式に向けては独自のマテリアル拡張 が登場するなどのマテリアル規格の乱立が続き、2023年には Academy Software Foundation が Autodesk と Adobe の協力によって新マテリアル規格の OpenPBR の策定を開始し、2024年にはその規格の正式版が公開された。
3DCGソフトウェア ソフトウェア毎の差異
なお、規格が同一でもソフトウェアによっては高速化のために近似計算を行っているため、ソフトウェア間のやりとりで見た目の変わることがある。
また特殊シェーダー (ヘアシェーダー、ボリュームシェーダーなど) は2025年時点でまだ標準規格は存在しない。
ボクセル/ボリューム形式は、流体シミュレーション、3D印刷、医療、一部のモデリングソフトウェア (3D-Coat等)などに使われている。3DCGでは、3Dテクスチャ (DDS形式、KTX形式等) や、オープンソースのOpenVDB形式 (*.vdb) が事実上の標準形式となっている。オープンソースのField3d形式 (*.f3d) に対応するソフトウェアもある。
3D印刷では、Shapewayのsvx形式や、NVIDIA及びHPの推進するGVDB形式 (*.vdx)があるものの、2017年現在普及していない。医療ではDICOM形式が使われている。
画像や映像のやりとりでは色空間が重要となる。色空間には、カメラの撮像素子の出力の色空間、圧縮のための色空間、作業のための色空間、保管のための色空間、頒布のための色空間、表示デバイスの表示素子の出力の色空間などが存在する。入出力デバイスによっても表現可能な色空間が異なるため、目的によって色空間を使い分ける必要がある。
3DCGソフトウェア ソフトウェア毎の差異
色変換の仕様としては Academy Color Encoding System (ACES) が存在し、2025年にリリースされたACES 2.0では従来の ACES に存在した色相の歪み、SDR出力とHDR出力のズレが解決されている。また ACES のパイプラインを実装したものとしてオープンソースライブラリの OpenColorIO が存在し、多くのソフトウェアがこのライブラリを採用している。Color Interop Forumの色相互運用ID仕様「An ID for Color Interop」も登場し、OpenEXR 3.4以降がそれを採用している。
3DCGソフトウェア 統合型ソフトウェアの例
統合型はシーンセットアップを基本に、モデリング、アニメーション、レンダリングなど多くの機能を備えた物である。最近はコンポジットやマッチムーブまで行えるソフトウェアが増えている。プラグインで機能を拡張できるものが多く、一つのソフトウェアだけで多くの作業が行えるほか、他のモデラー・レンダラー・モーション付けソフトウェアなどと組み合わせて作業パイプラインの中心の役割を担える。その他、モデリングなどの単機能目的のみで使われることも多い。一般的に統合ソフトは、標準機能同士の連携は優れているものの、他のソフトウェアに比べて一部の標準機能が古かったり低機能だったり直感性・操作性に乏しい場合が多々あるため、スクリプトやプラグインやソフトウェアを組み合わせて作業パイプラインを作ることが重要となる。
大きなプロジェクトでは、外部参照やアセットの軽量な代理表現、アセット管理 (#管理システムも参照)が重要となる。
OpenGLやDirectXの高機能化に伴い、ビューポートにおいてPBR (物理シェーダー)やエフェクト等によるリッチな表示が可能となった。また、3Dゲームや3D CADの可視化で使われるウォークスルー（歩行）/フライスルー（飛行）のような一人称視点ナビゲーションにも対応するソフトウェアが増えており、オーサリングせずに直接VR表示できるソフトウェアまで登場している。
3DCGソフトウェア 統合型ソフトウェアの例
GPUの汎用化（GPGPU）及びGPUに搭載されたレイトレーシングアクセラレータの普及によって高品質なレンダリングが高速となり、最終レンダリングと同等のインタラクティブレンダリングに対応するソフトウェアが増えている。レイアウトとレンダラーの統合は、特にライティング作業の効率化において重要となる。また、内外レンダラのビューポートへの統合も進んでいる。
並びは順不同である。
※以下▽はアニメーション対応、▼はアニメーション対応(キャラクタアニメーション有り)、■はアニメーション対応(ダイナミクス有り、キャラクタアニメーション有り)、★はアニメーション対応(キャラクタアニメーション有り、ダイナミクス有り、パーティクル有り)のソフトウェア。
★3ds Max（オートデスク←ディスクリート・ロジック←Kinetix）
Windows専用。NPR向けプラグインのPencil+に定評があり、アニメ業界で使われている。
3DCGソフトウェア 統合型ソフトウェアの例
ポイントクラウド、パラメトリックなアーキテクチャルオブジェクト、他のCG/CAD/CFDソフトウェアとの連携機能（ファイルリンク、ATF、CFD Data Object）、AutoCAD Civil 3D (土木設計向け)等との連携が可能なCivil View (旧DynamiteVSP)機能、2Dエフェクト (レンダリング効果)、簡易コンポジット機能 (ビデオポスト及びステートセット)、Exposure照明シミュレーションも内蔵している。2018.1では、VR向けとしてゲームエンジンの3DS Max Interactive (旧Autodesk Stingray)が付属された。
エフェクトでは、イベントベースのParticle Flowや液体シミュレーションのBifrostが搭載されている。また、エフェクト用のプラグインが豊富に存在しており、ルールベースのthinkingParticlesや、気体流体シミュレーションのFumeFXなどが良く使われている。
ポリゴンモデリングだけでなく、NURBSによるパッチモデリングにも対応しているものの長らく更新されておらず、制限がある。外部プラグインとしてPowerNURBSも存在する。
3DCGソフトウェア 統合型ソフトウェアの例
使用するプロジェクトの年間総収入に制限のある廉価な3ds Max Indieも存在する。過去には無料の簡易版であるGmaxや、可視化向けの3ds Max Designも存在した。
★Maya（オートデスク←エイリアス・システムズ）
クロスプラットフォームのハイエンド3DCGソフトウェア。映画業界のデファクトスタンダードとなっている。ゲーム業界でも使われている。CAD形式のインポートにも対応している（ATF）。
依存グラフが並列評価・GPU対応であり、キャラクターアニメーションに強い。Mudboxのスカルプトも統合されている。
描画から3Dオブジェクトを生成するペイントエフェクトという独自の機能がある。効率的にスキニングを行えるインタラクティブスキンバインドに対応している。
エフェクトでは流体のMaya Fluid Effectsや、ノードベースのBifrostが搭載されている。またモーショングラフィクス機能のMASHもある。ツール集のBonus Toolsも付属している。
3DCGソフトウェア 統合型ソフトウェアの例
ポリゴンモデリングだけでなく、NURBSによるマルチパッチモデリングにも対応している。Power Animatorを前身の一つとするMayaは、Autodesk Alias (旧Alias StudioTools)と兄弟関係にあり、Autodesk Alias AutoStudioパッケージにはAliasとMayaの両方が含まれている。
使用するプロジェクトの年間総収入に制限のある廉価なMaya Indie、サブセットかつ従量制のMaya Creativeも存在する。また以前は商用不可の試用版であるMaya PLEや廉価なインディーズゲーム開発者向けのMaya LTも存在した。
★Cinema 4D （MAXON Computer）
モーショングラフィクスに強い3DCGソフトウェア。After Effectsとの連携が優れており、放送業界で良く使用されている。After Effects CCに機能制限版のCinema 4D Liteとリアルタイム連携ツールのCinewareが付属している。また、Illustrator CC向けにCineware for Illustratorが無料頒布されている。
3DCGソフトウェア 統合型ソフトウェアの例
3Dサウンドレンダリング、文字アニメーションツール、モーショントラッカーなどを持っている。エフェクトでは、ノードベースのXPressoがある。そこにはルールベースのThinking Particlesも統合されている。
新しいバージョンはサブスクリプションのみとなっている。サブスクリプションにはチュートリアル及びプラグイン集 Cineversity へのアクセス権が付属している。Cineversity はプラグインやスクリプト管理のための CV Toolbox が用意されている。
★Houdini （Side Effects Software←Omnibus Computer Graphics。国内総代理店はインディゾーン)
ノードベースの統合ソフトウェア。高度なパーティクル生成機能、APIC法による流体シミュレーション、砂シミュレーション、有限要素法による破壊シミュレーション、群集シミュレーションなどエフェクトに飛び抜けて強いため、映画やCMのVFXで重用されている。15では、雪及び溶岩のシミュレーション、オブジェクトの融解にも対応した。コンポジットやオーディオフィルタにも対応している。
3DCGソフトウェア 統合型ソフトウェアの例
エディションにはHoudini FX、エフェクトを削ったHoudini、独立プロ向けのHoudini Indieがある。追加ツールセットSideFX Labs (旧Game Development Toolset←Game Development Shelf)も同梱されている。また、外部ソフトウェアでHoudini用アセットを使うためのプラグインとしてHoudini Engineがあり、Maya、3ds Max、Unity、Unreal Engine、Cinema 4D用が存在している (Indie版は制限付きで無料)。
ポリゴンモデリングだけでなく、NURBSによるパッチモデリングにも対応している。3Dペイントには未対応。
★LightWave (LightWave Digital←NewTek←Aegis Software。国内販売はディストーム←エヌジーシー ディ・ストーム ディビジョン←ディストーム)
モデラーとレイアウトが分かれている統合ソフトウェア。Aegis Videoscape及びAegis Modelerの後継。3Dペイント未対応。姉妹ソフトに、モーションリターゲティングとKinectによるモーションキャプチャに対応する「NevronMotion」が存在した。