fc2ブログ

UE5.3はプチフリーズします

emotionサイトトップ >UE(アンリアルエンジン)備忘録

UE5.2が色々と小バグがあって不安定だったのでUE5.3を使用しているのですが、
UE5.3はこっちはこっちでプチフリーズが発生します。

XBOX ONEもプチフリーズ連発で、シリコンパワーのSSDが原因だったのかOSの再インストールで解消されたのか分かりませんが、
UE5とプロジェクトを保存しているストレージがシリコンパワーのNVMeだったので、もしかして・・・
と思ってサムスンのSSDへ移行したものの、プチフリーズ現象は変わらず発生。

そろそろ安定したエディターをリリースして下さい。
プチフリーズからそのままクラッシュして、小一時間分前のデータに戻されたりシンドいわ。

でも5.2で関数入力に変数配列を設定すると、呼び出し元で必ず入力ピンを接続しないとコンパイルエラーになる謎仕様だったのが、5.3では解消されていました。

ようやくサスペンションの基本部分が出来た

emotionサイトトップ >UE(アンリアルエンジン)備忘録
emotionサイトトップ > UE(アンリアルエンジン)備忘録 >ようやくサスペンションの基本部分が出来た

UE5Car20231023.jpg
ようやくサスペンションの基本部分が出来ました。
結局PhysicsConstraitとAddForceの両方を駆使して、状況によってどちらかの使用するかの比率を計算してリニアにブレンドさせる事でいい感じになりました。
あとPhysicsConstraitのスプリングレート問題は、理論値を計算するのが難し過ぎたので、セッティングを変えたら実測して補正値を算出させて調整するようにしました。

スプリングレートを変えても、バネ上重量を変えても理論値通りの動作になりました。
それからサスペンションが安定する位置での荒ぶる挙動も解消されました。
ただフレームレートが60FPS以上じゃないと挙動が怪しくなります。
理由は低FPSでΔタイムでのサスペンションの変化量が増加してしまって、スプリングの反発力やダンパーの減衰力の演算結果の精度がおかしくなってしまう。
なので15FPS固定で動作チェックすると静止せずに荒ぶる事があるので、いくら調整しても静止しなかったのはフレームレートの問題だったというオチも・・・

それからダンパーの伸び縮みの両方で減衰調整出来るようにして、ダンパー特性グラフも採用してダンパーの変化量に応じて減衰力の変化するように調整。
スプリングもスプリング特性グラフを採用して荷重0時の変化も追加。
ようやく基本部分が出来上がりました。
サスペンション部分だけでこれだけ時間がかかるって・・・先が思いやられるw

これからタイヤのたわみとか色々と追加しなければならないけど、
それは一通り車としての動作が出来るようになってから。
ずっとサスペンションの調整ばかりをやっていたから、いい加減車を動かしたいw

でも難しいのはサスペンション部分だけなので、ここから遅れを取り戻せる筈。
株取引も前場で終わらせて、後場は別PCで監視させて引けてから結果を見て注文を入れるようにしたので、
お昼からUE5を起動して作業時間を確保。
PM12:00からAM2:00までの会社員だったら完全にブラック労働w
と言っても会社員だった時もAM2:00まで会社で作業して、それから持ち帰り残業して朝まで仕事していたから、会社員だった頃よりは相対的に楽。
それに通勤時間という無駄な時間も無いし、他人に足を引っ張られる事も無いから精神的に何十倍も楽。


PhysicsConstraitのVelocityTargetオフセットには要注意

emotionサイトトップ >UE(アンリアルエンジン)備忘録
emotionサイトトップ > UE(アンリアルエンジン)備忘録 >PhysicsConstraitのVelocityTargetオフセットには要注意

PhysicsConstraitを使用すると中心から振れるので端っこをスタート地点にしたい場合は
UE5PC20231023.jpg
PositionTargetでオフセット設定する必要があります。
ちなみに一切記載がありませんが、BPで設定するとVectorパラメータになっているので、左からXYZ軸の設定です。
一番右にチェックを入れて-50という事は、Z軸方向へ-50cmオフセットする事になります。
振れ幅を100cm設定にしている場合は半分の50cmオフセットする事で、一切力が加わっていない時に端っこへ戻るようになります。

ただVelocityTargetが厄介で仕組みが良く分かりませんでした。
減衰位置の設定かと思ったのですが、これをオフセットさせると暴走して荒ぶってしまいますw
静止するべき位置に到達した瞬間にカオスになって上空へ射出されます。
あのGTA5で門に挟まれて時に上空へふっ飛ばされるあの現象が発生しますw

物理演算って何かのきっかけで演算値が極端になって吹っ飛ぶので怖いですよねw

もしかしてクソマジメに作っていない?

emotionサイトトップ >UE(アンリアルエンジン)備忘録
emotionサイトトップ > UE(アンリアルエンジン)備忘録 >もしかしてクソマジメに作っていない?

グランツーリスモやForzaもそうだけど、車高のセッティングを決め打ちで変更出来る。
全長調整式の車高調でもスプリングを変えれば車高が変わってしまうから、スプリング変更によって変わってしまった分はダンパーの全長調整して車高を調整しなければならない。
でも車高を決め打ちで変更したら、スプリングレートを変えようが何しようが、車高は変わらない。
自動で全長調整していると言われればそれまでだけど、もしかして足回りのプログラミングはクソ真面目に作られていない?
クソ真面目に物理計算をして組み込むとどうしても荒ぶってしまって沼ってしまって、サスペンションの部分だけで大幅に時間を費やしてしまってしまう。
いや、逆に大手メーカーがそういう感じで作っているなら、インディーらしくクソ真面目に作った方が差別化出来て良いのか?
ただ、どうしても荒ぶってしまう部分だけは物理計算度外視で挙動を抑え込む必要があるけど。

というか未だにアサシンクリードオデッセイとFF15をクリア出来ていない。
やってる暇が無い。
FF15に関してはXBOX ONEのSSD交換してからインストールすらしていない。
容量が大き過ぎて500GB(実際に使用出来るのは370GB程)のストレージではインストールする事すら厳しい。
アサシンクリードをクリアしたらアサクリをアンイストールしてFF15をインストール・・・でもFF15はオープンワールドの移動がダル過ぎてやる気がおきないw

Physics Constraintの注意点

emotionサイトトップ >UE(アンリアルエンジン)備忘録

Physics ConstraintのPositionTarget.Strengthの単位は[N]とAIが回答していましたが、
実際は[kg/cm]だと思います。

それからPhysics Constraintの位置も結構重要で、両方のオブジェクトの中心に配置した場合
UE5PCTest_1.jpg
PositionTarget.Strength=1000
上のオブジェクトのMassを1000[kg]
の設定で動作確認したら、1cm沈んで理論値通りの結果になりました。
UE5PCTest_1.jpg

Physics Constraintの位置を50cm横にずらして実験してみると
UE5PCTest_1.jpg
何故かZ方向に2.9cmも沈んでしまいました。
UE5PCTest_1.jpg
これは一体どういう演算をしているのか?
斜めに方向に沈み込んでいるので、むしろZ方向への沈み込みは減るのなら未だ理解出来ますが、もしかしてレバー比みたいにテコの原理が働いた??
それとも重心から離れた事でPCへの荷重が変わった?
とりあえず理論値通りにしたい場合はとにかく真っ直ぐの位置に配置する必要があるみたいです。
あとまたオブジェクトのMassが反映されなくなった・・・イベントグラフで変更しても駄目、UE5.3で試してみてもだめ。
片方のオブジェクトの質量無効にしても動作影響しなくなったけど、とにかく動作が不安定。
減衰設定や入力Max設定も0にするとPositionTarget.Strengthも何故か0になってしまうバグ?っぽい動作をしていたのに、今確認したら減衰設定0にしてもちゃんと動作するようになっているし・・・
さっきまで変更影響を受けていたのに、突然影響を受けなくなったり色々とバグがあるのか、使い方によって妙な挙動になってしまうのか分かりませんが、使わない方がいいのかな?
でも動作制限や減衰動作が結構使えるので、これを活用したい。

もうちょっと色々と実験をして挙動確認しないとなのに、Massの変更反映されないバグ?を何とかして欲しい。


あと地面に接地する側のオブジェクトはCCDをTrueにしておかないと挙動がおかしくなるみたいです。
多分Physics Constraintのプロジェクションが影響しているのかもしれませんが、オブジェクトが地面にめり込んだ時の補正で意図しない物理演算が働いてPhysics Constraintが異常な動作をしていました。

でも相変わらずパラメータ変更して挙動が変わらず、パラメータを戻したら挙動が変わって、さっきのパラメータにまた戻すと挙動が戻らず・・・マジで動作が不安定なんですけど?
何故同じことをしているのに挙動が変わる?
本来、同じ事をしていたら結果は不変の筈なのに・・・やっぱり動的なバグが仕込まれているんでしょうね。


UE520231021.jpg
UE5.3をインストールして、一日中Physics Constraintのパラメーターを散々弄くり回して、複数のオブジェクトと連結したりして実験をした結果、ようやく有効な使い方を見つける事が出来ました。
色んなオプションパラメータをフル活用してようやく希望する動作になりました。
使用する際に色々と注意しなければならないので、実際に組み込む際にはその点に留意しなければなりません。
これマジで初見殺しのコンポーネントだわ・・・
単純に天井からぶら下げて振り子にするとか、物理的なドア改変のヒンジに使用するだけなら簡単なのですが、
理論値通りの数値の挙動を狙う時には全てのオプションパラメータについて一通り目を通して、試行錯誤する必要があります。
ただ、有効的な使い方を導き出せて良かった。
丸一日かけて「やっぱり使えない」判断になったら最悪ですからね。
正確にはPhysics Constraint自体は何日も前から使っていましたけど、がっつり実験したのは今日が初めてでした。



色々実験したりデータを取った結果・・・
XZで45°(100,0,100)になるような配置にするとスプリングレートが1/2倍になる。
Test6.jpg
Test6.jpg
多分スプリングレートが変わったのでは無く、リンクしたオブジェクトからの影響が2倍になったのかと。
最初はテコの原理で距離が離れた分だけ比率が変わったのかと思ったのですが、
45°(200,0,100)未満になると1/2倍固定。
こうなるとテコの原理じゃない。
59°の場合は1/1.35倍だったので三角関数で対称軸分だけ加算されているみたい。

ちなみに3次元の場合は更に加算されました。
XYZで45°(100,100,100)の場合は1/3倍になりました。
Test6.jpg

Y軸分も加算されてX軸分と合わせて200%。
3次元の場合も同様に45°未満の場合は45°と同じ扱い。

多分Z軸固定で使用していたので、Z軸方向での距離が上限になっているのかも?
とりあえずPCのスプリングレートの挙動は分かりました、何故そんな仕様にしているのかは謎過ぎて納得はしていませんがw
Z軸方向への制限をしているので、斜めに力が働いた時にベクトルが分散されて、Z軸方向以外へ分散された力が単純にカットして、力が逃げた分だけZ軸方向への過重が失われているだけ?
ソースコードをいじれないので逃げた分の力を戻す変更は出来ないので、位置によってロスする事を加味してスプリングレートを補正する処理が必要。

PCの減衰だけ活用して、スプリングはAdd Forceでアッパーマウントを押し上げようと思ったら・・・
静止時の制御が難し過ぎてまた丸一日試行錯誤していましたw
スポンサーリンク
カテゴリ
OS (5)
Web (7)
CPU (16)
GPU (35)
GA2 (2)
GTA5 (18)
リンク
Unreal Engine
UE4_logo.png

無料化したゲームエンジンです。ミドルレンジクラスのGPUが必須ですが、GTX750Tiでも軽快に動作します。
ueHow
unityHow
Steam
steam.png
Valve Corporationが運営しているプラットフォームで、PCゲームをダウンロード購入出来ます。 不定期ながらだいたい四半期毎と10月の米国感謝祭と年末に大幅割引セールが行われるので、セール中に購入するのがおススメ。
RSSリンクの表示


スポンサーリンク