【創作都市伝説】昆虫食は反重力技術の礎

このシリーズは、オリジナル都市伝説を創作してしまおうという試みです。

第一回目のテーマは、
　『昆虫食が反重力技術の礎となっている！』
・・・です。

何を言っているんだ？と思われるかも知れませんが、
実はこれが意外にも、とあるキーワード一つで繋がってしまうのですよね。

そのキーワードとは・・・
「強誘電体」です！

都市伝説マニアの方なら、一度は聞いた事があるかも知れませんが
昆虫学者ヴィクトル・S・グレベニコフ教授がある昆虫のキチン質から反重力効果を発見し、
それを使って反重力プラットフォームを作り出し１５００ｋｍで空を飛びまわったとか・・・

まあ、この話は信憑性に欠けるとして、創作だという認識が定説になっておりますが・・・
今からやろうとしている事は創作都市伝説ですからね。
「バケモンにはバケモンをぶつけんだよ!」の精神で、創作には創作をぶつけようと思います。

実際に、昆虫の羽根には「強誘電体」という性質を持つ事が確認されているのだとか。
本来、電力の恩恵を受ける為には「電界」といって電気の流れる回路が必要になるのですが、
「強誘電体」は「電界」が無くても電力の恩恵が受けられるのそうです。

実際に、カブトムシの様な重い甲虫が
あの羽根だけで飛べる原理は、実は解っていないそうですからね。
羽根に蓄えた電力で、地球の磁場に反発する電極を作り出して飛んでいるという可能性も
充分に有り得そうな話です。

ピラミッド建設に反重力技術が使われていたなんて都市伝説もありますが、
古代エジプトでは、スカラベという甲虫が神格化されている事を考えると
案外、このスカラベから反重力素材を製造していた可能性もあるかも知れません。
古代に車輪が無かったのは、そもそも「必要が無かった」からとも考えられますよね。


さて、この反重力技術が、もし本当に存在するとしたら・・・

その製造に必要となるのが、大規模な昆虫育成のプラントになります。
そう、ここで昆虫食と繋がる訳です。

昨今、注目を浴びるコオロギの食用化ですが
これ、実は・・・結構不可解な点が多いのですよね・・・

まず、コオロギは食用にはあまり向いていないという事。
とにかく、コオロギは育成のコストパフォーマンスが悪いのです。
すぐ共食いしますし、成虫になると鳴くので騒音問題にも発展します。

それなら、蚕の方が断然コストパフォーマンスが良いと思います。
特に蚕なら絹も採れますし、蛹は、食用だけでなく、肥料や飼料にも使え
最近では、バイオマス燃料にする研究も進んでいるそうですので、
かなり可能性の高い分野だと思います。

にもかかわらず、コオロギを押す理由とは何なのでしょうか？


という訳で、ここからが創作都市伝説です。

反重力システムの開発には、多くの昆虫の羽根が必要な為、
極秘に出来ない規模の巨大育成プラントが必要であった。
その為、表向きは食用という名目で、将来の水不足を理由に
世界中で飼育を推奨し、産業廃棄物となる羽根を利用する計画を立てた。

・・・という感じですかね。
蚕の蛹では、羽根は採集出来ませんからね。

ただ、ここで、生じる矛盾があるのですが、
この場合、最も効率良く羽根を得るのであれば
コオロギよりもゴキブリの方が、効率が良いというところなのですよね・・・

特にデュビアなら、
過密飼育でも共食いせず、温度管理も必要無く、餌もなんでも食べるという
コスパ最強生物ですからね。

実は、コオロギと偽ってゴキブリを養殖している可能性もあるのですかね？
粉にしてしまえば判別は不能でしょうし・・・
まあ、それこそ都市伝説ですかね？

コオロギで慣らしておいてからゴキブリへ移行する計画とかの方が現実的でしょうか。

まあ、ゴキブリは毒をもっている訳でも無いですし
自然界では、動物の死骸を食べる掃除屋としての役割や、多くの生き物の餌としての役割も果たす
むしろ益虫といっても良い仕事をする虫でもありますからね。

ゴキブリが嫌煙される主な原因である雑菌の媒介も
清潔な生育環境で飼育されているのであれば全く問題無いですし、
今後の人類は、ゴキブリにお世話に成る方向性に行くのかもしれませんね。

実は、古来からゴキブリも昆虫も、けっこう食べる習慣があったものなので、
むしろ、近年の虫への嫌悪っぷりの方が異常とも言えるのかもしれませんね。


・・・反重力の技術を一般人から遠ざける為に、昆虫食の印象を下げていた・・・
まあ、それこそ都市伝説ですかね？

【アイデアノート】ゲーム株の起死回生方法

昨今のゲーム株下落は凄まじきものですね。
私も、ゲーム株ホルダーの末席を汚す者として、血の涙で枕を濡らす毎日です。
やはり、米国の金融引き締めの影響が諸に出ているのでしょうか？
エンタメセクターは景気敏感株以上に景気敏感なのでしょうね。
まあ、利上げも一段落するみたいですし、今後を占うという意味でも、
目が離せないセクターではありますね。

それは、さておくとして、ここまでゲーム株が下がると
やはりなんとかして下げ止まらせる方法は無いものかと考えてしまいますよね。
そこで思いついたアイデアを、ここにメモがてら残しておきたいと思います。


『ゲーム株の起死回生方法』

それは、ずばり・・・
「株主優待で、ガチャチケットの配布」です！

・・・「え？そんな事で？」とか思うかも知れませんが
この「株主優待」、費用対効果が凄く高いと思うのですよ。

ゲーム会社で株主優待をしているところは少ないので、
それだけでも話題性がありますからね。

単純に有償石を配るだけでも良いのですが・・・
折角なら『株主優待専用ガチャ』を設置すると良いと思います。

株の宣伝にも成りますし、株主還元の意欲を見せる効果にも繋がります。
その上、基本的にゲームシステムの流用でいけるので、比較的に低コストで導入できます。
また、株主通信と一緒に交換コードを送る事になると思うので、
その際に、ゲームアプリの宣伝効果も期待出来るでしょう。

更に、
1単元で100連、5単元で200連、10単元で300連、という具合に設定する事で
ガチャを一回すのが300円だとすると、
1単元だけでも「30000円相当」10単元だと「90000円相当」という
「破格の還元利回り」が作り出せます。

こんな事が出来るのはゲームアプリならではなので、やらない手は無いと思います。

更に、更に、
『株主優待専用ガチャ』を「パッケージガチャ」（1000枚入り）にして、
全てのガチャを回しきると「ラストワン賞」として特別なモンスター・アイテムが手に入る様にしておけば
1単元だと10年、10単元でも4年は、ホールドしないとコンプリート出来ないので
自然と「売り」の抑制にも繋がり、株価の安定にも一役かってくれるに違いありません。

そう考えると、良い事尽くめですよね。


・・・懸念点としては・・・

ゲームアプリの寿命は、だいたい3～4年なので
パッケージガチャのコンプリートする前にギリギリサービス終了を迎えてしまう恐れがあるのと
たとえ、サ終を免れても、10年後にはゲームのインフレで
「ラストワン賞」が魅力的なアイデムでは無くなってしまっている事でしょうか。
その頃には「ウルトラレア」や「ミラクルレア」や「レジェンドレア」が出てきているでしょうからね・・・

それも見越して、能力を高めに設定しておくのもアリかも知れませんが・・・
そうなると、ガチャチケットの交換コードを別の株主から譲り受けて
一年目でパッケージをコンプリートしてしまう猛者が表れたときに
ゲームバランスの崩壊にも繋がる恐れがあるので、その辺は慎重に検討する必要がありそうです。。。

やはり「ラストワン賞」のみインフレと同時に能力が上がる仕様にするのが無難でしょうか？
あとは「レジェンドレア」は解放条件が整わないと使えない設定にするとかでも良いですかね？

まあ、そんな感じで、
「株主優待ガチャチケット配布」
ゲームバランスに配慮さえすれば、ゲーム株の起死回生の一助になるのではないかと思います。

三次元における2点AB間の距離をPythonを使って求めよ

結論から申し上げますと
やっぱりAIは凄いな…という、お話です。

3DCG系のDCCツールを使用していると、
どうしてもオブジェクト同士の距離を求めるツールが必要な場面が出て来ますよね。

まあ↓この公式に当てはめれば三次元における2点間の距離出るのですけど、
√(xA−xB)^2+(yA−yB)^2+(zA−zB)^2

問題は…
これを、どうやってPythonで表してやればいいのか
さっぱり見当が付かないとういうところですね。

そもそも、ルート計算はどう表せば良いか解りませんし、
べき乗の計算も「^」をPythonは受け付けない様で、一体どうすれば良いのか
途方に暮れていた訳ですが…

ただ、これをChatGPTに聞いてみたら
一発で答えが出てしまいました！すごい！

Pythonでは
↓*を二つ重ねる事でべき乗計算を表して、
(xA-xB)**2

↓0.5でべき乗計算する事でルートを表すみたいです。
** 0.5

・・・なるほど！


という訳で、
Mayaで指定した二つのオブジェクトの距離を求めるスクリプトを書いてみました。

#三次元における2点AB間の距離を求める
def fFindDistance( vStart, vEnd ):
    lAp = cmds.xform(vStart,worldSpace=True,translation=True,q=True)
    lBp = cmds.xform(vEnd,worldSpace=True,translation=True,q=True)    
    oDistance = (lAp[0]-lBp[0])**2+(lAp[1]-lBp[1])**2+(lAp[2]-lBp[2])**2    
    return oDistance ** 0.5
fFindDistance( "locator1", "locator2" )

"locator1", "locator2" の名前を、
任意のオブジェクトの名前に変える事で距離を測る事が出来ます。