ゲームのための物理（力学）

**名前は開発中のものです。** · 02/04/08 17:38

ゲームに必要な物理（力学）を語るスレッド。

例えば、坂道を転がる球の加速度だったら。

その球の密度が一様ならば、慣性モーメントは(2/5)MR^2なので

dV/dt = 5*g*sinθ/7;

と表せるよとか。

他にも剛体運動、力積とか語ってください。

**名前は開発中のものです。** · 05/03/01 17:54:49

>>787
俺もパネキスレから来ました
GJ!です
これでジェットヘリ作ろうと思います

**名前は開発中のものです。** · 05/03/01 18:55:23

なぜかエラーが出て起動できない
自分のPCがぼろいからかな？

**名前は開発中のものです。** · 05/03/01 19:03:00

オリジナルのパネキットでも、こんな広場が欲しかったなー。
学生さん、ＧＪです！

**名前は開発中のものです。** · 05/03/01 19:31:40

>>787
私もパネキットスレから参りました。
いやはやすごいですね。>>807さんの言うとおりモデル作成をGUIでできれば
本当にヤバイことになりますね。
それはそうと、全体的な動きの遅さはどうにかなりませんかね？
なんだか空気の密度が濃い感じになってますよね。自分としてはもう少しストーンと落ちてくれれば面白いのですが。。。

**811** · 05/03/01 20:10:51

あ、すみません、limit 30FPSのチェックをはずせばいいだけなんですね・・・。
お騒がせしました。

**名前は開発中のものです。** · 05/03/01 20:55:52

リミッターはずしても早送りになるだけ
しかしすげー、すげーとしかいいようねぇ

**名前は開発中のものです。** · 05/03/01 21:40:09

>>809はダウンロード時が原因のエラーでした。解決しました

**名前は開発中のものです。** · 05/03/01 21:50:34

これを強化するためにプログラミング学習開始
それくらいにすばらしい。でもひどく時間がかかりそうｗ

**名前は開発中のものです。** · 05/03/02 03:08:37

Basic例にしたヘルプファイルなら作れそう
作ってみる

**名前は開発中のものです。** · 05/03/02 03:38:20

http://49uper.com:8080/html/img-s/43453.zip
作った、適当だからそんなに参考にならないかも

**名前は開発中のものです。** · 05/03/02 03:53:16

うわ直リンしてるし間違いあるしもうだめぽ
とりあえず間違い訂正
誤：4～8はASDZXC
正：4～8はCXZDSA
ttp://49uper.com:8080/html/img-s/43453.zip

**名前は開発中のものです。** · 05/03/02 04:02:19

作者じゃないけどつっこみ

>>818
Valのstepは、ボタン離したときの変化量
ボタンの並びはＺＸＣＡＳＤ
Trim(){}が入ってない。Trim(){}はパネキットでいうところのＺジョイント。
RLW(){}が入ってない。RLW(){}は無慣性モーター。タケコプター専用。

**名前は開発中のものです。** · 05/03/02 04:03:48

セルフつっこみ

>>819
×無慣性　○無反動

ＳＦあんまり読まないんだけどナ・・・

**名前は開発中のものです。** · 05/03/02 04:06:05

あっれ何か勘違いしてる
キー設定については嘘書いてあるかもなので信用しないでorz

**名前は開発中のものです。** · 05/03/02 04:08:02

リロードするの忘れてるしもうね
勘違いも多いし申し訳ない適当で

**名前は開発中のものです。** · 05/03/02 23:19:29

ちょっとスレ違いだけどみんなどんなソフト使ってる？

**名前は開発中のものです。** · 05/03/03 00:50:20

スクリーンショット取るならWinShotっていうソフトが便利ですよ。

**名前は開発中のものです。** · 05/03/03 01:28:24

>>796 ：学生さん紹介させて
頂きました
素晴らしいですよ。

http://cgp.zive.net/modules/news/article.php?storyid=719

個人的には、これもお勧めなんで是非触ってみて下さい。
http://www.natew.com/juice/

学生 · 05/03/03 01:55:11

紹介していただいてありがとうございました。
juiceはODEからのリンクで勉強させていただきました。面白いですよね。
ODEはほんとの円柱が使えないので、自作するはめになりました。（最近は三角メッシュがつかえるようですが）

僕は数学が強くないので、ここのスレをもっと早く知っていれば、心強かったなと思います。
あのソフトはヒンジ拘束を2点拘束でしていますが、暴れがひどいので、
10回も、収束ループをかましてます。チップにしたことで質量がほぼ同じ同士なので
何とか収束してくれています。
後、摩擦に関しては、いんちき係数と名付けた係数が内包されてますww。

なんだか、ここのスレの方にはパーティー開いて散らかしただけのような気がして申し訳なく思っています。
でも、こういうものをつくりたいという気持ちは大勢の人が持っていると思うと
ホントにうれしかったです。

**名前は開発中のものです。** · 05/03/04 00:14:43

こってり屋みたいに技術系webページを開いて欲しいなぁ。
質点同士の演算や高速化の話や形状の拘束とかいろいろ興味あるし。
または気が向いたら書く技術系Blogとか。

**名前は開発中のものです。** · 05/03/04 00:55:40

言いだしっぺの法則というものが存在する。

**827** · 05/03/04 07:10:37

分かりました、というわけで作ってみました

http://homepage1.nifty.com/kaneko/index.htm

**名前は開発中のものです。** · 05/03/04 11:47:35

('A`)

**名前は開発中のものです。** · 05/03/04 13:29:36

>>829

金子さんは、ny作ったよりもそこら辺尊敬するよな。
ソース分かりやすいし勉強になる。

**名前は開発中のものです。** · 05/03/04 13:35:21

誰かﾊﾟﾈﾙ表作ってくれ。
ﾊﾟﾈﾙ…CHIP
ﾌﾚｰﾑ…FRAME
Yｼﾞｮｲﾝﾄ…RUDDER
Xｼﾞｮｲﾝﾄ…？
Zｼﾞｮｲﾝﾄ…TRIM
ｼﾞｪｯﾄ･･･JET
ﾓｰﾀｰ…？
無感性ﾓｰﾀｰ…RLW

**名前は開発中のものです。** · 05/03/04 13:55:04

ﾊﾟﾈﾙ　　　　　chip(angle,color)
ﾌﾚｰﾑ　　　　frame(angle,color)
Yｼﾞｮｲﾝﾄ　　　rudder(angle,color)
Xｼﾞｮｲﾝﾄ　　　ない
Zｼﾞｮｲﾝﾄ　　　trim(angle,color)
ｼﾞｪｯﾄ　　　　　jet(angle,power,color)
ﾓｰﾀｰ・ﾀｲﾔ　　Wheel(angle,power,color)
無反動ﾓｰﾀｰ　RLW(angle,power,color)

chipやframeやjetやwheelやrlwのangle（取り付け角）を変化させればXジョイント相当
ただしtrimやrudderのangleはそれぞれの角度制御に使われている

あとパネキと違う所としては
同じ個所にいくつでもチップを取り付ける事ができる
↓こんな感じ
core(){
　N:chip(){}
　N:frame(angle=90){}
　N:chip(angle=180){
　　S:wheel(){}
　}
}

**名前は開発中のものです。** · 05/03/04 14:17:17

そうか、ただのチップもアングルに入力すりゃ動くのか。

**名前は開発中のものです。** · 05/03/04 16:53:52

パネキスレのあれはここで受け入れるの?

**名前は開発中のものです。** · 05/03/04 17:13:12

パネキスレもここも微妙にスレ違いになりつつあるから
新しく専用スレ立てようって流れになってるような気がするかもしれない

**名前は開発中のものです。** · 05/03/05 02:57:45

ゲサロに専用スレ立ったようだな。

**名前は開発中のものです。** · 05/03/05 08:13:43

んじゃそっちで。

**名前は開発中のものです。** · 05/03/05 08:29:42

ここだね
http://game10.2ch.net/test/read.cgi/gsaloon/1109958786/l50

**名前は開発中のものです。** · 05/03/08 13:59:39

AC(アーマードコア)みたいな
跳躍時のブースト部分作ってるのですが
とりあえず動きはしたのだけども
これでいいもんじゃろか

Vg = g * Tg　　　　 (自由落下)
Vb = v0 + a * Tb　(等加速度直線)

Vy = Vb - Vg

g、v0、aは適当な数値

Tgは地上から離れたらカウント開始
接地するまで。

Tbはブースト使用する度にカウントアップ
接地すると0へ。

ってな具合にやってるんですが
何ぞいい参考資料やら、アドバイスの程ありませんでしょうか
ロケット　推進力でググッたけど、なかなかないス

**名前は開発中のものです。** · 05/03/10 11:55:58

>>841
動いてるとこでも見ないとなんとも・・・
自分で気に入ったならそれでいいんでは？

**名前は開発中のものです。** · 05/03/10 16:38:35

うほ　人がいた

一応こんなんです↓
ttp://gamdev.org/up/img/2409.zip
Ｆキーで飛びます飛びます。
ちなみに壁との判定無し、なんかの拍子で落下しますので。

で、仮に100s間滞空してたとしたら
9.8 * 100 = 980[m/s^2]とかすんごい事になってそうなんで
なんかないものかと

**名前は開発中のものです。** · 05/03/10 17:06:26

とりあえず　タイムTに
捕らわれない式にしてみたりする。
ただ加算してるだけだがｗ

上のはTg Tb使ったままだが

**名前は開発中のものです。** · 05/03/10 23:50:31

>>843
その方向で行ってみよう。
プログラムは実行できる環境にないんで何とも言えない。

**名前は開発中のものです。** · 05/03/12 08:49:32

>>842
空気抵抗でも入れてみたら？
具体的な式が出てこなくて申し訳ないが、たしか速度の2乗に比例するはず。

**名前は開発中のものです。** · 05/03/12 19:18:32

いきなり
Vｙ = v0 + （a * boost - g) * Tb
boost : ブースト時１
　　　　　（０～１のアナログ値にするとスロットル調整出来る）
にすればVgとかVbの値が大きくなるとか気にしなくてもいいんじゃない？

**名前は開発中のものです。** · 05/03/12 20:34:15

>>845
これすね
ma = mg - kv
途中からワケワカラン状態で
v = C1 e^なんてらかんてら + mg / k

もう微分とか忘れてもた。

>>846
なるほど、こちらも試してみまっす

弾道等、タイムＴとか理解できるけど
速度や方向が常に変化する場合とか、ややこしいのう

**名前は開発中のものです。** · 05/03/12 23:12:16

ソニーは間違いですよ(´･ω･`)

**名前は開発中のものです。** · 05/03/12 23:12:45

おもいっきり誤爆orz

**847** · 05/03/13 20:24:21

>>846式をやっちみました。
ちょち説明しがたいですが

時間経過に伴って
Boostをオン・オフ(0か1か)した場合
Vyの振幅が大きくなっていく

なんのこっちゃ。
しかしながら、( a * Analog - b )は参考になりますです。
有り難く頂戴致します。

**名前は開発中のものです。** · 05/03/13 21:04:49

それはTbのせいかな？
ΔTｂのつもりだったんで毎スキャン計算するならTｂは定数でいいね。
V0も初期速度じゃなく前回値だし。

**名前は開発中のものです。** · 05/03/13 21:09:12

ぐはっ

くそ～　俺もまだまだ愚か者であった
簡単に考えてしもた

なるほど、もっかいやってみます

**名前は開発中のものです。** · 05/03/16 14:26:34

OpenGLで物理シミュレーションしようとしてるんですが、
dt+=(float)30/1000;
dy-=0.5*G*dt*dt;
てな具合にするとおもうんですが、

この場合の、dtはフレームレート33.3fpsを想定してるんですが、
SwapBuffers()で描画処理するとfpsはどうなってるのかわからないんですが、、
fps設定したり知る方法ってないですかね？
glutは使っていません。

メインループ内では、
if ((!DrawGLScene_01()))
{
done=TRUE;
}
else
{
SwapBuffers(hDC);
}
となっています。

**名前は開発中のものです。** · 05/03/17 00:23:11

fps決め打ち（・A・）イクナイ

**名前は開発中のものです。** · 05/03/17 02:05:10

>853
winmm.libをリンクしてtimeGetTime使え
timeGetTimeはアプリケーションが起動してからの時間がmsで取れる
てWin32APIの勉強もしろよ
ただし４９日以上連続で動作させるときは注意しろ

あと今回はhDCと書いてあるからWinだと判断できたが、質問するときはOSや
開発環境(コンパイラなど)も書くべし
Windowsとは限らないからな

**853** · 05/03/17 19:36:38

ありがとうございます。
＞ fps決め打ち（・A・）イクナイ
ということはtimeGetTime()使って、
描画処理後時間（もしくはSwapBuffers()後かな・・・？）－描画処理前時間から
fpsが得られそれをもとにdtを算出したほうがいいのかな？
となると、前フレームでのfpsが次フレームのΔｔになるってことかね・・

>855
もう遅いですが、WINDOWSXP＋VISUAL C++です。

**名前は開発中のものです。** · 05/03/17 23:44:14

>>856
ちょっとまて。
>描画処理後時間（もしくはSwapBuffers()後かな・・・？）－描画処理前時間から
得られるのはdtではないのか？

dt = 今回の描画時刻 - 前回の描画時刻

**857** · 05/03/17 23:51:40

ごめんちょっと読み違えた。

DrawGLScene_01()の前でtimeGetTimeするようにして、
前回との差分を求めればそれがdtになるんじゃないかなって言いたかったのです。

描画処理前後の時刻から実際に描画した時間を求めたいんだと思うけど、
描画後から次の描画処理までの間って一定であることは保障されないから
動きがぎこちなくなるんじゃないかねぇ。

**名前は開発中のものです。** · 2005/03/25(金) 01:59:37

>ただし４９日以上連続で動作させるときは注意しろ

廃人仕様のネトゲを作る時は数ヶ月電源切らないバカのためにも
注意しないとダメなのね。

**名前は開発中のものです。** · 2005/03/25(金) 13:01:51

いっそフリーズさせてやったほうが親切な気もするけどな……。

**名前は開発中のものです。** · 2005/03/25(金) 16:06:37

49日以上も間を置いて処理が前後するはずがない。
せいぜい数秒だろ？
timeGetTimeの時間が前に保存した時間より前になってたら
一周したんだと判断して上手く処理すればいい。

まあ、処理する箇所全てでそんなことやってたら面倒で死にたくなると思うが、
比較用関数でも作ればいいわな。

**名前は開発中のものです。** · 2005/03/27(日) 01:30:31

おいおい、マジで言ってるのか。
分岐せずに普通に減算するだけだろ

**名前は開発中のものです。** · 2005/03/27(日) 05:25:09

＞おいおい、マジで言ってるのか。
分岐せずに普通に減算するだけだろ

？

**名前は開発中のものです。** · 2005/03/27(日) 13:25:27

ごく小さな差を出すだけならキャストして減算するだけだね
２進数表現と２の補数をちゃんと理解して

**名前は開発中のものです。** · 2005/03/27(日) 13:41:00

コンピュータの世界も成仏するのに４９日かかるのか。。

**名前は開発中のものです。** · 2005/05/24(火) 14:58:58

**名前は開発中のものです。** · 2005/06/04(土) 09:20:36

**名前は開発中のものです。** · 2005/06/04(土) 12:33:02

3
ダー！！

**名前は開発中のものです。** · 2005/06/07(火) 13:01:59

元気デスカァー！！

**名前は開発中のものです。** · 2005/06/08(水) 07:25:38

元気があれば

**名前は開発中のものです。** · 2005/06/08(水) 12:51:30

なんでもできる

**名前は開発中のものです。** · 2005/06/09(木) 20:29:21

アリガトーー！！！

**名前は開発中のものです。** · 2005/06/12(日) 02:11:20

「こってり屋」のアーカイブを持っている人いませんか？
web archive でも見ることができなくて残念。

あちらこちらで良い評価をもらっているサイトなので、
一度見てみたいと思っているのですが、何とかなりませんでしょうか？

**名前は開発中のものです。** · 2005/06/18(土) 10:17:11

つ ttp://kotteriyald.hp.infoseek.co.jp/

**名前は開発中のものです。** · 2005/06/18(土) 11:17:56

age

**名前は開発中のものです。** · 2005/07/22(金) 01:19:28

>>874
違い過ぎて逆にわらた
漏れも、ア、アーカイブきぼん。

**名前は開発中のものです。** · 2005/08/02(火) 21:53:30

http://www.modulobe.com/ModulobeJa.html
>Modulobeは，モジュールと呼ばれる部品を組み合わせて，
>仮想生物を簡単に作れる物理シミュレーション・システムです．
いろいろうねうねしてておもしろげ

**名前は開発中のものです。** · 2005/08/04(木) 21:01:39

うーん、これは面白い…
この方向性でいろいろなものが生まれてきそうな気はするね。

**名前は開発中のものです。** · 2005/08/28(日) 09:48:10

ロープとか鎖みたいな物の動きを短い棒を沢山連結させる事で表現したいんですけど
（ヌンチャクを沢山連結させたみたいな）、
調べるにあたってそういう物理モデルとか計算手法なんかに名前はついてたりしますでしょうか。
キーワードがあれば教えてください。

**名前は開発中のものです。** · 2005/08/28(日) 10:26:55

もちろん棒自体は体積は持たせんし、バネのように伸縮もさせません。
両端を連結させたただの「線分」というか。

**名前は開発中のものです。** · 2005/08/28(日) 12:54:50

>>879
ttp://homepage1.nifty.com/kaneko/indexp2.htm

47氏のページだけど、ここにあるロープってのがまんまそれ、ただしPseud Physicsだけどね。

**名前は開発中のものです。** · 2005/08/28(日) 14:42:59

>>877　つながり
http://www.sodaplay.com/

既出だったらスマンコ

**名前は開発中のものです。** · 2005/08/28(日) 15:19:07

>>881
アレ関係以外で47氏って呼ぶのやめようよ……。

**名前は開発中のものです。** · 2005/08/28(日) 15:39:58

Pseud Physicsというのはどこかのローカル用語？
http://www.google.com/search?num=50&hl=ja&c2coff=1&q=%22Pseud+Physics%22&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=

で、何をもってインチキと呼んでいるの？
究極的には古典力学な時点でインチキ手法とすら言えるわけだが
よく分かりませんな、頭の良い人の考えることは

**名前は開発中のものです。** · 2005/08/28(日) 16:24:50

>>884
物理モデルの持ち方が力学的じゃない方法をつかってるからそう書いただけ。
文字通り擬似の意味で。

>>883
金子氏って書いたら別板でぶつくさ言われたからそう書いたんだ。
セミナーも行った位あの人の講義好きだったのにorz

**名前は開発中のものです。** · 2005/08/28(日) 16:26:17

>>884
君は pseudo random number を「インチキ乱数」と訳して
「何をもってインチキと～」などと喚きたてるのかね？
よく分かりませんな、頭の

**名前は開発中のものです。** · 2005/08/28(日) 18:00:21

>>885
だからその
>物理モデルの持ち方が力学的じゃない
ってのが具体的にどこを指しているのか知りたいんだけど。
周知とは思うけど、Verlet法は分子動力学の世界じゃ古くから使われてる手法だよね？
ロープのデモって数年前に一度見ただけだけど、他に特殊なことやってたっけ？

>>886
何その頭の弱そうな突っ込み

**名前は開発中のものです。** · 2005/08/28(日) 22:42:42

>>887
通常の物理演算モデルだと慣性モーメント使うけど、金子さんのABメソッド（銘々が違ったらごめん）の場合それとは全く異なる方式だよね？
そういう場合、元のリクエストのように通常の物理演算を期待している人に提示すると混乱の元になるのは明らかじゃないですか。

だから元リクエストに対しては擬似物理演算だよと言うべきと判断したわけなんだけど、そこら辺を考慮した上で擬似と言う単語にくってかかるのなら
なぜくってかかるのか提示してもらいたいものですが、いかがですか？

**名前は開発中のものです。** · 2005/08/29(月) 02:55:45

何も分かってないな。

慣性モーメントは、質点系の質量中心を基準点としたときの
角運動量の総和を角速度を用いて表した式に出てくる係数ってだけで、
ニュートンの法則を一定の制限を設けて弄くり回しただけのものに過ぎない。
何ら新しい、使わなければ擬似であるようなパラメータではないんだよ。

これは古典力学の本読めば第一章辺りに必ず書いてあること。
（ニュートンの法則自体が厳密に成立するのが古典力学までの世界なので
　>>884を書いたわけだが、そんな意図は全く通じなかったようだ）

大体、君の言う"通常の物理演算"ってなんだ？
>>879-880の彼は別に剛体の物理そのものを求めているようには見えないが。
大量の拘束を連ねた剛体を想定しているなら、
Featherstone's Articulated Body Methodぐらい実装してからクチを開けよと言いたい。

知識が圧倒的に足りてないのに適当に語るから、こんな風にボロが出るんだよ。
Pseud Physicsなんて不思議な単語使ってくるくらいだから十二分に予想は出来ていたけどね

**名前は開発中のものです。** · 2005/08/29(月) 08:56:46

なんかよくわからんけど>>889かっこいい

**名前は開発中のものです。** · 2005/08/29(月) 22:05:21

まぁいいじゃない、ボロが出たって。
>>881は親切心で書いてるんだし。

**879-880** · 2005/08/30(火) 02:30:10

で、私は何をキーワードに検索すればいいのでしょうか。
金子さんのはやや独自らしいのでできれば教科書的な方法をまずやってみたいと考えてます。
想定しているモデルを物理用語っぽくいうと何ていうのでしょう。

**名前は開発中のものです。** · 2005/08/31(水) 00:33:59

Verlet method
AB法 (Anime-Body method)
Advanced character physics

**名前は開発中のものです。** · 2005/09/02(金) 21:09:30

すみません、古典力学についての質問です。

初期位置：y=150
加速度： acc = 10
初速度： spd = 50
速度： spd = spd + acc
床の位置：y=200に水平

上記の条件で画面下に向かって落下する物体があるとして、
更新後の座標はy = 150+50+10 = 210です。
当然めり込みが発生するんですけど、座標と速度の補正はどうすればいいんでしょうか？

床と物体との衝突は完全弾性衝突だとすると、単純に速度を反転させるだけでよいのでしょうか。
レベルの低い質問ですが、めりこみの補正がうまくいかず悩んでいます。
宜しくお願いします。

**名前は開発中のものです。** · 2005/09/02(金) 21:38:06

床にぶつかる場合は、座標を更新せず、速度の方向だけ変えるのが一番簡単じゃないの？
速度がめちゃめちゃ速い場合、床にぶつかってないように見えて、みっともないかも知れないけど。

この例だと、２１０で床にめり込んでしまうから、座標は更新せず、１５０のまま速度だけ-60にする。

**894** · 2005/09/02(金) 22:15:30

レスありがとうございます。
したの図のような状況になってしまうので、できれば正しい位置に補正したいのですが、
その場合に速度を－６０にしてしまうと跳ね返り後に不自然に加速してしまいます。

何か良い方法は無いのでしょうか？

　○　←本来はこっち
　　　＼　　　　　／
　●　＼　　　／　←座標補正しないと軌道がずれる
＿＿＼＿＼／＿＿＿
　　　　＼／　　　　

**名前は開発中のものです。** · 2005/09/02(金) 22:28:59

>>896
それだと、挟み撃ち法かなんかで、正確な衝突位置と時刻を計算して、
その時刻での速度を計算して、床の面で反転させて移動先を求めるしかない気がする。
そんなメンドウなことやったことないから、上手くいくかわからないけど。

**名前は開発中のものです。** · 2005/09/02(金) 22:29:12

アスキーアートに頑張りの後が見えたのでヒントだけ
http://jun.artcompsci.org/~makino/papers/ode/node6.html

**名前は開発中のものです。** · 2005/09/02(金) 22:34:23

>>896
Y速度が50なんだから、バウンドした量も含めて縦に50移動してればOK
一度方眼紙に書いてみれば感覚がつかめると思う。

この場合、めり込んだ10だけ跳ね返ったy=190が正解だと思うよ。
速度は-50+(40-10)*10/50を減衰させればいいかな？(自信ない)

**名前は開発中のものです。** · 2005/09/02(金) 22:44:25

>>899 なるほど

**名前は開発中のものです。** · 2005/09/03(土) 09:32:02

厳密ではないけど誤差を１０分の１に小さくする方法はあるよ。
移動速度を１０分の１にして、毎回１０回計算する。

**894** · 2005/09/03(土) 12:03:33

みなさんありがとうございます。
＞速度は-50+(40-10)*10/50を減衰させればいいかな？(自信ない)
これの(40-10)というのはどういう意味の計算なのでしょうか？
質問ばかりですみません

**名前は開発中のものです。** · 2005/09/03(土) 15:03:50

>>902
(壁に衝突するまでの距離－そこからの余剰分のベクトル)じゃ無いの？
いや、詳しくはわからんけど。

**名前は開発中のものです。** · 2005/09/04(日) 03:37:01

こういう風にめり込みを考慮した衝突を表現する場合、どういう力学の公式を適用すればよいのでしょうか？

こんな、ごく単純にボールが自然落下して床に当たって跳ね返るだけの処理で悩んでいるようでは
ゲームプログラマとしては才能がないのでしょうか・・・（´；ω；｀）

**名前は開発中のものです。** · 2005/09/04(日) 04:14:12

問題点を判っててしかも放棄して無いんだから資質はあるんじゃね？

っていうかやけに単位が大雑把な気がするけど何のゲーム作ってるんだろ？
厳密な計算はいくらやってもキリが無いからある程度の妥協は必要だぞ。

**名前は開発中のものです。** · 2005/09/04(日) 04:24:58

>>904
> こんな、ごく単純にボールが自然落下して床に当たって跳ね返るだけの処理で悩んでいるようでは
>ゲームプログラマとしては才能がないのでしょうか・・・（´；ω；｀）
ここはマジレスしてあげよう。
こういう問題で精度と計算結果が重要視されるのはシミュレーションや大学の論文。
で、ゲームプログラマーというかアミューズメント系はこういう場合ゲームシステムやプレイ感覚に与える心理的影響や
ゲームシステム上の不具合が発生しない方向を最初に検討してから対処する事になる。
つまり考え方とか方法論がはじめから違うのだ。

だから君が悩むべきは自分の作っているゲーム世界での影響を排除（あるいは許容する範囲の決定）であって
必ずしも数式的、物理的に現実に添うことではないのだよ。

#いまだプロでなくアマチュアであってなおかつ学生であるのなら悩んで当たり前だから、悩む事自体を楽しめるようになりたまえ。

**名前は開発中のものです。** · 2005/09/04(日) 06:22:05

>>906
言ってることは至極真っ当だが言い方がエラいムカつく