1 of 95

デモシーンへようこそ

4KBで映像作品を作る技術、およびゲーム開発への応用

TokyoDemoFest Organizers:

Seiya Ishibashi / Julien Guertault

2 of 95

はじめに

CEDEC 2016 のセッションの続きになりますが、前回を見ていなくても大丈夫な構成になっています
デモシーンの技術やノウハウをゲーム制作に応用してみよう、というのが今回の趣旨になります
辛口セッションなのでそれなりの前提知識を求めます

最低限 deferred shading がどう機能するか知っているレベル

スライドは公演後公開します

3 of 95

About Us

Tokyo Demo Fest の運営チーム
両者共ゲーム会社勤めだが、今回は TDF として講演

Seiya Ishibashi

(@i_saint)

Julien Guertault

(@Zavie)

4 of 95

Agenda

前回のおさらい
64k intro 制作から学んだこと (Zavie)
ゲーム制作への応用 (i-saint)

5 of 95

前回のおさらい

前回のおさらい
64k intro 制作から学んだこと (Zavie)
ゲーム制作への応用 (i-saint)

Agenda

6 of 95

前回はデモシーンについて浅く広く紹介し、4k intro の作り方について大雑把に解説しました

https://onedrive.live.com/view.aspx?resid=61562C8AE88D716B!4355

今回のセッションはレンダリングに絞った内容になっており、Raymarching に限って前回の内容をおさらいします

前回のおさらい

7 of 95

4k intro = 4KB の exe によるデモ
容量の制限からポリゴンを用いない特殊なレンダリング手法がよく用いられる
それが Distance Function & Raymarching

前回のおさらい

8 of 95

画面全体を覆う 4 角形を 1 枚出す
あとは全てピクセルシェーダでがんばる

Distance Function & Raymarching

9 of 95

モデルは Pixel Shader の中で数式で表現し、それを可視化していく
このモデルの数式が Distance Function、可視化のプロセスが Raymarching と呼ばれる

Distance Function & Raymarching

10 of 95

Distance Function & Raymarching

11 of 95

Distance Function & Raymarching

12 of 95

十分に距離が小さくなったら計算を打ち切る

もしくは上限マーチ回数を超えたら打ち切る
完全に正確な交差点は求まらないが、必要十分

この計算を全てのピクセルに対して行う

Distance Function の複雑さ * マーチ回数に応じて負荷が増大

特徴的なレイの進み方から Sphere Tracing と呼ぶことも

Distance Function & Raymarching

13 of 95

法線を求めることも可能
交差点からx,y,z軸それぞれ前後に少しずらした地点との距離を計算
勾配から法線を推測

Distance Function & Raymarching

14 of 95

法線が求まるのでライティングも可能
Ray→法線の反射方向へ再度レイを飛ばせば反射なども表現可能

Distance Function & Raymarching

15 of 95

ポリゴンでは難しいモデルの合成が簡単に実現できる

Distance Function & Raymarching

16 of 95

Distance Function & Raymarching

フラクタル

17 of 95

Distance Function & Raymarching

18 of 95

64k intro 制作から学んだこと

前回のおさらい
64k intro 制作から学んだこと (Zavie)
ゲーム制作への応用 (i-saint)

Agenda

19 of 95

Professional and hobbyist programmer.��“What do you do on your free time?”

“Same as at work.”

Demoscene: making demos with Ctrl-Alt-Test.

デモシーンについて

20 of 95

Ctrl-Alt-Testと言うグループ

64k intros (=64kBなデモ) を作ります
プログラマー2人
サウンド１人２人
たまに、他の友人も参加

デモシーンについて

21 of 95

64k intro: H - Immersion (2017)

22 of 95

64k intro: H - Immersion (2017)

23 of 95

例・調査船

24 of 95

例・調査船

25 of 95

例・調査船

26 of 95

例・調査船

27 of 95

例・調査船

メッシュ: ~934 バイト

テクスチャ: ~1013 バイト

misc/shared: +20~25% (?)

28 of 95

例・調査船

29 of 95

例・調査船

30 of 95

例・調査船

31 of 95

例・アルテミス神殿

世界の七不思議のひとつに挙げられている

32 of 95

例・アルテミス神殿

33 of 95

例・アルテミス神殿

人間

34 of 95

例・アルテミス神殿

35 of 95

例・アルテミス神殿

石像の

テスト

36 of 95

例・アルテミス神殿

アルテミス神殿のメッシュ: ~1174 バイト

柱のメッシュ: ~817 バイト

塑像のメッシュ: ~1461 バイト

アルテミス神殿のテクスチャ: ~1370 バイト

柱のテクスチャ: ~592 バイト

misc/shared: +20~25% (?)

37 of 95

サイズについて

メッシュ

音楽

テキスチャ

シェーダー

シーン

ベース

共同

38 of 95

Size-codingは楽しい。それに、面白いです。

But not very useful. :-)

So let’s talk about more useful things.

作成について

39 of 95

Ctrl-Alt-Testと言うグループ

64k intros (=64kBなデモ) を作ります

⇒ UE4, Unity, Photoshop, Maya, mp3 :-(

プログラマー2人
サウンド２人

⇒ Very limited manpower :-(

作成について

40 of 95

Reduce iteration time:

Hot reload data!
Hot reload shaders!
Hot reload assets!
Hot reload code! \o/

作成について

41 of 95

Hot reload code:

Parse array at runtime; include at compile time.
Tweakable values.�https://github.com/joeld42/ld48jovoc/blob/master/ld17_island/tweakval.h�https://www.gamedev.net/resources/_/technical/game-programming/tweakable-constants-r2731
Interpreted C.�https://github.com/zsaleeba/picoc
Runtime recompilation.�https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus

作成について

Minute 8

At the end of the slide, launch the MeshPlayground and show the construction of the viaduct.

3mn + 3mn

Note: during that demo I showed how the mesh and texture of the viaduct visible in the animation was made. This showed both the way we create content, and code reloading in action.

There are various ways to reload code.

The simplest way is a quick and dirty parsing: if you have an array of floats for example, reading it with a simple scanf() is simple. So you can use an include at compile time, and scanf() at runtime.

We used a lot tool called Tweakable Values. It’s a similar idea, and allows to change constants at runtime thanks to a macro. Say you have _TV(41) somewhere in your code: replace it with _TV(42) then save, and the value is changed automatically.

We’ve also used a C interpreter (picoc). It’s a bit involved because it needed to write an API, but it was useful. We don’t use it anymore.

Now we’re using Runtime Compiled C++, which detects source file changes, recompiles them, and replaces the runtime functions thanks to DLLs.

42 of 95

Abuse your tools!

デバッグについて

43 of 95

Visual Studio?

Clever syntax highlighting.
XML comments.
Natvis.

デバッグについて

44 of 95

デバッグについて

45 of 95

Have an error message?

Output log to the IDE output.�win32: OutputDebugString()
Include file location.
Format it like a compilation error.

→ Will appear in IDE console; double click will jump to location.

デバッグについて

46 of 95

Have an abstraction?

Graphic API abstraction class?

Write a debug implementation.

→ Insert a debug layer.

デバッグについて

47 of 95

H - Immersion

64k intro, 2017

デモ

48 of 95

ゲーム制作への応用

前回のおさらい
64k intro 制作から学んだこと (Zavie)
ゲーム制作への応用 (i-saint)

Agenda

49 of 95

Pros:

比較的少ない労力で複雑なモデルを出せる
ポリゴンベースでは難しい表現ができる

Cons:

シーン全てを Distance Function で表現するのは無理がある
編集や制御が大変
重い

ゲーム制作への応用

raymarching をゲームで使うメリットは、主にこの 2 点だと思います。

比較的少ない労力で複雑なモデルを出せる。

ポリゴンベースでは難しい表現ができる。

フラクタルや soft-min の合成はいい例で、ぱっと見すごくインパクトがあります。

一方で問題もあります。

シーン全てを distance function で表現するのは無理があります。アーティストの方に「今日から distance function 書いてね」というのも無理な話です。ポリゴンモデルと両立できるようにしなければ実用性はありません。

編集や制御が大変です。モデルを修正するにはシェーダの編集が必要になるので、マウスでちょっと移動、のような気軽な編集ができません。

そして最大の問題は、重いことでしょう。intro 作品はハイエンド PC で 720p でかろうじて 30 FPS、なんてのが当たり前です。

これらの問題をどうにかする方法を考えます。

50 of 95

シーン全てを Distance Function で表現するのは無理がある

ポリゴンモデルと Distance Function を混在できるようにしたい

Deferred Shading であればこれは容易に可能

ポリゴンモデルとの混在

51 of 95

Deferred Shading の場合ライティングは G-Buffer に対して行われる
G-Buffer さえ生成できれば一貫したライティングやポストエフェクト処理を実現できる
Raymarching で G-Buffer を生成すればポリゴンモデルと完璧な混在が可能

ポリゴンモデルとの混在

52 of 95

Raymarching とポリゴンモデルで座標系を一致させる必要がある
Raymarching に必要なパラメータは ViewProjection 行列から抽出可能

G-Buffer 生成

では、raymarching で GBuffer を生成してみましょう。

まず distance function とポリゴンモデルで座標系を一致させる必要がありますが、そのために必要な raymarching 用のパラメータは全て view / projection 行列から抽出できます。

よって、カメラに関するパラメータは普通にポリゴンモデルを描く場合と同じで問題ありません。

raymarching に必要なパラメータはカメラの forward, up, right 方向、focal length、そして position です。それらはこのようなコードで抽出できます。

ちなみにこの例は左手座標系です。右手座標系の場合若干変化がありますが、調べればすぐわかると思います。

あと、カメラの位置の算出は見ての通りちょっと複雑です。カメラ位置は大抵パラメータとして用意されてると思うので、あるならそちらを使いましょう。

これで raymarching の準備はできました。

53 of 95

Ray の位置に ViewProjection 行列を掛けて Depth を算出
Pixel Shader の Depth 出力機能で出力

HLSL だと SV_Depth
プラットフォームよって範囲が異なる可能性があるので注意

0.0~1.0 or -1.0~1.0

G-Buffer 生成

54 of 95

Normal

通常通り勾配から求める

G-Buffer 生成

55 of 95

Albedo, Emission など

特に決まった方法はない
出したい絵に応じて臨機応変に

G-Buffer 生成

56 of 95

G-Buffer 生成

57 of 95

G-Buffer 生成

58 of 95

Raymarching とライティングを 1 Pass で行えば混在可能
Depth / Normal Buffer などを要求される場合、専用のバッファを用意

Ray が進んだ距離を記憶して各 Pass で使い回す

Forward Shading の場合

一応 forward の場合についても触れておきます。

ほとんど検証していないので憶測になってしまいますが、基本的には raymarching と depth 生成とライティングを 1 pass でやるだけで、可能なはずです。

ただ、forward+ のように depth が先に要求される場合とか、post effect で normal buffer が要求されるような場合は拡張が必要になるでしょう。

ray が進んだ距離を格納する専用のバッファを用意して、depth 用の pass や normal 用の pass で結果を使いまわせるようにします。

また、ライティング処理はゲームエンジンによってはブラックボックス化されていたりするので、deferred より実装難度は上がると予想されます。

59 of 95

Intro の場合 Fullscreen Quad 1 枚で全てをレンダリングする

1 つの Distance Function で全オブジェクトを表現

ゲームの場合この制約は不要

ゲーム用にシーンの構成を改善する余地がある

Object Space Raymarching

60 of 95

Distance Function をパーツ毎に独立したシェーダに分解
Bounding Volume となる単純なポリゴンモデルをシーンに配置

Box, Sphere など

ポリゴンモデルの表面から Raymarching

Object Space Raymarching

61 of 95

オブジェクトの Transform を反映させる

Ray にオブジェクトの Transform の逆行列を掛ける

ゲームエンジン上で Distance Function モデルの配置が可能になる

Object Space Raymarching

62 of 95

パラメータによる形状の変化

エディタ上のパラメータ調整でバリエーションを出す

Object Space Raymarching

これは object space とはあまり関係ないですが、パラメータでモデルに変化をつけられるようにしておくと、バリエーションが増やせて都合がいいですよという例になります。

ゲームエンジン上で配置しつつ適当にパラメータも変えていけば、同じ distance function で微妙に違う形状にできるわけです。

左は六角形の床の distance function ですが、密度パラメータで歯抜けにしたり、アニメーションできるようにしています。

右はメタボールの distance function で、ボールの数や位置をパラメータとして編集できるようにしています。

こういう形状の変化が簡単にできるのは raymarching ならではと言えるでしょう。

63 of 95

Object Space Raymarching

Bounding Volume

Result

作例

64 of 95

Raymarching の負荷 3 要因

Distance Function の複雑さ
Raymarching の Step 数
描画 Pixel 数

この 3 つに比例して負荷が増大

Raymarching 高速化

65 of 95

Raymarching の負荷 3 要因

Distance Function の複雑さ
Raymarching の Step 数
描画 Pixel 数

この 2 つを最適化する方法を考える

これらは一度実装すれば Distance Function が変わっても適用可

Raymarching 高速化

66 of 95

低解像度のバッファから段階的に Raymarching することでトータル Step 数を減らす

低解像度のバッファで Step 数多めに Raymarching
高解像度のバッファで、低解像度の結果を引き継いで Step 数少なめに Raymarching
上記手順を何段階か繰り返す

Hierarchical Raymarching

67 of 95

Hierarchical Raymarching

68 of 95

非常に上手く機能する
品質の低下は少ない方だが、細部が潰れるのが欠点

Hierarchical Raymarching

69 of 95

数フレームに分けて Raymarching することで 1 フレームあたりの Step 数を減らす

Step 数少なめで Raymarching
前フレームの Ray の位置を Temporal Reprojection しつつ継続

Temporal Raymarching

70 of 95

Temporal Raymarching

71 of 95

大きな高速化が見込めるが、大きな問題も数点

結果が安定するまで輪郭付近が汚くなる
Temporal Reprojection の誤差により Ray が貫通する

輪郭付近は Step 数多めにする、モーションブラーなどで誤魔化す、Ray を少し引き戻すなど、泥臭い対策が必要

Temporal Raymarching

72 of 95

Pixel Shader で自力で Depth を出力する場合、Early Depth Test が無効化される

遮蔽される Pixel にも Pixel Shader が走ってしまう

Conservative Depth Output

73 of 95

Conservative Depth Output でその欠点をある程度克服できる

D3D11 世代で備わった機能
SV_DepthGreaterEqual / SV_DepthLessEqual

出力 Depth に本来よりも前 / 後ろの前提を与えられる
自力で Depth を出力しつつ Early Depth Test を有効にできる

Conservative Depth Output

74 of 95

今回の場合 Depth は Bounding Volume より必ず奥になる
SV_DepthGreaterEqual で高速化が見込める
ポリゴンモデルより後に描くようにすればより効果的

Conservative Depth Output

75 of 95

近隣 Pixel の Ray から Normal 生成

ddx() / ddy() で勾配を算出
Normal 生成には通常 6 回 Distance Function を計算する必要があるが、そのコストを削減できる
そのままでは品質の劣化が激しい

その他使えるかもしれないテクニック

ここから先は、採用を見送ったボツネタの供養になります。

何かの参考になるかもしれないので紹介いたします。

screen space で法線を算出するというテクニックがあります。

pixel shader には ddx() と ddy() という関数があります。この関数は特殊な性質を持っていて、近隣 pixel の情報を間接的に得られます。

これを使うと、近隣 pixel の ray との勾配を得られます。つまり、大雑把な法線が得られます。

raymarching で法線を算出する場合、普通は distance function を 6 回計算して算出しますが、そのコストを削減できるわけです。

しかし問題もあります。まず distance function 6 回分というのはそこまで大きな高速化にはなりません。

加えて、ddx() と ddy() は 2x2 pixel のブロック単位で行われるので、そのままだと解像度が下がったような見た目になってしまいます。

ddx() / ddy() の結果を綺麗に見せかけるテクニックもあるようなのですが、高速化に繋がらないと意味が無いので今回はそこまでやりませんでした。

76 of 95

横半分の解像度でレンダリングして前フレームの結果と混ぜる

Temporal Reprojection で補正しつつ Interlace で合成
効果はそこそこだが品質も落ちる
Killzone: Shadow Fall のマルチプレイヤーモードで採られた手法

その他使えるかもしれないテクニック

次のネタです。横半分の解像度でレンダリングして前フレームの結果と混ぜる。

これはもうそのまんま、レンダリング解像度を半分にして高速化を図るテクニックです。

前フレームの結果は interlace で混ぜるのですが、その際に temporal reprojection を適用するのがミソです。カメラなどが動いた時汚くなるのを緩和します。

これは raymarching に限ったテクニックではなく、使うならシーン全体に対してやる方がまだ違和感が少なくなると思います。

品質は落ちますが、どーしてもフレームレートが出ない時の最終兵器として記憶に留めておくといいかもしれません。

ちなみに、これは Killzone: Shadow Fall のマルチプレイヤーモードで採用されて有名になったテクニックです。

Killzone: Shadow Fall はこれが原因で解像度詐欺と言われて訴訟沙汰にまでなりました。使用の際は十分お気をつけください。

77 of 95

Enhanced Sphere Tracing

Mercuryによる提案手法

http://erleuchtet.org/~cupe/permanent/enhanced_sphere_tracing.pdf

intro 用テクニックでゲームにはやや不向き
以下大雑把に紹介

その他使えるかもしれないテクニック

78 of 95

Over-Relaxation Sphere Tracing

Ray を通常より多めに進める
Sphere がオーバーラップしなかったら引き戻して通常運行

Enhanced Sphere Tracing

Over relaxation sphere tracing という手法が提案されていました。

大まかなアルゴリズムは、raymarching をする時に通常より多めに ray を進めて、進みすぎた場合 ray を引き戻して通常の raymarching に切り替える、というものです。

この図を見るとわかりやすいと思います。上は通常の raymarching、下はこのアルゴリズムを適用したものです。

赤い部分は ray を多めに進めていますが、sphere がオーバーラップしているので問題ないとみなしてそのまま進めています。

この黄色い部分でオーバーラップが途切れたので、ray を引き戻して通常運行に戻しています。

これにより raymarching の step 数を減らしています。

このテクニックは、ray をどのくらい通常より進めるか、というのが悩ましい点です。

常に最適な値があるわけではなく、distance function 個別の調整が必要になります。大きすぎると ray が貫通して結果がおかしくなります。

また、最適な値が決まったとして、そこまで劇的に速くなるというわけでもありません。

シビアに速度が欲しい状況では検討の余地があるかもしれません。

79 of 95

Bounding Volume を用いた最適化

Distance Function の Bounding Volume を用意

Sphere など Ray との交差点を一発で求められる図形

Ray と Bounding Volume との交差点を計算
交差点から Raymarching 開始

Enhanced Sphere Tracing

こちらも enhanced sphere tracing で提案されているテクニックです。Bounding volume を用いた最適化。

例えばこの図のシーンを考えます。distance function の五角形モデルと、それの bounding volume となる sphere があります。

sphere と ray であれば、raymarching するまでもなく一発で交差点を求められます。

なので、まず ray と bounding volume との交差点を求めて、そこから raymarching を開始すれば、少ない step 数でいい結果を出すことができます。

このテクニックは要するに object space raymarching と同じアイデアです。bounding volume をポリゴンでやるかシェーダ内でやるかの違いです。

ゲームで使う観点で見ると object space raymarching の方が圧倒的に有利で、敢えてこちらを使うメリットは無いんじゃないかと思います。

intro の場合有用そうな感じはあります。

80 of 95

Distance Function を事前にサンプリングして近似モデルを生成

その他使えるかもしれないテクニック

81 of 95

複雑で描画面積が多い Distance Function を想定

≒フラクタル

事前に Distance Function をサンプリングして近似モデルを用意

Marching Cubes 法やボクセルモデル化などで生成

近似モデルを Depth のみ専用のバッファに出力

遮蔽されるピクセルに Raymarching が走るのを避けるため

出力された Depth を開始点として Raymarching

事前サンプリングによる近似モデル

82 of 95

少ない Step 数でいい結果を得られる
モデルによっては描画 Pixel 数軽減も期待できる
効果はあるが、運用が難しい

事前モデル生成が面倒
カメラがモデルに突っ込んだら Fullscreen Quad に切り替える必要がある

突っ込んだのをどうやって検出する?
CPU 側で Distance Function 計算?

事前サンプリングによる近似モデル

近似モデルが raymarching の開始点になるので、少ない step 数でいい結果を見込めます。

描画 pixel 数が減ることも期待できます。

しかしこの方法、運用が難しいです。

カメラがモデルに突っ込んだケースを考えなくてはいけません。

突っ込んだ場合近似モデルをやめて fullscreen quad に切り替える必要がありますが、

それ以前にカメラが突っ込んだのをどうやって検出するかも厄介な問題です。

色々やりようはあると思うのですが、スマートに運用できるところまで持っていくのが大変そうだったので、今回は見送りました。

Distance function を事前にサンプリングしておく、というアイデアは色々用途があるのではないかと思います。

83 of 95

ポリゴンモデルとの混在は問題なく可能
パーツ分解によりある程度の編集の柔軟性を確保可能

エディタ上でパーツを食い合わせてシーンを構築

工夫次第でかなり速くできる

ただし速度:品質のトレードオフは不可避

局所的な用途に限れば十分実用レベル

ゲームへの応用: まとめ

解説は以上となります。まとめです。

Distance function とポリゴンモデルとの混在は問題なく可能です。特に deferred shading の場合は簡単に実装できます。

Distance function をパーツに分解することで、ある程度の編集の柔軟性を確保できます。

ゲームエンジン上で distance function のモデルを配置できるようにすると、楽しくシーンを構築できるでしょう。作例で紹介したように、単純な distance function でも意外とゴージャスな絵を出せます。

工夫次第ではかなり速くできます。これまで見てきたように、高速化する方法は色々あります。あるんですが、どの方法も一長一短で、どこかしら品質が犠牲になります。シーンが複雑になるほどトレードオフに悩むことになります。

やってみた実感として、正直フラクタルは難しいです。やはり重いのが問題で、60 FPS のゲームに出そうとなるとかなりクオリティを犠牲にする必要があります。

しかし、distance function のパーツでシーンを構築する方法自体は実用に足るんじゃないかと思っています。

プログラマー一人でもそこそこ見れる絵を出せるのは魅力で、アセット制作をどうするかで悩みがちな小規模開発などで役立つツールになるのではないでしょうか。

84 of 95

本公演の作例データなど (Unity 用プロジェクト)

https://github.com/i-saint/Unity5Effects

ゲームへの応用: まとめ

85 of 95

実プロダクションに使われた例

最後に、実プロダクションで使われた例を紹介したいと思います。

ゲームではないのですが、今年、東映アニメーションさんから正解するカドというアニメがリリースされました。

見ての通り、この作品には堂々と mandelbox が出てきます。この mandelbox は raymarching でレンダリングされていて、しかも本公演で紹介したテクニックも一部用いられています。

Demoscener 的に意義深いものであったと思います。

東映アニメーションさんはこれのレンダリングのために人を雇い入れていて、もしかしたら raymarching が雇用を産んだ日本初の事例かもしれません。

東映アニメーションさんは今後これの技術解説をしていく予定があるそうなので、興味がある方はチェックしておきましょう。

86 of 95

Questions?

87 of 95

ありがとうございました！

Follow us: @TokyoDemoFest

End

88 of 95

Tokyo Demo Fest

http://tokyodemofest.jp/2017/�https://twitter.com/TokyoDemoFest�https://twitter.com/TokyoDemoFestEN�

Ctrl-Alt-Test

http://www.ctrl-alt-test.fr/

References

89 of 95

kkrunchy�http://www.farbrausch.de/~fg/kkrunchy/�https://github.com/farbrausch/fr_public/tree/master/kkrunchy�

PicoC�https://github.com/zsaleeba/picoc

Tweakable values�https://github.com/joeld42/ld48jovoc/blob/master/ld17_island/tweakval.h�https://www.gamedev.net/resources/_/technical/game-programming/tweakable-constants-r2731

Runtime Compiled C++�https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus

References

90 of 95

Unity frame debugger

https://blogs.unity3d.com/2014/07/29/frame-debugger-in-unity-5-0/

References

91 of 95

Bonus slides (Zavie)

92 of 95

サイズについて

Removed marching cubes algorithm

Improved shader compression�(ShaderMinifier)

Add back marching cubes + Poseidon statue

93 of 95

サイズについて

Party release at Revision�(April 2017)

__fastcall

New scene

94 of 95

Syntax highlighting?

Use meaningful colors.
Make the invisible visible.
Make the dangerous visible.

→ Local/global, variable/function, class/namespace, etc.

デバッグについて

95 of 95

デバッグについて

Macros!

(隠しコード)

Global!�(危ない所かも)

Namespaces�(外のコード)