geniacllm/wiki40b huggingface dataset:
1970年代よりセクトゥール制といわれる地域医療が発達している。この制度はフランス特有の公的精神医療・福祉サービス体制であり、公立病院（81%）への入院、外来、地域医療、福祉のすべて一貫して県の組織で行われ、私立以外はすべて無料である。入院内・外の継続治療、病気の予防や発症の早期発見などが一つの機関で行え、CMP（医学心理センター）、Hopital de jour（昼間病院、デイケア）、Apartment thérapeutique（治療アパート）、CATTP（時間限定治療センター）など備わっているのが特徴。このセクトゥール制に属する病院はフランス全土に950存在し、公的精神病床数は61500床あり、約6600人の精神科医が配置されている。
日本では、2006年の調査で精神科を利用している患者は約320万人おり、その数は年々増加する傾向にある。国立精神・神経医療研究センター長の松本俊彦は「今の診療報酬体系では精神科医が1人の患者に時間をかけて話を聞きにくい。短い診察時間だと患者は医師を信頼せず、薬をもらうだけの関係になりやすい為、過量服薬につながる可能性が高まる。じっくり患者の話に耳を傾けることで患者とのつながりを作れる体制を整える必要がある」と語る。診療所や病院の外来における診療時間は概ね10分から15分程度である。また高齢化に伴いアルツハイマー病などの認知症の患者も増えており、外来・入院あわせての患者数は約38万人で、1996年から2008年の12年間での認知症患者数は3.5倍増加している。しかし介護領域からの推計によると、200万人以上もの認知症患者が存在すると見られ、2030年には350万人に増えると予想される。今後精神科をはじめとした医療機関の負担もさらに増すと見られている。
2006年4月、障害者自立支援法が施行。患者の世帯収入に応じた応益負担による自立支援医療が実施される。通院治療において、この制度を使うと、医療保険を使用した時、医療費全体の原則10%負担となる。なお、患者の世帯収入が少ない場合は負担額の上限が設けられ、月額上限2,500円から20,000円の間となる。また、市区町村によっては、この負担額の上限とは別に独自に補助を行っている地方公共団体もある。この制度を利用する場合、病院の医師やケースワーカーに相談し主治医に診断書を作成してもらい、住民票のある市区町村に診断書と申請書類を提出することが必要である。
口唇ヘルペスに対しては、治癒までの期間、疼痛のある期間、ウイルスが検出されなくなるまでの期間を最短で1日に短縮する。通常、治療しない場合の同期間は2週間程度である。
ペンシクロビルはそのままの形では不活性である。ウイルスに感染した細胞内にはウイルス性チミジンキナーゼが存在し、ペンシクロビルをリン酸化する。このリン酸化過程がペンシクロビルの有効化の律速段階である。ヒト細胞性キナーゼがペンシクロビルリン酸エステルをさらにリン酸化してペンシクロビル三リン酸が生成すると、ウイルスの遺伝子複製過程に混入し、DNAポリメラーゼを阻害してウイルスの複製を妨げる。ペンシクロビルの選択毒性は2つの要素から成る。1つ目は宿主の細胞性チミジンキナーゼによるリン酸化が非常に遅く、非感染細胞内でのペンシクロビルリン酸エステル濃度が感染細胞内の濃度に比べて充分に低い事である。2つ目はペンシクロビル三リン酸のウイルスDNAポリメラーゼへの親和性がヒトDNAポリメラーゼへの親和性に比べて充分に高い事である。これらの結果、ヒト健常細胞への細胞毒性は無視し得るほどに小さい。ペンシクロビルの構造と作用機序はアシクロビル等の他の多くのヌクレオシドアナログと同様である。アシクロビルとペンシクロビルの違いは、三リン酸化体の作用時間の違いである。感染細胞内でのアシクロビル三リン酸の半減期が約1時間であるのに対して、ペンシクロビル三リン酸の半減期は約10〜20時間である。従ってペンシクロビルはアシクロビルよりも充分に大きな等価量を有していると言える。
環 R は右からの積で自然に右加群と考えられる。R が右 R-加群としてアルティン的なとき、右アルティン環と呼ばれる。左アルティン環の定義も同様である。非可換環においてこれらの区別は必要である。片側でアルティン的だがもう片側ではアルティン的でない環が存在する。左右の語は加群において普通必要でない、なぜなら加群 M は通常はじめに左または右 R-加群として与えられるからである。しかしながら、M が左右両方の R-加群としての構造をもつことがあり、そのとき M をアルティン的と呼ぶのは曖昧であるので、どちらの加群としての構造がアルティン的であるのかを明確にする必要が生じる。2つの構造を分離するために、左 R-加群として M がアルティン的であると言うのが正しいときに、用語を濫用して、M を左アルティン的または右アルティン的と言うことができる。左右両側の加群の構造をもつ加群は珍しいことではない。例えば R 自身は左かつ右 R-加群としての構造をもつ。実はこれは両側加群の例であり、別の環 S によってアーベル群 M を左 R 右 S 両側加群にできるかもしれない。実際、任意の右加群 M は自動的に整数環 Z 上の左加群であり、さらに Z-R 両側加群である。例えば、有理数体 Q を自然に Z-Q 両側加群として考えよ。すると Q は左 Z-加群としてはアルティン的でないが、右 Q-加群としてはアルティン的である。アルティン条件は両側加群の構造についても定義できる。アルティン両側加群 とは両側加群であって、その部分両側加群が降鎖条件を満たすようなものである。R-S 両側加群 M の部分両側加群は当然左 R-加群なので、もし M が左 R 加群としてアルティン的であれば、M は自動的にアルティン両側加群になる。しかしながら、両側アルティン加群が左または右アルティン加群でないことは、次の例で示すように、起こり得る。例： 単純環が左アルティン的であることと右アルティン的であることは同値であり、このとき半単純環でもあることはよく知られている。R を右アルティン的でない単純環とすると、左アルティン環でもない。R を自然に R-R-両側加群と考えると、その部分両側加群はちょうど R のイデアルである。R は単純なのでそれは2つしかない。R と零イデアルである。したがって R は両側加群としてアルティン的であるが、左または右 R-加群としてはアルティン的でない。
環の場合と違って、アルティン加群だがネーター加群でないものが存在する。例えば、\mathbb{Q}/\mathbb{Z} の p-primary component、つまり、\mathbb{Z}[1/p] / \mathbb{Z} を考えよ。これは \mathbb{Z}-加群としてp-準巡回群 \mathbb{Z}(p^\infty)と同型である。真増大列 \langle 1/p \rangle \subset \langle 1/p^2 \rangle \subset \langle 1/p^3 \rangle \subset \cdots は無限に続き、\mathbb{Z}(p^\infty) は（従って \mathbb{Q}/\mathbb{Z} も）ネーター的でない。しかしすべての真の（この仮定は一般性を失わない）降鎖列は止まる。そのような列は整数 n_1 , n_2 , n_3,\ldots  に対して \langle 1/n_1 \rangle \supseteq \langle 1/n_2 \rangle \supseteq \langle 1/n_3 \rangle\supseteq  \cdots という形をしている。包含関係 \langle 1/n_{i+1} \rangle \subseteq \langle 1/n_i \rangle によって n_{i+1} は n_i を割り切らなければならないので、n_1 , n_2 , n_3, \ldots は正整数の真の減少列である。それゆえ列は止まり、\mathbb{Z}(p^\infty) はアルティン的である。可換環上の任意の巡回アルティン加群はネーター加群でもあるが、非可換環上の巡回アルティン加群は長さが無限になり得る。このことは Hartley の記事で示されており、Hartley の記憶に捧げてPaul Cohn の記事でうまく要約されている。
エヴァンスの父はクラシック・ピアノの奇才で、エヴァンス自身も中学生になるまではクラシックのクラリネットを学んでいた。サックスを学ぶようになって、最初はソニー・スティットやスタン・ゲッツといったアーティストのライブをシカゴのライブハウス「ショーケイス」で聴いていた。ヒンズデイル中央高校に進学しテナー・サックスをヴィンス・ミッコに師事する。エヴァンスは主にテナー・サックスとソプラノ・サックスを演奏している。ノース・テキサス大学や、ウィリアム・パターソン大学で学び、マイルス・デイヴィスと共演したデイヴ・リーブマンに師事している。1979年にニューヨーク市に移り、数えきれないほど多くの時間をかけてロフトでのスタンダードの演奏に打ち込み、自身の即興スタイルを完成させた。22歳の時、マイルス・デイヴィス・バンドに加入、1980年代初頭のマイルス・デイヴィスの復帰に立ち会っている。マイルスと共演しているよく知られたアルバムに、『ザ・マン・ウィズ・ザ・ホーン』、『ウィ・ウォント・マイルス』、『スター・ピープル』、『デコイ』がある。さらに、ハービー・ハンコック、ジョン・マクラフリン、マイケル・フランクス、ウィリー・ネルソン、ミック・ジャガー、レス・マッキャン、マーク・イーガン、ダン・ゴットリーブ、イアン・アンダーソン、ランディ・ブレッカー、オールマン・ブラザーズ・バンド、メデスキ、マーティン・アンド・ウッドといったアーティスト達と共演、もしくはツアー参加、あるいは録音を行っている。ライブ・アルバム『Petite Blonde』では、ヴィクター・ベイリー、デニス・チェンバース、ミッチ・フォアマン、チャック・ローブらと共演し、前面に出た演奏を聴くことができる。最新作とその前のアルバム、すなわち『ソウル・インサイダー』と『ソウルグラス』は、グラミー賞候補として推薦された。『ソウルグラス』は革新的なブルーグラス／ジャズ・フュージョンのアルバムであり、ベラ・フレック、サム・ブッシュ、ブルース・ホーンズビー、そしてドラマーのヴィニー・カリウタらが参加している。1980年代から1990年代にかけて、エヴァンスはグループ「エレメンツ」のメンバーだった。1984年にはマハヴィシュヌ・オーケストラの再結成にも合流し、1987年の解散まで在籍した。1990年からは、自分自身のバンドを率いて、世界中で年間90回近くコンサートを行うようになった。これまでに17枚のソロ・アルバムを録音し、グラミー賞候補に二度推薦されている。また、2009年にはアルバム『Vans Joint』を録音している。自分のソロ・プロジェクトでは、ブルーグラスの影響を受けたジャズからファンク、コンテンポラリー・グルーヴまで様々な種類の音楽を演奏している。また、エヴァンスはいろいろなグループと交流を持っており、楽器について豊富な知識を持つ人物だと考えられている。「アメリカーナ（フォーク、カントリー、ブルーズ、リズムアンドブルース、ロックンロールなどが融合した音楽）で使われるような、バンジョー、フィドル、マンドリン、スティール・ギターといった楽器を使いたい。こうした楽器を用いて自分の曲を書こうと考えている」と述べている。
『メトロイドプライム4』（Metroid Prime 4）は、アメリカのレトロスタジオが開発し任天堂より発売予定のゲームソフトである。メトロイドプライムシリーズの4作目。
本作は2017年6月のE3で発表された。その時発表されたのは本作のタイトル、ロゴ、対応機種だけだった。その後、任天堂のビル・トリネンは、これまでメトロイドプライムシリーズの開発を担ってきたレトロスタジオ社は本作の開発には関わっておらず、ほかのチームが開発を担当していると発言した。2019年1月、ゲームのクオリティ不足を理由に開発をレトロスタジオへと変更することが発表された。
業界によって使われるOSが異なるため、3DCGソフトウェアはマルチプラットフォームに対応したものが多い。macOSはGPUドライバのOpenGL対応が4.1止まりとなっているうえ、Mojave (10.14) でOpenGLおよびOpenCLが非推奨化されており、macOS版の提供を取りやめるソフトウェアも登場し始めている。一方、Windowsは64論理コアよりも多くのCPUコアを扱うためにソフトウェアの変更が必要となるため、64論理コア以下にしか対応していないソフトウェアが残っている（Mayaや3ds Maxを含む）。歴史的経緯により、建築業界や機械業界ではWindowsの使用が多い（SolidWorksやInventorやAutoCAD、3ds Maxなど）。映像業界ではWindowsだけでなくmacOSもよく使われており、ポストプロダクション会社ではUnix系ワークステーションも使われている（Autodesk Flameなど）。日本のアニメ業界ではWindowsの使用が多く、グラフィックデザイン業界ではmacOSの使用が多い。映画業界ではワークステーションや巨大なレンダーファームを必要としており、スケーラビリティの高いUnix系のOSの使用が多い。かつてはSGI IRIXが、現在はLinuxが主流となっている。Linuxディストリビューションとしては、CentOSとUbuntuの両方がよく使われている。ディストリビューション間の互換性の問題を減らすため、視覚効果協会 (VES) の協力によってVFX Reference Platformが定められている。映画向けのハイエンド・ソフトウェアはLinux版が作られたあと、他のOSに移植される場合が多い（例えば3D-EqualizerやMARI、Autodesk Smokeなど）。ゲーム業界では、プラットフォームによってOpenGL/Vulkan/DirectX/その他の独自APIが使われており、複数APIに対応することも多く、開発ではWindowsの使用が増えている。iPhone用ゲームの開発ではmacOSも使われている。かつては、コンシューマー向けのゲーム開発でUnix系ワークステーションが使われていた時期もあった（スーパーファミコンでのSONY NEWS、NINTENDO64でのSGI IRIX、PlayStation 2でのLinuxなど）。
ソフトウェアによって用語の違いが存在する。アメリカ英語とイギリス英語の違い（ColorとColourなど）をはじめ、訳語の違い（ノーマルと法線、シームと継ぎ目など）や、呼び方が違うもの（カラーランプ〈Rampは傾斜〉とグラデーション、モーフとモーフィングとブレンドシェイプとShape Interpとモーフターゲットとシェイプキー、エクスプレッションとドライバ、ShellとSolidifyとThickness、BMesh(Maya SoUP) とSkin Modifier(Blender) とアーマチャー (Metasequoia)、マグネットとAffect RegionとProportional Editなど）がある。また、同じ用語でもソフトウェアによって意味するものが異なる場合（例えば、3ds MaxのSkin ModifierとBlenderのSkin Modifier、Maya SoUPのBMeshとBlenderのBMesh、BlenderのArmatureとMetasequoiaのアーマチャーなど）がある。
画像の座標は、DirectXやGDIが左上原点、OpenGLやCore Graphicsが左下原点となっているため、3DCGソフトウェア及びそれに関連した2DCGソフトウェアにおいても、画像座標は統一されていない。スクリーン空間の座標も基本的に画像座標と同じものの、DirectX 9以前には半ピクセルオフセットがあったため、古いシェーダーやDirectX 9以前のシステム等で互換問題の起きることがある。また、スクリーン空間のZ座標は、手前から奥にかけて、DirectXならば0.0～1.0に、OpenGLならば-1.0～1.0にマップすることが標準となっている。現在、深度の精度を改善するため、手前から奥にかけて1.0～0.0にマップするReversed-Zが普及してきている (Unreal Engine 4、Unity 5.5以降、CRYENGINE 3.8.1以降など)。
3DCGにおいては、CADに比べて長さの正確性があまり必要とされてこなかった。しかし、物理演算や物理ベースのレンダリング、実写合成などが普及し、正確な長さの必要な場合が増えている。また、座標が浮動小数点数で表されるため、設定された単位と単位スケールによって表せる範囲や精度が異なり、それがモデリングやシーン配置にも影響を与えうる。そのため、多くのソフトウェアでは長さの単位と単位スケールが設定できるようになっている。3DCGソフトウェアではそれぞれ汎用単位を持っており、Generic Unit (GU)と呼ばれる。独自の名前が付いているGeneric Unitも存在する (XSIのSI unit (SoftImage Unit)、BlenderのBU (Blender Unit)、PoserのPNU (Poser Native Unit)、Unreal EngineのUU (Unreal Units)など)。汎用単位の標準の単位設定はソフトウェアによってバラバラに異なっている。一つの単位と単位スケールだけでは表現できるシーン範囲に限界があるため、オープンワールドのゲームなど広い地形を必要する場合にはタイル化された地形を動的に読み込むという手法が用いられる。
内部計算に単精度を採用するソフトウェア (3ds MaxやBlenderなど)と、倍精度を採用するソフトウェア(CINEMA 4D v12以降など)が存在する。両方に対応するソフトウェアも存在する (UNIGINEなど)。単精度は高速だが、巨大なデータを扱う場合に問題が起きる。演算のアクセラレーションを行うGPUは、ゲーム用に単精度で速いもの(GeForceシリーズ)と、業務用で倍精度が得意なもの(Quadroシリーズ)に分かれている。また、距離の計算においては、高速なsqrt(a*a+b*b)や高速な比較のためのa*a+b*bを使っているか、オーバーフローの起こしにくい低速なhypot(a,b)を使っているかでも、問題の起きる範囲が異なる。Blenderでは、通常-5000.0から5000.0の範囲の値が信用できるとされている。
画像は内部で浮動小数点として扱うことが多いため、リニアカラースペースの32bpc浮動小数階調(float)画像が多く用いられているが、16bpc(half float)が使われる場合もある。フォーマット形式としては、OpenEXR (*.exr)、TIFF、DDS、KTX形式が良く使われている。歴史的経緯によりRadiance HDR (*.hdr)が使われることもあるが、Radiance HDR形式はOpenEXR形式に比べ色の正確性に劣る。また、float画像の非可逆圧縮形式としては、OpenEXRのDWAA/DWABコーデックがある。half-float画像の非可逆圧縮形式ではDirectX及びOpenGL向けのBC6H (BPTC_FLOAT)形式やOpenGL及びDirectX 11.3以降向けのASTC形式も存在する。なお、ASTCは3Dモードも持っており、三次元テクスチャを効率的に圧縮することもできる。ステレオ3D画像や多視点画像では、それらに標準で対応するOpenEXR形式が多く用いられており、その拡張子は一般的な.exrのほか、ステレオ画像で.sxr、多視点画像で.mxrが使われている。また、画像を独立したペアの画像ファイル(例えば*_L.pngと*_R.png)として保存することも行われている。ステレオ3D画像では、フレームパッキングやインタレースやサイドバイサイドやトップアンドボトムなどの3D方式に変換してステレオ3D未対応の画像形式で保存することも行われている。素材には16bpcレギュラー画像(Photoshop PSDなど)やLogカラースペースの10bpc画像(CineonやDPXなど)、デジタルカメラのRAW形式などが使われることもある。テクスチャサイズは時代と共に拡大しており、DirectX 11世代以降、16Kテクスチャ (16384x16384) までが一般的となっているものの、32Kテクスチャ (32768x32768)に対応するソフトウェアも現れている (Mari、Substance Designer 6以降、xNormalなど)。また、仮想テクスチャ(OpenGLではSparse Texture、DX11ではTiled Resources)により、256Kテクスチャ(Graniteなど)や2Mテクスチャ(Amplify Texture2など)に対応することを謳うものも現れている。標準で仮想テクスチャに対応しているゲームエンジンもある (Unity 4.5以降など)。また、マルチタイルテクスチャーのUDIMに対応するソフトウェアも増えている。UDIMに対応するゲームエンジンも登場した (Unreal Engine 4.23以降など)。レギュラー画像では、歴史的経緯により、Truevision TGA (別名Targa。Truevision社のグラフィックボード由来)、SGI (SGIワークステーション由来。16bpc対応)、Maya IFF (Autodesk Maya由来。16bpc対応)、Windows bitmap (BMP)なども使われていた。しかし、最近ではPNG (16bpc対応)のような一般的な形式を使うことも多い。ゲーム用途でのテクスチャは、DDS形式 (Windowsが標準で対応)、KTX形式 (Khronos Groupが制定)、PVR形式 (iOSが標準で対応)、PKM形式 (Androidが標準で対応)などが使われている。画像サイズは、B0サイズ/150dpiの静止画ポスターの場合、6083px*8598pxとなる。駅ナカ広告などでは、複数枚の大判ポスターを連貼りして一枚にすることが行われており、B0サイズ/150dpi/5連貼・2段の場合、12166px*42990pxとなる。一部のソフトウェアでは、大きな画素数に未対応となっている。ベクター画像は、テクスチャとして使う場合、事前にラスター画像化する必要のある場合が多い。しかし、ベクター画像のままテクスチャとして使えるソフトウェアも存在する (modo 901以降など)。
アルファチャンネル付きの画像には通常のストレート(非事前乗算)なものと、アルファをRGBに事前乗算したものとがあり、画像形式によってアルファ値の扱いが異なっている。例えば、PNG形式ではストレートアルファにのみ対応しており、一般的にアルファの事前乗算には対応していない。一方、OpenEXRではアルファの事前乗算が標準となっている。3DCGソフトウェアやコンポジットソフトウェアなどにおいてはレンダリングやコンポジットにアルファオーバーが多用されるため、それを高速化するために事前乗算した画像が良く使われている。事前乗算形式にすると、RGBの情報が不可逆的に失われ、RGBがアルファに依存するようになるが、浮動小数点画像においては逆変換での精度の問題は起こりにくい。
精度や速度やカラースペースの問題もあり、コンポジットの中間形式にはHDR画像の連番が使われることが多い (OpenEXRの連番など)。容量の大きさから、圧縮効率の良いYUV色空間で10ビット～12ビットの色深度を採用した非可逆な中間形式が使われることもある (Apple ProResやAvid DNxHD (VC-3)、GoPro CineForm (VC-5)など)。これらの動画形式は編集の容易さのために、圧縮率の高い予測フレーム(インターフレーム)を使わずに、キーフレーム（イントラフレーム）のみで構成されているものが多い。実写素材においてもキーフレームのみの形式が使われることが多かったが(AVC-Intraなど)、記録媒体の容量や速度が制約となるために、圧縮率の高い予測フレームを使った動画形式が使われることも増えた (AVCHDやXAVCなど)。近年は、再圧縮での劣化の少ないVisually Losslessな中間形式 (ProResやDNxHDなど)で直接撮影できるカメラが増えている。色空間では、効率的にHDRを記録するために、Log系の色空間 (Cineon (*.cin)、Sony S-Log、RedLogFilm、ALEXA LOG-C ProRes、BMDFilm Log、P-10Log、Canon Logなど)で撮影することが増えている。また、大きな記録容量が必要になるものの、RAW形式 (CinemaDNG、ARRIRAW、Sony RAW MXFなど)での撮影も行われている。一部のプロ向けカメラを除いて、多くのカメラではクロマ間引き(YUV 4:2:2やYUV 4:2:0など)が行われているものの、クロマ間引きはクロマキーで抜く場合やカラーコレクションを行う場合などに、ノイズやアーティファクトを発生させる要因となる。同様に、編集時にもクロマ間引きを行わないことが望ましいが、一部の手順はクロマ間引きを行ってしまう (例えば中間コーデックにYUV 4:2:2なApple ProRes 422やGrass Valley HQXを使うなど)。オーサリングでは、メディアによって異なるフォーマットが用いられる。HDテレビ向けにおいては、以前はテープメディア (HDV、HDCAM、HDCAM-SR、HD-D5、DVCPRO HDなど)が主流だったものの下火となっていき、現在は光学ディスクのXDCAM HD (MPEG HDコーデック)や、フラッシュメモリのSRMASTER (MPEG-4 SStPコーデック)、P2-HD (AVC-Intraコーデック)、XDCAM EX (MPEG HDコーデック)などが伸びている。4Kテレビ向けでは、XAVC形式によるハードディスク/SSD納品やネットワーク経由での納品が行われている。コンシューマー向けには、ブルーレイディスクムービー (Full HD解像度まで、Rec.709色空間、8bit、59.94iまで、H.264コーデック)、ブルーレイ3D (Full HD解像度まで、Rec.709色空間、8bit、Full HDで24p/HDで60pまで、H.264 Annex H (MVC)コーデック)、Ultra HD Blu-ray (UHD BD。4K解像度、Rec.709色空間またはRec.2020色空間、SMPTE ST 2084 EOTFまたはDolby PQ EOTF、10bit、60pまで、H.265コーデック)が使われている。デジタル映画向けには、未圧縮のデジタルシネマディストリビューションマスター(DCDM)形式 (4K解像度、XYZ色空間、16bit、TIFF)と、配布のために非可逆圧縮したデジタルシネマパッケージ(DCP)形式 (2K又は4K解像度、XYZ色空間、12bit、JPEG2000コーデック)が使われている。映画のフィルム配信向けには、DPX/ADX形式 (ADX-10又はADX-16色空間、10bit又は16bit、DPX)が使われている。ネット配信では、Netflixが、MPEG­-2のNetflix Profile、Apple ProResのiTunes Profile、SMPTE IMF App 2e+での納品を採用している。3DCGではサブフレームを使った処理が行われているため、ソフトウェアによって異なる総フレーム数制限が存在する。例えば、Blenderでは最大500,000フレームまでしか対応しておらず、60fpsの場合に2時間18秒までの動画しか作ることができない。一方、Maya 2017 Update 2以前では時間を1/6000秒単位の32bit整数で管理していたため、約±50時間まで対応していた。Maya 2017 Update 3以降では時間処理が改善され総フレーム数制限がほぼ無くなったものの、互換性の問題から古い時間制限の使用を推奨している。実験的には120fps以上のハイフレームレート(HFR)動画も作られているが、一部のソフトウェアはHFR動画に未対応となっている (例えばAfter Effects 2017.2より前では99FPSまでにしか対応していなかった)。
多くの3Dソフトウェアは、3Dマウス(6軸コントローラ)に対応している。また、多くのスカルプト・3Dペイントソフトは、タブレットの筆圧感知に対応している。MIDIデバイスに標準で対応しているソフトウェアも存在する (3ds Max、Softimage、MotionBuilder、HoudiniのMIDI In CHOPなど)。
スクリプト言語としてはPythonが良く使われており、多くの3DCGソフトウェアがそれに対応している。Pythonを使うことでスクリプトの再利用性を高めることができ、特にパイプライン構築で重要となる。しかし、Python 2系と3系で互換性が低い。また、APIの標準化などはされておらず、ソフトウェアによってAPIは大きく異なる。ゲームエンジンの開発言語ではC#が良く使われており、WebGL方面ではJavascriptが良く使われている (#ゲーム及びインタラクティブコンテンツ作成の開発言語参照)。グラフィカルUIではQtのPythonバインディングであるPySide (または互換性のあるPyQt) が普及しており、それを提供する3DCGソフトウェアが増えている。Qt未搭載のソフトウェアにおいても、PyQtやPySideを別途インストールすることによって、同じUIを使うことができる。なお、古くから存在するソフトウェアには独自のスクリプト言語を持つものもある。MayaはPerlやTclに似た文法のMELスクリプト(旧Wavefront Sophia)を持っており、3ds MaxはMAXScriptを持っており、HoudiniはC Shellに似た文法のHScriptを持っており、LightWaveはC言語に似た文法のLScriptを持っている。また、Cinema 4DはC++に似た文法のC.O.F.F.E.E.スクリプトを持っていた (R20で廃止)。Rubyを採用したもの (SketchUp等) やAngelScriptを採用したもの (3D-Coat等) も存在する。また、標準規格の拡張をした言語を採用しているソフトウェアや、OSに依存するという欠点があるもののOSのスクリプト機能を採用したソフトウェアも存在する。Rhinocerosは、VBScriptを拡張したRhinoscriptが使われている。Adobe After EffectsにおいてはECMAScriptを拡張したAdobe ExtendScriptが使われている。DAZ Studioでは、ECMASciptを拡張したQtScriptを更に拡張したDAZ Scriptが使われている。Softimageにおいては、Active Scriptingに対応しており、JScriptやVBScriptを使用することができた。
ステレオ3Dの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に対応している。3D印刷向けのモデル形式では、カラー未対応のSTL形式、カラー対応のVRML形式 (*.wrl)、3MF形式などが使われる。また、3DCGソフトウェアでもノンリニア編集のファイル交換に使われるEDL形式やその他の交換形式に対応するものが存在する。BlenderのビデオシーケンサがCMX3600のインポートに、MayaのカメラシーケンサがAAFのインポート及びFCP XML形式のインポート/エクスポートに、Unreal EngineのSequencerがCMX EDL及びFCP XML形式のインポート/エクスポートに対応している。Pixarが中心になって開発しているオープンソースのOpenTimelineIOライブラリは、それら形式の多くに対応している。
最初のマテリアルは完全拡散反射に光沢やフレネル効果や完全鏡面反射を足すものであったが、その後、微細表面 (マイクロファセット) のラフネス (粗さ)を考慮したシェーダーが使われるようになり、その後、誘電体や導体 (金属)などの物性別のシェーダーが現れ、現在はメタルネス (金属さ)が導入されて誘電体と導体の両者に使用可能な物理ベースシェーディング (PBS)に対応するソフトウェアが増えている。PBSシェーダーの普及により、FBX形式やglTF形式などもPBSシェーダーに対応したが、古いソフトウェアでは未対応のままとなっている。また、ソフトウェアによっては高速化のために近似計算を行っているため、ソフトウェア間のやりとりで見た目の変わることがある。なお、PBSシェーダー以外の特殊シェーダー (スキンシェーダーやヘアシェーダー、ボリュームシェーダーなど) は標準が無いため、マテリアルのやりとりで問題となる。そのため、2017年現在LucasfilmとIndustrial Light＆Magicがマテリアルをやりとりするための新規格であるMaterialXを開発している。
ボクセル/ボリューム形式は、流体シミュレーション、3D印刷、医療、一部のモデリングソフトウェア (3D-Coat等)などに使われている。3DCGでは、3Dテクスチャ (DDS形式、KTX形式等) や、オープンソースのOpenVDB形式 (*.vdb) が事実上の標準形式となっている。オープンソースのField3d形式 (*.f3d) に対応するソフトウェアもある。3D印刷では、Shapewayのsvx形式や、NVIDIA及びHPの推進するGVDB形式 (*.vdx)があるものの、2017年現在普及していない。医療ではDICOM形式が使われている。
画像や映像のやりとりでは色空間が重要となる。色空間には、カメラの撮像素子の出力の色空間、圧縮のための色空間、作業のための色空間、保管のための色空間、頒布のための色空間、表示デバイスの表示素子の出力の色空間などが存在する。入出力デバイスによって表現可能な色空間が異なるため、目的によって色空間を使い分ける必要がある。カメラの撮像素子の出力は、固有の色空間を持っており、カメラで撮られたRAW画像やRAW動画は固有の色空間となっている。ガンマは基本的にリニアとなっている。バス幅や帯域幅や保存領域などのサイズの問題から画像や動画の非可逆圧縮が必要となる場合、見た目の劣化が少なく非可逆圧縮に向く色空間への変換が行われている (DPXのLog、ProPhoto RGB、YUV 4:4:4 12bit、YUV 4:2:2 10bitなど)。作業のための色空間では、光の物理的性質を利用した処理とアーティスティックな処理が行われるため、色差が物理的に均一で、かつ色域が人間の見える範囲により近く、かつ人間が扱いやすいRGBの色空間であるACEScgリニア(D60ホワイトポイント)やRec.2020リニア(D65ホワイトポイント)がよく使われている。歴史的経緯から、狭い色域のRec.709リニア(D65ホワイトポイント、NukeやBlenderの標準)が使われることもある。また、法線マッピングやバンプマッピングや透過マップや深度マップやIDマップなどでは、RGBを色ではなく単なる数値として使うため、リニアなカラースペースが使われる。レイトレーシングレンダリングにおいては、RGBだけでなく、スペクトルカラーも使われている (スペクトルレンダリング)。コンポジット作業においては、RGB特有の処理が多用されるため、RGB色空間を使う場合が多い。編集作業では、RGBだけでなく、YUVも使われている。カラーコレクションには、RGBだけでなく、YRGBも使われている (Davinci Resolveなど)。保管のための色空間では、将来に備えてより広い色空間が使われている　(デジタルシネマの保管におけるDCDMの16bit X'Y'Z' ガンマ2.6 5900Kなど)。頒布のための色空間では、出力機器(ブラウン管(CRT)、液晶、有機EL、プロジェクター、プリンター等)の特性と人間の識別(XYZ表色系やバートンランプなど)に適したものが使われる (SDTVにおけるRec.601、HDTVにおけるRec.709、デジタルシネマにおけるDCI-P3、UHDTVにおけるRec.2020、WebにおけるsRGB、プリンタにおけるAdobe RGBなど)。目的とする出力機器では出せない色も出てくるため、作業では出力機器を模した色空間も使われているが、その場合でも作業用ディスプレイの色空間への変換が行われるため、完全に同一にはできない。表示デバイスの表示素子の出力の色空間はそれぞれ固有の色空間を持っており、例えばブラウン管(CRT)のガンマ値は2.2に近く、液晶のガンマはS字カーブを描いており、プロジェクターのガンマは1.5に近かった。これらの差異を吸収するために、表示デバイスのファームウェアは、頒布のための色空間からデバイス固有の色空間への変換を行っているものの、未対応の色空間があったりズレが生じたりと完璧ではないため、OSのカラーマネージメントシステム(WindowsのWindows カラー システム(WCS)、macOSのColorSync、Linuxのcolordなど)がモニターのカラープロファイルを管理して色空間変換の補正を行っている。しかし、OSのカラーマネージメントに対応していないソフトウェアも存在する (Mac版DaVinci Resolveの12.1より前など)。また、一部のモニターは10bit表示に対応しているものの、一部のソフトウェアは8bitへのトーンマッピングを行うなどして、10bit表示に未対応となっている (Mac版DaVinci Resolveの12.1より前など)。ディスプレイ機種固有の色空間を直接出力する仕様も登場している (FreeSync 2など)。かつてPCモニターでは、sRGBが主流であったが、その後、Adobe RGB対応のPCモニターが広まってきている。そのため、Webにおいても、従来sRGBが使われてきたが、現在Webブラウザの多くはICCプロファイルv2に対応しており、様々なカラースペースを使うことが可能となっている。しかし、Adobe RGB色空間での画像出力や、ICCプロファイルv2の埋め込みに対応していない3DCGソフトウェアも存在する。色空間の変換方式はカラーマトリクス、1D-LUT、3D-LUT、曲線当てはめなどが存在し、色空間の変換パラメータの形式には、ICCプロファイルv2/v4、Autodeskのlut、Autodeskの3dl、Autodesk CTF、Adobe SpeedGrade (旧Iridas SpeedGrade)のlookやitxやcube、Cinespaceのcsp、Houdiniのlut、Sony Pictures Imageworksのspi1dやspi3dやspimtx、Pandora Pogleのm3dやmga、ASC CDL、ASC CCC、ACESのCTL、Nukeのvf、DaVinci Resolveのdctlなど多くの形式 (カラー・コレクション#カラープロファイル / LUT形式) が存在している。オープンソースのOpenColorIOは、その多くに対応している。
独自仕様にするとアプリケーション同士の連携が難しくなるため、やりとりに関わる部分においてオープンソースのミドルウェアが増えてきている。主にスタジオ側がミドルウェアをオープンソースとして開発・公開しており、商用ソフトウェアにおいてもそれらのミドルウェアを使った機能が標準で搭載されるようになってきている。2000年1月、Robert McNeel & Associatesは、openNURBS Initiativeを設立し、openNURBS Toolkitをリリースした。openNURBS (*.3dm)は現在、Rhinoceros、MoI 3D、modoなどに使われている。2003年1月、オープンソースのHDRI画像フォーマットであるOpenEXR (*.exr)が、インダストリアル・ライト&マジックによって公開された。2007年11月には、OpenEXRにステレオ3D画像や多視点画像を埋め込むための仕様がWeta Digitalによって公開された。2013年4月には、Deep Data画像に対応した2.0がリリースされた。2014年8月には、DreamWorks Animationにより開発された非可逆圧縮のDWAA/DWABに対応する2.2がリリースされた。2010年1月、Walt Disney Animation StudiosがUV展開不要のテクスチャマッピングシステムのPtex (*.ptx)をオープンソースとして公開した。2010年1月、Sony Pictures ImageworksはGIレンダラ向けプログラマブルシェーディング言語のOpen Shading Language (OSL、*.osl)、ボクセル・データ保存ライブラリのField3d (*.f3d)などを、同年7月にはカラーマネージメントライブラリのOpenColorIO (OCIO)をオープンソースとして公開した。OCIOは各統合ソフト、Nuke 6.3v7以降、Vegas Pro 12以降、V-Ray 3.0以降、Clarisse iFX 2.0以降、Fusion 7以降などで使われている。2012年8月、PixerはRenderMan互換サブディビジョンサーフェスを実装するためのGPU対応ライブラリOpenSubdivをオープンソースとして公開した。2012年8月、DreamWorks Animationは、疎ボリューメトリックデータ形式及びツールのOpenVDB (*.vdb)を公開した。各統合ソフトや各レンダラーの他、Clarisse iFX 2.0以降、emFluid 5以降、RealFlow 7.1.2.0147以降、Phoenix FD 2.2以降、FumeFX 4.0以降、Stoke MX 2.0以降などで使われている。Sony Pictures Imageworksとインダストリアル・ライト&マジックによってVFXのためのシーンファイル共有フォーマットAlembic (*.abc)の開発が進んでいる。各統合ソフトや各コンポジットソフトの他、Clarisse iFX、Unreal Engine 4.13以降、CryEngine、Poser 11以降、RealFlow、thinkingParticles 6.3以降、Vue xStream 2015以降PFTrack 2015以降、V-Ray、RenderMan、Maxwell Render V3以降、OctaneRender、Guerilla Render 1.3以降、KATANA、Esri CityEngine 2016以降など、多くのソフトウェアがAlembicに対応している。
ハードウェアメーカーがハードウェアの需要を起こすためにオープンソースで開発することもある。2005年、Sony Computer Entertainmentの開発者によって開発された物理エンジンのBullet Physicsがオープンソースとして公開された。その後、2009年よりAMDがBullet Physicsの開発を支援している。Bullet Physicsに対応する3DCGソフトウェアは増えており、Blender、LightWave、Maya、Cheetah3D、Cinema 4D、modo、Houdini、Maya付属のMayaBulletプラグイン等が対応している (ソフトウェアによって対応具合は異なる)。2011年7月、Intelが高速なレイトレースカーネルのEmbreeをオープンソースとして公開した。CINEMA 4D R15やStrata Design 3D 8.1以降、V-Ray、LuxRenderなどが搭載している。
テレセントリックレンズは正投影 (オルソ)に似ているものの、ピントが存在する。一部のレンダラーはテレセントリックカメラに対応している (Mitsuba Renderなど)。
パニーニ投影 (Vedutismo投影としても知られる) は絵画に使われている投影法であり、線の歪みを抑えながら広い視野を実現できる。標準で対応するソフトウェアも存在する (Unreal Engine 4、UnityのSRP 6.0.0以降など)。
VRに使われる、全天周動画や360°動画を作成するためのソフトウェア。多くの統合ソフトウェアは既に360°動画の作成に対応している。
ブーリアンに対応する統合ソフトウェアやモデラーは多く、ブーリアン時のフィレットに対応するソフトウェアもある。また、パーツの切り分けに向けた機能が存在するソフトウェアもある (ZBrush、3D-Coat、Blender 2.78以降に付属のCarver MTアドオンなど)。
テクスチャにはいくつかの手法が使われる。従来はUV展開してAOなどのアタリをベイクしてから画像を書いたり、素材画像を元にUV展開することが多かった。しかし、UVの切れ目や歪みの問題などがあり、現在では3Dペイントを使ってオブジェクトに直接テクスチャを書いたり、画像を変形しながら貼り付けたりするのも一般的となってきている。また、解像度を気にしないで3Dペイントができる、Ptexという技術も登場している。近年は物理ベースシェーディング (PBS)の普及により、従来とテクスチャの種類が異なる物理ベースシェーダー用のテクスチャ作成に対応したソフトウェアが増えている。立体的なテクスチャの製作には2.5Dペイントも使われている。また、マットペイントでもテクスチャと同様に描画だけでなく、クローンブラシ(コピースタンプ、スタンプで描画、クローンツール)や修復ブラシ、ワープ変形などを使った写真の変形・加工・合成が使われている。マット絵自体は2D的であるが、被写界深度や視点変更のために深度が必要となるため、レイヤを使ったり、深度をペイントしたり、3Dモデルにカメラプロジェクションしたりといった手法が使われている。マットはテクスチャと異なり、コンポジットソフトウェアで合成されることも多い。カラーマネージメントの普及に伴い、テクスチャには線形空間の浮動小数点画像(HDR画像)を使うことが増えており、2DペイントでもHDR画像やカラーマネージメントに対応しているソフトウェアを使うことが増えている。ペイント以外では、パラメーターからテクスチャを生成するプロシージャルテクスチャというものが使われている。画像をタイル状に繰り返すタイルテクスチャでは、元画像を作るために画像をタイルテクスチャ向けに加工したり、タイルテクスチャ向けの画像を作成するためのソフトウェアがある。また、ノードを使ってテクスチャを非破壊編集できるソフトウェアもある。その他、レンダラーを使ってレンダーパスをテクスチャ化するテクスチャベイク(法線焼き付けやAO焼き付けなど)も使われている。
キャラクター作成に標準対応する3DCGソフトウェアもある (Poser、DAZ Studioなど)。
内部でL-systemを使っているものがある。植物生成向けの機能を持つ統合ソフトウェアや景観作成ソフトウェアもある (MayaのPaint Effects、HoudiniのL-system SOP、Blender内蔵のSaplingアドオン、VueのSolidGrowthなど)。草生成機能を持つレンダラーも存在する (Maxwell Renderなど)。また、草にはヘア・ファー向け機能も使われる。
分岐形成は雷、氷晶、地衣類、サンゴ、植物などのモデリングに使われている。分岐形成のアルゴリズムには、一般的な拡散律速凝集、雷の生成に使われる絶縁破壊モデル (DBM、拡散律速凝集と電界の組み合わせ)、高速なLaplacian Growth、自由なルールが作成可能で植物の生成にも向くL-Systemなどが存在する。L-Systemのルールが標準で使えるソフトウェアも存在する (HoudiniのL-System SOP、Cinema 4DのMoSplineのTurtleなど)。植物生成については#植物・植生生成も参照。
LiDARスキャンしたデータなどを取り込むためのもの。標準でポイントクラウドに対応する統合ソフトウェアもある (3ds Max 2015以降のPoint Cloud Object、Houdiniなど)。他用途のソフトウェアでも、ポイントクラウドの読み込みに対応するソフトウェアが存在する (Houdini 16以降のLIDAR Import SOP、3ds Max、Krakatoa 2.4以降のPRT Loader (PRT形式以外にも対応)、Autodesk ReCap 360など)。大規模な3Dスキャンは、建築方面だけなく、科学捜査や法廷アニメーション、VFXでも行われている。
テクスチャの取り込みには、写真を画像処理で変換する手法、3Dスキャンからテクスチャ抽出する手法、マテリアルスキャナーを使う手法などがある。前者二つについては#マップ生成を参照。マテリアルスキャナーでは、測定したマテリアル (MERL database形式、X-riteのAxF形式、MDLのMBSDF形式、V-RayのVRscans形式など) をそのままレンダリングで使ったり、別のシェーダーにフィッティングすることが行われている (#測定マテリアル参照)。マテリアルスキャナーは市販のものも存在する (X-rite TACなど) が、簡易的なものは自作することもできる。
多くの統合ソフトウェアは、標準でノードベースのシェーダー構築に対応している (MayaのHypershadeやNode EditorやShaderFX (元Lumonix製、HLSL及びGLSL向け)、3ds MaxのSlate Material Editor (旧NodeJoe、元Thinking Apes製)やShaderFX、modoのNodal Shading、HoudiniのSHOP、Blenderのマテリアルノード、Unreal EngineのMaterial Nodes、Unity 2018.1以降のShader Graphなど)。多くのレンダラーもノードによるシェーダー構築が可能となっている。OSLシェーダーのコード編集に対応する統合ソフトウェアやルックデブソフトウェアも存在する (3ds Max 2019以降のOSL Map、BlenderのText Editor、GafferのOSLCode Nodeなど)。多くのゲームエンジンはリアルタイムシェーダーのコード編集に対応している。一部の開発環境にもリアルタイムシェーダー作成補助機能が搭載されている (Graphics Tools for XcodeのOpenGL Shader Builder、Visual Studio/Eclipse用プラグインのNVIDIA NsightのDynamic Shader Editing機能、PowerVR Tools and SDKのPVRShaman/PVRShaderEditorなど)。その中には、ノードベースのシェーダー構築に対応するものも存在する (Visual Studioのシェーダー デザイナーなど)。