WPF で 3D オブジェクトを回転させる

前回の WPF で 3D オブジェクトを表示するに引き続いて、今回は 3D オブジェクトを回転させます。
図のようにボタンを配置して、6 方向の回転ができるように実装します。

次のようにコードを追加・変更します。

ボタンとして RepeatButton を配置しています。
RepeatButton は、押したままにしておけば断続的に Click イベントが発生します。
また回転の状態を表すために、ModelVisual3D.Transform の中で MatrixTransform3D を使います。

回転には、回転軸と回転角度が必要です。

  • 回転軸は、ベクトルで表されます。
  • 回転角度は、回転軸の方向に右ねじを押し込む場合を正とします。

6 つのボタンはそれぞれ、x, y, z 軸を回転軸とした正方向または負方向の回転を表します。
1 回の Click イベントにつき 5° ずつ回転させています。
なお、カメラは z 軸上の正の位置から原点方向を見下ろし、右側が x 軸の正、上側が y 軸の正を表しています。

Click イベントハンドラーの中で、Matrix3D.Rotate メソッドを呼び出すことでオブジェクトを回転させます。
引数には、回転軸と回転角度を表す Quaternion (四元数) を指定します。
このように、回転軸と回転角度がわかっている場合は比較的簡単に実装ができます。

下図は、最初の状態から x 軸の負の方向に 60° 回転させたところです。

全体のソースコードは DiceRotationWpf (GitHub) にあります。
マウスまたはタッチのドラッグ操作でも回転できるようになっています。

Dice Rotation

 

前回: WPF で 3D オブジェクトを表示する

作成したサンプル
DiceRotationWpf (GitHub)

バージョン情報
.NET Framework 4.5

参照
3-D グラフィックスの概要
3-D 変換の概要

WPF で 3D オブジェクトを表示する

WPF の 3D グラフィックスの機能を使って、3D オブジェクトを表示する方法を示します。
XAML でさいころのような立方体を描画することを目指します。

Dice (XAML)

先に XAML を示します。この後に簡単な説明が続きます。

 

まず、Viewport3D を配置します。
3D オブジェクトを描画するには次の 3 種類のものが必要で、これらを Viewport3D に設定します。

カメラ
Viewport3D.Camera プロパティに指定します。PerspectiveCamera を使うと、遠近感が出ます。
既定では LookDirection="0,0,-1" UpDirection="0,1,0" となっており、
つまり z 軸の逆方向を向いており、y 軸の正方向が上になっています。

照明
通常のオブジェクトと同様に、Viewport3D.Children プロパティにモデルとして追加します。
AmbientLight を使うと、影がなく、一様な明るさでオブジェクトが表示されます。

オブジェクト
主に ModelVisual3D として定義し、Viewport3D.Children プロパティに追加します。

以下では、ModelVisual3D の設定について書いていきます。
GeometryModel3D でオブジェクトを定義し、ModelVisual3D.Content プロパティにそれを指定します。
複数のオブジェクトをグループ化するには、Model3DGroup を使います。
GeometryModel3D には、マテリアルとジオメトリを指定します。

マテリアル

GeometryModel3D.Material プロパティで、何を表示するかを指定します。
ここでは、さいころの面を描くために 2D の TextBlock を用意しておき、それをテクスチャとして指定しています。
2D の Brush をテクスチャとして利用するには、DiffuseMaterial を使います。

また、BackMaterial プロパティに、Material プロパティと同じものを指定すれば、裏面には表面を反転したものが表示されます。
つまり、「3」の裏面は「ε」のようになります。

ジオメトリ

GeometryModel3D.Geometry プロパティで、どこに表示するかを指定します。
具体的には、MeshGeometry3D を利用して、次のものを指定します。

点の集合 (Positions プロパティ)
メッシュを構成する三角形に分割した場合に、頂点となる点の集合を指定します。

三角形の集合 (TriangleIndices プロパティ)
Positions プロパティで指定した点に0からインデックスを付けて、メッシュを構成する三角形の頂点を列挙します。
三角形の頂点の順番は、表側から見て反時計回りになるように指定します。

テクスチャの位置 (TextureCoordinates プロパティ)
Positions プロパティで指定した各点が、マテリアルの中のどの点に対応するかを指定します。
マテリアルは 2D なので、左上が (0, 0)、右下が (1, 1) です。

例えば、

<MeshGeometry3D Positions="-1,-1,1 1,-1,1 1,1,1 -1,1,1" TriangleIndices="0,1,2 0,2,3" TextureCoordinates="0,1 1,1 1,0 0,0"/>

とした場合は、P0(-1, -1, 1), P1(1, -1, 1), P2(1, 1, 1), P3(-1, 1, 1) の 4 点があり、
メッシュは P0P1P2 と P0P2P3 の 2 つの三角形で構成され、
P0 が左下、P1 が右下、P2 が右上、P3 が左上となるようにテクスチャを描画するという意味になります。
なお、これらの値を XAML 上で列挙するときの区切り文字としては、カンマまたはスペースの両方が使えます。

アフィン変換 (移動、スケール、回転など) について

3D オブジェクトのアフィン変換は、ModelVisual3D.Transform プロパティで指定します。

コードでの記述について

XAML の代わりに C# などの .NET のコードで記述することもできます。
同一の処理が繰り返される場合には、コードで生成したほうが簡単に表現できることもあります。

 

次回: WPF で 3D オブジェクトを回転させる

作成したサンプル
Wpf3DSample (GitHub): コードで描画した例もあります。

バージョン情報
.NET Framework 4.5

参照
3-D グラフィックスの概要
3-D 変換の概要

Bot Framework で Slack の bot を構成する

Microsoft Bot Framework を利用した bot API を公開して、Slack をクライアントとして使えるように構成してみました。
その構築手順と注意点の簡単なメモを残しておきます。

基本的には、次の 2 つの記事をもとにしています。

(1) 環境設定

(2) bot を Web API として開発

  • テンプレートからプロジェクトを作成する
  • プロジェクトのプロパティで [アセンブリ名] を変更する
  • NuGet で Bot Framework を更新する

(3) Azure App Service に配置

  • Visual Studio から発行する

(4) Bot Framework サイトに登録

  • Web.config の appSettings にアカウント情報を設定するには、Azure Portal の [アプリケーション設定] を利用する
  • Web Chat を構成する
    • HTML に Web Chat を埋め込む
  • Slack bot を構成する
    • Slack の設定を追加するときに表示される手順の通りに進める

 

以下は注意点です。

(1) 開発環境における実行について

ローカルの開発環境においては、
Visual Studio で開始した bot API に Bot Framework Channel Emulator から接続することになりますが、
[デバッグなしで開始 (Ctrl+F5)] では 401 エラーとなります。
[デバッグの開始 (F5)] で実行すれば接続できます。

これは、Controller に BotAuthentication 属性が付けられていることによって、
デバッガーにアタッチされているときは認証不要になるためです。
したがって、開発環境では [デバッグの開始 (F5)] で実行しましょう。

(2) クライアント上でのテキストの表示について

テキストは既定で Markdown 形式です。したがって、記号などを使用するときは注意が必要です。
なお、reply.TextFormat を plain に設定しても、Web Chat では無効のようです。
また、reply.TextFormat を plain に設定しても、Slack ではなぜか * が _ と表示されます。

(3) Activity.Type について

Slack からは、activity.Type が ActivityTypes.Message でない要求が送られてくることがあります。
activity.Type の値により処理を分岐させないと、応答メッセージが重複して表示されてしまいます。

(4) URL の送信について

Slack から URL を送信すると、bot 側で受信するテキストでは、URL が < と > で括られます。

 

素因数分解 bot API のコードを示します。
全体のソースコードは、FactorizationBotApi (GitHub) にあります。

 

Slack で実行したときのスクリーン ショットです。

Factorization bot

 

表情分析 bot については、Bot Framework で Slack bot 構築メモ (Qiita)に書きました。

作成したサンプル
BotSample (GitHub)

バージョン情報
.NET Framework 4.6
Microsoft.Bot.Builder 3.3.0

参照
人工知能パーツ Microsoft Cognitive Services を使った表情分析アプリを作ろう! (Emotion API × Bot Framework 編)
Azure で Web 公開&お手軽 Web Chat を試す
Microsoft Cognitive Services & Bot Framework 概要
Bot Framework Overview

Bot Framework で Slack bot 構築メモ

カテゴリー: クラウド. タグ: , . Leave a Comment »

エスカレーターのシミュレーション

ひたすら人々がエスカレーターで昇っていく動画です。

 

4種類のエスカレーターがあり、右から、

  • 両側とも詰めて乗り、歩かない。
  • 両側とも1段おきに乗り、歩かない。
  • 左側は1段おきに乗り、歩かない。右側は歩く。
  • 左側は1段おきに乗り、歩かない。右側は歩く。ただし、右側に来る人の頻度は低い。

を表しています。

ソースコードは、Tools-2016 (GitHub) にあります。

参照
Escalator Simulator (YouTube)
エスカレーターは歩かずに立ってるほうが結局速い。ロンドン地下鉄が実証

カテゴリー: ツール. タグ: . Leave a Comment »

マウスのドラッグ イベントを Rx で実装する

WPF などの GUI アプリケーションでマウスのドラッグ操作を扱うには、
例えばマウスのドラッグ中の各点の情報も通知するなどの要件に合わせて、
基本的には自分で実装することになると思います。

従来であれば、MouseDown などの各イベントごとにイベントハンドラーを登録して実装していましたが、
リアクティブ プログラミングにすることで、より抽象度の高い形式で扱えるようになります。
今回は、WPF のマウスのドラッグ イベントを Reactive Extensions (Rx) で実装してみます。

WPF アプリケーション プロジェクトを作成して、NuGet で System.Reactive をインストールします。
そして次のクラスを作成します。

イベントと IObservable は、本質的には等価です。
まず Observable.FromEventPattern メソッドを使って、
MouseDown などの既存のイベントを IObservable<MouseEventArgs> に変換します。

ドラッグの実装方法については、
MouseDown が発生してから MouseUp または MouseLeave が発生するまでの間、MouseMove を通知させます。
これが MouseDown の発生のたびに開始するため、
MouseDrag の型は IObservable<IObservable<Vector>> のような入れ子になります。
ここでは、MouseDown イベントが発生した位置からの変位を通知することにしています。
(要件によって実装方法は異なるでしょう。)

次に、上で実装した MouseDrag を利用するには、次のコードのようになります (主にコンストラクターの部分)。
完全なソースコードは MouseRx2Wpf (GitHub) にあります。

ウィンドウには、変位とそれを表す 8 方向の矢印を表示しています。

MouseRx2Wpf

 

この方法はマウス以外にも応用できます。
Leap Image Pinch は、Leap Motion Controller を使って空中で 2 本の指でつまんで画像をドラッグする例です。

作成したサンプル
MouseRx2Wpf (GitHub)

バージョン情報
.NET Framework 4.5

参照
System.Reactive
Reactive Extensionsの概要と利用方法
Leap Image Pinch

アートのプロセスについて

前回のメディアアートについてで書いた通り、アートの基本となるのは概念の抽出です。
アーティストが作品を制作する際にはテーマに対する徹底的なリサーチが含まれており、そのプロセスはさながら研究といえるでしょう。
(こういうプロセスが不要な人は天才と呼ばれます。)

今回は、アートのプロセスについて考えてみたいと思います。

 

現代美術の展覧会を鑑賞すると、「難度の高い IQ テスト」という感想を持つことがあります。
作品を見ても最初は「これは何だろう」で思考が停止してしまうのですが、
作品の意味を聞くと納得でき、もはやそういうものにしか見えなくなります。
むしろ、なぜ最初に気付けなかったのだろう、と思うのです。

これに近い現象は他の分野でも起こります。
数学や MENSA においても、良い問題というのは
「解き方を知ってしまうとその解き方が当然のように見えてしまうが、それに気付くのは難しい」という側面があります。
実はプログラミングにおいても、「プログラミングの知識があるからといって、実装ができる人とは限らない」ということがあります。

では、なぜこのような非対称性が発生するかというと、

  • 「この技術を使うと、これが実現できる」は演繹 (deduction)
  • 「これを実現するには、この技術を使うとよさそう」は仮説的推論 (abduction)

という違いがあるからだと考えます。

仮説的推論 (仮説形成、アブダクション) とは、不確実性下で尤もらしい解を導くことです。
演繹では結果が保証されますが、仮説的推論では結果が 100% 保証されるとは限りません。
簡潔な説明が Wikipedia の論理的推論に載っています。
人工知能などのコンテキストで、仮説的推論や帰納は、より人間らしい創造的な能力であると説明されます。

プログラミングにおいては、学習時には主に演繹の形式で理解するのに対して、開発の現場では仮説的推論が必要になります。
現場で品質がばらばらになるのはこのためです。
この意味で、プログラミング自体が創造的な側面を持っているといえるでしょう。
(ちなみに、対比のメタファーとして、製造業のアルバイトが挙げられます。
製造業のアルバイトでは、作業手順のマニュアルがあるため、それに従えば一定の品質が保たれます。)

このように考えると、アーティスティック (芸術的、審美的) な研究のプロセスでは
「どのように作ったか」よりも「どのように思い付いたか」が重要になってきます。
前者を知って真似することはできても、後者を知って真似することは難しいはずです。
短期的な投資をする人たちにとっては前者でよいですが、長期的な投資のためには後者が必要です。

そしてそのために必要なものは何かというと、概念をより多く知ることではないかと考えています。
パターンを増やす、多様性、ともいえます。
上位のコンテキストを捉えられれば、より汎用的な能力を身に付けることになります。

例えば数学の研究において、概念を拡張することは重要な仕事の一つですが、
概念を拡張するには、「このように定義すれば、さまざまな事象を共通的に記述できるだろう」と気付くことが必要です。
既知の概念やパターンが増えてくれば、同時に「まだ整理されていない事象は何か」「未知の領域は何か」に気付きやすくなり、
考察の対象を絞り込めるようになるでしょう。

前回: メディアアートについて

カテゴリー: 芸術. タグ: . 1 Comment »

メディアアートについて

私はこれまでに、2015 年の菅野創+やんツー「SEMI-SENSELESS DRAWING MODULES #2 – Letters」および
2016 年の菅野創+やんツー「Asemic Languages」というメディアアートの作品の制作に、技術協力として参加してきました。
この 2 つの作品はいずれも、入力となる筆跡データに近い新たな筆跡データを生成して機械が描くというもので、
私は新たな筆跡データを生成する部分を担当し、機械学習を利用して実装しました。

さて、私は美術を専門とはしていませんが、
以下では、これまでの活動を通じてメディアアートについて得られた知見を書いていきたいと思います。

 

アートおよびメディアアート

一般の多くの人たちが思い浮かべる「美術」は、自身が高校生以前の「図画工作」「美術」の授業で扱った内容の知識で
止まっていることと思います。それらはおそらく、古典美術やビジュアルデザインなどに分類されるものでしょう。
美術のカテゴリの中で、とくにコンセプトを問うのが現代美術 (contemporary art) で、
さらに現代技術 (ハードウェアやソフトウェア) と融合したものがメディアアートです (個人の見解です)。

アートの基本となるのは、概念の抽出やパターン認識です。これは数学や哲学でも同じです。
事象から概念を抽出し、それらの関係を変化させることで美しさや非日常的な興を生み出すことができます。
アーティストは作品を通じて、鑑賞者に概念的な気付きを与えてくれます。

現代美術の作品は、答えではなく問いである、といえるでしょう。
答えが出てしまっているものは、アートではなくデザインです。
プログラマーは既に経験した技術を使い、デザイナーは既存の概念を使い、アーティストは概念を問うたり創り出したりします。

例えば上で紹介した作品では、「線が文字っぽく見えるとはどういうことか」
「人工知能やロボットが自発的に生成した絵画は、特定のアーティストの作品と呼べるのか」 などということを世の中に問うているのです。

時には芸術作品の意味が理解できないこともあるでしょう。
同じように、例えば哲学や経営の本を読んだとき、賛否を論じる以前にピンとこない、難しい、著者の意図が分からない、
ということがあると思います。この状況はすなわち、これまでの人生でその概念を獲得できていなかったということを示します。
より高い概念を獲得した人たちの間では共通認識、暗黙の了解のようなものが生まれ、より複雑な状況下での判断ができるようになります。

アートと歴史

言うまでもなく、アートは現代に始まったものではありません。
日本の歴史においても、庭園、茶道、茶器、絵画など、さまざまな種類が挙げられるでしょう。
時代劇などでも地位の高い人を招いて美学やわびさびを論じさせるという描写があり、その応対を通して、
相手の人物がどの水準の概念を獲得できているか、空気を読めているか、大局的な判断ができるかなどを鑑定していたことが想像できます。
これについては現代社会でも同様だと思います。

アートと都市

アルス・エレクトロニカは展覧会のほかにも Futurelab という研究機関を併せ持ち、
メディアアートから企業のイノベーションまでをつなぐサイクルが成り立っています。
アルス・エレクトロニカの運営資金は、リンツ市が 35~40% を支援しているそうで、
研究開発の成果は都市のいたるところにインストールされています。
日本では芸術祭の開催に積極的な都市もあり、このような都市が登場してくる可能性はあります。

アートと企業

将来、創造性の低い職業はロボットで置き換えられていき、利益率も下がると言われていますが、
取って代わられない職業の最たるものがアーティストです。
アーティストはコンセプトを見出す能力や 0 から 1 を創り出す能力に優れているため、例えば自社の製品を作品に使ってもらったり、
ワークショップを開催したりするなど、アーティストと連携していくことが効果的であると考えています。

第一線の創造的事業を継続するためには、本業を軸として芸術分野に投資することも求められていきます。
「本業で」というのがポイントで、例えば、自動車業界であれば F1 をはじめとするモータースポーツを通じて、
自動車の研究開発を世に問うています。 また、現在では多くの企業が博物館をはじめとする展示施設を運営しており、
そこからそれぞれのテーマに関する新たな知見を得ていることでしょう。

次回: アートのプロセスについて

 

これまでの展覧会

カテゴリー: 芸術. タグ: . 1 Comment »