TOP

XEL3のＱ＆Ａはこちら　XEL3 DX 9 Q&A　XEL3 DX 11 Q&A
 
　
　
2023/06/20 XELPHI3 -Airlty ST/Ride-のWindows 11対応につきまして
 
　
 
　
XELPHI3のDirectX 9版 / 11版共に、Windows11が動作要件となっていませんでしたが、
この度、ゲーム単体での動作確認、並びに、
配布先（Digiket.com様）のシステムも対応可能である旨確認が取れました為、
上記２タイトルの動作環境にWindows 11を追加致しました。


 　
　 
　
　
2023/01/25 初代XELPHI、並びにXELPHI -Second Limit-の公開を終了致しました。
 
　
 
　
2022年11月12日に当サイトやTwitter上にて告知しておりました通り、
初代XELPHI、並びに、XELPHI -Second Limit-につきまして、
これら2作品の公開を停止させて戴きました。

予想以上に多数の方に永きに渡りご愛顧戴きまして、有難う御座いました。


先の告知にて記載させて戴いておりましたが、
今後この２作品につきましては、作品自体の無断配布・転載はもちろん、
作品の動作画面やマニュアルを撮影した画像や動画、音声類、
その他の二次的利用につきましても、今後は完全に禁止とさせて戴きます。

既に公開されている動画類につきましても、今後継続して公開されている場合、
削除等の対象とさせて戴きます。

以上、ご承知の程よろしくお願い致します。

 　
　 
　
　
2022/11/12 初代XELPHI、並びにXELPHI -Second Limit-の非公開化について
 
　
 
　
初代XELPHI、並びに、XELPHI -Second Limit-につきまして、
公開から約20年という月日が流れ、これら作品もかなり古い作品となった事もあり、
この度、これら2作品の公開を停止させて戴く事としました。

詳細な時期については不定とさせて戴きますが、
XELPHI -Second Limit-の初公開より20年後となる、2023年2月1日までには公開停止する予定です。

ですが、状況等次第ではそれ以前に、もしかすると明日にでも公開終了するかも知れませんので、ご承知おき戴ければと存じます。


つきまして、初代XELPHI、並びに、XELPHI -Second Limit-のゲームプレイ動画の投稿を解禁させて戴いておりましたが、
この投稿を持ちまして、以後、上記2作品の二次的利用（作品自体の複製、動画投稿等全て）を禁止とさせて戴きます。

以上、ご承知の程、よろしくお願い致します。

 　
　 
　
　
2020/11/21 ゲームのプレイ動画投稿についての規約変更について
 
　
 
　
ゲームの動画投稿に関する規約を変更しました。

初代XELPHI、並びに、XELPHI -Second Limit-に関しましては、ゲームのプレイ動画の投稿を解禁させて戴きます。

（但し、ゲーム内容を改変・改造等している物については、投稿は許可できません旨、ご了承下さい。）

投稿時には、可能な範囲でご連絡を戴けますと幸いです。

連絡先等、詳細は左側フレーム内「MAIL」内にて。
 　
　 
　
　
Twitter TimeLine
 
　
 
　
 　
　 
　
　
Twitter TimeLine
 
　
 
　
 　
　 
　
　
2018/03/30 MelonbooksでのXELPHI3 -Airlty ST/Ride- の公開停止について
 
　
 
　


Melonbooks側のシステム関係の理由により、2018/03/31を持ちまして、
同サイトでのXELPHI3 -Airlty ST/Ride-の公開を終了する事となりました。

DiGiketでの公開は今の所終了の予定はありません。


 　
　 
　
　
2016/11/20 XELPHI3 -Airlty ST/Ride- の隠し要素を公開しました。
 
　
 
　


XELPHI3 -Airlty ST/Ride-のDirectX 9/11とTest/Main Edition全てで共通の隠し要素を公開します。
内容については下記の動画にて。




 　
　 
　
　
2016/06/19 Xamarin.Formsの共通部（PCL側）でInitializeComponentがエラーになる件
 
　
 
　

Visual Studio上でXamarin.Formsの開発をしていて、結構なっている方が多いようなので、
気付いた点をシェアさせて戴きます。



先に結論から。

発生後の対処法ではなく、予防法になってしまいますが、こちらで発生している状況からすると、
Xamarin.FormsのNuGetパッケージのバージョンダウンは避けた方が良いかも知れません。



開発中になぜかいきなり、

「InitializeComponentという名前は存在しません」

とのエラー表示と共に、InitializeComponent()メソッド呼び出しに赤い波線の下線が引かれる事があります。


少なくともこちらの環境では共通部（PCL側）のNugetパッケージ内にある、
Xamarin.Formsコンポーネントのバージョンを下げると発生していて、
一度発生すると、元のバージョン「2.0.0.6482」に戻しても改善せず、
バージョンを「2.2.0.4-pre1」以上にする事で改善されています。

それ以前のバージョン（「2.1.0.6529」を含む、それより古いバージョン）では改善されませんでした。


最新のバージョンがインストールされている状況から少し前のバージョンに更新すると、
発生する事もあるようですが、詳細な発生条件までは特定し切れておらず、
バージョンを上げる分には、こちらでは今の所発生していませんので、
現状では、Xamarin.Formsのコンポーネントのバージョンをダウンする事が疑わしいかな？と思います。


こちらでは、環境が整って制作が始まった以降等、
バージョン（NuGetパッケージ）を変更しなくなると発生しなくなっている背景もあり、
Xamarinを触り始めた方に多く発生しているようでもあるので、
NuGetパッケージの変更に関連して発生しているのが疑わしいのかなーと睨んでいます。

現状では、なるべくバージョンダウンは避けた方が賢明かも知れません。


不確定部分も多く申し訳ない上に簡素ですが、参考になれば幸いです。



↓一応、以下に、こちらの環境で100%発生する方法を画像つきで


１：Visual Studioのメニュー－ファイル－新規作成－プロジェクトを選択し、
ウィザードより、Xamarin.Forms Portableのソリューションを作成します。
（この画像ではソリューション名「test」になっています。）





２：共通部（画像では「test(移植可能)」と表示されている箇所）で右クリック－追加－新しい項目を選択し、
共通部のXaml Page（画像ではCross-Platform内のForms Xaml Page、名前「Page1.cs」）を追加します。





３：当然作成直後ではエラーは出ていません。





４：共通部プロジェクトを右クリック－NuGetパッケージの管理を選択し、
初期でインストールされているXamarin.Formsのバージョン「2.0.0.6482」を、
１つ前の「1.5.2.6478-pre3」に更新（バージョンダウン）します。





５：バージョンダウン直後より、InitializeComponent()にエラーが表示されるようになりました。





６：この状態から、Xamarin.Formsのバージョンを「2.2.0.4-pre1」へ更新すると、
InitializeComponent()のエラーが消えるようになります。





 　
　 
　
　
2016/05/24 一応
 
　
 
　
習学を兼ねて、androidスマホ用の簡易アプリを作成してみました。

Twitterのアカウント不要で、各国各都市の最大数（約50件）のトレンドを表示します。

ウィジェット配置可能で、各ウィジェットは同時に複数配置、別設定可能です。

Twitterの公式アプリがトレンド少し見難いと感じたので作ってみました。

簡単にまとめると、自分用って事です。( ´-`)

（ダウンロードはこちらから）






 　
　 
　
　
2016/02/01 アップすんな言うの禁止
 
　
 
　
どーん。

リアル系のフリーモデルを見つけたので、うちのシステムで描画してみました。




 　
　 
　
　
2016/01/24 こっち見んな言うの禁止
 
　
 
　
以前から処理は書いてあったので、遊びで「こっちを見る」ようにしてみました。
最初の一枚はライトアップしてみた感じです。





 　
　 
　
　
2016/01/21 Wow!! Wow!!
 
　
 
　
眼を明るくしたり、髪の色を落ち着いた感じにしたり、
少しだけ変えてみました。





 　
　 
　
　
2016/01/20 Wow!!
 
　
 
　
フリーモデルでクオリティ高い物を見つけたので、うちのシステムで描画してみました。






 　
　 
　
　
2016/01/03 明けましておめでとう御座います。
 
　
 
　
明けましておめでとう御座います。
本年も宜しくお願い致します。


と、挨拶が終わった所で、いきなり簡単な概要説明に入りたいと思います。

DirectX12がリリースされましたけども、これといっためぼしい技術が無いみたいで、
（正確には、内部処理的な更新が多いみたいなので、ユーザーさんには分からない話かな、と思いまして。）
未だに、DirectX11のテッセレーションてなんぞや？て人も結構いるみたいなので、
少しでも理解出来る人が増えるように、画像を作って視覚的に概要等を。


テッセレーション（以下TSと略）とは、簡単に言うと、「シェーダーで処理する、ポリゴンを分割出来る技術」です。

実はTS自体は固定シェーダーなので、プログラム出来ません。
TSの手前で処理を行う「ハルシェーダー」と、TSの後ろにある「ドメインシェーダー」と言う、
２つのシェーダーに記載する事で、コントロールします。

ですが、ここではあくまで概要説明とし、書式や技術解説は省かせて戴きます。
（技術的な面については、他の方のサイトをご覧になった方が良いかと思いまして。）
又、細かい説明は他のサイト様へ委ねるとして、ここでは見た目で分かるように画像や動画で説明して行きたいと思います。


さて、TSってポリゴンの分割？それならモデリングの時点で分割すれば良いんじゃ？
もちろんそれでもOKです。
ただ、それだと、処理量が常時多くなってしまう為、PC負荷が常時高くなる可能性がありますよね？

例えば、カメラから遠くにあるキャラクター等は、小さく表示されるので、
ポリゴンを多くした所でつぶれてしまってほとんど見えなくなってしまい、
大量のポリゴンを処理しても、無駄になってしまいます。

そこで、TSを利用すると、元々のモデルはローポリゴンで作成しておいて、
カメラの近くにあるキャラクター等だけポリゴンを分割して細かく（ハイポリゴンに）し、
遠くの物はローポリゴンのままにする、等も可能になります。

この処理については、以前作成した↓の動画がそのままなので、
見て戴いた方が早いかと思います。





以下は画像を踏まえて、テッセレーションを利用した、ディスプレースメントマッピングの処理についてです。
ディスプレースメントマッピングとは、テクスチャ（良く利用されるのは法線マップと呼ばれるテクスチャ）の、
凹凸（法線マップの法線情報や、ハイトマップの高さ情報等が良く利用されます。）に応じて、
ポリゴンの頂点を移動させる処理方法です。



↓まずはこれが元の状態。


↓ディスプレースメントマッピング処理でアスファルトみたいな床を移動。
変化が分かりにくいですが、岩みたいな部分との境目を見ると少しだけ変化が出ています。


↓分かりにくいので最初の状態をワイヤーフレーム表示。


↓ディスプレースメントマッピング後のワイヤー表示。
床が変形していますが、頂点数が少ない為、結果的に変化が滑らかになってしまっています。


↓では、まずTSで頂点を増やして行きましょう。まずは少しだけ・・・。


↓徐々に増やします。増えた状態を連続画像でお見せします。






↑ここまで見て、多分予想外の分割のされ方だったと思います。
分割方法は複数あるので、これだけではないのですが、ここでは割愛させて戴きます。


↓分割後のポリゴン（テクスチャ含む）表示。
テクスチャ（のUV座標等）もちゃんと分割されている（正確にはされるようにシェーダーを書いてある）ので、
表面の見た目は元の状態と同じように見えます。


↓更に続けて分割行きます。





↑かなりポリゴン数が増えました。
この状態でディスプレースメントマッピングをもう一度行ってみます。


↓少し見えにくいですが、頂点数が増えたので、変化が細かくなっています。


↓視点を床付近へ移動。


↓凹凸の変化量を増やしました。


↓TS＋ディスプレースメントマッピング後のワイヤフレーム表示。


↓ワイヤーフレーム表示の状態で、視点を床付近へ移動。



細かく言葉で説明するより判り易いかな、と思いましたので、このような形式で以て、
概要説明とさせて戴きます。

以上で御座います。（かしこ



 　
　 
　
　
2015/12/29 統合
 
　
 
　
何気に結構手こずったのですが、ようやっと太陽の描画が出来ました。
IBLに太陽を書き込む形式にしようか試行錯誤しましたが、最終的に太陽は例外で別処理する事にしました。

さて、これで、太陽の光だけ調節すれば、
光の反射を勝手に全オブジェクトに光の反射計算してくれるような統合的なシステムな感じになって来ました。
まだ調整等は行うと思いますが、描画関係は安定して来たので、
平行してゲーム内容に関する作業も始めている感じです。



↓太陽光が強い状態で。光が雲を突き抜けている感じになっています。



↓上の画像と似たような位置で、太陽光を少し弱めに。雲に太陽光が遮られてる感じに



 　
　 
　
　
2015/12/27 年の瀬ですねぇ。
 
　
 
　
なんかしっくり来なかったので、計算式変えてみたら、ちょっとメリハリついたかなー。





 　
　 
　
　
2015/12/20 めりくり
 
　
 
　
大急ぎでクリスマスツリー作ってみたものの、ツリーの輪郭分からなくなってしまいま。

ライトが動いてる感じのテストを兼ねていたりなんてしません！しませんから！

本当はモーションでライトを色々動かそうと思ってたけど、面倒で止めたなんて事もないから！






 　
　 
　
　
2015/12/17 フォグフォグ☆彡
 
　
 
　
はいはい、フォグフォグ。
遠くがあんま見えないね。
はい、終わり。
（↑使いそうだから実装したけど、あんまり興味ない奴


↓「遠方に未確認機確認も視界不良にて詳細不明！これより調査に入ります！」みたいなシチュ。



↓カメラのピントの差異のSS上げてなかったので、一応。
奥の青い塔の足元辺りにピントが合っている状態。


↓カメラの注視点がカメラの目の前にある状態。
SS撮りませんでしたが、ピントが合う（ピンぼけが出ない）範囲も変えられます。



 　
　 
　
　
2015/12/16 ボケボケ☆彡
 
　
 
　
XEL3でも（途中のバージョンから）実装していました、被写界深度の処理を追加
処理負荷を増やさない範囲で、より自然に見えるように少し工夫してみました。
又、今回は焦点情報も加えてみた（適当処理ですが）ので、カメラのズームイン・アウトの表現が出来ます。

グレアの処理を交えると、ちょっと雰囲気出て来た感じがします・・・しません？



↓遠くの物がボヤけて見える感じです。


↓近くのオブジェクトははっきり。（グレアのせいで少しボケた感じに見えますけども。）



 　
　 
　
　
2015/12/15 キラキラ☆彡
 
　
 
　
前回追加したぼやけた画像を流用して、特に変哲の無いグレア処理入れてみました。

光の回折と言うよりは、レンズや網膜での正反射でない光のエミュレートになるんすかねー。（←ちゃんと計算してない事バレバレ
一応映り込みの光が強ければ、それに対してもグレアが掛かってます。

やっぱりこの処理が入ると、派手と言うか艶やかと言うか華やかと言うか輝いていると言うか素敵と言うかテロテローンて言うか煌びやかと言うか光輝的と言うか、そんな感じになります。


↓判り易くする為に、ちょいと強めにグレア。少し幻想的な感じに。


↓強さ調整可能にしたので、比較用にグレア無し。やっぱりちょっと寂しい感じ。





 　
　 
　
　
2015/12/14 迂回。
 
　
 
　
レイトレーシングのように、レイを多数飛ばして乱反射をエミュレートする方法は、
処理負荷的に余りにも実用的でない為、迂回手段としてぼかしたIBL画像を用意し、
ラフネスが粗い時には、そちらを参照する方法を試してみました。

見た目だけで見たら、レイ飛ばしまくりには敵わないですけど、
処理速度と見た目のバランス的に、これで行こうかなーと思います。
ぼやけた画像は他の処理でも使いまわせそうですし。（と言うか、使う予定アリ。）


（レイ飛ばしまくり乱反射の処理は、まだ残したままにしてあるけどね。（ﾎﾞｿｯ））



↓太陽出ていない早朝くらいのイメージで映り込み。


↓少し表面を粗くしたイメージ。


↓更に粗く。だいぶ映り込みがボヤけて来ました。


↓更に粗く。原型が分からなくなって来ました。


↓更に粗く。もう何が何やら。


↓更に粗く。マリモみたいになりましたけど？（←聞かれても知るかって話



 　
　 
　
　
2015/12/10 販売委託について。
 
　
 
　
大変申し訳御座いません。
真に勝手ながら、諸事情により、DL.Getchu.comでの販売委託を停止させて戴きました。

現状では他の委託先での販売は継続しております。
（現時点では特に停止する予定は御座いません。）

何卒ご理解の程、宜しくお願い申し上げます。



 　
　 
　
　
2015/12/07 確認終わって安心して忘れてた。
 
　
 
　
XEL3のWindows10対応ですが、プロテクトの関係で委託先毎に対応しているかが変わります。
販売委託先に問い合わせた所、まだ対応確認が取れていないとの事でした。
今後対応確認が取れ次第アナウンスされるとの事。


後、一応、左のメニューの所に、ツイのリンクも加えておきました。
今までほとんど使っていませんでしたが・・・。





 　
　 
　
　
2015/12/06 問題は乱反射。
 
　
 
　
簡単に言うと、カメラからレイ（視線の先へ光線）を飛ばして物体に当たったら、
反射した先にある物体の光を得る、と言った流れの処理になっていますが、
（実際の処理的流れはもっと違うのですが、説明しにくいので、大まかにこんな感じだと言う事で。）
現在のCG技術で問題になる事が多いのではないかと思いますが、
物体に当たった際の乱反射があって、当然こちらでも色々頭悩ませている状態です。

複数回反射の大がかりな変更するかどうかの前に、比較的簡単に実装出来る内容でしたし、
反射計算がちゃんと出来ていないと、反射の回数が増える度に誤差でひどい事になると思うので、
とりあえず乱反射の処理を追加してみました。

カメラから見たレイが物体に行き当たり、その物体が乱反射する材質だった場合に、
その地点から更に乱反射的に無数のレイを飛ばして、その先に物体があるかを取得すると言う、
力技と言うか、より現実的と言うか、そんな処理になります。


とりあえず、実装してみましたが、暫くグラボを新調していないので非力なのもありますが、
まともな感じの見た目になるくらいの数のレイを飛ばすと、処理負荷的にまともに動きませんね、コレ・・・。(^^;

ラフネス（物体表面の粗さ）が滑らかであれば、乱反射先の範囲（ステラジアン）が小さいので、
同じ数のレイを飛ばしても、結果的に密度が高くなるのでより精度が高くなるかと思いますが、
ラフネス粗い物体だと、かなりの数のレイが必要になっちゃいますね。

しかし、この処理を必要としているのは、表面粗い物質だと言うジレンマ的なものもありますし。

この処理負荷見ると、光源の数だけBRDF計算する方が現実的かなぁ・・・。


とりあえず処理は実装したままで、設定で元の処理レベルに戻せるように、
ユーザーでも変更出来るような形にしておいたので、
制作状況に合わせてどうするか決める事にしようかな・・・。


それとも開き直って、色々な技術突っ込みまくって、
現在のハイエンドグラボでもまともに動かないくらいにしちゃおうかな・・・（←悪魔の囁き

それにしても、見た目の処理って、いじってるといくらでも手を掛けられてしまって止まらないっす。



↓まずは乱反射で飛ばすレイが1本だけの状態。
車体や球は乱反射ほぼしないメタリックな素材なので、レイの数の影響はほぼありませんが、
乱反射すべき女性の服や肌が、メタリックな物質みたいになってしまっています。



↓レイを16本に増量。女性がまだメタルメタルしていますね。
床が少し乱反射するので、結果的に反射している範囲が広くなっています。
（範囲が広がったのに明るさが暗くなっていないので、BRDF的にちゃんとしていませんけども。）



↓レイを64本に増量。少し全体的になじんだ感じと言うか、安定した感じになって来ました。



↓レイを128本に増量。だいぶ見れるくらいになって来ました。
しかし、FPS表示忘れていましたが、フレームレートひどい状態です。



↓レイを256本に増量。ここまで来れば使えるかな？と言う安定度合かなー。
しかし、シェーダー最適化出来てないのも手伝って、もうまともに操作出来ないレベル・・・。



↓特に意味のない画像ですが、なんとなく髪の質感がディ○ニーっぽいなーって。
床での光の反射も、乱反射でかなり広がっている感じになっていますね。



↓モデルがミクさんでレイ16本。髪は乱反射少ないメタリックな感じの物質設定です。
服が乱反射かなりする物質設定で、真後、右後、左後に光源となる青い塔があります。



↓レイ64本。



↓レイ256本。だいぶ安定。
左の袖辺りを見ると、なんとなく左後ろと真後ろに光源があるように感じられなくもないかな？
首の辺りは立体感が出た気がします。



↓レイ1本で、服が乱反射処理を全くしない物質設定に、物凄い適当な処理で誤魔化した場合。
後ろから照らされてる感じが全くなくなってしまいました。
でも、処理負荷的には、実用レベルはこれくらいかなぁ・・・。



 　
　 
　
　
2015/12/04 とりあえず暫定処理変更で2回反射。
 
　
 
　
とりあえず簡単に処理変更出来る範囲で、2回反射を試してみました。
あくまで簡単に変更しただけなので、背景の光源だけを2回拾ってるだけですけど、
並べてみると、結構印象違ってみえるものだなー、と。

大がかりな処理変更すれば、光源2つ同士での相互反射なんかも出来ると思うのですが、
変えてしまっただけで処理量増大が確定してしまうので、どうするか悩んでます。

そこまで行くと、ほんとレイトレーシングに近いよなぁ。
パストレーシングなんてのも出て来てるし、やっちゃおうかなぁ。

処理量増やしていいなら、追加したい処理はまだ他にもあるんですよねー・・・。
うーん、悩みます。


↓浮いてる光源が地面に反射し、その反射が車体や球で更に反射しています。


↓1回反射だけの場合。並べて比べると、思ったより暗い部分が多いです。









 　
　 
　
　
2015/12/03 実はですね・・・。
 
　
 
　
IBLで多数光源設置しても、処理負荷がほぼ変わらない（オブジェクトを数の分だけレンダリングする負荷だけ）事の確認と、
問題点の洗い出しを兼ねて、光源となる物体を30～40個ほど設置してみました。

そしてこれが出来てしまうと、16bit浮動小数型での情報保存が可能な事と併せて、
「光源が全く要らなくなってしまう。」と言う事が可能となりそうな状況で御座います。

16bit情報で、強い光の情報が保持出来る事によって、
わざわざ太陽を別計算で行わなくとも、IBLに強い光の太陽を書き込んでおけば、
システムが勝手に、太陽光を拾い上げて描画してくれるんですよねぇ・・・。

実は、光源やライトと呼ばれる概念・考え方が昔からあまり好きじゃなくて、
それらを排除出来るのは、実は個人的な理想であったのですが、
いざ、それが出来そうになっても、躊躇してしまう小心者で御座いますｗ


多数光源設置に関しては、静止画だと分かりにくいかと思って、
動画をしたためてみましたが、見事なエンコ殺しで見難くなってしまいました・・・。orz
かしこ。





↓せっかくなので、色とりどりに100個くらい光源置いてみました。
ちょっとファンシー過ぎる絵に・・・。(^^;







 　
　 
　
　
2015/12/03 間接光
 
　
 
　

※注　画像が大量にありますが、前半は暗い画像ばかりです。明るい画像は後半にて。


以前からずっとやりたかった処理があって、その為に必要な処理が多数ある事に気づき、
回り道的に色々な処理を追加し続けて調整して来た経緯なのですが、
ようやっと、それらしい処理が出来ました。


と、言う事で、IBL（イメージベースドライティング）を基底とした、間接光です。
グローバルイルミネーション的な処理になると思います。
（複数回の反射は今の所処理していませんけども、やろうと思えば出来ます、多分…。）


太陽や電球等の光源があると仮定して、その光源がどれだけの光を放っているか、
その光を受けた物体がどれだけ光を反射するか、を計算するのがごく一般的かと思います。

ですが、その手法では、光源の数が増えれば増える程、計算量が増える事になってしまいます。
それをなんとか解決したいと思っていました。

現状では、唯一の光源と言える物は太陽だけで、その光を直接受けた計算は行っていますが、
それ以外は光源を一切設置していません。ただ、明るい物を置いてあるだけです。
「ある物体に視線を落とした時に、近くにあった明るい物の光が入り込んできた。」と言うのを、
IBLによる光の反射計算として勝手にやって貰うようにしているだけです。
（処理負荷と相談しながら、今後別の光源を追加するかも知れませんけれども。）
実は、最近アップしていた画像は全部この手法で描かれています。
直接当たっている光は太陽のみで、それ以外はほとんどが、反射した光を勝手にシステムが拾っているだけです。

説明しにくいですが、カメラから見て、物体の表面で反射した先にある物の、
明るさ（物体が反射した光）を、カメラまで届かせている形の処理になるので、
考え方的には、レイトレーシングに非常に近いと思います。

ただ、レイトレーシングは、実際にカメラからレイを飛ばして、
全物体と当たり判定を取るのが基本になると思いますので、
物体の数が増えると処理量が増えてしまうのがネックです。

ですが、この処理では、光の反射回数だけ物体を描画すれば済む事になるので、
反射一回だけでしたら、反射計算用の描画は一回で済む事になるので、コストが比較的低く済みます。
CPUで当たり判定しなくて済む代わりに、GPUの負荷が増える事になる形かと思いますので、
GPU負荷はかなりのものになると思いますが…。
（GPGPUで当たり判定演算やっているならまた違いますけども。）

光源からの光を受けて、その光を反射した物体があるなら、それも光源になるわけで、
それらを反映する手法として実装してみましたが、やってみた後に、
もう簡易レイトレーシングと言って良いくらいの処理なんだなぁ、と。


そんな感じで、試作の処理でもあるので、今後変更・廃止する可能性もありますが…。(^^;


いやー、やりたかった処理が形になって、嬉しい限りで御座いますうううううううううううう。
いやっしゃあああああああああああああああああああああああ。



↓薄暗い中で、建物だけが自己照明的に明るい状態を作ってみました。
明るい建物が、地面や車体等に投光している形になっています。
ちゃんと計算していませんけど、建物が放っている光は、多分1000～2000ルクスくらいになるのかな？
あ、後、背景→車等のオブジェクトへの間接光は反映していますが、
オブジェクト→背景への間接光は反映していません。

（これらの画像では、判り易くする為に建物自体が光を発している形ですが、）
（光源からの光が建物に当たっても同じような見え方になります。）
（但し、その場合は、光源の光が他の物体にも当たって光る事になるので、間接光が目立たないと思いますが。）



↓より判り易くする為に、上の画像と似たような位置で、建物の自己照明以外の光源を完全になくしてみました。
これらの画像の中で、真っ暗でない部分は全て、建物自身の明るさだけで見えています。



↓ビル「アイアムレッドサイク○ン！」
（建物が赤い光を放っている場合）



↓光源となっているビルを５棟に増量
（もちろん今ならお値段据え置き）
光源となるような物体を増やしても、全く処理量が増えません。
見た目的にも、良い感じかな？実用に耐えるかな？



↓通常使用するテクスチャはRGBA各色に8bitずつ（整数型が）割り当てられていますが、
それでは各色256段階しか情報が保持されない為、256段階を超えるような強い光の情報が保持出来ません。
そこで、暫定的に16bitの浮動小数型に変更して、256を超えた強い光を設定出来るようにし、
ビルの発光をかなり強めにしてみました。（計算してませんが、多分10000～30000ルクスくらいになるのかな？）
（最終的な描画で8bitに丸められますし、強すぎる光はただの白になりますけども。）



↓この処理の弱点としては、画面に見えている物体の、
カメラから見て背面側の情報がなくなっている為、その分の光が反映されない事です。
これらの画像で言う、向かって一番奥の壁が暗い理由がそれになると思います。
（正面なので、フレネル反射で反射率低めなのも相まってるのもあると思いますけれど。）
ただ、良くある手法としては、奥側をフォグ等で濁して誤魔化す方法もあるかな、と。(^^;



↓これだけでも少し絵になっている感すらあるので、実用まで行きたい所です。
IBL用に使用しているバッファは、大きな物にしても見た目に出る影響が小さめな為、
元々小さいサイズで使用していて、そこだけ16bit浮動小数型にすれば事足りるので、
それ程使用メモリが大きくなるわけではなかったりしますし。



↓16bit情報にて描画するように処理変更し、朝方くらいの明るさ＋ビル照明で描画。
ユーザーが設定で8と16bitを選べるような処理に出来ました。


↓比較用に8bit情報にて描画。明るさ情報が失われて、地面への映り込みが少し暗くなっています。
ビルの明るさがそれ程でもないので差が分かりにくいですね、失礼しました…。orz



↓色を変えたら、一気に遊園地や繁華街風味に。
明るい部分をフレア処理等したら、見映えが良くなりそうです。



↓奥の壁に光届かないのが気になるなら、壁をなくせばいいじゃない！＞＜



 　
　 
　
　
2015/12/02 ルクス
 
　
 
　
光学計算やり始めた頃から意識するよう（と言うよりはせざるを得ないと言うか）になった、「光の強さ」。

古いCGの考え方やPC内部処理ではRGB（赤緑青）の光の三原色の強さ等で光の強さを表していますが、
光学計算をベースに写実的な表現をしようと思うと、どうしてもそれだけでは何か足りない感がありました。

そこで、より写実的にしたいなら、現実世界の数値を使えば良いじゃないか、と、当然のように行きつくわけで。

で、現実世界で使用されている光の強さである「ルクス」を参照してみようという事に。


材質設定を変更する事が非常に多くなったので、以前から使用していたモーションエディターで、
材質設定直接変更出来るようにしたので、AKSR制作統合環境っぽくなってしまいました。(^^;

あ、ディフューズとかスペキュラ設定出来るっぽく見えますが、
面倒なのでその表示にしているだけで、各項目の数字は、全く違う事に使用していたりします。

DirectXの古いモデル（Xファイル）形式を変換して独自形式にしている関係から、
Xファイル形式で使用されていたパラメータを流用している関係でそのようになっております。


いやあああああああ、ようやっと安定したわあああああああ、うれしいわあああああ。
これで地盤部分は出来て来たので、ゲーム内容制作中心の作業へ移れそうです。



↓晴れた午前中くらい？の明るさ（80000ルクス程度）を想定した場合。（太陽の位置が高め）


↓朝方くらい？の明るさ（8000ルクス程度）を想定した場合。（太陽の位置が低め）


↓夕方くらい？の明るさ（ちゃんと計算していませんが4000ルクス程度かな？）を想定した場合。（太陽の位置が低め）



↓元モーションエディター（現：AKSR制作統合環境）


 　
　 
　
　
2015/12/01 地盤
 
　
 
　
光学計算に納得が行かなくて、色々試していたのですが、
ようやく、これかああああああああ！と言う感じになって来ました。
（式変えてから材質変えてないので、おかしな感じの部分ありますが。）

ある計算式をベースに、アレンジを加えたりしていたのですが、
どう変形したりしても破綻しているようにしか思えず、
１から全部詳細洗い出してみたら、ベースにしていた計算式がおかしかったという…。orz
そして、そこを直してみた所、あぁ、これかぁぁぁ、と言った次第。

なんて言ってたら、ただの勘違いで、全部またやり直しなんて良くある話ですけどね…。


ちなみに、↓の画像の女の人は、フリーモデルお借りしたのですが、
なんか顔がすっげー怖く見えてしまったので、ちょいとデュラハン。



 　
　 
　
　
2015/11/24 安住の地を求めて
 
　
 
　
試行錯誤が続きます。



 　
　 
　
　
2015/11/19 ちょっとずつ　その２
 
　
 
　
ふっ、俺は影の世界の住人なのさ。（←そのまま黙って部屋に引き籠る

おい、中二病の上に引き籠りかよ！
と言うセルフ突っ込みから始めさせて戴きましたが、皆さんいかがお過ごしでしょうか。

と言う事で、影の処理の見直しなんぞを。


XEL3の時にも実装していましたけども、
カメラの角度なんかでちょっと不安定な感じになってしまっていたり、
メモリ使用量の割に、効果がイマイチだったりしたので、改良したいとは思っていました。

XEL3よりも、処理負荷を下げた上に、メモリ（VRAM）使用量減らしつつ、
見た目の安定性を上げられそうな処理を思いついたので、実装してみました。

うーん、まだ課題はあるけど、XEL3より全然良くなったかな。
なんとかカスケード2枚だけでやりくりして、なるべくジャギを軽減出来るようにしてみました。

ソフトシャドウになるようにしていますが、分散（バリアンス）シャドウマップは使ってなくて、
オリジナルの評価基準でやってみています。

分散シャドウも考えたのですが、あの処理だと、
評価値を一旦保持する形？になって、メモリ使用量増えそうなのと、
影のない部分も全て処理する事になってしまうかなーと。
（良く理解してない＆処理方法知らないだけで、もっと良い処理方法があるかも知れませんが。）

こちらの処理では、影となると判定された時のみソフトシャドウの処理を入れて、
全体の処理負荷軽減を目指してみました。


誤判定出てしまっているけど、もう１つ判断基準加えたらイケそうかなぁ…？
ちょっと評価基準を考えてみよう…。


↓遠方用のシャドウで描画されている為、粗い影になっている。
（車の下の影が判り易いと思います。）


↓カメラが近づき、近景用のシャドウで描画され、ディテールが細かくなった。


↓影に使用する解像度が2048×2048（カスケードでそれを2枚使用）
（ミクさんの足元の影が判り易いと思います。）


↓影に使用する解像度が4096×4096（カスケードでそれを2枚使用）


↓影に使用する解像度が8192×8192（カスケードでそれを2枚使用）



 　
　 
　
　
2015/11/19 ちょっとずつ
 
　
 
　
ゴムゴムのーーー！ゴム！

おいそれ、ただのゴムやろ！
と言うセルフ突っ込みから始めさせて戴きましたが、皆さんいかがお過ごしでしょうか。

と言う事で、ゴム感を出せるように試行錯誤してみました。

とは言っても、計算式の範疇で材質設定変えてみただけなんですけども。

周りの光の状態によっても、見る角度によっても、見た目が安定してる感じなので、
まぁそれなりの及第点？なのかなー。

XEL3の時にも色々やってみてましたけど、計算式変わったので、ちょっとはマシになったかな。

使わせて貰っているフリーのモデルに、タイヤの溝がついてなくて、
すんごい適当にやっつけで溝つけただけの物で試してみてる状態なので、
溝が横まで来てたり、均等についてなかったりするのは気にしない方向でっ。

もうちょっと灰色っぽい感じでも良いかも知れないけど、
そこはアルベド変えれば大丈夫だろうから、良しとしておこう。



 　
　 
　
　
2015/11/18 ちょっとこじゃれました。
 
　
 
　
という事で、イメージベースライティング（IBL）の処理をちゃんと書いてみました。
光学計算の方もかなり見直す必要が分かって、色々大変でしたけども…。(^^;

似たような画像が2枚ずつあるのは、周りを壁が囲っているような閉鎖的な場所と、
周りの壁がない、オープンスペース的な場所との対比用です。

車の車体等は、周りの壁の影響を受けて、見た目がかなり変わっているのに対し、
ミクさんはあまり影響を受けずにいる感じになっておられます。（尊敬語


IBLは環境マッピングとほぼ同じような考え方の処理ですが、
物理ベースレンダリング、BRDFなんかだと、IBLて呼ばれるみたいな感じでおられます。（尊敬語その2

テストで作ったロボのモデルも出してみましたけど、
テストモデルのクセにパーツ数が多く、材質設定面倒過ぎてかなり適当な上に、
デザイン自体もひどいので、色々と残念な出来栄えとなっておられます。（尊敬語その3







 　
　 
　
　
2015/11/08 気付いてなかったとか。
 
　
 
　
なんか発色が悪いなーと思ってたら、
設定パラメータ１つ分、まるっと計算式から抜けてた事に気づきました。orz

計算に追加したら、明るい印象になりましたとさ。


それにしても、光学計算やってみると、太陽って本当に明るいんだと言う事が改めて分かりました。
ちょっと明るくし過ぎて、白飛びしちゃってる感じですけども。
HDRの処理入れれば良いのでしょうけど、個人的にあの処理あまり好みじゃないんですよねぇ…。(^^;


あ、もちろんクイックヒントの表示なんて気のせいです。




 　
　 
　
　
2015/11/07 やっぱり引き締まる感じが違いますね。
 
　
 
　
なんか物足りない感があったので、影を付けてみたら、
やっぱり引き締まり感が違いますね。
立体感が出ると言うか。

こっちの方がキュート度合が上がる不思議。



 　
　 
　
　
2015/11/07 材質色々。
 
　
 
　
色々な材質テストちう。

↓ノーマル


↓もこもこ。
袖の部分が気持ち悪い感じだけど、胴体部分はセーターっぽい？


↓縦縞もこもこ


↓テカテカ。
シルクっぽいイメージ？


↓さらにテカテカ。
ビニールとかプラスチックっぽいイメージ？


↓家の外壁みたいに…。


↓外壁アップ


↓胴体部分が布っぽい場合


↓胴体部分が金属っぽい場合


 　
　 
　
　
2015/11/06 柔らかい表現って難しい…。
 
　
 
　
前回、背後霊みたいな扱いで申し訳なかったですが、
表示テストでモデルをお借りして、人物系の表示の課題解決を試み。

と、言う事で、初音ミクさんのモデルをお借りしました。

やっつけでこちらのシステム用にデータを変換したりした関係もあって、
ポリゴンが突き抜けてしまっていたりして、
ファンの方のイメージ崩してしまったらごめんなさい。
こちらのシステム専用に作られたモデルではなく、
あくまで簡易テストレベルで使わせて貰っているだけですので、
ご容赦をば。m(-_- )m

洋服のモコモコ感と、腕輪？の金属感はまぁまぁ使えないレベルではないかなぁ、としても、
肌の感じがちょっと無機質に見えてしまうので、改善したい所。
人物表現あまり使わないと思うので、ファーシェーダーは今の所書かないつもりですけど。
やっぱり、皮膚下の散乱で、光に血液の色がつくのを再現しないと駄目かなー。
あ、髪の毛はわざとくすんだ金属っぽい材質で試してます。
（感覚的には、プラスチックくらいの材質になるのかな？）


思っていたよりはひどくなかったので、
ちょっとだけ安心していたのですが、
丸い感じと言うか柔らかい感じの表現を、
計算で出すのって、本当に難しいと痛感しました。


これでも少し肌荒れてる感じの材質指定してるけど、
こうやって見るとほとんど分からないので、人肌感出すには、
もっと大袈裟にやらないと駄目そうです。

今の所、人物表現はそれほど重要ではない（使用しない）と思うので、
技術的な部分と処理負荷と見た目を天秤に掛けて試行錯誤です。




↓やっつけで、肌荒れを少し大袈裟にしてみた。
目が粗いので、近づくとひどいですが、細かくすれば、まぁまぁになりそうかなー。


↓後ろから見ると、髪の毛テカり過ぎですね。
そーゆー材質にしてるからなのですが。
服とか肌ののっぺり感をなくしたいけど、
芝の色はそれなりに見えなくもないから、
及第点と言えなくもないのかなぁ、難しいです。


↓逆光っぽい感じにしてみました。
影の処理（シェーディング・陰面処理ではなく、シャドウイング・投影処理の方）をしていないので、
本来影になる部分で、エッジが浮き出てしまっておかしな感じの所がありますね。


 　
　 
　
　
2015/11/04 これでもかといじくりまくる。
 
　
 
　
BRDFでマイクロファセットで幾何学減衰で分布関数でフレネルです。
光とは世界中から降り注いでいると言う事に気付きました。


何語しゃべってんだって話ですね。
まぁ細かい事は気にしない気にしない。
だいぶ怪しい世界に首突っ込んでるんだなぁと、憐れんであげて下さい。


何？初音○クみたいな背後霊が見える？
選択された行をコメントアウト？って何だ？

全て気のせいだ、気のせい。




 　
　 
　
　
2015/10/26 一体どうしてくれると言うのかね。
 
　
 
　
「さて、とりあえず暫定で空と機体の描画が出来たから、」
「映り込みのテストの為にも、雲の専用処理を気合い入れて書くぞー！」

（※ちょっとだけ処理書いて、それを試してる間にふと思いつく※）

「え・・・あ・・・いや・・・ちょっと待てよ・・・。」
「雲の処理って何だ・・・？」
「そんなの必要なくなったんじゃ・・・。」

現状、光学計算をベースにして描画（インチキ物理ベースレンダリング）を行うようにしているので、
車を描画している処理ほとんどそのままで雲も描けてしまうのではと思いつき、
雲の材質を設定して、厚みの情報を処理する所だけ付け加えてみた所・・・。

「うあ・・・もっとダメかと思ってたのに、思ったよりイケてる・・・。orz」
「ずっと雲の処理書きたかったのに、要らなくなるやんじゃないでござる・・・。」
（↑気合い入れてやろうと思ってたのに、やる事ほとんどなくなって錯乱中


と、言う事で、車と雲をほぼ同じ処理で描画してみた次第。
めでたしめでたし。


（前回いきなり動画作ったのは、このせいで時間が空いたからだったり。）


基本的に広いオープンスペースな場所が好みなのもあって、
前々からその表現はしっかりやりたいと考えていたので、
お外の表現で重要となる、雲の専用処理は書きたかったんですけどねー。(^^;
まだ薄っぺらい感がどうしても出てしまっていて、
何かひねりを加えようとは思ってますので、別処理も書きたい所。







↓上の画像の状態から、雲の厚さを半分にしてみました。


↓上の画像の状態から、更に雲の厚さを半分に（以下略
雲の向こう側の空が透けて見えて来ました。


↓上の画像の状態から、更にくｍ（略
雲の向こう側の空がかなり見えています。


↓上のがｚ（ｒｙ
雲が消えそうなくらい薄くなりました。


↓（ｒ
雲も画像も消えました。
（※画像ｒｙ）

 　
　

TOP

inserted by FC2 system