【HSP】HSPで３Dゲーム　４　【３D】

**名前は開発中のものです。** · 2008/12/13(土) 13:20:15

HSPで３Dゲームを作る人のためのスレ。
ﾏﾀｰﾘﾏﾀｰﾘ

■過去スレ
【HSP】HSPで３Dゲーム【３D】
http://pc11.2ch.net/test/read.cgi/gamedev/1016699230/
【HSP】HSPで３Dゲーム　２　【３D】
http://pc11.2ch.net/test/read.cgi/gamedev/1181967317/
【HSP】HSPで３Dゲーム　３　【３D】
http://pc11.2ch.net/test/read.cgi/gamedev/1210197298/

■makimo.to
ttp://makimo.to:8000/cgi-bin/search/search.cgi?q=HSP+3D&sf=2&all=on&view=table

**名前は開発中のものです。** · 2009/08/31(月) 16:45:55

HSPの開発環境で市販のゲームと比較とか馬鹿ですか？

**名前は開発中のものです。** · 2009/08/31(月) 16:57:32

今の時代はノート主体だろ。

**名前は開発中のものです。** · 2009/08/31(月) 18:14:48

>>434
HSPだろうと3Dゲーを作るんだったらそれなりの物をつくりたいとか思わないの？
高画質の3DゲーはHSPじゃ無理ってのが君の考えらしいけど
実際のところHSPが遅いのはrepeat等で計算をループしたりするような部分であって
3D描写の処理はC++でコンパイルしているからDLLを使う元がHSPであろうがC++だろうが関係ないんだよｗｗｗ

**名前は開発中のものです。** · 2009/08/31(月) 18:38:21

「それなりのもの」レベルを目指すならともかく
市販レベルを目指すなら最初からHSPなんて選択しないし、そもそもEasy3Dなんかに頼ったりしない
それすら理解できないほど馬鹿なの？

**名前は開発中のものです。** · 2009/08/31(月) 18:53:54

それなりのものをE3Dで作ってくれるとはなかなか頼もしい言葉だ
勇気付けられた

**名前は開発中のものです。** · 2009/08/31(月) 19:36:01

晒しあげ

**名前は開発中のものです。** · 2009/08/31(月) 19:47:52

>>437
馬鹿、馬鹿、さっきから罵倒してばっかだけど
そういう君は具体的な理由を何一つ述べずにHSP≠高クオリティをくり返し言ってるだけ
何故Easy3Dを使ったら市販レベルの画質を目指せないって言い切れるの？
プログラミングが得意で何から何まで全部自分で作り上げたいって言うのならまだしも
得意じゃないからHSPを使う人が多いと思うんだけどｗ
そういう意味でモデラーにも優しいHSPで3Dゲーを作れるEasy3Dはとてもいいと思うよ
難しいところを全部DLLでやってくれるしね
高度な敵AIを作成するなんてのはHSPじゃきついだろうけど
HSPの時点で画質を諦めちゃうのはちょっと早すぎじゃない？
というか3D描画の部分はC++でコンパイルしてるってさっきも言ったしな
少なくともSM2.0は実装してしかるべき。5年も前から標準モデルだぜｗｗｗ
今SM1.xを搭載してるPCなんてどちらにしてもCPUがしょぼすぎてまともに動かないっての

**名前は開発中のものです。** · 2009/08/31(月) 19:58:25

開発環境はそれなりでもよいけど

ターゲット側、プレイ側PCは敷居が低くないと遊んでもらえない。
利己的な人は視野が狭いから、一般的な環境を知らないのだろう、
CPUは強いが、恐ろしく3Dに弱いPCが一般的だ

**名前は開発中のものです。** · 2009/08/31(月) 20:39:01

>>441
利己的とおっしゃいますが、より良い品質のものを作ろうとする心構えのどこが利己的なんでしょう？
SM1.x切捨てに反対するのは利己的だと思うけどさｗ
あと話の筋から察するに、恐ろしく3Dに弱いってのはSM2.0対応じゃないってことでいいのかな？
どちらにしてもソースだせよ

ttp://www.techpowerup.com/gpuz/stats.php
ちなみにこの統計少し古いと思うんだけど、
ここ見る限りDirect8以下が7%だからSM1.xもそのくらいじゃないの？
一般的って言うにはちょい少な過ぎるんじゃね？ｗ

**名前は開発中のものです。** · 2009/08/31(月) 22:27:25

あんま相手にすんなって。

　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！どんなパソコンでも動かないとヤダ！
　　　　　　｀ヽ_つ＿_つ
　　　　　　　　　　　　　　ジタバタ

コレどう考えてもアタマ足りないガキでしょ。

**名前は開発中のものです。** · 2009/08/31(月) 23:06:10

2.0未満を切るのはおちゃっこ氏でなく、ゲームを作る個人に任せればいいんじゃないかと思うんだ。

**名前は開発中のものです。** · 2009/09/01(火) 00:07:28

E3Dを利用するかどうかも、ゲームを作る個人の判断に任せられてるわな。

E3D作者の意向に不服があるのなら、早めに別のツールに切り替えることだ。
そういう、ユーザーに使ってもらえなくなるリスクを踏まえたうえでの決定だろうからな。

**名前は開発中のものです。** · 2009/09/01(火) 00:57:14

「RokDeBone2 モーション、ゲーム作成キット」で
ピクセルシェーダー２．０未満の安定版の集めたものを出してくれれば良い。
古いビデオカード対応版のような
そうすれば「まとめ」になるし、区切りも良い。

以降の最新バージョンは、PS3.0でも、DirectX12でも構わないし
ある意味で、古いカード切り捨ての方がよい。

DirectX9の情報からは本当のハード情報が取れないから
カード毎に調査しないと動作の保証が難しい部分があるだよ

**名前は開発中のものです。** · 2009/09/01(火) 00:59:35

現実問題、相当腕のあるニートでもない限り
一人で市販並みの3Dゲーなんて技術的・時間的に無理だわな

**名前は開発中のものです。** · 2009/09/01(火) 01:04:34

互換性気になるならもうHGIMG3でいいんじゃないの。
作る人次第では凄く出来が良いのもあるし。
それでも不満があるならプラグイン自作とか。

たぶんE3Dはゲーム製作者にとってEASYなプラグインという路線みたいだから、ある程度スペック要求するのは仕方ないと思うよ。

で、ハードのこととかよくわからんけど、現状をまとめると
・今のEasy3Dは現状、ピクセルシェーダー2.0より古いものは切り捨て。つまりDirectX9.0より古いものは切り捨てという意味。
・DirectX9.0が出たのが2002年12月？（Wikipediaより）
・最近はネットブックタイプが普及中。

切捨ての是非を考えるなら、
・事実上どの程度のユーザー（ユーザー数やPCスペック）が切り捨て対象となるのか。
・切り捨てなかったとして、最近のポリやボーン、モーションデータが増えたゲームを支えられるスペックがあるのか。
・切り捨て対象ユーザーに3Dゲームへの需要があるのか。
・どのくらいのスペックが普通なの？
この辺が論点な気がするが…あってる？

>>444
選べるということは、環境依存を考慮した設計やプログラミングをしないといけなくなる。
新しい機能も積極的に使ってもらえなくもなる。
…ということだと思う。たぶん。

**名前は開発中のものです。** · 2009/09/01(火) 01:42:17

作り手の立場からすると、
時間が限られているから、手間が増える事はやらない。
一行を追加する程度で効果が大きければ加えてみるかもしれない。
AIとか物理エンジンとかなら欲しいと思う。
時間短縮になるようなツールなら欲しいと思う。

**名前は開発中のものです。** · 2009/09/01(火) 08:19:29

古い環境を切り捨てたらEasy3Dが普及するとでも？

**名前は開発中のものです。** · 2009/09/01(火) 11:24:15

進化するために必要なことなんだから潔く諦めろ

**名前は開発中のものです。** · 2009/09/01(火) 11:49:59

Windowsの歴史は進化が必ずしも良い事だとは言ってないけどなｗ

切捨ての判断なんて結局自分自身の判断でするしかないな
動作環境が広ければ喜ぶ人がいるのも間違いないし
広がった表現を歓迎する人もいる訳だしな

**名前は開発中のものです。** · 2009/09/01(火) 11:59:29

ピクセルシェーダー2.0未満のPCなんて今の時代に売っているものなの？
ネットブックでも2.0や3.0以上はあると思うんだけど
今は、ネットブックが最低スペックだから、これで動かせれば無難ではないのかな

**名前は開発中のものです。** · 2009/09/01(火) 12:45:29

PCを壊れるまで使い続ける人と、新しいPCを買い換える人の2タイプがいるが
e3dは後者向けってことで。

**名前は開発中のものです。** · 2009/09/01(火) 13:38:12

Easy3Dに切り捨てられた私のノートは
P4-2.8GHz、メモリ2GB、1680x1050ピクセルでこれといって不満がないので買い換える必要を感じません
というのは少数派なのか

**名前は開発中のものです。** · 2009/09/01(火) 13:55:29

それいつのPC？
俺も5年前に買ったやつがP4の2.8GHｚ×2でメモリ2Gだけど、
シェーダー2.0対応してたよ

**名前は開発中のものです。** · 2009/09/01(火) 13:56:30

ゲーマーくらいだろう、毎年買い換える奴なんて。
一般的にPCを家電と考えるならスパンは5年以上じゃね。決して安くないし。

**名前は開発中のものです。** · 2009/09/01(火) 13:56:46

ノートで3Dゲームのプレイや開発をするのが少数派

**名前は開発中のものです。** · 2009/09/01(火) 14:35:21

安いと噂のマウスコンピュータのさらに一番安いノートでも
ピクセルシェーダ3対応だったよ
2.0未満の人はこれを期に買い換えたら？

**名前は開発中のものです。** · 2009/09/01(火) 14:42:26

心配なのは、これからどんどんと切り捨てていく仕様になってしまうことなんだ。

**名前は開発中のものです。** · 2009/09/01(火) 16:18:47

それは心配のしすぎだな

**名前は開発中のものです。** · 2009/09/01(火) 17:47:26

SM2.0ですら時代遅れだと思うけど
5年以上のマシンは中古でもジャンク扱いだし、何時壊れるかわからない
実際自分が低スペックテスト用に買ったPen3のマシンも壊れちゃったからね

**名前は開発中のものです。** · 2009/09/01(火) 18:16:55

Windows7が発売されたらDirectX9以前は全部切り捨てでいいよ

**名前は開発中のものです。** · 2009/09/01(火) 18:19:43

ちょ、いくらなんでもそれは早杉ｗ
まだ半分くらいはXPユーザーじゃん

**名前は開発中のものです。** · 2009/09/01(火) 20:22:39

>>463　発売されてもすぐにみんな買うわけじゃないんだから。
それに9x系、2k、Meからの買い替え派でも１年ぐらいは様子見するんじゃないかな。

> まだ半分くらいはXPユーザーじゃん
あくまでうちのサイトの統計だけど、
XP...63%
Vista...29%
他...8%
うちは企業が見に来るとは思えない内容だからほとんどが個人ユーザーだと思われ
半分じゃすまないね。

>>460　DirectX10以降はVistaより古いものは切り捨てなんだってね。

>>455　大事にしてあげてください。

５年は買い替えの目安とかパソコンの寿命とか言われてるみたいだけど、５年前の標準的なスペックってどんなもんだっけ。
５年前のハイスペック機じゃなくてね。

**名前は開発中のものです。** · 2009/09/01(火) 21:01:33

国内メーカーの普通の個人向けなら、
Pen4 2～3Ghz、メモリ256～512MB、GPUはインテル内臓のGMA以前じゃね。

**名前は開発中のものです。** · 2009/09/01(火) 21:09:14

DirectX10はピクセルシェーダー4.0だな
以降するのは相当先の話だろうけど待ち遠しいわｗ

ところでRokDeBoneの座4でボーンをIKすると、青いマニピュレーターの軸でしか回転しないよな？
緑のマニピュレーターは動きすらしないし
何ゆえこの仕様？

**名前は開発中のものです。** · 2009/09/01(火) 21:29:58

>>467
こーゆーこと。
ttp://www5d.biglobe.ne.jp/~ochikko/rdb2_za4.htm

**名前は開発中のものです。** · 2009/09/01(火) 21:53:21

おおすまんよく見てなかった、ありがとう
これだとIKの階層を深くしたときに変な方向に曲がらないってことか
しかしせっかく角度制限があるんだし
指定軸で全方向に動かせるモードがあれば便利だと思うんだがどうよ？
この想い、おちゃっこ紳へ届け！

**名前は開発中のものです。** · 2009/09/01(火) 22:34:08

>>466　thx
GMAは2004年発表で、ピクセルシェーダ2.0対応か。そういうころなのね。（by Wikipedia）

5年前(2004年)自分でも調べてみた
GeForce6が登場したようですね。１年型遅れで手ごろな価格のものが普及品と考えると１世代前のGeForceFXが標準と見てよさそう。発表も2002年だし妥当だと思う。
そういやうちでも5年以上前のPCにFX刺さってた。…このPCがまた最近不調でね、たまに起動しなくなるんだ。
あと、RADEON9700が2003年には出てるみたい。
オンボードだとSiS760が前年発表されたもの。こいつはピクセルシェーダ1.3対応。
ノートパソコンは2003/2004年発売品をざっと見てみたけどピクセルシェーダ2.0対応とそうでないものが混在してた。

オンボードやノートを考えると切り捨てるには微妙な時期な気がするかもしれないが、プラグインが出来てからゲームを作るまでの開発期間を考えればそろそろ切り捨てていい時期だと調べてみて思った。

> 指定軸で全方向に動かせるモード

いってる意味がわかりにくい。例えばどんな感じのことがやりたいの？
kwsk

**名前は開発中のものです。** · 2009/09/01(火) 23:21:24

要するに、座4と同じように軸方向が設定できて
座1、2、3と同じように一つの軸方向以外にも動かせる
ってことだ
これなら好きな方向に好きなだけ角度制限を掛けられるだろ？
座3でも微妙に軸方向が目的のそれからずれてて、角度制限を掛けるのに苦心している人は俺以外にも沢山いるはず

**名前は開発中のものです。** · 2009/09/02(水) 06:42:18

モーフィング対応版が出た。
ttp://www5d.biglobe.ne.jp/~ochikko/rdb2_morph.htm

**名前は開発中のものです。** · 2009/09/02(水) 09:05:52

RokDeBoneにmqo入れたとき、ボーンは作られてなくてジョイントしか認識されないじゃん？
開く度に一々ボーン作るの面倒なんだがどうすればいいかね？

RDBの質問てここかCG板でするか迷うわ…

**名前は開発中のものです。** · 2009/09/02(水) 09:33:26

>>473
くりぼーさんのメタセコプラグインBoneCreate

**名前は開発中のものです。** · 2009/09/02(水) 12:58:32

>>474
(´･ω･)やっぱプラグイン使うしかないんかね？

**名前は開発中のものです。** · 2009/09/02(水) 13:55:20

シェアにするか、bonファイルを利用するか。

**名前は開発中のものです。** · 2009/09/02(水) 15:35:05

>>473　あと２通りある。
１．メニュー：File -> 形状ファイルインポート
２．mikoto形式

>>471　なるほど。角度制限というより軸を限定させるのね。もしやるならモデル上に軸を表示してもらいたいね。

**名前は開発中のものです。** · 2009/09/02(水) 16:13:29

せめてどの座標表示を使うかをボーンごとに個別に設定できれば作業が格段に楽になる
例えばボーン1は座1で、ボーン2は座4という感じ
動かすボーンを変えるごとに上のボタンで切り替えるのは面倒すぎて死ねる

**名前は開発中のものです。** · 2009/09/02(水) 16:58:26

>>477
ありがとう
やってみるわ

**名前は開発中のものです。** · 2009/09/02(水) 17:27:16

Rokdebone2で何かするたびにダイアログが出るのがウザイ

**名前は開発中のものです。** · 2009/09/02(水) 18:13:36

3Dゲーム・クックブック HSP+Easy3D入門って本買って学べば
ttp://doom15.blog.shinobi.jp/Category/26/
↑のFPSみたいなのは作れるようになるかな？

**名前は開発中のものです。** · 2009/09/02(水) 20:18:27

付属のサンプル見て無理なら本読んでも無理

**名前は開発中のものです。** · 2009/09/03(木) 01:47:57

確かにRDBのインターフェイスのブラッシュアップを
そろそろやってもらいたいよなあ。

**名前は開発中のものです。** · 2009/09/03(木) 17:35:29

RDBのグローバル座標のマニピュレーターっておかしいよな
メタセコと比べたらよくわかる。

**名前は開発中のものです。** · 2009/09/03(木) 19:11:27

>>483　マジメな話、プログラマーに優れたUI作れとか無茶だよ。いろんな意味で。
でも、まああのUIは何とかしてほしいね。たくさん機能ついてるのにもったいない感じがする。

**名前は開発中のものです。** · 2009/09/03(木) 21:33:25

だったら良いと思うUI案でも出してみたら？

彼も自覚はあるようなこと言ってたし

**名前は開発中のものです。** · 2009/09/03(木) 21:46:36

MMDみたいにモーションのタイムラインをボーンの数だけ複数行表示して欲しい

**名前は開発中のものです。** · 2009/09/03(木) 22:58:57

モーフのマニュアル、ワケわかめ

**名前は開発中のものです。** · 2009/09/03(木) 23:06:17

MMDより、RokDeBoneの方が、直感的に操作しやすかったよ。
いまだにMMDは操作方法がよくわからん。

**名前は開発中のものです。** · 2009/09/04(金) 11:57:55

>qua保存のモードを名前基準のみにしました。
>読み込みは番号基準のものも出来ます。

RDB5200以降のquaは読み込みのとき、
ボーン構造が全く同じでもボーン名が違うと
エラーはいて強制終了しちゃうみたい。

製作途中でやっぱりボーンの名前変えたほうが良かった、なんて時や
いつどのボーン名を変えたかが分からなくなってしまったなんて時に
今まで作ったquaが全て使い物にならなくなってしまうので
従来の方法が良いのでは？

**名前は開発中のものです。** · 2009/09/04(金) 12:11:04

確認ダイアログ出してOKしたら読み込みだな

**名前は開発中のものです。** · 2009/09/04(金) 21:51:03

E3DVec2CCWのCCWってなにの略かわかる？

**名前は開発中のものです。** · 2009/09/04(金) 22:04:30

>>492
カウンタークロックワイズ
だと思った。反時計回り。

**名前は開発中のものです。** · 2009/09/04(金) 22:26:50

ttp://ja.wikipedia.org/wiki/CCW
Countryside Council for Wales. ウェールズ地方協議会だと思ってた

**名前は開発中のものです。** · 2009/09/04(金) 22:38:54

>>490　いつの間にそんな仕様が…！
ボーン名称が異なるモデルへのモーション移植とかもRDB単体では出来なくなるね。

>>489　全体的に使いにくいけど、487が言うように部分的に優れてるところもあるよね。

**492** · 2009/09/04(金) 22:55:24

カウンタークロックワイズね、ありがと。

**名前は開発中のものです。** · 2009/09/05(土) 00:11:27

すっごい必殺技っぽい響き

**名前は開発中のものです。** · 2009/09/05(土) 05:51:45

E3DVec3Lengthの二次元版ってありませんかね？
もしくはそれに似たe3d以外の関数があるならそれでもいいのですが

**名前は開発中のものです。** · 2009/09/05(土) 11:49:02

veczが0なら２次元になるじゃないか。まあ、vecx=0でもvecy=0でもどれか１個以上が０にすればいいわけだけど。
E3DVec3Lengthは、
length = sqrt(vecx*vecx + vecy*vecy + vecz*vecz)
としてるだけだよ。ベクトルの教科書見てくるといいよ。

ちなみに２次元(XY平面)だと
length = sqrt(vecx*vecx + vecy*vecy)
こうね。vecz=0のときと同じでしょ。

**名前は開発中のものです。** · 2009/09/05(土) 12:09:56

sqrtはマイナスの値だと、エラーがでるから面倒なんだよね
一回絶対値になおしたほうがいいよ。

**名前は開発中のものです。** · 2009/09/05(土) 12:56:20

>>499の式なら絶対にマイナス値にはならないけどね

**名前は開発中のものです。** · 2009/09/05(土) 13:05:22

>>500はvecxが虚数だった場合のことを心配してるんだよ。
HSPの変数は虚数は扱えないけどね。

**名前は開発中のものです。** · 2009/09/05(土) 15:07:04

>>499
それをHSP上でやるとE3DVec3Lengthを使うより重くなるんです。
なのでE3DVec3Lengthの二次元に特化したのが有ればもう少し処理速度を
稼げるのではないかと思い質問させてもらいました。

**名前は開発中のものです。** · 2009/09/05(土) 17:35:02

>>503
499のちなみにより上だけ見ろ。

**名前は開発中のものです。** · 2009/09/05(土) 17:48:45

>>503
そんなに頭固いと後々苦労するよ

**名前は開発中のものです。** · 2009/09/05(土) 17:55:31

>>503
ごめんなさい。説明が少しわかりにくかったですね。sqrtを使った式をそのまま使ってしまったんですね。
もっと丁寧に説明してみます。

E3DVec3Length命令の中では、HSP風に計算式を書くと
length = sqrt(vecx*vecx + vecy*vecy + vecz*vecz)
という計算式を使って計算しています。実際には、DirectX（のD3DXVec3Length）を使ってハードウェアに計算を投げていると思いますが使っている式は同じです。
ですので、例えばveczを0.0にして計算するということは、
length = sqrt(vecx*vecx + vecy*vecy)
という式を使っていることと同じ意味になります。この式は２次元ベクトルの長さ（距離）を求める式と同じですね。（数学の教科書参照）

つまり、１行目で書いたとおり、引数のどれか一つに0.0を指定し、残り２つの引数を使って計算してください。
例えば座標(0,0)から座標(vecx, vecy)までの距離を求めたいときは、
E3DVec3Length vecx, vecy, 0.0, length
とすれば、lengthに答えが代入されます。これなら重くなることなく同じ時間で計算できますね。

それでもどうしても速度を追求したいのであれば、D3DXVec2LengthをE3Dでも実装してもらえるようお願いしてはどうでしょう。
よほどたくさん使わない限り微々たる物だと思いますが。

**名前は開発中のものです。** · 2009/09/05(土) 20:00:02

ただたんに503はsqrtで計算するよりE3DVec3Lengthのほうが速かったっていってるんだろ？

**名前は開発中のものです。** · 2009/09/05(土) 20:19:10

>>507
503以外の人はE3DVec3Lengthの引数の一つを0にすれば
結果は同じ（=二次元版を探す必要は無い）って言ってるんだよ

**名前は開発中のものです。** · 2009/09/05(土) 20:25:42

話がかみ合ってないね
498 E3DVec3Lengthの二次元版って無いでしょうか？
499 Zを0にすればE3DVec3Lengthでも二次元計算できるよ、ちなみに二次元の計算はこんな感じ、ほら三次元のZを0にしたのと同じでしょ？
503 (499の二次元計算の部分だけしか見えてない)HSPでsqrt使ったら重かったんです
506 いや、だからE3DVec3LengthでZを0にして使えばsqrt使わなくても二次元の計算ができるんだってば

**名前は開発中のものです。** · 2009/09/06(日) 12:07:37

モーフってターゲットを入れればsigもでかくなるし処理も重くなる？
モーフをウェイト調整が難しい肩や脇とか股とかの調整に使うなんてのは
無謀なのかな？

**おちゃっこ** ◆RyN5mfp1Kg · 2009/09/06(日) 13:17:05

>>510
お、やっとモーフィングへの反応があった！
２０日間もかかって実装したのに反応が薄くて
おじさんさみしかったよ（笑）

重くなるか？との質問ですが。
モーフはまずターゲットの数分パラメータをミックスします。
この際ブレンド率が０のものは無視されるので重くなりません。

しかし一番速度に関係するのはミックスしたデータのビデオメモリへの転送です。
毎フレームミックス後の頂点データを転送します。
頂点数が多いほど遅くなります。ターゲットの数は関係しませんが。
パスの遅い古いマシンだと結構影響あるかも。

影響度はベース形状のものしか考慮しないので
シビアな影響度の部分には難しいかも。

>>488
どの辺がわかりずらいですか？
直そうかな。

**名前は開発中のものです。** · 2009/09/06(日) 15:38:33

RokDeBone2の影響度4(○○-ジョイント-シリアル△△って書くやつ)の設定ってどうやって保存するん？
bonファイルには保存されてないし、im2ファイルを保存してもダメだった

**名前は開発中のものです。** · 2009/09/06(日) 16:16:18

>>512
sigファイルにパーツ名として保存される。
シリアルはいらない。-は一個。
「表示パーツ名-ボーン名」

**名前は開発中のものです。** · 2009/09/06(日) 16:47:41

>>513
ありがとう
助かったー

**名前は開発中のものです。** · 2009/09/08(火) 21:40:37

質問です。

HGIMG3の地形メッシュマップにて、
上り坂を歩行する場合、坂の角度に応じて
歩行速度を落としたいのですが、どうしたらいいでしょうか？

**名前は開発中のものです。** · 2009/09/08(火) 22:22:03

>>515
進行方向に当たり判定を２つ並べて、その差が大きいとスピードを落とすようにすればヨシ！
ベクトル計算？三角関数？ナニそれ？

**名前は開発中のものです。** · 2009/09/09(水) 00:25:27

三角関数くらいは知っておいた方がいいぞｗｗﾜﾛﾁ

**名前は開発中のものです。** · 2009/09/09(水) 03:06:35

>>516は、余計な数学を使わないでもアイデア次第で出来るってことを言いたいんだろうが、
それを差し引いても、言っていることがよくわからない。

その差ってのが、何の差なのかよくわからない。
おそらく当たり判定同士の距離だと思うが、空間距離なのか、軸に射影した距離なのかは不明。

**名前は開発中のものです。** · 2009/09/09(水) 03:11:08

一応、言っておくが、移動後の高さを見ているだけなら、
当たり判定なんていらないぞ。キャラのy座標を見ればいいんだからな。

**515** · 2009/09/09(水) 05:19:18

>>516-519
回答ありがとうございます。

地面の法線から坂の角度を割り出そうとしていました。
が、挫折しました。(旋回すると角度が変化する所で)

移動前、移動後の高さの差でやってみようと思います。

**名前は開発中のものです。** · 2009/09/09(水) 07:19:53

床の法線は取得できるのね
なら床の法線ベクトルをN=(nx,ny,nz)、キャラの向いてる方向ベクトルをP=(px,py,0)としてNとPの内積を使ったらどう？
具体的には係数kを使ってキャラの速度を
speed -= k*(nx*px+ny*py)
といった感じに変更する
ちなみに k=speed だったら、90度の上り坂で速度0、90度の下り坂で速度2倍、
平坦な場所で速度1倍って具合になるよ

ゲーム制作頑張ってね

**名前は開発中のものです。** · 2009/09/09(水) 07:25:09

ごめん、
speed += k*(nx*px+ny*py)
だったｗ

**名前は開発中のものです。** · 2009/09/09(水) 17:16:27

>>521-522
（１）普通は、y座標を高さにする。
（２）spped += k * （内積）だと、
　　　内積が0になる90度では、speed += 0 で、キャラの速度はspeedになるはず。
　　　つまり、キャラの速度は0にならず、地面にめり込む。

**名前は開発中のものです。** · 2009/09/09(水) 17:25:49

あ、失礼（２）は違う。

**名前は開発中のものです。** · 2009/09/09(水) 18:20:45

法線との内積だから上手くいくはずだぞ、
ちなみに地面の角度に沿って移動するのを前提とした話であって
めり込むとかそういうのは別問題
あとHGIMGは左手系だったのね、使ったこと無いから右手系だと勝手に思い込んでたわ
だったらP=(px,0,pz)に変えて
speed += k*(nx*px+nz*pz)
とすればおｋ

**名前は開発中のものです。** · 2009/09/09(水) 18:29:31

k = speed
じゃないとき、跳ね返りがおかしくなったりしない？

**名前は開発中のものです。** · 2009/09/09(水) 19:19:02

ttp://homepage3.nifty.com/ghpk/e3d/e3d3p001.htm
E3D用だけど、モジュールだから中見れば式ぐらいは出てくる。

**名前は開発中のものです。** · 2009/09/09(水) 19:57:35

>>525
ものすごい勘違いしてそうだから書くけど、speedってのはキャラの速さのことだ
さっきも言ったが向きは別で求めてくれ
515を見る限り地面に沿った移動は出来るんだと思うけど、一応言っておくと
P-(P・N)N = ( px-nx*(px*nx+pz*nz), py-ny*(px*nx+pz*nz), pz-nz*(px*nx+pz*nz) )
で地面に沿った向きが出せる
あとはこれを正規化してspeedをかければおｋ
今まで言ったのをまとめて全部書くと
speed = 10.0 ;平地でのキャラの移動の速さ
k = 10.0 ;坂での減速係数
pvx = px-nx*(px*nx+pz*nz) ;キャラの移動方向ベクトルを計算
pvy = py-ny*(px*nx+pz*nz)
pvz = pz-nz*(px*nx+pz*nz)
nrm = pvx*pvx+pvy*pvy+pvz*pvz
pvx/=nrm : pvy/=nrm : pvz/=nrm ;正規化
speed += k*(nx*px+ny*py) ;坂で減速
pvx*=speed : pvy*=speed : pvz*=speed ;移動速度決定
法線ベクトルNと、キャラの向きベクトルPは自分でゲットしてね
ついでに実際には地面の角度が変わる境界でもうちょっと工夫すべきところがあるけどそこはもう勘弁
我ながらお人よし過ぎるぜｗ

**528** · 2009/09/09(水) 20:08:22

やべ、自分で自分のレスにアンカーしちまった・・・
ごめん。寝不足なんだよ・・・
>>525じゃなくて>>526ってことで
式もどっか間違えてるかもしれないけど、そのときは誰か直してくれ

**名前は開発中のものです。** · 2009/09/09(水) 21:04:31

地面の法線ベクトルと、キャラの向きのベクトルのなす角度が１８０度のとき、
内積は－１

speed += k * -1
だから、k = speedなら、sppedは0になるが、
k != speedなら、ふっとばされるか、よじ登ってしまうってことを言ったのさ。

**528** · 2009/09/09(水) 21:55:24

なるほどそういう事を言ってたのか
俺の例えが悪かったんだな。すまん。90度ってのは分かりやすいから一例として挙げただけであって、
俺が書いたコードは坂での減速のためだから、実際はそんな急な坂というか壁は想定してないし、
壁か地面かの判定はまた別でやってくれ・・・
係数もゲームに丁度合ってそうなのを自分で探してちょ
そもそも地面も壁も天井も全部オールインワンで処理したいんだったら、さっき言ったみたいな非現実的な方法なんて使わないで
摩擦と重力を考慮して物理的にちゃんと計算すべき。でも流石にそこまでは面倒見切れないだろ

**515** · 2009/09/09(水) 22:47:15

こんなにも具体的に書いていただけるとは・・・
>>521-531皆さんありがとうございます。

現在>>528のソースで前進移動のみ試して、
マップ端の壁以外は上手い具合に坂で減速しております。

3Dの効果音の時といい、このｽﾚの住人にはお世話になりっぱなしです・・・

**名前は開発中のものです。** · 2009/09/10(木) 17:02:19

rokdebone2でmoaを読み込んで編集しmoa上書きすると、アイドリング設定してるのに
---------------------------
アイドリングエラー
---------------------------
アイドリング設定のモーションが、１つだけ存在する必要があります。
設定を直して、再試行してください。
---------------------------
OK
---------------------------
と出るのをどうにかしてほしい。
皆でない？

【HSP】HSPで３Dゲーム ４ 【３D】

【HSP】HSPで３Dゲーム　４　【３D】