推 yan04870449:受教了！謝謝。 08/06 23:25
→ reizarc:比較新的顯示卡都有 occlusion query 的功能 08/07 02:01
→ reizarc:不過不知道用在這種case合不合適 看到selection buf想到的 08/07 02:02
→ Splash5:有點像z buffer的感覺 08/07 15:07
※ 引述《yan04870449 (一片死寂)》之銘言：
: 可能畫的有點爛...不過書上大概是這樣子講的，右圖的判斷比較好寫
: ，但是相對的精準度比較低，左邊的當然精準度就提高了，但相對就要
: 多寫好幾行CODE，，這兩種我大概都知道怎麼寫，但是我想知道如果真
: 的要寫到完成是圖與圖相碰(圓與圓碰在一起)才算碰撞的話，理論上來
: 講應該要怎麼做，或者是說有什麼方向可參考呢？
比較傳統的作法都是兩個要素 距離 + bounding box
比較精準的作法就是再加上 三角面vs三角面
可以想想 你的圓如果最後是方塊圖片內的不定形狀 還會不會這麼容易比對?
前面我有提過碰撞在3D空間中的幾種方法.
不過你這case比較特殊.我想到了一個特殊作法.
整個畫面是固定大小的,ex.固定像素1024*768.
你可以用一個資料結構來做一個簡易的select buffer.
當有透明度圖片存在某個位置時,就在那些不透明的像素位置
填入select buffer對應的像素位置.
->填物件ID
然後當每一片圖片填完之後.
就可以知道某一個像素有沒有同時被多個圖片同時佔據=多個物件碰撞了
概念如此.
然後再來就是要加速整個過程,也盡量用較少的記憶體跟搜索的時間.
可以用down sample的方式來降解析度.
也可以用顯示卡來幫你作select buffer的寫入你再取回來判斷.
另外其實大部分情況是沒碰撞的(select buffer的堆疊<2),這也是一個加速的關鍵.
不過最後說不定你寫個
"2D圖片的圖片內容框線轉成3Dmesh的轉換器"
然後交給現成的物理引擎還比較快XD
--
"May the Balance be with U"(願平衡與你同在)
http://vision.twbbs.org/~ndark/
視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）論文代讀(含投影片製作)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.230.208.162