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の物理で実現するよりも、自前で動作を組み込んだほうが安定したレールを実現できるように思います。
がんばってください。
[hging4] 列車用の物理挙動用ノードについて
