3D ／ WEBGL EXPERIENCE
VITRINE — 硝子の間
密閉された円形の展示室を、7 章ぶん 1 シーンに積んだまま切り替える没入体験。 章の切り替わりでロードが走らないので、停止が原理的に起きません。 文字だけを被写界深度から外す専用パスを持っています。
- GLB 16 点 ／ Draco 圧縮
- HDRI ＋ 実時間反射
- DPR 上限 1.75 ／ 自動降格
体験を開く
01 ／ STANDARD
守るものが三つ、
それ以外は自由。
表現の方向性はプロジェクトごとに変わります。変わらないのは、この三つだけです。 すべて「見た目の好み」ではなく、破ると体験が壊れるという理由で決めています。
-
01
プロシージャル形状の禁止
NO PROCEDURAL SHAPES
球と立方体を組み合わせて「車らしきもの」を作らない。 実地検証済みの GLTF と PBR テクスチャだけを使います。 手癖の形状は、拡大された瞬間に必ず嘘だとわかるからです。
-
02
裏画面の 100% 遮断
ZERO BREAKAWAY
カメラが壁を抜ける瞬間の空洞、章の切り替わりの空白フレーム、 ロード失敗時の無言の黒画面。どれもユーザーには「バグ」に見えます。 壁は穴を開けた実形状として作り、遷移演出はどの章にも属させません。
-
03
実時間の光と反射
REAL-TIME LIGHTING
単色の黒背景に平行光を一灯、で済ませない。 HDRI 環境光と PBR を全要素に強制し、金属は roughness 0.15 / metalness 0.95、 硝子は transmission 0.95 / ior 1.5 と、数値で管理します。
02 ／ WORKS
二本のレーンで作ります。
3D と 2D は、測る項目が根本的に違います。前者はドローコールと VRAM、 後者は LCP と転送量。同じ物差しで語らないことが、どちらも speed で殺さないコツです。
2D ／ HTML ・ CSS
STUDIO — このページ自体
フレームワークなし、外部ホスト 0、ラスター画像 0 枚。 和文は約物サブセットを font-family の先頭に置き、行間 1.8・ トラッキング 0.02em で組んでいます。
- 依存ライブラリ 0
- ブレークポイント 3 個固定
- prefers-reduced-motion 対応
RESEARCH ／ FIELD NOTES
実サイト解析ノート
他社の実サイトを DOM・CSSOM・ネットワークまで降りて解析し、 1 テーマ 1 ファイルで記録しています。良い実装だけでなく、 測れなかったことも正直に書き残すのが方針です。
- 3D レーン ／ 2D レーン
- 数値は実測のみ
- 推測は推測と明記
03 ／ NUMBERS
感想ではなく、数値で。
「速い」「重い」は担当者ごとに違う言葉です。合意できるのは数値だけなので、 着手前に必ずこの表を握ってから作り始めます。
0倍
和文の行間
欧文基準の 1.5 では和文は詰まって見える。1.7〜1.8 が実測での基準値。
0fps
3D の下限フレーム
下回った端末は DPR とポストを自動で落として維持する。固定値では組まない。
0ホスト
サードパーティ
解析タグは体験を落とす最大要因。必要なら 1 コンテナに統合してから載せる。
0個
ブレークポイント
増やすほど破綻する。640 / 960 / 1280 の 3 個に固定し、間は流体で埋める。
初回 43.7MB・VRAM 302MB という構成でも、 待ち時間を隠す仕掛けとセットなら成立する。 逆に言えば、隠す仕掛けの無い「全部先に積む」設計は破綻する。
04 ／ PROCESS
五段階。
最初の二つが本体です。
制作より前に、素材と限界値を決めます。ここを飛ばすと、 出来上がったあとに「重いから削る」という一番つらい引き算が始まります。
-
STEP 01
限界値の合意
目標端末、転送量の上限、VRAM の上限、下限フレームレート。 4 つの数字を先に決めます。表現の議論はその内側でだけ行います。
-
STEP 02
素材の確保と検証
GLTF・HDRI・PBR テクスチャをライセンスごと確保し、圧縮して実機で開く。 「動くはず」の素材は使いません。開いたものだけが素材です。
-
STEP 03
動線と遷移の設計
カメラが通る場所、章が入れ替わる瞬間、失敗した時に何を出すか。 空白が出るポイントを先に列挙し、そこに演出を割り当てます。
-
STEP 04
実装と実測
ドローコール、テクスチャ VRAM、LCP、CLS。 週次で同じ項目を測り、悪化した週に必ず原因を特定します。
-
STEP 05
降格経路の実装
低スペック端末・WebGL 不可・コンテキスト消失。 3 つの経路すべてに、黒画面ではなく「見える結果」を用意して納品します。
05 ／ STACK
引用元を明かします。
使っている素材とライブラリは、出所とライセンスまで含めて開示します。 出所の言えない素材は、納品後に必ず問題になるからです。
| 名称 | 用途 | ライセンス |
|---|---|---|
| glTF-Sample-Assets | PBR 検証済みの標準 3D モデル | 各アセット準拠 |
| Poly Haven | HDRI 環境光 ／ PBR テクスチャ | CC0 |
| AmbientCG | PBR マテリアル | CC0 |
| Draco | メッシュ圧縮のデコード（自ホスト） | Apache-2.0 |
| React Three Fiber | WebGL のレンダリング層 | MIT |
| YakuHanJP ／ YakuHanMP | 約物だけを詰める和文サブセット | MIT |
| Noto Sans JP ／ Zen Old Mincho | 本文 ／ 見出しの和文書体（使用文字だけに削って自ホスト） | OFL 1.1 |
NOTE 外部 CDN の直リンクは、実績のあるホストでも体験の単一障害点になります。 落ちた時に巻き添えで落ちるのは、こちらの体験の方です。だから全て自ホストにしています。
06 ／ FAQ
よく聞かれること。
3D は重いのでは？ スマートフォンで見られますか。
見られる設計にします。具体的には DPR に上限と下限を設け、 フレームレートが落ちた端末では解像度とポストエフェクトを自動で落とします。 そのうえで WebGL が使えない環境には、静止画とテキストの代替画面を出します。 「重いから諦める」ではなく「降格して必ず何かを見せる」が基本方針です。
制作期間と体制はどれくらいですか。
規模によりますが、3D 体験は素材確保に想像の倍かかると考えてください。 モデルとテクスチャが揃っていれば実装は進みますが、 揃っていない状態で始めると、実装が素材待ちで止まります。 最初の二週間を素材と限界値の確定に充てる進め方を推奨しています。
既存サイトの改善だけの依頼もできますか。
できます。多くの場合、最初に効くのはコンテンツではなく計測タグの整理と フォントの読み込み方です。実サイトの解析では、本体 453KB のページが サードパーティ 40 ホストを抱えている例もありました。 まず現状を実測し、削る順番を数値で決めます。
和文のデザインで、まず何を直すべきですか。
約物（、。「」）の余白です。約物サブセットを font-family の先頭に 一行足すだけで、和文の見た目は一段変わります。 次に行間を 1.8 に、本文の色を純黒からわずかに温かい黒に。 この 3 つは、費用対効果が突出しています。
納品後、自分たちで更新できますか。
2D サイトはトークン（色・サイズ・余白の変数）を CSS の先頭に集約して 納品するので、値の変更だけなら 1 ファイルで完結します。 3D 体験は章の構成・カメラ経路・文言を 1 つの設定ファイルに集約します。 更新が難しいのは仕組みの問題であって、依頼側の問題ではありません。
07 ／ CONTACT
まず、限界値の話から。
「かっこいい 3D が欲しい」より、「どの端末で、何秒で、何を見せたいか」から 始める方が早く着地します。決まっていなくても構いません。一緒に決めます。
- 対応端末と目標フレームレート
- 公開予定日と、動かせない日付
- 既に持っている素材（モデル・写真・ブランド規定）