2026年7月23日木曜日

GLSLは誕生時からvoid main()を唯一の入口として固定し、C言語に近い統一的な実行モデルを採用した

 シェーダープログラミングにおける「入口関数が一つ存在する」という設計は、一見するとHLSLやGLSLによって突然導入されたように見える。しかし、その思想は1980年代の映画用レンダリング言語まで遡ることができる。RenderMan Shading Languageでは、surfacelightなどのシェーダー自体が一つの実行単位であり、各シェーディング点に対して独立に評価される構造を持っていた。これは現在のフラグメントシェーダーと本質的に同じ「多数のデータに対して同一の処理を適用する」というSIMD的発想である。一方、1990年代末のGPUでは、テクスチャコンバイナやRegister Combinersによって固定回路を組み合わせる方式が主流であり、プログラムというより配線に近いモデルであった。その後、DirectX 8やOpenGL ARB_fragment_programではアセンブリ形式の命令列が導入され、GPUを命令列で制御できるようになったが、この段階ではまだ入口関数という概念は存在せず、ファイル全体が一つのプログラムとして先頭から実行された。転機となったのは2002年前後のCgおよびHLSLであり、GPUプログラムがC言語風の構文を持つ高水準言語へと抽象化されたことで、関数・型・構造体を備えたソフトウェア的な設計が可能となった。HLSLでは入口関数名は任意であり、コンパイル時に指定される。一方、GLSLは誕生時からvoid main()を唯一の入口として固定し、C言語に近い統一的な実行モデルを採用した。したがって、「mainが一つ」という現在のGLSLの様式は、レンダリングアルゴリズムの進化というより、GPUを一般的なプログラミング対象へと昇華する過程で生まれた言語設計上の到達点と位置付けることができる。関連キーワード

  • RenderMan Shading Language (RSL)
  • REYES
  • Texture Combiner
  • Register Combiners
  • NVIDIA Cg
  • HLSL
  • GLSL
  • ARB_fragment_program
  • Pixel Shader
  • Fragment Shader
  • GPU Assembly
  • Shader Model
  • OpenGL 2.0
  • DirectX 9
  • エントリーポイント
  • main() 関数
  • SIMD
  • データ並列処理
  • 高水準シェーディング言語
  • プログラマブルGPU

NESASMとNessembleはいずれも、6502系CPUを用いるファミコン向けプログラムをROMへ変換するアセンブラである

 NESASMとNessembleはいずれも、6502系CPUを用いるファミコン向けプログラムをROMへ変換するアセンブラである。しかし両者の差は、単なる新旧ではなく、開発思想と記述体系の違いにある。NESASMは、.bankによって8KB単位の出力領域を切り替え、.orgでCPUまたはPPU上の配置先を指定する。ギコ猫でもわかるファミコンプログラミングをはじめ、多くの古典的教材はこの構造を前提としており、PRG-ROMとCHR-ROMを物理的なバンクの並びとして意識させる。これに対してNessembleは、.prg.chr.segmentなどによって領域の意味を明示し、Rust、WebAssembly、LSP、メディア取込みといった現代的な開発環境へ接続する。6502の命令、PPUレジスタ、VBlank待機など、ファミコンそのものの原理は変わらないが、ローカルラベル、マクロ、インクルード、ROM配置の構文には互換性がない。したがってNESASMのソースをNessembleへ移す作業は、単なる記号置換ではなく、当時の「ROMを区画へ詰める」感覚を、現在の「意味を持つセグメントとして構成する」感覚へ翻訳する行為といえる。古い教材をNESASMで味わうことは当時の制作工程を追体験することであり、Nessembleで再構成することは、その知識をブラウザ上の実験環境へ蘇らせる試みである。

関連キーワード: NESASM、Nessemble、6502、ファミコン、iNES、PRG-ROM、CHR-ROM、バンク、.org.prg.chr、PPU、VBlank、アセンブラ方言、WebAssembly、JSNES、レトロゲーム開発、ソース移植

2026年7月22日水曜日

レオナルド・ダ・ヴィンチ『絵画論』における空気遠近法

 レオナルド・ダ・ヴィンチ『絵画論』における空気遠近法 ― 視覚科学としての絵画理論

レオナルド・ダ・ヴィンチが遺した『絵画論(Trattato della Pittura)』は、単なる絵画技法書ではなく、人間が世界をどのように知覚するかを探究した視覚科学の記録でもある。なかでも空気遠近法の記述は、遠方の物体が青みを帯び、輪郭が曖昧となり、明暗や色彩の対比が弱まる現象を、観察者と対象物との間に存在する「空気」の働きとして説明した点で画期的であった。これは、建築物や道路の消失点によって空間を構成する線遠近法とは異なり、光、大気、水蒸気、塵などの媒質が視覚へ及ぼす影響を描写へ取り込もうとする試みである。レオナルドは自然観察を繰り返し、山並みや大気の色の変化を実証的に記録し、画家は物体だけでなく、その間に満ちる空気まで描かなければならないと考えた。この発想は17世紀の風景画家クロード・ロラン、さらに19世紀のターナーや印象派へ受け継がれ、光と大気を主題とする風景表現へ発展する。また現代では、大気散乱モデルやボリュームレンダリング、レイマーチングなどコンピュータグラフィックスの理論とも対応関係を見いだすことができ、レオナルドの洞察が五百年以上を経てもなお視覚表現の基盤として生き続けていることを示している。

関連キーワード
レオナルド・ダ・ヴィンチ、絵画論、Trattato della Pittura、空気遠近法、大気遠近法、線遠近法、光学、視覚科学、自然観察、大気散乱、青色散乱、コントラスト、輪郭、風景画、クロード・ロラン、J.M.W.ターナー、印象派、ボリュームレンダリング、レイマーチング、コンピュータグラフィックス

レイトレーシングとレイマーチング

 レイトレーシングとレイマーチングは、いずれも視点から放たれたレイ(光線)を用いて画像を生成する技法であるが、その本質的な違いは「交点を解析的に求めるか」「反復的に探索するか」にある。レイトレーシングは、球や三角形など幾何学的に定義された物体との交差を数式として解き、最初の衝突位置を直接決定する。したがって、ポリゴンモデルを中心とする現代CGや映画制作において、高精度な反射・屈折・影の計算に適している。一方、レイマーチングは、空間上の各点で「物体までの距離」を返す距離関数(SDF)や密度場を評価し、その距離だけレイを前進させながら表面や内部構造を探索する。この反復過程は、未知の形状へ近づいていく探索アルゴリズムとして理解でき、複雑な数式曲面やフラクタル、滑らかな形状合成などを容易に表現できる点に特徴がある。

芸術史的な比喩を用いるなら、レイトレーシングはルネサンス以降の遠近法のように、空間構造を幾何学的に確定する手法に近い。それに対し、ボリュームレイマーチングは、光が空気中を伝播する過程を微小区間ごとに積算するため、空気遠近法との対応が見出せる。遠景ほど青みを帯び、輪郭や明暗差が失われる現象は、大気による散乱・吸収をレイに沿って積分する結果として自然に再現される。したがって、レイマーチングは単なる「遅いレイトレーシング」ではなく、空間を距離場や媒質として捉え直す計算思想であり、映画における雲・煙・炎・霧の表現からShaderToyに代表される数式アートまで、現代コンピュータグラフィックスに新たな造形言語をもたらした技法として位置づけられる。

関連キーワード

  • レイトレーシング(Ray Tracing)
  • レイマーチング(Ray Marching)
  • ボリュームレイマーチング
  • ボリュームレンダリング
  • 符号付き距離関数(SDF)
  • 距離場(Distance Field)
  • レイ・サーフェス交差判定
  • ポリゴンレンダリング
  • BVH(Bounding Volume Hierarchy)
  • フラクタルレンダリング
  • レイ積分
  • 光輸送(Light Transport)
  • 散乱(Scattering)
  • 吸収(Absorption)
  • 空気遠近法
  • 線遠近法
  • 解析的交差判定
  • 距離推定法(Distance Estimation)
  • ShaderToy
  • プロシージャルモデリング 

Physically Based Rendering(PBR) は、映画のためだけに発明されたものではなく、光学や物理学に基づく反射理論をCGへ取り入れる長年の研究成果であり、

 コンピュータグラフィックス(CG)の歴史を振り返ると、その発展は単なる計算能力の向上ではなく、「映画で何を表現したいか」という要求と、「数学・物理・情報科学が提供する理論」との相互作用によって形作られてきたことが分かる。例えば、Perlin Noise は、人工的で均質なCG表現に自然界の揺らぎを与えるために考案され、雲や煙、岩肌、木目といった質感表現を可能にした。Boids は、多数の鳥や魚を一体ずつアニメーションする限界を克服するため、局所的な三つの規則から群れ全体の秩序を創発させる分散アルゴリズムとして提案された。一方、Physically Based Rendering(PBR) は、映画のためだけに発明されたものではなく、光学や物理学に基づく反射理論をCGへ取り入れる長年の研究成果であり、映画制作がその実用化を強力に後押しした技術体系である。また、レイマーチングは、距離関数や体積データを数値的に探索する手法として、科学可視化や医療画像とも共通の基盤を持ち、映画では煙・雲・炎など境界の曖昧な現象の描画に活用された。これらはいずれも「映画のためだけ」に生まれたわけではないが、映画産業は従来の技術では実現困難な映像表現を次々と要求することで、新しい理論やアルゴリズムの実験場となり、その成熟を加速させた。CG史とは、数学が映像へ翻訳される歴史であると同時に、映像表現が新たな数学的発想を刺激してきた歴史でもある。この相互作用こそが、現代のリアルタイムレンダリングやゲームエンジン、VFXに至る技術基盤を築いたのである。

関連キーワード

  • コンピュータグラフィックス(CG)
  • 映画VFX
  • 手続き的生成(Procedural Generation)
  • Perlin Noise
  • 勾配ノイズ
  • Boids
  • 創発(Emergence)
  • 群知能(Swarm Intelligence)
  • Physically Based Rendering(PBR)
  • Cook–Torranceモデル
  • フォン反射モデル
  • レンダリング方程式
  • レイマーチング
  • Sphere Tracing
  • Signed Distance Function(SDF)
  • ボリュームレンダリング
  • モンテカルロ法
  • パストレーシング
  • 光輸送(Light Transport)
  • SIGGRAPH
  • Pixar
  • Industrial Light & Magic(ILM)
  • Ken Perlin
  • Craig Reynolds
  • James Kajiya
  • John C. Hart


2026年7月12日日曜日

WebAssembly 3.0

 公式サイト・公式ドキュメント優先で一覧にします。現在の共通仕様は WebAssembly 3.0 です。

WebAssembly共通仕様

WASI・Component Model

WITは、Component Modelのインターフェースやworldを定義するIDLです。


C / C++

Emscripten

EmscriptenはLLVMを利用し、C/C++をブラウザ、Node.js、Wasmランタイム向けにコンパイルする総合ツールチェーンです。

Clang / LLVM


Rust

wasm-bindgenはRustとJavaScript間の高水準な型変換・関数接続を担当します。


Zig

Zigでは主に次のターゲットを使います。

wasm32-freestanding
wasm32-wasi
wasm64-freestanding
wasm64-wasi

現状、WebAssembly専用の独立した公式入門ページは少なめで、言語リファレンスとターゲット指定を参照する形です。


AssemblyScript

AssemblyScriptはTypeScriptそのものではなく、Wasmを直接ターゲットにしたTypeScript風言語です。


Go

ブラウザ向け:

GOOS=js GOARCH=wasm go build

WASI向け:

GOOS=wasip1 GOARCH=wasm go build

Go 1.24では、WASI向け関数exportなどWasm連携機能が追加されています。

TinyGo

Go標準より小さなWasmを作りたい場合はこちらです。


C# / .NET / Blazor

Blazor WebAssemblyはブラウザ内で.NETランタイムとC#アプリケーションを実行でき、AOTコンパイルにも対応しています。


Kotlin

Kotlin/Wasmには、ブラウザ向けのwasm-jsとWASI向けのターゲットがあります。


Swift

Swift公式には、ブラウザ向けとWASIランタイム向けのWebAssembly SDK手順があります。


Python

Pyodide

PyodideはCPythonとPythonパッケージ群をWasm化し、ブラウザやNode.jsで実行する仕組みです。

CPython本体


Java

TeaVM

TeaVMはJavaバイトコードを入力にして、JavaScriptまたはWebAssemblyへAOTコンパイルします。KotlinやScalaのクラスファイルも入力可能です。

CheerpJ


実行ランタイム

Wasmtime

WasmEdge

Wasmer

WAMR

組み込み機器やマイコンでは重要です。

wasm3

小型インタプリタです。

Wazero

Goだけで実装されたWasmランタイムです。


言語名称正体単体/複合
Rustrustcコンパイラ単体
Rustwasm-bindgenJS相互運用ライブラリ+CLI複合寄り
Rustwasm-packビルド・パッケージ化CLI単体
Rustweb-sysWeb APIバインディング単体
Rustjs-sysJS標準APIバインディング単体
C/C++Emscriptenコンパイラツールチェーン複合
CemccC向けコンパイラドライバー構成要素
C++em++C++向けコンパイラドライバー構成要素
AssemblyScriptAssemblyScript言語・ランタイム・ツール群複合
AssemblyScriptascコンパイラCLI単体
Gojs/wasmブラウザ向けターゲット名称
Gowasip1/wasmWASI向けターゲット名称
Gosyscall/jsJS相互運用パッケージ単体
TinyGoTinyGoGo用別コンパイラツールチェーン複合
TinyGowasmブラウザ向けターゲット名称
TinyGowasip1 / wasip2WASI向けターゲット名称
ZigZig言語・コンパイラ・ビルドツール複合
Zigwasm32-freestandingターゲット指定名称
KotlinKotlin/WasmKotlinのWasmバックエンド構成要素
KotlinwasmJsブラウザ向けGradleターゲット名称
KotlinwasmWasiWASI向けGradleターゲット名称
KotlinCompose MultiplatformUIフレームワーク複合
.NETBlazor WebAssemblyWebアプリフレームワーク複合
.NET.NET WebAssembly runtime.NETランタイム構成要素
.NETInteractive WebAssemblyレンダーモード名称
.NETWebAssembly AOTコンパイル方式名称
PythonPyodidePython/Wasmディストリビューション複合
PythonCPythonPython処理系複合
Rubyruby.wasmCRubyのWasm移植群複合
RubyCRubyRuby処理系複合
SwiftSwift SDKs for WebAssembly公式Wasm SDK複合
SwiftSwift for WebAssembly分野・対応全体の名称名称
SwiftSwiftWasmコミュニティプロジェクト複合
SwiftJavaScriptKitJS相互運用ライブラリ単体

M5Stack / ESP32でWebAssemblyを扱う際によく使われるリポジトリ・公式サイト

 以下は M5Stack / ESP32でWebAssemblyを扱う際によく使われるリポジトリ・公式サイト のリンク集です。


M5Stack向けサンプル

M5Stack Core2 + wasm3 + AssemblyScript

M5Stack Core2でWebAssemblyを実行する代表的なデモです。


M5Stamp C3 + WAMR

RISC-V版(M5Stamp C3)向けです。


旧版 M5Stack wasm3

初期の実験版です。


ランタイム

WAMR (WebAssembly Micro Runtime)

Bytecode Alliance系の軽量ランタイム。


wasm3

ESP32で最も普及している軽量インタプリタです。


M5Stackライブラリ

M5Unified

現在の標準ライブラリです。


M5GFX

高速LCDライブラリ。


旧M5Stackライブラリ

現在は非推奨ですが参考になります。


開発環境

ESP-IDF

ESP32公式SDK


Arduino-ESP32

Arduino環境


PlatformIO

IDEを問わず開発可能です。


Wasmを生成する言語

AssemblyScript

TinyGo

Rust


解説記事

M5StackでAssemblyScript + wasm3を動かした作者本人の記事です。


おすすめ構成(2026年時点)

用途おすすめ
学習・デモwasm3 + AssemblyScript
本格開発WAMR + ESP-IDF
Arduino中心WAMR-ESP32
Goで開発TinyGo
Rustで開発WAMR + Rust