当たり判定について

[たろう]

返信ありがとうございます。いいえ、当たりとみなしません。

[softya]

>角度は0のままでも出来るのでしょうか？
出来ますが、垂直でも斜めでも自在に作れないなら理解しているとは言えません。
当たり判定をちゃんと理解するために作っているはずでよね。

[ookami]

> いいえ、当たりとみなしません。
それはなぜですか？

[たろう]

赤い円の中に移動後は青い移動後に入らないためです。

[たろう]

softyaさん
返信ありがとうございます。

わかっていなかったみたいです。
ヒントでもいいので教えてもらえませんでしょうか？

[ookami]

> 赤い円の中に移動後は青い移動後に入らないためです。
わかりました。

ではこれは？(添付)
今回は、青は動きません。

[たろう]

ookamiさん
返信ありがとうございます。
当たりません。
理由はすり抜けてしまうからです。

[ookami]

え...？では、これは？
(ちょっとずらしました)

[たろう]

当たらないと思うのですが。。。
間違っていますでしょうか？

[たろう]

すみません。いっきに移動したらですよね？

[シエル]

定義が少ないんじゃ。。。
その物体の速さとか教えてあげないと答えづらいですよ。

[ookami]

確認しますが、
たろうさんがやりたい当たり判定では、
No.60350でもNo.60354でも、当たってないとみなす、
ということで、ファイナルアンサー？

[ookami]

# シエルさん
たろうさんのお答え次第では、速さうんぬんが意味なくなってしまいますからネｗ
まぁもうちょっと待ちましょう。

[たろう]

ファイナルアンサーで。。。

[softya]

ookamiさんの質問の意図は、
>確認なんですが、たろうさんがやりたい当たり判定では、
>図のような場合は、当たりとみなしますか？
なので、それに沿っての返答を求められていると思いますよ。

>わかっていなかったみたいです。
>ヒントでもいいので教えてもらえませんでしょうか？

ヒントと言っても物体２が静止しているならt=0.7だけで当たるためには物体１の速度に応じた適度な小ささの当たり半径を選んでやればそのタイミングだけで当たります。角度０でも。
でも、これは一番簡単な奴なので不十分ですけどね。
図を色々書いてみても分かりませんか？頭の中でイメージできないなら実際に紙の上に書いて考えるしか無いと思いますよ。

[シエル]

なるほどｗ失礼致しました。

[たろう]

すみません。
違います。
その画像で当たり判定されるようにしたいのです。

[ookami]

うはｗｗｗｗ ファイナルアンサーに対して罵倒を書くところでしたｗｗｗｗ 確認してよかった。せふせふ。

では、次はこの添付、どう思いますか？

-- 追記：添付しわすれましたｗ

[たろう]

当たり範囲に入っていません。それはわかります。

[ookami]

> 当たり範囲に入っていません。
というのは、たろうさんがやりたい当たり判定では、当たってないと見なすんですか？
それとも、関数を工夫して、当たっていると見なせるようにしたいんですか？

[たろう]

関数を工夫して当たっているとみなせるようにしたいです。

[ookami]

その工夫っていうのは、上のソース上ではどんな感じでするんでしょう。

[softya]

良いトレーニング法を思いつきました。
No:60303 でたろうさんの作ったプログラムの物体１と物体２の当たり判定の円を絵に書いてもらえませんか。
tは0.1刻みで0～1.0の全部を書いてみてください。

[たろう]

返信ありがとうございます。
t0.0～0.5まで書いてみました。
当たり判定はこんな感じですよね？

[たろう]

すみませんわかりません。
答え教えていただけませんでしょうか？

[ookami]

座標を書き加えてもらってもいいですか？
あと、楕円は何ですか？

[softya]

>返信ありがとうございます。
>t0.0～0.5まで書いてみました。
>当たり判定はこんな感じですよね？

No:60303のプログラムの
printfDx("%d",atarihantei(7.0f,0.0f,7.0f,0.0f,10.0f,21.0f,0.0f,0.0f,0.0f,0.0f));
のパラメータで動かした場合の図形ですよね？
物体１と物体２で色変えてもらって良いですか。
それと0.0か1.0まで全てお願いします。

ちゃんと計算して数値も書いてくださいね。
※　プログラムで計算しても良いですけどね。

[たろう]

返信ありがとうございます。
出来ました。

#define GLOBAL_INSTANCE  
#include "include/DxLib.h" 
#include<math.h> 
// 動いてない円同士の当たり判定 
int test_circle_circle(float x1, float y1, float r1, float x2, float y2, float r2) 
{ 
    float x = x1 - x2; 
    float y = y1 - y2; 
    float r = r1 + r2; 
    return x * x + y * y <=r*r; 
} 

// 動いている円同士の当たり判定 
int atarihantei( 
    // X座標, Y座標, 半径, 角度, 速度 
    float x1, float y1, float r1, float a1, float v1, 
    float x2, float y2, float r2, float a2, float v2
    ) 
{ 
    // 経過時間 
    // 円がそれぞれ a1, a2 の方向に v1, v2 だけ進んだ時間を 1.0 とする 
    float t = 0.0f; 

    while (t < 1.0f) 
    { 
        // 初期位置から t だけ進んだ円同士の当たり判定を行う 
        if (test_circle_circle( 
            x1 + cos(a1) * v1 * t, y1 + sin(a1) * v1 * t, r1, 
            x2 + cos(a2) * v2 * t, y2 + sin(a2) * v2 * t, r2)) 
        { 

            return 1; 
        } 

        // 適当に時間を進ませる 
        // ここの値は r1, r2, v1, v2 から適切に求めるべきだけど、ここでは面倒なのでやらない 
        t +=0.1; 
    } 
    // 初期位置から 1.0 だけ進んだ円同士の当たり判定を行う 
     
 
    return test_circle_circle( 
        x1 + cos(a1) * v1, y1 + sin(a1) * v1, r1, 
        x2 + cos(a2) * v2, y2 + sin(a2) * v2, r2); ; 
} 


int Prossessloop() 
{ 
    if(ProcessMessage()!=0) 
        return -1; 
    if(ClearDrawScreen()!=0) 
        return -1; 
    return 0;  

} 
int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow ){ 
    ChangeWindowMode(TRUE);//ウィンドウモード 
     
    if(DxLib_Init() == -1 || SetDrawScreen( DX_SCREEN_BACK )!=0) return -1;//初期化と裏画面化 

    while(Prossessloop()!=-1){ 


//当たり判定 


    // X座標, Y座標, 半径, 角度, 速度  
    printfDx("%d",atarihantei(0.7f,0.0f,0.00000023841858f,//0にしたいのですがプログラムで計算されると誤差が出えるのでこの数値にしました。
                                0.0f,1.0f,  2.1f,0.0f,0.0f,0.0f,-1.0f)); 
//x1を１上げると当たらない、rを下げると当たらない 
        ScreenFlip(); 
    } 

    DxLib_End(); 
    return 0; 
}

[softya]

>返信ありがとうございます。
>出来ました。
えーと何が？は冗談として、えらく極端な衝突パターンで来ましたね。

理解度を確認したいので図は必ず書いてくださいね。
1)最初のNo:60303
2)最新のNo:60453
の両方でお願いします。

【追記】
ookamiさんの最後の質問にも答えてくださいね。

[たろう]

返信ありがとうございます。
画像です。汚いですが勘弁してください。。。
60303は待ってください。

[たろう]

No60303の画像です。

[softya]

とりあえず、No:60303のやつは、
// X座標, Y座標, 半径, 角度, 速度
atarihantei(7.0f,0.0f,7.0f,0.0f,10.0f,
　　　　　　21.0f,0.0f,0.0f,0.0f,0.0f));
ですよね。

　　　　X座標, Y座標, 半径, 角度, 速度
物体１　7.0 0.0 7.0 0 10.0
物体２ 21.0 0 0 0 0.0

なので物体２は座標(21,0)に静止する（速度0）半径0の当たり範囲もつ物体というわけです。
図と違いますよね？
それと物体１は座標(7,0)から速度10.0/フレームで角度0で移動する当たり判定半径7の円をもつ物体ですよね。
これも図と違うと思います。

ちゃんと計算すれば分かる話ですので、
１．まずちゃんと計算して表などにまとめること。
２．グラフ用紙などに計算結果を反映した図を書くこと。
以上をやってみてください。
出来れば、表だけ先にここに書いてもらうと間違っているかすぐ分かります。

[ookami]

ちょっと確認なんですが、
　座標(x0,y0)から、角度 a で 距離 r 進んだ座標
を、数式で表現できますか？
添付をご参考ください。

[ookami]

連続ですみません、
さらに確認なんですが、たろうさんがやりたい当たり判定では、
図のような場合は、当たりとみなしますか？

[たろう]

softyaさん返信ありがとうございます。
物体２は静止してます。
赤い丸がそうなんですが。
＞それと物体１は座標(7,0)から速度10.0/フレームで角度0で移動する当たり判定半径7の円をもつ物体ですよね。
当たり判定のｘ座標を載せていなかったのが間違っていたのでしょうか？
ookamiさん返信ありがとうございます。
＞数式で表現できますか？
((x0-?)*cos(a),(y0-?)*sin(a))ですよね。
図のような場合は、当たりとみなしますか？
みなします。

[ookami]

> ((x0-?)*cos(a),(y0-?)*sin(a))ですよね。
> 図のような場合は、当たりとみなしますか？
> みなします。

ちょっと心が折れそうなのでまた明日お返事します。
もう一度よく考えてみてください。
その回答は、単に間違っているというだけではありません。
すごくまずいです。

[たろう]

すみません。
(r*cos(a),r*sin(a))です。

[softya]

>物体２は静止してます。
>赤い丸がそうなんですが。

図の解釈が間違っているかも知れませんが、赤い丸も緑い丸が移動している様に見えます。
すいません、図にある赤い丸、緑の丸、青丸の意味を教えてください。
それとt=0から1.0までの物体1と2の座標と当たり半径の大きさを書いてもらっても良いですか。

>＞それと物体１は座標(7,0)から速度10.0/フレームで角度0で移動する当たり判定半径7の円をもつ物体ですよね。
>当たり判定のｘ座標を載せていなかったのが間違っていたのでしょうか？

図に描かれている数値は座標ではないのでしょうか？

[softya]

>(r*cos(a),r*sin(a))です。

それも違います。
仮に値を入れて見たり、グラフを書いてみれば分かります。

[ookami]

> (r*cos(a),r*sin(a))です。
違います。移動量ではなく座標を聞いています。

あと、「当たるとみなす」ほうは、どうなんです？

--

念のためですが、
ここまで皆さんが紹介されてきたアルゴリズムは、
どれも、すりぬけ(トンネリング)や、
逆に当たっていないのに当たったことにしてしまう場合がある半面、
計算量が少ないなどのメリットがあるから紹介してくださっていることを、理解していますか？

[たろう]

すみません。
?のところを書けばよかったのでしょうか？
だとしたら
(x0+r*cos(a),y0+r*sin(a))です。

[たろう]

赤い丸は、物理１、で緑の丸は物理２で青はここまで当たり判定するです。
＞それとt=0から1.0までの物体1と2の座標と当たり半径の大きさを書いてもらっても良いですか。
座標は、(14,0)(13,0)(12,0)(11,0)(10,0)(9,0)(8.0)(7,0)(6,0)(5,0)です。
当たり半径は7です。
＞図に描かれている数値は座標ではないのでしょうか？
書き間違えました。すみません。座標です。（ｘ座標の）

[softya]

>赤い丸は、物理１、で緑の丸は物理２で青はここまで当たり判定するです。

ごめんなさい。やっぱり分からないです。
当たり半径は図に書いてないと思って良いですか？

>座標は、(14,0)(13,0)(12,0)(11,0)(10,0)(9,0)(8.0)(7,0)(6,0)(5,0)です。
>当たり半径は7です。
これは物体１ですよね？
スタートの座標に14がくるのが分かりません。
(14,0)を求めた式と当てはめた数値を書いてもらって良いでしょうか？

>書き間違えました。すみません。座標です。（ｘ座標の）
これは何のＸ座標でしょうか？
物体１とも違うわけですよね？

[たろう]

説明が下手ですみません。
＞当たり半径は図に書いてないと思って良いですか？
いいです。
＞スタートの座標に14がくるのが分かりません。
// 初期位置から t だけ進んだ円同士の当たり判定を行う
if (test_circle_circle(
7 + cos(0) * 10 * 0, y1 + sin(a1) * v1 * t, r1,
21 + cos(0) * 0 * 0, y2 + sin(a2) * v2 * t, r2))
＞これは何のＸ座標でしょうか？
当たり判定のx座標です。

int test_circle_circle(float x1, float y1, float r1, float x2, float y2, float r2)
{
float x = x1 - x2;
float y = y1 - y2;
float r = r1 + r2;
return x * x + y * y <=r*r; ここのx座標
}
＞物体１とも違うわけですよね？
物体１と物体２の当たり判定です。
説明が下手でほんと申し訳ありません。
とりあえず解決とします。こんな馬鹿な自分ですが、
こんな人に回答していただきまして誠に本当にありがとうございました。

[softya]

ここまでやったなら最後までやりませんか？
ookamiさんにの最後の質問にも答えてませんし。

>return x * x + y * y <=r*r; ここのx座標
これはＸ座標ではなく、物体１と２のＸ方向の距離です。

>当たり判定のx座標です。
つまり物体同士の距離を表す図って事になりますよね。
うーん、それでも図は良く分かりません。

私は、
>No:60303 でたろうさんの作ったプログラムの物体１と物体２の当たり判定の円を絵に書いてもらえませんか。
とお願いしたハズなので、tの値それぞれの時に物体の存在する座標と当たり判定の範囲が分かればよかったのですが。
つまり、スタート地点(t=0)だと座標(7,0)に半径7の円を書いてもらって、これをt=1.0まで書いてもらえば良いんです。これを書くだけでかなりイメージ出来ると思うんですけど。

[たろう]

返信ありがとうございます。
最後までやるつもりです。
画像です。
ookamiさん
気づきませんでした。
＞計算量が少ないなどのメリットがあるから紹介してくださっていることを、理解していますか？
知りませんでした。こんな計算があるんだなとしか。

[softya]

この図は、No:60303 のものでしょうか？
だとすると円の半径は7ですので今の図だと移動距離に比べて円が小さいです。
それと半径は固定されているので最後の位置の(17,0)までずっと同じ大きさの円になります。

>知りませんでした。こんな計算があるんだなとしか。
当たり判定の正確さとＣＰＵの負荷はトレードオフです。
どこかで妥協しないといけません。
ある程度までは工夫で高速化出来ます。

[ookami]

>> ここまで皆さんが紹介されてきたアルゴリズムは、
>> どれも、すりぬけ(トンネリング)や、
>> 逆に当たっていないのに当たったことにしてしまう場合がある半面、
>> 計算量が少ないなどのメリットがあるから紹介してくださっていることを、理解していますか？
> 知りませんでした。

これまでの皆さんのアドバイスを振り返ってみましょう。



# No:58756
# １．移動のフレームレートを上げる。
# 1フレームの間に10回移動させてやっても結構平気だったります。こうすることでトンネリングの発生する確率はかなり低くなると思います。
# ２．円が移動してできた軌跡同士で当たり判定を行う。
# ただし、明らかに当たってない場合も当たってしまうと判断されてしまう場合があります。

# No:58896
# ある時刻と別の時刻では衝突していないが、その間の時間に当る可能性を見過ごしている。
# もちろん、この時間を短くすることによってより正確に判定することは可能であるが、
# 厳密な判定をするためには限りなく無限小に近い時間間隔で計算しなければならず、ゲームに必要な高速性を維持することができない。

# No:59054
# 線分交差法は厳密な意味で考えると駄目だとおもってます。
# ただ厳密性がどこまで必要かも考える必要がありますよね。

# No:59126
# この線分交差による判定方法がダメだということではなく、
# こういった状況が発生したときに、たろうさんの作っているゲームはそれが許容できるのかどうかということになってきます。

# No:59296
# v1 や v2 が r1 や r2 の 10 倍以上の大きさになっている場合にはやっぱりすり抜けてしまう現象が起きてしまう可能性が高くなってしまいます。



ちょっと挙げるの疲れてきましたが、
みなさんが、「いろいろな方法があるが、精度もいろいろだ」と
たろうさんに仰っているんです。

[ookami]

ちなみに、いまのところ、もっとも「正確」であるが、「計算が難しい(人によるけど)」のは、
softyaさんが示されているリンクの先にある、「移動する２つの球の衝突場所と時刻を得る」だと思います。
http://marupeke296.com/COL_3D_No9_GetSp ... ndPos.html

もっとも「正確でない」けれども「簡単」なのは、フレームの間のことは考えないことです。

[たろう]

softyaさん返信ありがとうございます。

＞この図は、No:60303 のものでしょうか？
＞だとすると円の半径は7ですので今の図だと移動距離に比べて円が小さいです。
＞それと半径は固定されているので最後の位置の(17,0)までずっと同じ大きさの円になります。
同じ円が書けなかったのでばらばらな円になってしまいましたが。同じ円です。すみません。
円で書くとどうなるんでしょうか？

ookamiさん返信ありがとうございます。
そうだったんですか、あまり考えていなかったので、全然気づきませんでした。

[softya]

>同じ円が書けなかったのでばらばらな円になってしまいましたが。同じ円です。すみません。
>円で書くとどうなるんでしょうか？

移動距離が1ピクセルづつに対して円の半径が７ピクセル(直径１４ピクセル)なんですが大体想像できませんか？
1cm毎ずらしながら半径7cmの円を１１個書くのと同じです。想像できないならグラフ用紙に書いてみたほうが良いと思いますけど。

>ookamiさん返信ありがとうございます。
>そうだったんですか、あまり考えていなかったので、全然気づきませんでした。

理解度が不明なので、もう少し詳しくookamiさん向けに返事してくださいね。
No:60503 と　No:60505 の内容にまったく触れられてません。

[たろう]

＞移動距離が1ピクセルづつに対して円の半径が７ピクセル(直径１４ピクセル)なんですが大体想像できませんか？
1cm毎ずらしながら半径7cmの円を１１個書くのと同じです。想像できないならグラフ用紙に書いてみたほうが良いと思いますけど。

そのつもりで書いたのですが・・・

[softya]

>そのつもりで書いたのですが・・・

本当に定規とコンパスで書いてみると分かります。1cmづつ移動する半径7cmの円ですよ。
フリーハンドで書いても絶対にこんな円の重なり方はしません。
信じてやってみてください。
こちらで答えを書いても良いのですが、それでは図形を考えるトレーニングになりませんので。

[ookami]

>> みなさんが、「いろいろな方法があるが、精度もいろいろだ」と
>> たろうさんに仰っているんです。
> そうだったんですか、あまり考えていなかったので、全然気づきませんでした。

もうちょっと書き方を工夫したほうがいいと思いますよ？
たろうさんが考えないで、他に誰が考えるんですか？

[Dixq (管理人)]

> たろうさん

規約に従って利用して下さっているにも関わらずすみません。
ここの掲示板の仕様上、１トピック内のレス数があまりにも多いと掲示板のトップページ全体に表示される最新トピック数が減ってしまうようです。
その為、更新から24時間経過していないトピックが過去ログに落ちてしまう場合がいくつか発生しています。

一応掲示板では１質問１トピックを基本とさせて頂いています。
話が長くなってしまう場合や、関連した話でわざわざ別にトピックを立てる必要が無い場合もあると思いますが、
なるべく後から見た人が解りやすいようにトピックごとに細かく質問をわけ、関連性が高い時は、前トピックのリンクを貼って頂けると幸いです。