HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2022
0213
アキアキノヒロロ[hging4] 列車用の物理挙動用ノードについて12解決


アキアキノヒロロ

リンク

2022/2/13(Sun) 00:02:39|NO.95399

[hging4]で物理挙動を利用するには、以前は単純に、[getpos]可能な、[gpbox]での[box]を物理挙動用ノードとするしかありませんでした。
〓通りすがり さん〓
http://hsp.tv/play/pforum.php?mode=pastwch&num=84957#84965

しかし、〓hashikemu さん〓の情報提供によって、ノードを[FBXエクスポート]時に、[FBX単位スケール]で行ない、
[gpload]で3パラメータ目にオブジェクト名を入れることで、[getpos]可能になることが分かり、[gpbox]での[box]だけでなく、
ローポリノードを物理挙動用ノードに使えるようになりました。
https://hsp.tv/play/pforum.php?mode=all&num=92295#92410
https://twitter.com/kemuduino/status/1481971954865573897

これで、〓youdai さん〓がおっしゃるように
現状、「物理挙動用ノードは当たり判定用のローポリ、実際の見た目のノードは所謂普通のポリゴン」という組み合わせで行くことになります。
https://hsp.tv/play/pforum.php?mode=all&num=92411
ただし、[FBX単位スケール]でのエクスポートなので、他の全てのノードのサイズを、
この物理挙動用ノードのサイズに合わせてきめていくことが、限定条件となります。

また、〓youdai さん〓の、ここでの要望に対する、おにたまさんの返答が頂けていないようです。

それと別スレではありますが、GPBモデルの中のオブジェクトに関係してきそうなこととして、
〓ひつじ さん〓が、親子関係の設定に関する質問をされていますが、反応がないようです。
http://hsp.tv/play/pforum.php?mode=all&num=95343


私は、これら、皆さんの知見を頼りにするしかないものです。
前置きが長くなりましたが、そこで、質問です。

箱長な乗り物(車輌)が、カーブ軌道をそれらしく曲がれる移動用のノードを作りたい。
車輌の前部後部にある台車の車輪がレールに乗っている(各台車の中心が軌道中央)状態でカーブを曲がるようにするには、
その車輌ノードのための物理挙動用ノードは、どのようなものにすればいいのか。

連結車輌を、連結状態維持のまま、軌道に沿って移動させたい。
何両もの車輌を連結した編成列車を走らせるには、その車輌ノードのためのそれぞれの物理挙動用ノード同士は、
どんな関係で動かせばいいのか。


このことに関して、色々と実験をしてみましたが、うまくいきません。
私のツイッター
https://twitter.com/akiakinohiroro


オブジェクト名を指定したそのオブジェクトのみが物理挙動の対象になるため、2つある台車位置用の物理挙動用ノードを同時に指定できません。
また、その2つのオブジェクトを合成して、1つのオブジェクトとすると、そのもとのオブジェクト間の空間も物理挙動用ノードとしてのサイズ空間となってしまい、
カーブで車輪がレールから外れ、脱線してしまいます。

,里海箸北椶鬚弔屬辰燭箸靴討癲△泙燭篭法甲擦ぜ幎(トロッコのような)を想定したとしても、車輌を連結した状態の列車を動かす方法が考えつきません。
以前考えだした、ゾロゾロ関数なるものを使っても、連結状態を保ち続けることが出来ません。

これらのことを質問するのは、まるで、プログラムの根幹になるようなアイデアを考えてくれ、と丸投げしているようで、反則技にも思え、申し訳ないですが、
何か、お知恵を拝借できないでしょうか。



この記事に返信する


zrs90(5さい)

リンク

2022/2/16(Wed) 11:27:39|NO.95434

blender ジェットコースター
...で検索、気になった物を
いくつか拾ってみました。

検索トップの外国人の方が
作った物の方が、本格的なんですが...
特殊なアドイン?を使ったり
(※この点は、どの製作物も同じと思います)
当然、実況も英語です。


blender ジェットコースター テストYouTube · OHMIYA WORLD2017/05/14

↑は、個人的に、制作過程が
あるなら、一番見たかった動画。
この方の情報は、見つかってません。
結構捜したんですが。


https://kuraudo.hatenablog.jp/entry/2019/01/07/203431

↑ 簡易コース線路状の
制作方法とトロッコ(完成品)


http://quunee.blog.fc2.com/blog-entry-59.html

https://site-builder.wiki/posts/22355

↑簡易コースの制作方法と
動作ムービー 下の方は
多分、上のリンクを
含んでますが
英語の資料?が多く
全く分からないので、触らず
読み飛ばしてます。


【物理エンジン】回転部の一部が切れたジェットコースターは滑ることが ...YouTube · こーじ(物理エンジン)2019/05/11

↑このムービー、かなりふざけてますが
トロッコの底面に、分かりやすく
する為に、赤い輪を付け
レールに通して、ループ時でも
脱線しない様にしてるようです。
当然、ひねり等も出来ますね。
うまい方法だな、と思いました。
(※ゲーム的なウソ表現?に
なってしまいますが。)

...ちなみに、動画解説や動画の
コメントも面白いです。


後、どこで見たのか忘れましたが
カーブに透明な高い壁やトンネル
を作って、強制的に脱線しない様に
していた物も、ありました。


連結車両については
出来るのか不明ですが
前の車両の動きを一定時間後
コピーして動かす...ぐらいしか
思いつきませんでした。

私からすると、ゾロゾロ関数 
のゴムの様な動きの方が
難しい...と考えています。


ただ、アキアキノヒロロ さん
のhspプログラムと、blender
の生成キャラ等を、見ることが
出来ないので、コレが役に立つか
分かりません。
役に立たない場合は
そのまま、スルーして下さい。

●追記
以前から掲示板、Twitterで、お話が出ている
プログラム実行時に、タイミングがズレる件も
上と同様の理由で、誰も推測で、答える事しか
出来ないと思うので...

アキアキノヒロロ さんの
詳細なPCスペック、例のソース
blenderの生成キャラ等
をセットにして、公開する
ことは可能でしょうか?



Drip

リンク

2022/2/16(Wed) 17:22:53|NO.95440

Dripです。
アキアキノヒロロさん、こんにちは。

Hgimg4の物理は物体同士がぶつかった際の押し出し処理がそこまで正確ではありません。
レールを作成して物理設定したところで、レールから外れずに物理移動してくれる確証は殆どないことに注意してください。
Hgimg4では多角形よりも立方体のほうが安定した物理判定が行えるようですが、それでも状況によっては押し出しが不正確なために度々おかしな動作になり得ます。
特にGPPBIND_MESHで物理設定した場合は注意する必要があり、かなり変な方向に押し出しが発生する恐れがあることを覚悟されてください。

以下のサンプルでは薄い容器を作成し、容器にすっぽり収まる立方体を250個生成しています。
容器から絶対にこぼれるはずのない箱のはずが、漏れてばらばらと落ちていく様子が確認できるかと思います。
この暴走はgppsetやgppbind等の設定によってある程度抑えることは可能なのですが、
比較的動作が安定する立方体モデルであっても完全な抑止は不可能であり、
自由形状ですとこの物理動作は更に不安定なものとなります(体験談)。

//Hgimg4の物理は押し出しに弱いサンプル //容器の容量は充分です。箱が250個全部容器に入るかな? #include "hgimg4.as" chdir dir_exe+"\\sample\\hgimg4" gpfloor id,50,4,$888888:gppbind id,0,0.5 //底面を作成 gpplate id,50,100,$AABBFF:setpos id,0,50,-2:gppbind id,0,0.5 //奥側の壁を作成 gpplate id,50,100,$AABBFF:setpos id,0,50,2:setang id,m_pi:gppbind id,0,0.5 //手前側の壁を作成 gpplate id,10,100,$AABBFF:setpos id,25,50,0:setang id,0,-m_pi/2:gppbind id,0,0.5 //右側の壁を作成 gpplate id,10,100,$AABBFF:setpos id,-25,50,0:setang id,0,m_pi/2:gppbind id,0,0.5 //左側の壁を作成 setpos GPOBJ_CAMERA,-50,100,150 //カメラ座標設定 gplookat GPOBJ_CAMERA,0,50,0 //注視位置を設定 repeat //メインループ if cnt<2500:if cnt\10=0:{ //250個の箱を徐々にリリース gpbox id,3.9,$0000FF:setpos id,0.4*(rnd(100)-50),95 //適当な位置に箱を生成 setang id,0,0,0.01*rnd(628):gppbind id,10,0.5 //適当な角度で箱に物理設定 gppset id,GPPSET_GRAVITY ,0,-100,0 //箱に重力を設定 gppapply id,GPPAPPLY_IMPULSE,10*(rnd(100)-50),-500,10*(rnd(100)-50) //箱に適当な衝撃を設定 ct++ } redraw 0 color:boxf gpdraw pos ginfo_winx/4,ginfo_winy/2:color 255,255,255:mes "box= "+ct redraw 1 await 16 loop
以前アキアキノヒロロさんが問題提起されていた物理動作が実行するたびに結果が微妙に異なるのも、物理動作はHSPのフレーム単位ではなく内部的にリアルタイムで動作していることに起因しているようです。
これは見かけ上の検証に基づく結論なのですが、物体が壁から衝撃を受けるとき若干壁にめり込みますが、リアルタイムを用いて移動量を計算した場合、めり込む量もわずかに変化して押し出され方も変わってきますから、反発方向などにズレが生じ、そのズレが次々に重なり前回と全く違う動作になってしまうこともしばしば起こり得ます。
そのほかにも、物理動作は内部的にリアルタイムで動作していると言いましたが、正確にはその動作は少し未来までしかプールされないようです。
例えば今程のサンプルを実行したら暫くタイトルバーを掴んでスクリプトの実行を一時的に止めてみましょう。
タイトルバーを離すと、箱の移動地点が期待される次のフレームの様子ではなく、少し未来の状態になり、次にリリースされる箱もいくらか遅れて生成されることに気づくはずです。
しかしいくら長時間タイトルバーを掴んでいても、何秒も先の状態にはなりません。
Hgimg4のこの辺の仕様は現在不明瞭であり、フレーム単位の正確な物理テストを行えないことには、Hgimg4に正確な物理動作を期待することはまずできないように思っています。


以下のサンプルでは物理動作がプールされる時間によって物理動作の誤差が顕著に現れるサンプルです。
全く同じ条件で生成される箱は毎回同じ軌道を描いて落ちていくはずですが、以下のように物理動作がプールされる時間が変わると
動作結果に大きな誤差が生じ、箱があっちこっちに吹き飛んで行く様子が確認できます。

#include "hgimg4.as" chdir dir_exe+"\\sample\\hgimg4" gosa=16 gpbox id,10:setang id,0,0,m_pi/4:setpos id,0,-30:gppbind id,0,0.5 repeat //メインループ if cnt\20=0:{ gpbox id,10:setang id,0,0,m_pi/4:setpos id,0,30:gppbind id,1,0.5 gppapply id,GPPAPPLY_IMPULSE,0,-200,0 gppapply id,GPPAPPLY_TORQUE,50,100,-45.88 //誤差が生じ易い衝撃を与える gppset id,GPPSET_GRAVITY,0,-100 } redraw 0 color:boxf stick a,768:gosa=((a&768)=0) pos 30,30:color 255,255,255 mes "★マウスを押し下げている間、物理動作を安定させることができます" pos 100,100 if gosa:color 255:mes "今、物理の誤差が大きいです。":else:color ,255,255:mes "誤差は小さいです" gpdraw redraw 1 if gosa:await 16+rnd(16):else:await 16 //意図的にフレームを不安定にします loop
アキアキノヒロロさんはHgimg4によるプラレール的な物を構想していらっしゃるのでしょうか。
今のところは…ですが、それをHgimg4の物理で実現するよりも、自前で動作を組み込んだほうが安定したレールを実現できるように思います。
がんばってください。



zrs90(5さい)

リンク

2022/2/16(Wed) 17:24:20|NO.95441

検索のついでに、見つけたので追加。

#blender質問室 
#blender質問箱

↑この2つは、検索すると分かりますが
blenderについての質問が出来る
Twitter版の、hsp掲示板みたいな所です。
質問で利用する場合は、ルールみたいなのが
ある様なので、そちらを読んで下さい。


blender 電車

↑検索すると動画等に、連結していたり、
長い列車を走らせるヒントがあります。
コース起伏のない、ジェットコースター
のつもりで、参考にすると良いです。



アキアキノヒロロ

リンク

2022/2/17(Thu) 02:32:45|NO.95444

zrs90(5さい) さん、Drip さん、有難うございます。

私は、2009年コンテストに、[E3D]で作った「鉄道ジオラマ」を出品した者です。
https://hsp.tv/contest2009/list_n3.html#id143
あれを[Hgimg4]で再現したいと思っている訳です。
2019年の「Treasure Hunt」にも、フィールドを周回するトロッコ風のものを登場させましたが。
(これは、円周上を走るように回転させているだけです)

今では、[E3D]は[Hgimg4]へと移行しつつあるように思えますが、
[E3D]で出来ていたことでも、[Hgimg4]では叶わないことが多々あって、
色々と代替方法やアイデアを探っているところなのです。

zrs90(5さい) さん紹介の『はてなブログ』
『カーブと配列複製を使って線路を作ってみた。』
も、動くカメラの位置を、[HSP]側から逐一取得できれば、なんか出来そうな予感。

zrs90(5さい) さんに習って、色々検索してみたところ、
『りゅうくんの工房 / Blenderで電車を作る(3)』
http://ryuukunblog.blog.fc2.com/blog-entry-18.html
これが一番の収穫のようです。
特に、このページ最後のgif製動画のように、
これを[HSP]から操作出来るようになればいいわけで。

まだ使ったことのない[Blender] の機能がでてきて、また勉強ですが、
Path、Curve、Empty、そして親子関係。
やっぱり、親子関係が出てきたか、と思いました。

あと、コンストレイント。
一つのオブジェクトを基準にして他のオブジェクトを追従させる機能
だそうで、これは、[Blender] での機能であって、これが[HSP]側で出来るものかどうか。
出来るなら、これで全て解決しそうだけれど、そう簡単なものではないでしょう。

ちょっと、思うのは、この線路に沿って動くというのは、
[E3D]でのナビラインと同じじゃないかな。(E3DControlByNaviLine)
ナビラインの座標設定、作るの、めちゃくちゃ大変だったのを思い出した。

>赤い輪を付けレールに通して
このアイデアは、実験済です。[Blender]では出来るようですが、
[Hgimg4]の物理設定では、このような組み合わせは今のところ不可能です。
固定された輪に棒を通すことは出来ても、その逆、固定された棒に輪を掛けて、
その輪を動かすことは出来ません。

>カーブに透明な高い壁やトンネルを作って、強制的に脱線しない様に
このアイデア、実験済で、活用しています。
https://twitter.com/akiakinohiroro/status/1478308156656984068
また、今回のコンテストに出した「ANIMAL_ISLAND」の「オロチの島」で、
https://dev.onionsoft.net/seed/info.ax?id=2075
これを応用して、オロチの口から入り込んで、尻尾へと胎内移動の冒険が出来ます。

>前の車両の動きを一定時間後コピーして動かす
このアイデア、是非試してみたいです。目からウロコの方法ですね。
時間差で同座標移動。何とかなりそうな予感です。
有難うございます。


Drip さんのご考察、
>物理動作が実行するたびに結果が微妙に異なるのも、
>物理動作はHSPのフレーム単位ではなく
>内部的にリアルタイムで動作していることに起因しているようです。
初心者同然の私ですが、2年以上前から今まで、[Hgimg4]の物理設定/物理挙動で色々悩まされ、
その都度、実験用スクリプトを何十となく作って試してきた者として言わせて頂くと、
やはり、私も、Drip さんのおっしゃっていることを感じてしまいます。
これは、現状、もう仕方ないこととして受け入れ、そういう誤差を最小にする工夫を施し、
その誤差内で不都合にならないように、プログラムする、そう腹を括るのが賢明ということになるのでしょう。

>それをHgimg4の物理で実現するよりも、
>自前で動作を組み込んだほうが安定したレールを実現できるように思います。
[E3D]でのナビラインの座標設定、これも試してみようと思っています。


長文、申し訳ありませんでした。
解決ではありませんが、「解決」のチェックを入れます。



youdai

リンク

2022/2/17(Thu) 09:20:18|NO.95445

>Dripさん
>例えば今程のサンプルを実行したら暫くタイトルバーを掴んでスクリプトの実行を一時的に止めてみましょう。
>タイトルバーを離すと、箱の移動地点が期待される次のフレームの様子ではなく、少し未来の状態になり、次にリリースされる箱もいくらか遅れて生成されることに気づくはずです。
>しかしいくら長時間タイトルバーを掴んでいても、何秒も先の状態にはなりません。
>Hgimg4のこの辺の仕様は現在不明瞭であり、フレーム単位の正確な物理テストを行えないことには、Hgimg4に正確な物理動作を期待することはまずできないように思っています。

自作の特殊な動作をする頂点シェーダーの動作テストをしていた時に、ウィンドウの閉じるボタンにカーソルを合わせている状態だと
頂点シェーダーが一定確率で不具合を起こし、メッシュが崩壊するという現象を確認したことがあります。
このメッシュが崩壊する現象はウィンドウモード以外発生せず、bgscrの枠無しウィンドウやフルスクリーンモードでは発生しない現象でした。
その時の自分の仮説は、どうやらHGIMG4はWindows APIに何か命令が発生するタイミングと画面の更新が重なると不具合を起こすらしい、というものでした。
タイトルバーもWindows APIと関係するものですから、このことも何か関係があるのかもしれません。



Drip

リンク

2022/2/17(Thu) 15:36:29|NO.95448

youdaiさん

こんにちは。
恐らくそれと今回の物理の件は無関係かと思います^^;

ウィンドウを掴むというのは、プログラムに複雑なウェイト処理を追加するのが手間なのでそうしていただいているに過ぎず、スクリプトに単にウェイトを噛ませるだけでも物理挙動の事象は再現可能です。
一定値以上のウェイトをかけるとその時間に応じて物理挙動は遅くなりますが、一定値以下のウェイトですとプールの範囲内となりウェイト時間に関係なく物理動作の移動量はリアルタイムに対して殆ど変わらなくなります。
これをスクリプト改変によって説明するより単に自分で実行を停止してもらったほうが遥かにわかりやすいと思いそのように説明させていただいております。

> 自作の特殊な動作をする頂点シェーダーの動作テストをしていた時に、ウィンドウの閉じるボタンにカーソルを合わせている状態だと
> 頂点シェーダーが一定確率で不具合を起こし、メッシュが崩壊するという現象を確認したことがあります。

ここからはアキアキノヒロロさんの物理に関する話題から逸れます。失礼致します。

私の確認した範囲ではですが、ウィンドウの操作によってHgimg4の動作に異常を来たすというのは見たことがありません。
それ以前の問題として、Hgimg4でカスタムシェーダーやBufferを利用した場合、プログラム終了時にHgimg4がクラッシュする(Windowsのエラー(○○は動作を停止しました)でWindowsのイベントログにも追加されます)環境がある事を確認しており不安を払拭できず、そもそもHgimg4でカスタムシェーダーを使うこと自体殆どありません。
この不具合には以下のような特徴があります。
・HSP付属サンプル customshader.hsp や、posteffect.hsp などでもこの問題が発生します。
・カスタムシェーダーやbufferなどの特定の機能を呼び出さない限りこの問題の発生を確認できません。
・この問題が発生するPCでは高頻度で発生しますが、発生しないPCでは全く発生しません。
・この問題はhgimg4.as使用時でのみ発生し、hgimg4dx.as使用時は発生を確認できません。
これがyoudaiさんの仰るシェーダーの不具合に関係したものかどうかは不明ですが、hgimg4dx.as使用時はPCに備わるOpenGLの性能に関係なくAngleが正しい動作を完全にエミュレートしてしまうために問題が起こらない…のか?とも勝手に想像しています。
Windows10の場合はサイレントクラッシュとなる可能性が高く、クラッシュしててもユーザーが気づかない…という事が懸念されます。
気づかないならいいじゃないか、というものでもありませんよね(−−;

複数のPCで動作テストしておりますが、未だ臆測の域を出ません。
サイレントクラッシュであってもマイクロソフトにHSPのクラッシュレポートが毎回送信されてしまっています。



アキアキノヒロロ

リンク

2022/2/17(Thu) 17:13:49|NO.95449

そんな問題もあるんですね。
Drip さんが言う問題とは違うかも知れませんが、
bufferについては、私も以前思い通りに働いてくれないことがありました。

私が立てた話題でなくとも、[Hgimg4] に関することで、スレが広がるのは嬉しいです。
一人相撲時代は、懲りごりなので。



アキアキノヒロロ

リンク

2022/2/18(Fri) 08:33:47|NO.95454

「列車用の物理挙動用ノードについて」
と言いながら、色々話題が広がってしまいましたし、一応の解決ともしているのに、
また、蛇足を付け加えることをお許し下さい。


Drip さんが、
>物理動作がプールされる時間が変わると、動作結果に大きな誤差が生じ、
とおっしゃっていることに関してです。

PCの物理挙動の計算処理能力が間に合わない場合は、
[HSP]側がその処理終了を待たずに描画に移ろうとする。
また、PCの物理挙動の描画処理能力が間に合わない場合は、
その間、本来の物理動作は先に進んでしまっているから、
[HSP]側が次の描画のためのループに入った時には、ズレてしまっている、と。

ということは、です。
その時扱っている物理に対して、PCの物理に関する処理能力も、物理挙動の描画処理能力も、
ともに間に合っているのであれば、プールされる時間を常に一定に保ってやれれば、
動作結果に大きな誤差が生じることはない。
ということになる?

この辺のことは、表題から外れるので、
それに、より相応しい、私の別スレ
「物理挙動の内部処理って?」
http://hsp.tv/play/pforum.php?mode=all&num=95190
に移動したいと思います。



youdai

リンク

2022/2/18(Fri) 09:24:05|NO.95455

>それ以前の問題として、Hgimg4でカスタムシェーダーやBufferを利用した場合、プログラム終了時にHgimg4がクラッシュする(Windowsのエラー(○○は動作を停止しました)でWindowsのイベントログにも追加されます)環境がある事を確認しており不安を払拭できず、そもそもHgimg4でカスタムシェーダーを使うこと自体殆どありません。
HGIMG4において、いわゆる標準のcoloredシェーダー等と、そうでない自作のシェーダーとの実装上の違いはありません。
どちらも単にGLSLで記述されているものが動作しているに過ぎないからです。
自作シェーダーを使ってクラッシュするのはそのシェーダーか、もしくはグラフィックボードのOpenGL系の設定に問題があるからだと思います。

>hgimg4dx.as使用時はPCに備わるOpenGLの性能に関係なくAngleが正しい動作を完全にエミュレートしてしまうために問題が起こらない…のか?とも勝手に想像しています。
HGIMG4DXの場合は自分のPC環境の場合、自作のシェーダーがほとんどの場合、正確に反映されない(変換されない)ことを確認しています。
これは全くの想像なのですが、HGIMG4DXは標準のcolorer等が動作しやすいよう最適化され、アレンジがされているのかもしれません。
そのため、そのアレンジ部分が邪魔をして自作シェーダーの再現率が非常に低いのかもしれないと思いました。

もし使用しているPC環境で、HGIMG4DXの方では動くが、HGIMG4の方では動かない、もしくは不具合が起きる場合、
グラフィックボードのOpenGL系の設定を変えると正常に動作する可能性があります。
もし不具合が起きている場合、OpenGL系の設定のクオリティを高く設定し過ぎているとそれが原因で処理が追いつかなくなり、
HGIMG4のスクリプトの方には問題がなくても結果的にエラーが発生していることもありえるからです。



youdai

リンク

2022/2/18(Fri) 09:39:39|NO.95457

せっかくなので、その他の不具合の起きる可能性も記述しておきます。

●何も間違っていなくてもエラーが起きる可能性がある
シェーダーも正しく、HGIMG4のスクリプトも正しく、グラフィックボードのOpenGL系の設定も正しいのにエラーが起きる場合、
使用しているテクスチャのサイズが大きすぎるとエラーが起きることも確認しています。
例えば、4Kだったテクスチャを512*512にリサイズして、.materialのテクスチャの品質系の設定を低くすると問題なく動作したことがあります。

●画像ファイルが壊れている場合がある
上記のようにテクスチャのサイズを小さくしても動かなかったケースでは、画像ファイルが壊れていたことが原因だったケースがあります。
これは実はとても分かりにくい不具合で、画像ビュアーによっては、画像ファイルが壊れていても自動で補正して正常に表示する機能を持っているものがあるので、
使っている画像ビュアーがまさにその機能で自動補正していたので、画像ファイルが壊れていたことにしばらく気が付きませんでした。
これは色々な画像ビュアーで画像を閲覧してみて、閲覧できないビュアーがあったことから、画像ファイルが壊れていることに気づけました。



アキアキノヒロロ

リンク

2022/2/18(Fri) 09:54:20|NO.95458

youdai さん、申し訳ないですが、
私のこのスレの表題とズレすぎた話題になってしまっているようですが。

大事な問題でもあり、有用な情報でもあると思います。
他の方たちとも共有できるようにするためにも、
youdai さんご自身が、別に新たにスレッドをお立てになられることをお勧めいたします。

すいません、ご一考のほどを。



Drip

リンク

2022/2/18(Fri) 19:02:29|NO.95465

こんにちは。


アキアキノヒロロさん

>ともに間に合っているのであれば、プールされる時間を常に一定に保ってやれれば、
>動作結果に大きな誤差が生じることはない。
>ということになる?

そうですね。
awaitにいかなる固定値を指定したところで動作環境によってリアルタイムと僅かに誤差が生じてしまいますから、何とか誤差を小さくすることはできても、誤差を無くすことは残念ながら現状不可能に思えます。
Hgimg4にフレーム単位の計算結果を出力する機能が欲しいところですが^^;


youdaiさん

話題が相当飛躍しているように思えるのですが、当方では自作シェーダーなどではなくHSPの付属サンプルで問題の発生を確認しており、付属シェーダーtextured.frag, textured.vertと付属テクスチャbtex.pngを用いたgpusermat命令による簡易的なマテリアルの呼び出しにおいても同等の問題が発生することを確認しています。
ただし、gptexmatによる呼び出しでは問題の発生を確認することができません。

このことから、この時点の問題の原因が払拭されないことには、これより先にある問題(例えばyoudaiさんの言及されるような事柄に関して)の検証に至ることができません。仰る問題も感知・再現できておりません。

原因の可能性としてPCのOpenGLの環境も視野に入ってくるかと思いますが、その正確性を世界中のユーザー(作品の利用者)に強いるのは中々酷な所ではあるかと思います。
あなたの使用環境が悪い!…で済まされてしまってはユーザーも開発者も納得が行きませんよね。
少なくともこの掲示板の狭いコミュニティ内でも問題が確認されている状況ですので、どうにかして問題の原因を突き止めたいものですね。



記事削除

記事NO.パスワード
(質問が解決したスレッドは他の利用者に活用してもらうため、削除しないようお願いします)

NO.95399への返信

マスコット

好きなマスコットを選んでください。

名前

e-mail
HOME
  1. 初めて利用する方は、HSP3掲示板の使い方をお読みください。
  2. 不要部分の多い長いスクリプトの投稿は ご遠慮ください。
  3. 書き込みは自動改行されません。適度に改行を入れてください。
  4. スクリプトは小文字の<pre>〜</pre>で囲むと見やすく表示できます。

削除用パスワード

解決したら質問者本人がここをチェックしてください。

エラー発生時、再送信すると二重送信になることがあります。
回答が得られたら、お礼書き込み時に[解決]チェックしてください。
SPAM防止のためURLから始まる文章は投稿できません。
SPAM防止のため英文字のみの本文を投稿することはできません。

ONION software Copyright 1997-2021(c) All rights reserved.