こんにちは。Dripです。
アキアキノヒロロさん＞
>> 「GPPBIND_NOSCALE」は過去バージョンとの互換性のためのもの
>この意味がよく分かりません。[hgimg4] の過去バージョンと互換を取るという、
>そのことが具体的にどういうことを意味しているのか分かりません。
HSP3.51までは物理動作がscaleを考慮せずに判定していた時代があります。
Hgimg4付属サンプルの test11.hsp の37行目あたりに setscale i,2,2,2 を一行追加して実行してみますとHSP3.6と3.51での動作の違いがわかるかと思います。
この不具合の修正とともにかつてバグの存在したバージョンと互換性を取るために設けられたパラメータがGPPBIND_NOSCALEです。
使いようによっては任意で少し壁にめり込んで見える物理動作モデルの生成等にも使うことができますよ。
フリーメッシュに関して＞
個人的な見解ですが、現状のHgimg4のメッシュの物理動作は仕様通りに動作しておらず、殆ど使う事ができない気がしています。
まず頂点の登録順序やUVの座標説明がマニュアル通りになっていないことは誰もが混乱する部分かと思います（少なくとも四角ポリゴンを生成しようとした場合、頂点を時計回り（或いは反時計回り）に登録することは絶対にできないはずです）が、
当たり判定も滅茶苦茶で空中に浮いたり地面にめり込んだりと、まともに動作していないように見えます。
別のスレッドでGENKIさんも気づかれていらっしゃいますが、HSP付属のフリーメッシュのサンプルも誤記によってメッシュの物理が正常に設定できておらず、
そもそも動作の見た目がgpboxと何ら変わり無い形状でテストしているため、フリーメッシュとの違いが全くわからないのも問題に思います。
//フリーメッシュの物理動作がおかしいサンプル（コピペで実行できます）
// ・物体が適当な大きさの箱型に判定されてるっぽくないですか？
// ・マウスを動かすとカメラが回転します
// （HSP3.6〜HSP3.7b2にて動作・テスト済）
#include "hgimg4.as" //hgimg4読み込み
chdir dir_exe+"\\sample\\hgimg4" //hgimg4のフォルダで実行
gpfloor id,100,100,$8899FF:setpos id,0,-10,0 //床生成
gppbind id,0,0.5 //床に物理設定
repeat 2 //2種類の図形を生成
//なんか適当な物体を生成する処理
gpmeshclear:idMax=0 //ポリゴンリセット
type=3+cnt\2 //三角ポリゴンか四角ポリゴンか指定
height=8.0 //ろくろの形状ごとの高さを指定
ddim size,1 //ろくろの形状（幅）
if cnt=0:size=1.5,8.0:ccc=$99FFAA //ろくろの形状と色を登録（1回目）
if cnt=1:size=1.5,8.0,4.0:ccc=$FFAA99 //ろくろの形状と色を登録（2回目）
repeat length(size):y=cnt //形状情報数でループ
repeat type //ポリゴン分の頂点を生成
fv=sin(m_pi/type*2*cnt)*size(y),height*y-2,cos(m_pi/type*2*cnt)*size(y)
gpmeshadd IDs(idMax),fv,fv(1),fv(2),fv,fv(1),fv(2),0,0:idMax++
loop
loop
if idMax<4:end //ろくろが生成されていない
if type=4:{ //四角ポリゴンで作るろくろ
gpmeshpolygon IDs(3),IDs(2),IDs(0),IDs(1) //蓋
gpmeshpolygon IDs(idMax-4),IDs(idMax-3),IDs(idMax-1),IDs(idMax-2) //底
}else:if type=3:{ //三角ポリゴンで作るろくろ
gpmeshpolygon IDs(2),IDs(1),IDs(0) //蓋
gpmeshpolygon IDs(idMax-3),IDs(idMax-2),IDs(idMax-1) //底
}else{
end //それ以外のポリゴンは認めない
}
repeat type*(idMax/type-1) //ろくろの側面を生成
id=cnt\type+cnt/type*type,(cnt+1)\type+cnt/type*type
gpmeshpolygon IDs(id),IDs(id(1)),IDs(id+type),IDs(id(1)+type)
loop
repeat 5 //5個のろくろをランダム配置
gpmesh id,ccc:setang id,0.01*rnd(628),0.01*rnd(628)
setpos id,rnd(60)-30,10+cnt*height,rnd(60)-30
gppbind id,1,0.5,GPPBIND_MESH //ろくろはメッシュで物理形状判定
gppset id,GPPSET_GRAVITY,0.0,-20.0,0.0
loop
loop
repeat //メインループ
fv=sin(0.01*(ginfo_winx/2-mousex))*80 // マウスで
fv(1)=0.1*(ginfo_winy/2-mousey) // カメラ
fv(2)=cos(0.01*(ginfo_winx/2-mousex))*80 // 操作
setpos GPOBJ_CAMERA,fv,fv(1),fv(2)
gplookat GPOBJ_CAMERA,0,0,0
redraw 0 //描画開始
color:boxf
gpdraw
color 255,255,255:pos 30,30:mes "フリーダムすぎる＾＾；"
redraw 1
await 16
loop
この状態で作品制作にフリーメッシュを（特に物理で）利用されている方は今のところ存在するのかもかなり怪しい気がしています。
個人的には…ですが、もう現時点までのフリーメッシュの仕様や互換性は正直どうでもいいので、
実際の作品制作を想定した仕様に刷新した方が良いような気がしています。
ここまでおかしな動作ですと、旧バージョンとの互換性を取るフラグもかえって混乱の元なのでこの際要らないと思っています。
P.S：
上記のサンプルで物体の見た目がヌルッとしているのは頂点を使いまわしている結果なんですが、
頂点は使いまわしつつ面ごとにUVや法線を設定することはできないのでしょうか？
（内部的に意味のある事かはわかりませんが）現状のHgimg4で面ごとに法線やUVを設定しようとした場合、
同じ座標の頂点を使う面が複数あっても面の数だけ同じ座標の頂点を再登録する必要があり、メモリを相当無駄遣いするような気がしています。
田
↑このような4つの四角面を持つメッシュを生成しようとした場合、頂点が使いまわせれば頂点情報は9個で済みますが、
面ごとに法線やUVを設定しようとした場合頂点は使いまわせず、16個の頂点を登録する必要があり、
特に中央の頂点は４つの面に利用されてますから、4回も同じ座標を再登録するハメになりますよね。
なんだか凄くメモリの無駄遣いをしている気がするのですが＾＾；；；
（三角ポリゴンで形成しようとした場合は更に増えて24個の頂点が必要に。9個 → 24個… うぅ…ん）
[hgimg4] についてのひとりごと
