ボクセル勾配の式
ボリュームレンダリングなどをするときに、結果にシェーディングをかけたい場合、光の反射する角度を計算するためにどうしてもボクセルの法線というものが必要になる。
そんな情報は元々ないので、以下の式で計算する。要は、自分と自分の隣、または自分の隣同士のボクセルの差を求め、その結果をベクトルの成分とする。iとi+1の差を求めるか、i+1とi-1の差を求めるかは、偉い人たちの間でも議論が分かれるようである。まあ下々の者にとってはどうでも良い。
映画版のミッション・インポッシブルを見た感想を伝える努力をする
Huluで、トム・クルーズのミッションインポッシブルの1～4までやっていたので見たんだが、その感想をなんとか人に伝える努力をしてみたいと思う。
例えば、「名探偵コナン」を劇場まで見に行った所を想像して欲しい。開始から約十分で事件が起こり、コナンが推理を始める。しかしその十分後に大きな地震がおこり、容疑者の鞄が床に落ち、はずみで中から凶器が飛び出す。「ちっ。ばれちゃあしょうがねえな！」といきなりの自白。次の瞬間には犯人がどこからかマシンガンを取り出し乱射。アガサ博士、毛利小五郎、蘭、目暮警部といった重要人物が意識不明の重体。コナンだけが体格の小ささもあって軽傷で済む。
犯人は逃走するが、後日、ネットの匿名掲示板に都会での無差別殺人の予告が書き込まれる。その時刻には警察が向かうが、犯人は戦車で現場に現れ、周囲に砲撃を繰り返す。警察の装備では歯が立たず窮地に陥るが、警察の言いつけを破り現場に来ていたコナンが戦車に飛びつき、アガサ博士のところから持ち出した新型小型爆弾の試作品を使い、戦車の装甲に穴を空ける。警察はここぞとばかりに拳銃を撃ち込み、犯人を負傷させる。だがそれでも犯人は命からがら逃走する。
数日後、警察は破棄された戦車から犯人の行動範囲を洗い出し、潜伏先の特定まで至った。犯人逮捕に向けて動き出す警察だったが、いても立ってもいられずコナンは先に潜伏先へ向かう。
そこで見たものは、負傷した犯人と、「警察は三日後にはここに来る。パスポートは用意したから国外へ逃げろ」と犯人に言い聞かせる、高木だった。
何で裏切ったんだ！みたいな会話がちょっとあって、二人は撃ち合い、犯人は死亡、高木は車で逃走。コナンも車に乗ってカーチェイスを繰り広げ、持ち前のドライビングテクニックで高木を追い詰める。後がないと悟った高木は「小学生に追い詰められるなんて、考えもしなかったよ。君は何者だい？」「江戸川コナン。探偵さ！」「まいった。僕の負けだよ」で高木が自殺。
最後、警察は潜伏先の資料から真犯人と高木について調査を開始する。ほぼ時を同じくして、コナンはみんなの見舞いに行くと、ちょうどその時蘭が目を覚まし、「蘭！よかった・・・！」で感動の終幕という具合だ。
さて。名探偵コナンを知らない人が見れば、「コナン格好いい！」「あんな小学生いたら惚れてしまうわ。」「高山みなみかわいい」みたいな感想になることは間違いない。そして別に間違った感想ではない。
だが名探偵コナンを大スクリーンで見に来た人は、
推理しろよ
としか思わない。
まあ、凄腕の原作ブレイカー（宮崎駿とか）は普通にこういうシナリオを書くので別に珍しくないのだが、悉く、どういうつもりなのか疑問が絶えない。
それでも、トム・クルーズに罪はない。作品は監督の意向に沿って作られるのだから、非難されるべきは監督だ。
と思っていたらWikipediaに、
なんて書いてある・・・結局お前が主犯か。
彼の失敗はただ一つ、タイトルを「Mission:Impossible」にしたところで、００７なら恐らくなんの問題もなかっただろうし、トム・クルーズ人気で人が集まるのなら、完全オリジナルでもよかった。
大体トム・クルーズはスタントマンを使わないで全部自分で演技するところが売りの俳優だ。ところがスパイ大作戦(原作MissionImpossibleの日本版タイトル)は、いかに「何事もなかったかのように仕事をするか」が重要な作品なのだ。
ミッション・インポッシブルとは本来、”凄く難しい任務”をこなす話ではない。”そもそも成功するわけがないような”作戦を、技術とチームワークで推し進め、何が何でも成功させる。しかもそのような干渉があったこと自体しられてはならない、そんな一見地味だが息つく間もない緊張感を楽しむ作品だ。
例えば麻薬の密売組織Aが、犯罪組織Bに麻薬を売ろうとしている。これを阻止しA,Bを壊滅させろ、という指令が下る。
この時、原作のIMFなら、「Aが麻薬の輸送中に、その中身を小麦粉などにすり替え、Bが持ってくるトランクの中身の現金をすぐそれとわかる偽札にすり替え、取引時に互いの不信感を煽り撃ち合いをさせ自滅に追い込む」というプランを立てる。
実行する上で、IMFの関与がわずかでも疑われたら、AとBが自滅しなくなってしまう。そのため第三の組織の干渉の痕跡は一切残してはならない。実はここが一番難しい。爆発や銃撃戦などを起こせば、自分たちの存在を教えるようなものだから論外だ。
つまり、アクションシーンが売りの俳優が活躍できる作品ではない。
最初に1を見たときは私自身スパイ大作戦を知らなかったので十分楽しんだのも本当だ。だから作品自体はアクション映画としては最高の出来なのだ。だが原作を知ってしまったらあれをミッションインポッシブルと呼ぶわけにはいかない。
いやまじで、
なんでタイトルそれにした。
感想を聞かれたらそれしか出てこないではないか。炎上マーケティングのつもりだろうか。
Blender 苔応用 Cyclesで地球の模型 テクスチャの合成 複数のUVマップ
前回、岩、というか石に苔をつける作業をやったが、その応用で地球のような物を作る。
※これはリアリティを求めたものではない。
こんなのができあがる。
[①]. まず球をUV展開しないと行けない。
こちらを参考に:http://qcganime.web.fc2.com/BLENDER/Misc01.html
|
1. 点が集中する |
 |
2.押し出してから |
 |
| 3.UV展開 Sphere Projection Directionを Align to Objectに |
 |
4.頭頂部の点を メモしておいた座標に 収束させる |
 |
こうしてできたUVマップ。
[②]. 次にテクスチャを苔、海、地図の三枚読み込む
地図はhttp://www.collabonote.com/template/waiwai/map/003/003.htmこちらをお借りして陸を黒く塗りつぶした。
[③]. 球を選択し、二つ目のUVマップを追加する
[④]. Editモードへ入り、UV Editingが見えるようにして、UV Mapsに追加したUVMap.mossを選択する。
UV Editing上で[s]を押し、UVマップを拡大する。
これで、UVMapとUVMap.mossが異なるマップになった。
[⑤]. あとはノードエディタで以下のように設定。
前回の岩に苔をはる作業との大きな違いは、ColorRampのFacの入力元を、陸を黒くした白地図にしているところと、陸と海のテクスチャで違うUVマップを使っているところ。あと、海はDiffuseじゃなくてGlossyにしている。
陸と海のUVマップを変えている理由は、陸側のUVマップを拡大・縮小( [④]参照 )すれば海はそのままにして陸のテクスチャの解像度を自由に変えられるから。逆もまたしかり。
あと、海をGlossyにしているので、海だけてかっている。陸にてかりはない。
一生お金に困らない生き方
タイトル：一生お金に困らない生き方
著者: 心屋仁之助
ページ数:201ページ
さて、普段ならぜってーこの手の本は買わないんだが、某所でメンタルブロックの外し方の参考書籍に上げられていたので購入。その方面の書籍にはやはり敵わないが、参考にはなった。少なくとも買って後悔はしていない。
内容は、あえて大別するなら引き寄せ系なので、そっちを多少知っている人には目から鱗的な特別真新しいことは書いていない。ただ、引き寄せの法則関係の本の場合、自分が幸せになれるなにかを引き寄せるという、いわば漠然とした内容なのに対し、この本はお金に的を絞っているのでとても具体的でわかりやすい。
内容を一言で表すと、メンタルブロックを外し、自己評価を上げ、お金の流れをせき止めない（ちゃんと使う）でいれば、なんか知らんが裕福になるよ、という、「そんな事で金持ちになれるなら誰も苦労はせんわ！だから誰もやらないんだ！」的なことが書かれている。（いい加減その矛盾に（ｒｙ ）
で、実際に心の癖を直したりするにはどうすればいいんですかということもちゃんと書いてはあるが、何しろ３～４時間で読めてしまったくらいの本なので小難しいことは何も書いていない。信じる信じないは別として誰でもすんなり理解できるはずだ。
はずなのだが
結局アマゾンレビューはアテにならんというか、Amazonの低評価、人数は少ないが、明らかに目次すらろくに読んでいないものがあるので、参考にしてはいけない。一般論として、アマゾンレビューから信者とアンチをふるい落とすのは大変なので、
google様の力を借りて立ち読みしよう
本当はレビューがどれぐらいアレなのかちょっと書いたのだが、読み方によっては個人攻撃 になりかねないので削除した。もし購入した人がいたら、是非照らし合わせてみて欲しい。ちなみに、潜在意識は科学的に研究も証明もされているはずなので、その活用という観点から見れば非科学的ではない（と思う）。常識的でないだけである。私は夕べ一気に読んだばかりなので効果があったとかなかったとかは全くいえないが、私の中の評価が結構高かったのは本当だ。
Blender [岩に苔をつける] Cyclesでテクスチャの混ぜ方
http://blendersketch.blogspot.jp/2014/11/waterfall-series3-1.html
このチュートリアルの岩に苔を生やすところで何が起こっているかわからなかったので真面目に考えた。
こんなのができあがる。
[α]. まず石っぽいオブジェクトを作って（別にsphereやCubeでもいいけど）、Editモードに入って全頂点選択→[U]→[Smart UV Project]でUV展開する。
次にオブジェクトにマテリアルを+して、ノードエディタへ行く。
[β]. そして以下のように設定
[γ]. ②、③はそれぞれ、普通に岩のテクスチャと苔のテクスチャを読み込んで、Diffuseの色として指定しているだけ。
[δ]. ①が問題で、まずノイズテクスチャを作り、その色をColorRampの入力へつなげている。
これをそのままDiffuseへつなげて適用すると、下のようになる。
[ε]. この黒～白までの値を、[β]にあるMix ShaderのFacへ入れる。Mix ShaderはShader1とShader2を合成するが、合成の割合はFacで決まる。
●Facが0に近い場合、Shader1がより優先される
●Facが1に近い場合、Shader2がより優先される
従って、ColorRampをマテリアルに適用した時([δ]参照)に黒に近い部分はよりShader1のテクスチャが、白に近い部分はよりShader2のテクスチャが強くなる。
これによって[δ]の図の黒い部分はShader1で指定した苔のテクスチャが、白い部分にはShader2で指定した岩のテクスチャが出ることになる。
Blender Cyclesでのバンプマップ
ところで、Cyclesはマテリアルの設定にNodeエディタを使うことがほぼ前提になっているらしい。なぜなら殆どのチュートリアルではそうしているからだ。
そこでバンプマップの使い方が今ひとつわかりづらかったので調べた。
こんなのができあがる。
使うバンプマップはこれ:
手順は
①UV展開する
②以下のようにノードを設定する
●[Add]-[Shader]-[Glossy BSDF]
●[Add]-[Shader]-[Diffuse BSDF]
●[Add]-[Shader]-[Mix Shader]
●[Add]-[Input]-[Texture Coordinate]
●[Add]-[Texture]-[Image Texture]
●[Add]-[Output]-[Material Output]
Glossyはなくてもいいが立体感が出にくい。
C++/CLIで自作クラスの配列をソート
近所の村の市の店長はとてもいい人なのだが、中島みゆきの糸をBGMにかけていたときはさすがに神経を疑った。いったい何のつもりだ。泣き出すところだっただろうが。
そんなわけでプエルトリコがデフォルトしたらしい。デフォルトってどういうことなのか正確には掴めていないんだが、要は○○日までにお金払いますよ、という約束を果たせなかったということのようだ。気持ち的に近い言葉としては、不渡りとか踏み倒しとか、そのあたりだろうか。
http://www.yomiuri.co.jp/world/20150630-OYT1T50077.html
この結果、高金利の金融商品「プエルトリコ債」が償還されなくなる恐れがあり、米国の投資信託などが多く保有していることから、国際金融市場に深刻な影響を与える懸念がある。
どうやらこういうのはデフォルト宣言があった次の日にどうなる、というものではなく、数週間かけて影響が出てくるという。もうしばらくしたら連鎖倒産が始まるんじゃないか、と予想する人も沢山いるようだ。どうせゼロ金利だし、取り付け騒ぎとか預金封鎖がくる前に定期預金をタンス預金に切り替えたほうがいいかもしれない。箱根山も騒がしいしね。
あとソートのほうなんだが、C#の例は腐るほどあるのにC++/CLIの例がなかなか見つからない。
C#と同類のはずなのに^つけないといけないとか、C++と名乗りながら継承にpublicつけないとか、お前は誰だ言語なのでメモしておかないとはまる可能性がある
// ConsoleApplication2.cpp : メイン プロジェクト ファイルです。 #include "stdafx.h" using namespace System; ref class DataType{ //自作クラス 何でもいい int a; System::String^ b; public: int geta(){ return a; } System::String^ getb(){ return b; } void set(int _a,System::String^ _b){ a = _a; b = _b; } }; //比較用のクラス。 //IComparer<>を継承したクラスを作成し、 //virtual int Compareメンバ関数を定義する ref class Ccmp : System::Collections::Generic::IComparer<DataType^> { public: //xがyより小さいときはマイナスの数、大きいときはプラスの数、同じときは0を返す virtual int Compare(DataType^ x, DataType^ y) { if( x->geta() < y->geta() ) return -1; else if( x->geta() > y->geta() ){ return 1; } return 0; } }; //使い方 int main(array<System::String ^> ^args) { //データ(配列)を用意 int sz = 7; array<DataType^>^ ary = gcnew array<DataType^>(sz); for(int i = 0; i < sz; i++ ){ ary[i] = gcnew DataType(); } ary[0]->set(5,"5"); ary[1]->set(2,"2"); ary[2]->set(7,"7"); ary[3]->set(1,"1"); ary[4]->set(3,"3"); ary[5]->set(5,"5"); ary[6]->set(8,"8"); //ソート実行。 Ccmp^ cmp = gcnew Ccmp();//比較用クラスのインスタンスを作成し、 Array::Sort( ary, cmp);//Array::Sortの第二引数にそのハンドルを渡す //結果確認 for(int i = 0; i < sz; i++ ){ Console::WriteLine( "{0} {1}",ary[i]->geta() , ary[i]->getb() ); } int k = Console::Read(); return 0; }
ロゴはこれで行くべき
☆のところの目のテストをやってみたら
 |
が |  |
 |
が |  |
と、楽天に取り込まれるとロゴがダサくなる。Edyとかe-bankとか、旧ロゴは利用者が特定の企業のサービスとして意識しなくていいようにとの配慮からああなっていたらしいのだが、楽天はそんなことは全くお構いなしなようだ。まあ、思想以前にセンスが全く感じられないところが問題なんだが・・・
ところが何故か野球チームだけは
なんかかっこいいんだけど、なんでこれだけ力入れてんの。
野球だけ特別扱いというのは日本人の三大欠点の一つだと思う。まあアメリカ人もアメリカンフットボールになると発狂するのでどこの国も似たようなものなのだろう。
そうはいっても、このEaglesのロゴは別の意味で酷い。なんといっても楽天ぽくない。
楽天のロゴなら、とりあえず”楽天”の文字が目に入って、「なんだまた楽天かよ・・・」とがっかりしてから、「で、こいつはなんだ？ああ、銀行か」と、サービスを理解するのに必ず一手間置き、まず一度落胆を経由させる効果がなければならない。
それが楽天という企業だ。
だから、楽天Eaglesははやくロゴを変えた方が良い。このままだと、楽天のチームだ、ということがわかりにくい。
具体的には:
絶対この方が良い。楽天ぽい。
ダンスの思い出
中学の時のこと。全校でダンス会的なものが開かれたのだが、ルールが厄介で、
① ラブレターを三通用意する
② 二通を名前と”よろしく”的なことを書いた自己紹介カードにする
③ 一通は本気の恋文にする
④ 本番、男子の輪、女子の輪で◎を作る。
⑤ 男子は右回り、女子は左回りで回る
⑥ ストップの合図があったときに隣にいた人と踊る ⑤→⑥を三回繰り返す。
⑦ ⑥の際、相手が気になる人物だった場合は③を渡す
⑧ ⑥の際、相手がどうでもいい人物だった場合は②を渡す
⑨ 三回の間に意中の相手に③を渡せればよかったね、渡せなければ残念でした
誰がこんなふざけた催し物を考えついたのか。楽しそうにルール説明をしていた髪なし能無し配慮なしの脳筋ヤクザ体育教師以外に思いつかない。むろん私は状況証拠だけで特定個人の残虐性を確信するほど歪んだ性格はしていないが、かといって教員と名乗られれば無条件に忠犬を装えるほど純粋でもない。いずれにせよいずれでもないにせよ、ボイコットするほどの度胸はないので何らかの策を講じねばなるまい。ここに知恵が必要である。
ルールの特徴として、三回も機会がある。
仮に学校内に意中の相手がいた場合、当たってしまう確率は極めて低いとはいえゼロではない。特に、１・２回目で当たった場合、ルール通りなら本命用の恋文を渡すことになる。この時問題になるのは、
●１．本命を渡した時点で、相手にそれがばれる（それが目的なわけだが）
●２．三回目に自己紹介カードを渡さなければならなくなる。これは暗に、三回目の人物に、校内に意中の相手がいる、という内容を（その真偽に関わらず）示してしまう。
さらに、意中の相手が校内にいないか、最後まであたらなかった場合（ほとんどのケースはこれだろう）。
●３．三回目が必然的に本命カードになる。全く興味のない人間に自分の恋文が読まれることになる。
加えるなら、校内に相手がいる場合で、三回目に運悪く遭遇した場合。
●４．本命相手に恋文を渡したにもかかわらず、自己紹介カードの扱いを受ける。
●5. 本命にマジな恋文が読まれる
と、皆考えるはずだ。
4ならいいが5とセットのため、極力避けるべきである。1は確率的には低いが、当たったときのダメージが即死レベルだ。セットの2も必然的に除外されなければならない。すると3しか残らない。
しかし、3は確率が高いからカモフラージュとして有効というだけで、1や5の破壊力が軽減されるわけではない。確率しか根拠のない油断は死を招く。
ここは、「安全なのはどれか」ではなく「最悪のケースを避ける」という観点からの攻略が正解だろう。最悪なのはあくまで1と5だ。これを避けるのは簡単で、本命が来たら自己紹介カード、それ以外なら恋文を渡せばよい。
と、皆考えるはずだ。ここまでは容易に想像できる。だが、最悪なケースを避けられたからといって満足しているようでは危険だ。最悪のケースを避ける、という目標が達成できたら、最善の結果を生み出すための努力をしなければ、このサバイバルは生き残れない。
先の対策の問題は、確実に3と同等の現象が生じる点にある。ここで改めて、1～5を確認すると、セット効果を無視すれば5は3と同じ現象であることがわかる。その条件なら、マシなのは4>=2>5ということになる。今は最悪の5であるため、なんとか4または2にしたい。4は元々低確率(ないしゼロ)なので狙うべきではない。つまり、1と独立した2が最良の結果という事になる。
与えられた枠組みの中でそれを実現するのは不可能だ。
だが、もし、三枚とも自己紹介カードだったら？2以外の結果はありえないではないか。
思い返してみれば、 そもそもこの会は成績に影響しないし、ルール違反の罰則もない。
と、皆考えるはずだ。当日は悪徳教師の思惑は外れ、ただの自己紹介会となるに違いない。そんな中で一人恋文なんぞ持参するのは顔面にバカとかいて校舎を練り歩くようなものだ。
と、皆考えるはずだ。だからこそ、私は鉄壁の自信を持って三枚とも自己紹介カードで挑んだんである。
三回目に恋文が来た時は愕然としたね、実際。
お前ら少しは頭を使え。ルールに従うことが常に正解とは限らないんだぞ。
しかも教室に帰ったら卑怯者とか言われたし。
悪かったよ。学んだよ。
馬鹿の思考は深読みしちゃいけないってことをな。
というか人を卑怯者呼ばわりしたくなるくらい苦痛なら抗議するなり欠席するなりやりようはあるだろうが。こっちはその代りに落雁が作れるほどのブドウ糖を脳に流し込んでるんだよ。
だが今思えば私も人の事は言えないのかもしれない。
むしろ連中は、私が彼らの思考にたどり着いたとこにいち早く気づき、その裏をかいた可能性もある。
結論。敵はそこらじゅうにいる。教師の目をかいくぐり、不確定要素を極力排除してもなお、完璧な勝利を手にすることは難しいのである。渡る世間は鬼ばかり。中学時代の苦い思い出である。
OpenCLのカーネルプログラムとの引数の連絡
と言うわけで、OpenCLのカーネルプログラムの引数に値を渡して、その結果を返してもらうサンプルを作った。
カーネル側の*var1,*var2にintの値を与え、*retへ結果を格納。
・clCreateBufferでデバイスにメモリ確保、
・clEnqueueWriteBufferで確保したメモリへ値を代入
・clSetKernelArgでカーネルプログラムの引数に確保したメモリのアドレスを指定
・clEnqueueReadBufferでデバイス上のメモリから値を取得
・clReleaseMemObjectでデバイスのメモリを解放
と言ったところだろうか。
http://www.fixstars.com/ja/news/books/opencl/
↑この本を参考に書いたが、これ、関数のインタフェースに関してはもちろん事典として記載はあるのだが、具体的にどう使うのかは実例を見て解読するしかないという所が多いように思う。clEnqueueWriteBufferとか、なんとかググらずに済んだが不親切だ。
#pragma warning(disable : 4996 ) #include <windows.h> #include <CL/cl.h> #include <string.h> #include <stdlib.h> #include <iostream> #pragma comment(lib,"OpenCL.lib") #define MAX_SOURCE_SIZE 0x100000 int cl_inout(){ cl_device_id device_id = NULL; cl_context context = NULL; cl_command_queue command_queue = NULL; cl_program program = NULL; cl_kernel kernel = NULL; cl_platform_id platform_id = NULL; cl_uint ret_num_devices; cl_uint ret_num_platforms; cl_int ret; char *source_str; size_t source_size; source_str = (char*)malloc(MAX_SOURCE_SIZE); strcpy(source_str, "__kernel void hello(" " __global int* var1," " __global int* var2," " __global int* ret" ")\n" "{\n" " *ret = *var1 + *var2;\n" "}\n" ); source_size = strlen(source_str); /* プラットフォーム・デバイスの情報の取得 */ ret = clGetPlatformIDs(1, &platform_id, &ret_num_platforms); ret = clGetDeviceIDs(platform_id, CL_DEVICE_TYPE_DEFAULT, 1, &device_id, &ret_num_devices); /* OpenCLコンテキストの作成 */ context = clCreateContext(NULL, 1, &device_id, NULL, NULL, &ret); /* コマンドキューの作成 */ command_queue = clCreateCommandQueue(context, device_id, 0, &ret); /* メモリバッファの作成 引数として使用 */ cl_mem arg1_X = NULL; cl_mem arg2_Y = NULL; cl_mem arg3_R = NULL; arg1_X = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(int), NULL, &ret); arg2_Y = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(int), NULL, &ret); arg3_R = clCreateBuffer(context, CL_MEM_READ_WRITE, sizeof(int), NULL, &ret); /* 読み込んだソースからカーネルプログラムを作成 */ program = clCreateProgramWithSource(context, 1, (const char **)&source_str, (const size_t *)&source_size, &ret); /* カーネルプログラムをビルド */ ret = clBuildProgram(program, 1, &device_id, NULL, NULL, NULL); /* OpenCL カーネルの作成 */ kernel = clCreateKernel(program, "hello", &ret); /* カーネルプログラムの引数に値を設定 */ int val1 = 20, val2 = 50; clEnqueueWriteBuffer(command_queue, arg1_X, CL_TRUE, 0, sizeof(int), &val1, 0, nullptr, nullptr); clEnqueueWriteBuffer(command_queue, arg2_Y, CL_TRUE, 0, sizeof(int), &val2, 0, nullptr, nullptr); /* OpenCLカーネル引数の設定 */ ret = clSetKernelArg(kernel, 0, sizeof(cl_mem), (void *)&arg1_X); ret = clSetKernelArg(kernel, 1, sizeof(cl_mem), (void *)&arg2_Y); ret = clSetKernelArg(kernel, 2, sizeof(cl_mem), (void *)&arg3_R); /* OpenCL カーネルを実行 */ ret = clEnqueueTask(command_queue, kernel, 0, NULL, NULL); /* メモリバッファから結果を取得 */ int ret_val; ret = clEnqueueReadBuffer(command_queue, arg3_R, CL_TRUE, 0, sizeof(int), &ret_val, 0, NULL, NULL); /* 終了処理 */ ret = clFlush(command_queue); ret = clFinish(command_queue); ret = clReleaseKernel(kernel); ret = clReleaseProgram(program); ret = clReleaseMemObject(arg1_X); ret = clReleaseMemObject(arg2_Y); ret = clReleaseMemObject(arg3_R); ret = clReleaseCommandQueue(command_queue); ret = clReleaseContext(context); free(source_str); /* 結果の表示 */ std::cout << ret_val; int k; std::cin >> k; return 0; }