stanford-oval/wikipedia huggingface dataset:
樋口高顕
経歴

警察官僚でのちに警視総監を務めた樋口建史の長男として長野市で生まれる。祖父は群馬銀行元常務取締役の内田啓利。なお、名前である高顕の「高」は祖父母の故郷である群馬県高崎市にちなむ。
幼少期は、父親の仕事の関係で長野、東京、徳島、ロンドンなどを転々とした。東京都の巣鴨中学校・高等学校を経て京都大学法学部卒業。大学では大嶽秀夫教授の政治過程論ゼミに参加した。また、在学中に当時兵庫6区選出の衆議院議員だった小池百合子の地元事務所（兵庫県伊丹市）で4年間インターンを経験した。
京大卒業後は、品川にある電通国際情報サービスに7年間営業職として勤務した。公や社会に貢献したいという気持ちが強くなり2014年に退職し、台湾大学大学院へ3年間留学。両岸関係、中国政治経済、台湾地方政治、アジア主義などの研究を行った。
2017年東京都議会議員選挙に千代田区選挙区より都民ファーストの会公認で出馬。自由民主党の中村彩ら3候補を破り初当選。
2021年1月13日、任期満了に伴う千代田区長選挙への出馬を表明。1月31日の投開票の結果、元千代田区議会議員の早尾恭一ら3候補を破り初当選した。
※当日有権者数：52,525人 最終投票率：45.30%（前回比：-8.37pts）
| 候補者名 | 年齢 | 所属党派 | 新旧別 | 得票数 | 得票率 | 推薦・支持 |
| --- | --- | --- | --- | --- | --- | --- |
| 樋口高顕 | 38 | 無所属 | 新 | 9,534票 | 41.03% | （推薦）都民ファーストの会・（支持）国民民主党 |
| 早尾恭一 | 59 | 無所属 | 新 | 7,668票 | 33.00% | （推薦）自由民主党・公明党 |
| 五十嵐朝青 | 45 | 無所属 | 新 | 5,598票 | 24.09% | （推薦）日本維新の会・（自主支援）日本共産党 |
| 宮田朋輝 | 26 | 無所属 | 新 | 435票 | 1.87% |  |
2024年12月24日、翌年2月に行われる千代田区長選挙に2期目を目指し立候補する意向を表明した。選挙期間中、都民ファーストの会、公明党、国民民主党に加え、候補擁立を断念した自由民主党も支援に回った。2月2日の投開票の結果、新人4候補を破り2選。
※当日有権者数：53,619人 最終投票率：39.11%（前回比： 6.19pts）
| 候補者名 | 年齢 | 所属党派 | 新旧別 | 得票数 | 得票率 | 推薦・支持 |
| --- | --- | --- | --- | --- | --- | --- |
| 樋口高顕 | 42 | 無所属 | 現 | 10,703票 | 52.50% | （自主支援）都民ファーストの会、国民民主党、自由民主党、公明党 |
| さとうさおり | 35 | 無所属 | 新 | 6,474票 | 31.75% |  |
| 浜森香織 | 46 | 無所属 | 新 | 2,991票 | 14.67% |  |
| 新藤伸夫 | 75 | お金をみんなへシン独立党 | 新 | 157票 | 0.77% |  |
| 黒川敦彦 | 46 | 政治団体Q | 新 | 63票 | 0.31% |  |
親族

父・樋口建史
愛媛県出身の警察官僚。警察庁生活安全局長、警視総監、在ミャンマー大使を務めた。
祖父・内田啓利
群馬銀行元常務取締役。群馬ビジネスサービス元社長。藤田エンジニアリング元監査役。母・利恵子の父。
三股町立勝岡小学校

| 三股町立勝岡小学校 |
| --- | --- |
 ja北緯31度45分11.9秒 東経131度07分14.6秒﻿ / ﻿北緯31.753306度 東経131.120722度﻿ / 31.753306; 131.120722座標: 北緯31度45分11.9秒 東経131度07分14.6秒﻿ / ﻿北緯31.753306度 東経131.120722度﻿ / 31.753306; 131.120722
過去の名称:  尋常勝岡小学校 勝岡尋常小学校 （尋常科4年） 勝岡尋常高等小学校 （尋常科4年・高等科2年） 勝岡尋常小学校 （尋常科6年） 三股尋常高等小学校 勝岡分教場 勝岡尋常小学校 (尋常科6年) 三股村勝岡国民学校 三股村立勝岡小学校
国公私立の別:  公立学校
設置者:  三股町
併合学校:  簡易前目小学校 簡易餅原小学校 簡易蓼池小学校
設立年月日:  【3校統合】 1899年（明治22年）10月14日
共学・別学:  男女共学
所在地:  〒889-1913
 宮崎県北諸県郡三股町大字餅原973番地
外部リンク:  公式サイト
 ウィキポータル 教育  ウィキプロジェクト 学校
テンプレートを表示
三股町立勝岡小学校（みまたちょうりつ かつおかしょうがっこう）は、宮崎県北諸県郡三股町大字餅原（もちばる）にある公立の小学校。
沿革

明治初期 - 勝岡小学校・餅原小学校（もちばる）・蓼池小学校（たでいけ）が創立。
時期不詳（明治初期） - 勝岡小学校は前目に移転し、「前目小学校」と改称。
時期不詳（明治初期）- 上記の3校が統合により、それぞれ三股小学校の支校（分校）となる。
1881年（明治14年）- 3支校（分校）がそれぞれ「前目小学校」・「餅原小学校」・「蓼池小学校」として独立。
1886年（明治19年）頃 - 小学校令施行により、簡易科（3年制）を設置の上、「簡易前目小学校」・「簡易餅原小学校」・「簡易蓼池小学校」に改称。
1889年（明治22年）
5月1日 -  北諸県郡5村（宮、樺山、長田、餅原、蓼池）が合併の上、「三股村」が発足。
10月14日 - 上記の簡易小学校3校を統合の上、「尋常勝岡小学校」（4年制）とする。餅原字南原973番地を校地とする。
10月31日 - 尋常勝岡小学校の設置が正式に認可される。
1892年（明治25年）4月1日 - 「勝岡尋常小学校」に改称。
1893年（明治26年）1月 - 校舎を増築。
1901年（明治34年）
4月 - 初代校長に長友林蔵が就任。
5月 - 校地を拡張。
1906年（明治39年）4月 - 毎月、全児童からたまご1個を集め、基本金の造成の制を定める。
1907年（明治40年）4月 - 旧校舎を廃止し、木造新校舎が完成。高等科（2年制）を併置の上、「勝岡尋常高等小学校」（尋常科4年・高等科2年）に改称。
1908年（明治41年）
4月1日 - 改正小学校令により、尋常科（義務教育年限）が4年制から6年制に改められる。これにより、旧高等科1年を尋常科5年、旧高等科2年を尋常科6年に改める。これにより高等科が廃止され、「勝岡尋常小学校」（尋常科6年・高等科なし）に改称。
12月21日 - 統合により、「三股尋常高等小学校 勝岡分教場」となる。分教場は尋常科のみ設置（6年制）。
1911年（明治44年）6月6日 - 「勝岡尋常小学校」（6年制）として独立。
1912年（大正元年）10月 - 校舎を増築。
1924年（大正13年）2月 - 校地を拡張。
1926年（大正15年）- 南校舎を増改築。勝岡青年訓練所が併置される。
1928年（昭和4年）10月 - 教育後援会を設立。
1934年（昭和9年）12月 - 奉安殿が完成。
1935年（昭和10年）- 青年学校令施行により、三股青年学校が併置される。
1936年（昭和11年）10月 - 運動場を拡張。
1937年（昭和12年）10月 - 校門を設置。
1940年（昭和15年）10月 - 児童図書館を設置。
1941年（昭和16年）4月1日 - 国民学校令施行により、「三股村勝岡国民学校」（初等科6年・高等科なし）と改称。尋常科を初等科に改める。
1945年（昭和20年）9月 - 台風により、校舎が倒壊。
1947年（昭和22年）4月1日 - 学制改革により、国民学校初等科は新制小学校「三股村立勝岡小学校」に改組・改称。
1948年（昭和23年）
1月 - 新校舎が完成（復旧）。
5月2日 - 町制施行により、「三股町立勝岡小学校」（現校名）に改称。父母と先生の会が発足。
1957年（昭和32年）10月 - 全校舎を改築。
1961年（昭和36年）12月 - 給食を開始。
1968年（昭和43年）
3月 - 体育館が完成。
8月 - プールが完成。
1981年（昭和56年）2月 - 鉄筋コンクリート造新校舎が完成。
1988年（昭和63年）
4月 - 新プールが完成。
10月20日 - 創立100周年記念事業を実施。
2010年（平成22年）2月 - 新体育館が完成。
2018年（平成30年）1月 - プレハブ校舎（2教室）を増築。
交通

JR九州 日豊本線 「餅原駅」
三股コミュニティバス（くいまーる） 「勝岡小学校入口」停留所
宮崎県道12号都城東環状線
国道269号 「蓼池」交差点
周辺

旭ヶ丘公園・旭ヶ丘運動公園（陸上競技場・野球場）
殿岡生活改善センター
勝岡城跡
ロータス園勝岡
参考資料

「三股町史」（1961年（昭和36年）6月8日, 三股町役場）p.332～p.335
3DCGソフトウェア

3DCGソフトウェアは、3次元コンピュータグラフィックス (3DCG) を制作するためのソフトウェアである。
3DCGは主に
プリプロダクション（ストーリー/コンセプトアート/コンセプトモデリング/ストーリーボード/プレビズ/R&D）
映像素材作成（撮影/LiDARスキャン/フィルムスキャン/3Dトラッキング）
3Dスキャン/テクスチャスキャン (3D再構築/テクスチャ抽出/ライティング除去）
アセット制作（モデリング/UV展開/テクスチャリング/Surfacing/シェーダー作成/シェーダー割り当て/リギング/キャラクターセットアップ）
アセット配置（レイアウト）
動作付け（アニメーション/キャラクターFX/群集/エフェクト）
ポストアニメーション（ショットスカルプト）
画像化（ライティング/レンダリング）
映像素材の下処理（フィルムクリーンアップ/ワイヤーリムーバブル/ステレオフッテージ修正/ロトスコープ）
画像合成及び調整（ペイントフィックス/コンポジット/マットペインティング/ポストエフェクト/カラーグレーディング）
2D-3D変換、ポストプロダクション（コンフォーム/フィニッシング/エンコード/オーサリング）
の工程に分かれている。作業の基幹となり多くの工程の調整が行える統合型ソフトウェアの他に、個別の機能に特化したソフトウェアも存在する。モデリングが中心となっているソフトウェアは「モデラー」、レンダリングが中心となっているソフトウェアは「レンダラー」と呼ぶ。
各種工程における機能においては、破壊的なものと、非破壊的なものが存在する。非破壊的なものは過去の操作の修正がしやすく、パラメータにキーフレームやドリブンキー/IPOドライバを入れることでアニメーションさせることもできる。しかし、メモリやディスク容量を消費するため、メモリサイズの大きなものを扱ったり細かな編集を繰り返したりといったことは苦手である。互換性の問題もあるため、他のソフトウェアとのやりとりには破壊的な形式に直すことも多かったが、最近は非破壊的な交換形式というものが開発されてきている。
3次元CADソフトウェアについては「CAD」、3次元GISソフトウェアについては「地理情報システム」を、仮想地球儀については「仮想地球」を、3次元プラネタリウムソフトウェアについては「プラネタリウムソフトウェア（英語版）」を参照。
概要

3DCGが発案された当初は一部の用途にのみ用いられる技術であり、多くの処理能力に高価な高性能ワークステーションや専用のハードウェアが必要となることが多いために市場も小さく、ソフトウェアも高価であった。しかし、時代が進むにつれてコンピュータの性能が向上し、高性能なコンピュータが一般に普及することにより、3DCGの市場が拡大してソフトウェアの低価格化・高機能化が進んだ。
3DCGソフトウェアは、科学からエンターテイメント、純粋芸術までさまざまな用途に使われており、用途によって必要な機能、必要な品質、環境、納期などが異なるため、それに合わせて多くの種類が存在する。必要なレベルに達しているソフトウェアのことを「Production Ready」であると表現する。1つの用途を達成するために複数のソフトウェアが必要になることもあり、その場合にソフトウェア同士の連携が重要となる。
3DCGソフトウェアの主な用途としては、以下のものがある。
実写合成映像 (VFX)
映画
CM・企業VP
ドラマ
ミュージック・ビデオ
3Dアニメーション
映画
CM
アニメ
ミュージック・ビデオ
ゲームのムービーシーン
パチンコ・パチスロ機のCG
3Dモーショングラフィックス（#モーショングラフィクス）
CM・企業VP
キネティック・タイポグラフィ
タイトルCG
テレビ番組のオープニングCG/ジングルCG
3Dアニメーションロゴ
リアルタイム実写合成
テレビ番組のバーチャルセット（#バーチャルセット）
拡張現実 (AR)（#インタラクティブVR/拡張現実 (AR)/複合現実 (MR)）
ビジュアライゼーション/ビジュアルコミュニケーション
製品ビジュアライゼーション
テクニカルイラストレーション
建築パース/ウォークスルー（#ビジュアライゼーション向け）
エクステリア
インテリア
映像撮影のプレビジュアライゼーション
演劇舞台のデザイン
科学可視化（英語版）
地理情報システム
ニュース番組の再現CG/解説CG
ドーム映像（#ドーム動画作成）
プラネタリウム
インタラクティブコンテンツ（#ゲーム及びインタラクティブコンテンツ作成）
ゲーム
バーチャルリアリティ (VR) - VR動画（#VR動画）およびインタラクティブVR（#インタラクティブVR/拡張現実 (AR)/複合現実 (MR)）
博物館の展示物
仮想遊園地・仮想水族館
フライト/鉄道/ドライビングシミュレータ
手術シミュレータ
防災シミュレータ
バーチャルリアリティ療法（英語版）
3D仮想観光（英語版）
インタラクティブウォークスルー
インタラクティブ3Dコミュニケーション
Web3D
出版物 (DTP)
商業ポスター
挿絵CG
漫画の背景CG
純粋芸術
アブストラクトアート/フラクタルアート（#アブストラクト）
デスクトップ壁紙/スクリーンセーバー
3D印刷
シェーダーアート
CG画集
キャラクター/バーチャルアイドル
写真集
ダンスCG
デジタルフィギュア
3D印刷によるフィギュア作成（#3Dプリンタ出力）
その他
ゲームのMOD
コンセプトデザイン
犯罪捜査
CGによる囮捜査
法廷アニメーション（#法廷アニメーション向け）
3Dエフェクト
3Dトランジション
歴史

→詳細は「3DCGソフトウェアの歴史」を参照
ソフトウェア毎の差異 > OS及びプラットフォーム

歴史的経緯により、建築業界や機械業界では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

ソフトウェアによってUIやショートカットは異なるが、共通点も多い。
| 画面 | 用途 | 操作 | 備考 |
| --- | --- | --- | --- |
| ツリービュー リストビュー | アウトライナ、アセット管理、ファイル表示 |  |  |
| 2Dビュー | レンダリング表示、画像編集、2Dペイント、UV編集、マスク編集、リグ選択、フリップブック |  |  |
| 2.5Dビュー | 2.5Dペイント |  |  |
| 3Dビュー | オブジェクト編集、スカルプト、3Dペイント、リギング、スキニング、オブジェクト配置、アニメーション付け、シミュレーション表示 |  |  |
| ドープシート | アニメーション編集、コンポジット | タイミング調整 |  |
| グラフエディタ (カーブエディタ) | アニメーション編集、コンポジット | 補完設定 |  |
| シーケンサー | ノンリニアアニメーション、カメラシーケンサ、ノンリニア動画編集 | トラック複製、オーバーラップ制御 |  |
| スタックリスト ノードエディタ | ヒストリ保存、非破壊編集、コンストレイント、ソルバー制御、コンポジット、ゲームロジック | 上流の編集、グループ化による再利用、焼き付け・フリーズによる軽量化 |  |
| スプレッドシート | データインスペクタ、データ編集 |  |  |
| テキストエディタ | スクリプト編集、シェーダー編集 |  |  |
| ブラウザ | ヘルプ閲覧、イントラネット閲覧 |  | Softimage Netview、Maya 8.0以前、Cinema 4D、Houdini 14以降、Modo 901以降などが組み込みブラウザを持っている。 |

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度回転する必要があり、右手系と左手系を変換をするには負のスケールを使って一軸を反転する必要がある。
| 座標系 (前方) | グラフィクスAPIの既定値 | 3DオーディオAPIの既定値 | 統合ソフトウェアの既定値 | 統合ソフトウェアの代替値 | コンポジット | ゲームエンジン | 備考 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 右手系Z‑up (Y Forward) |  |  | 3ds Max, Carrara,  Blender | Maya, Houdini, modo |  | CryEngine | 工業/工学で良く使われている |
| 右手系Y‑up (‑Z Forward) | OpenGL, WebGL,  Java 3D, XNA,  WPF 3D | OpenAL, Oculus Audio SDK | Maya, Softimage,  Houdini, Shade, modo |  | Nuke | OGRE |  |
| 左手系Z‑up (‑Y Forward) |  |  |  |  |  | Unreal Engine |  |
| 左手系Y‑up (Z Forward) | Direct3D, Stage3D,  Renderman | DirectSound3D, XAudio2 | LightWave, Cinema 4D |  | After Effects | Unity, Irrlicht Engine | ゲーム業界で良く使われている |

また、ボーンの座標系(ボーンの長さ軸/主軸(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以降など)。
ソフトウェア毎の差異 > 頂点順序

レンダリング高速化のための背面カリングにおいて、ポリゴンの表面は頂点順序によって決定されるが、ソフトウェアによって表面の指定が右回りと左回りで異なる。また、ファイル形式においても、法線方向が頂点順序によって決定されるものが多い。そのため、この方向の違いによって、モデルのやりとりで法線の反転する問題が発生する場合がある。
| 表面の方向 (カリングの方向) | API | 統合ソフトウェア | ゲームエンジン | 備考 |
| --- | --- | --- | --- | --- |
| 右回り (左回り) | DirectX (標準), OpenGL (GL_CW) |  |  |  |
| 左回り (右回り) | OpenGL (標準), DirectX (D3DCULL_CW) |  |  |  |
ソフトウェア毎の差異 > 長さの単位

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に使われるオブジェクトには幾つかの種類がある。ソフトウェアは通常、複数の種類に対応している。
| タイプ名 | 主な用途 | 備考 |
| --- | --- | --- |
| Empty/ Null/ Locator/ Dummy | 座標や座標系の定義 |  |
| ポイントクラウド | 3Dスキャン、 トラッキング、 エフェクト |  |
| パーティクル | エフェクト | パーティクルは、ポイントクラウドと異なり法線や大きさなどを保持している。 |
| ボクセル / ボリューム | 流体シミュレーション、 スカルプト |  |
| ポリゴン |  | ソフトウェアやファイル形式によって、四角ポリゴン、非平面ポリゴン、多角ポリゴン、穴空きポリゴン(ドーナツポリゴン)、凹型フェース、ぶら下がりエッジ(dangling edges)、ぶら下がりフェース、浮き頂点、浮きエッジ、浮きフェース、独立頂点、独立エッジ、独立フェース、自己交差、Tシェープ、ボウタイシェープ、ラミナフェースなどのオーバーラップしたフェース、法線反転フェース (非連続法線)、退縮エッジ (長さ0のエッジ)、退縮フェース (面積0のフェース)などの対応具合に差異がある。 三角ポリゴンのみのポリゴンオブジェクトはゲームやレンダラーに使われており、3ds Maxではオブジェクトの種類として三角ポリゴンのみの編集可能メッシュを持っている。 |
| 曲線 | アニメーションの軌道、 オブジェクトの変形 | 曲線には2次ベジェ曲線、3次ベジェ曲線、B-スプライン、カーディナルスプライン、エルミートスプライン、TCBスプライン(Kochanek–Bartelsスプライン曲線)、秋間スプライン、NURBSなどが存在し、ソフトウェアによって対応具合が異なる。曲線の直接レンダリングに対応するレンダラーが存在する。 |
| 曲面パッチ |  | 同上。 |
| ボーン | キャラクタアニメーション |  |
| メタボール | エフェクト | ソフトウェアによって対応形状や使用する核関数などが異なる。例えば、StoneyDesignerはメッシュメタボールに対応していた。Rendermanでは独自の核関数が使われている。 |
| テキスト | 立体ロゴ、 キネティック・タイポグラフィ | ソフトウェアによってカーニングやアニメーションの扱いなどに差がある。例えばCinema 4DはMoTextというテキストアニメーション用の機能を持っており、R15でカーニングが強化されている。3ds Maxも2016 Extension 1でカーニングなどを強化した。 |
| カメラ | カメラワーク | ステレオカメラや魚眼レンズに未対応のレンダラーなどがある。 |
| ライト | ライティング | ポイントライト (点光源)、スポットライト (円錐光源)、シリンダーライト/ネオンライト (円筒光源)、スフィリカルライト/球形ライト (球形光源)、エリアライト/ライトボックス (面光源)、クラッドライト (四角光源)、ディスクライト (円盤光源)、メッシュライト (メッシュ光源)、スカイライト/アンビエントライト/ドームライト/Hemiランプ (天空光源)、サンライト/ディレクショナルライト/ディスタントライト/インフィニットライト (平行光源/無限遠光源)、レーザーなどがある。レンダラーにより対応具合は異なる。 |
| スピーカー/ Ambient Sound Actor | 音響効果 | 主にゲームエンジンで使われているが、他にも音声レンダリングに対応しているソフトウェアが存在する(Blenderなど)。 |
ソフトウェア毎の差異 > 画像形式

画像は内部で浮動小数点として扱うことが多いため、リニアカラースペースの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までにしか対応していなかった)。
ソフトウェア毎の差異 > I/O

多くの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以降など)。
シェーダーを中間コンパイルして中間言語バイナリにすることも行われている。
| API | プログラミング言語 | 中間言語アセンブラ | 中間言語バイナリ |
| --- | --- | --- | --- |
| DirectX (Shader Model 4 / 5) | HLSL言語 (*.hlsl) | Shader Model 4 / 5 アセンブリ | DXBC (*.cso) |
| DirectX (Shader Model 6以降) | HLSL言語 (*.hlsl) | DXIL | DXILバイトコード (*.cso) |
| OpenGL/Vulkan | GLSL言語 (*.vert、​*.tesc、​*.tese、​*.geom、​*.frag、​*.comp、​*.mesh、​*.task、​*.rgen、​*.rint、​*.rahit、​*.rchit、​*.rmiss、​*.rcall) | SPIR-Vアセンブラ (*.spvasm) | SPIR-Vバイナリ (*.spv) |
| Vulkan 1.2以降 | HLSL言語 (*.hlsl) | SPIR-Vアセンブラ (*.spvasm) | SPIR-Vバイナリ (*.spv) |
| Apple Metal | MSL言語 (*.metal) |  ? | AIR (*.air) |

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/多視点/VR動画ワークフロー > ステレオ3D/多視点

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

VRデバイス向け動画には、一般的な球形ステレオ3D形式と、ライトフィールド形式が存在する。360°の球形ステレオ3D形式は、全方向ステレオ (ODS)とも呼ばれる。球形ステレオ3Dの3DCGを作る場合、球形ステレオ3Dワークフローに対応するソフトウェアを使うことが望ましい。以前はワークフローで多くの問題が指摘されていたものの、その後、球形ステレオ3Dに対応するソフトウェアが増えていっており、解決に向かってきている。360°動画や360°ステレオ3D動画のファイル形式としては、GoogleによるSpatial Media仕様が一般的となっている。かつては、360°動画用としてQuickTimeのQuickTime VR形式も使われていた (3ds MaxのPanorama Exporter Utilityがその出力に対応していた)。360°動画や360°ステレオ3D動画の再生及びオーサリングについては「オーサリングツール#360度動画・VR動画」を参照。
ライトフィールドワークフローに対応するソフトウェアはまだ極少数だが、ライトフィールドへのレンダリングに対応するレンダラーが存在する(OctaneRender 3以降など)。