【UE4】Unreal Engine 4 part6 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
とりあえず 1500円で 2000本 を目指そうや 4.17/4.18で出てるメモリリークの話って結局どうなったの?? 少なくともこの前確認したときは何も変わってなくてリーク続行してた >>637
ありがとう。みんな4.16でやってるのかな?? レンダーターゲットとリフレクションさえ使わなかったら
多分メモリリークはそんな起こらないと思うから、困らないやつは困らないと思うよ
全員がメモリリークで困ってるなら
公式の質問ページとかもっと大騒ぎになってるはず >>639
そこ以外では発生しないのか。勘違いしてたわ、ありがとう。
公式に要望出しつつ様子見すればそのうち修正してくれるだろうね。 >>581だけど、買うかどうか迷ってるうちに$150が$45まで安くなってたので買っちゃいましたw
まだ使い方模索中だけどテストマップ見てるだけでも楽しいです、買って良かったかも RenderTargetもReflectionも使っているが4.17で特に問題は起きていない pythonプラグイン公式対応か
色々面白いことできそう 基本機能しか使ってないサンプルゲームですらわずかながらメモリリークが起きてるのに
そんな限定的な話ではないと思うが あー謎に満ちた至極のshippingエラー
もう悪魔ですわ
昨日から解決法探ってんのに出てこない shippingなぞなぞゲームを開催するのEpicさんもう止めて >>646
それはさすがにメモリの使用量調べればわかるんじゃ? >>649
内部キャッシャ積んでるだけかも知らんし、単純にメモリ使用量の増減だけじゃリークしてるかはわからんでしょ 単純なキャッシュなら何回かプレイを繰り返すとメモリ使用量が変わらなくなるよ
まあデバッグコマンド使ったほうが手っ取り早いか じゃあメモリリークとは言ってもそんなに大した影響はないってことなのか。 いやメモリーリークは問題だろ
本当にメモリリークなのかどうかってことだよ 4.18のgradleからパッケ後のapkの解析エラーでshipping地獄から未だ解放されず
詰んだ Androidはわからんなー
AnswerHubへドゾー みんなアセットってマケプレの奴購入か自作かどっちで作ってる?? AIで動かしてるキャラクターってそのままじゃroot motion使えないんか
専用モーション作ったのに移動しなくてワロタわ 俺のAndroid端末のOSが5.0.1
ビルドのパッケージング後の解析エラーの原因が見えてきた気がする
たぶんUE4.18のgradle使うとSDKの最低バージョンが14以上で設定しないとパッケージエラーが起きる
でも14以上指定すると俺の端末が息してない
まだ見えてない解決方法はあるはずなんだが NOX凄いね
初めて知った
ここじゃなんかスレチな感じだから次から質問スレに書くね SDKのバージョン調べたらSDKバージョン14ってOS5.0は対応してた……
原因が他に有ったとは…… >>657
root motion modeをプレビューで変えてたせいだったわ。しょうもな… そうして試行錯誤してスキルアップしていくのさ…(キリッ Epic社内のプロジェクトでは使われてるみたいだし少しずつ更新されてると思うけど なんでVtuberはUE使わないの?Unityばっかりだけど いや、リアルタイムレンダリングの性能では互角以上だしblueprintの方がアーティストにも扱いやすいじゃん
なのになんで面倒なUnity使うのかと思って 目的から辿ってググってみればわかる
初期の人がUnity使って記事書いてるからだ
ある程度レールが敷いてあるから参入は難しくない トーシローだけどUnityとUE4lどちらも同じ.pmxモデルインポートしてみたらUE4の方は読み込み時にエラーが沢山出た
(ボーン関係だったはず)
あとFilanIKのお試し版も触ってみたけれどUE4は関節がおかしくなって調整できなかった
もちろん自分の技術がペーペーなのが原因だけどUnityは解説サイト通りにやったらできた
一年前に4.14か4.15ぐらいで試したことだから新しいversionなら改善されているかもだけど 昨日どっかの映像コンテスト?か何かで作品の70%がUnity製って言ってたけど、映像関係のエコシステムではUnityの方が使いやすいのかね アダムとかみてるとクオリティ的にはUnityも十二分にできそうな気がするけど、レンダリングにおいてまだUEの方が優れてるとこあるのん 性能が高くても情報が少なくてそれらの使い方を知ることが出来ないと無いのも同じだからな。
CGソフトの栄枯盛衰はいつもこのパターン。
このソフトはこの先も企業の大作がメインの使われ方をするんだと思うけど。 vtuberがライトマップ綺麗にベイクしててもキモいだけだしキズナアイみたいなセルルックに毛が生えた程度で問題ないわな
それならUnrealである必要もないか
sayaみたいなフォトリアルが中心になったら自然とunrealが台頭しそうやね UEがフォトリアルでUnityより優れてるのってどこから来るの。 >>684
昔はそういうのはあったけど、今はぶっちゃけどっちもどっちかなって。
ただ、UE4の方が手軽に良いグラフィックが作れるってだけで。 4.19来たのか
メモリリークはそろそろ直ったかな グラフィックの優位性は確実に距離を詰められてしまった いやいや、どこが縮められてるんだよ
相も変わらずUnityはクソグラモバイルゲーしか出してないしPS4の大型タイトルは内製かUE4だぞ
グラフィックがすごいUnityゲーがあるなら例示してみなよ クソ蔵っていうのはエンジンの問題よりは作り手の技量の方が多くないかい?
やりやすいかどうかっていうのはあるけど。 >>688
ツールの善し悪しと、製品の善し悪しは別 ゲーム会社はUE4をライブラリとして流用してるだけでBPなんか一切使わないし
データもすべて会社独自の形式で作ってるはず
個人の使い方とは全く異なる。ツールとしては使用してないからね。 >>688
それは今までの実績から選択されてるのが多いのでは。
少なくとも今世に出てるものなんか開発数年前からやるんだから。
今のエンジンが追い付いてるかとは別。 前から思ってるけどここで質問してもUEのこういうところがこうだからUnityよりもレンダリング能力高いとかそういう説明出てこないんだよね。
出てきてもデフォルトの設定で綺麗に出るようになってるよぐらいで。
結局のところもうレンダリングについてエンジンの能力的には差はほぼなくデフォの設定がUEは整ってるだけなのか、まだこの辺はUnityにできないとかあるので縮まったとは言えど差はまだあるのとどっちなん。
BPとかC#とかそういうのは除いて。 同じ描画したら同じくらいの負荷がかかるのは当然だし
俺にはデフォルト設定のアドバンテージ以外は言えないさ 整ってるというか単に初期設定が重くて高品質か軽くて低品質かってだけの差でしょ
フィジカルベースになった時点でやることはどれも同じなんだからその精度をどこまで上げるかってだけの話
エディタの機能性だけで言えばUEの方が優れたのかもしれないけど
Unityもシェーダーエディターが標準搭載になるみたいだしもうじきunityはグラが悪いとか言ってる奴は馬鹿にされるようになる Unity は欠点だったグラフィックが格段に向上してるのは間違いないし開発も努力してるのが解るが
一方アンリアルの欠点である重さやモバイル対応などはUnity 程の成果や努力は見えない気がする。
この部分でジワジワ詰められてる印象になるんだな。
ユーザー数も巻き返してる感じも無いし大企業がいくら使ってもここにいる個人ユーザーにとって恩恵がどれだけあるか疑問ではある。
開発元も企業しか見なくなると個人開発はやりにくくなるのは歴史的に繰り返してるし。 Post Processing Stackでポストプロセスの優位性も言えなくなった
今度はシェーダーもノードベース
Timelineも付いた
UE4の利点がどんどんつぶされてる
BPとC++かC#かの好みぐらいの差かもね >>700
プレイメーカーみたいなのもその内付きそうな予感 まだ公式のタイムテーブルには載ってないけど検討中の項目には上がってるな > ビジュアルスクリプディング animal pack ultraのアセット安いね >>700
最初のうちはBP確かに簡単でいいわと思ってるんだけど、
これまでよりほんの少し規模の大きいものを作ろうとしただけで一気に視認性悪くなるし、
結局コード書いたほうがってなるともう好みの違いでしかなくなってくるよね、Unityが色々追いついてきた現状では。
UE4の方がエンジンそのもののソースに手を入れられるから良いと思ってたけど、
正直個人レベルでそこまでのことが必要になるケースなんてそうそうないしな。 ソースコードなしとか考えられない。
トラブルも挙動の不明点もソース追えば一発なのに(追えるやつはね)。
ソースコードないVisualStudioは使っていて本当に苛立たしいことばかりです。 ビジュアルスクリプトが効果を発揮するのは小規模までだからな。
ある程度やったら皆気付く事だけどその先はぐちゃぐちゃな見た目になりがちで効率が極端に悪くなる。
だから主流がコード書き書きになるのは当然だろうな。 エンジン側でトラブル発生した時に、
エンジンのC++のソースコード見て修正して解決できるやつなんて
もはや素人の個人開発者の域超えてるだろ。 ゲームエンジンのトラブルまで個人で修正してたら本末転倒感はあるな 会社でも小規模開発ならエンジン側のバグとどううまく付き合うかを考える所の方が多いわ
ヒストリアとかだと中身ガンガン弄ってたりするんだろうけど ソースコード見れるならあれこれなんでおかしいのってのの調査に役立つだろ 追っていっても肝心な所はライブラリ化されてるような
あのコード書き直すくらいなら、自分で一から作った方が早くて確実じゃないか UEは知らんけど、ソースコード見れるのはソースコードを修正するだけでなく、バグの原因がわかるからそれを生む何かを修正するって役割もあゆ エンジン側のバグってなんやねん
普通にゲーム作っててそんなの引っかかったことないんだが一体どんな特殊なゲーム作ってるんだ 汎用ライブラリが大嫌いで、大して意味がなくても全部自分で
ソースコードを追える・書くことに一種宗教的に拘ってる人って
ゲーム業界じゃなくても技術者には結構いる。
でもそういう人はエンジンや基盤を作る側に回った方がいい。
少なくともUE4みたいな汎用ゲームエンジンにおいては、
重大な不具合なら報告すればそのうち直すだろうし、
ソースコードを見られることにそこまでこだわる必要もない。 みんなのレス見てないけど、俺はソースコード見て改善出来た方が良いと思うな
アプリ配信直前のビルド時に致命的ビルドエラーで今までの製作時間がおじゃんになるとか考えられん まあ変なダベリを見てるくらいならソース見てた方が心も落ち着くかもな 汎用ゲームエンジンは素材がありがたい
3Dゲーになると一人でモデリングとかテクスチャとか絶望的
あとエディタもいい感じ 自分でソースいじくり回した後に本家が全体的に何らかの修正なり変更を加えた時に別の問題が出てきそうだけど
完成するまでバージョン固定で対応するのかね? >>723
そういうのがあるからUEに限らずソースをいじるのは最終手段だよ いじれる人は必要があればいじるって感じだよ
プライベートに入ってる関数や変数に有用なのがあったり
継承して拡張しようとしてもエクスポートされてなかったり
ざらにあるからね
やりたいことを実現するか
やれることをやるかで大きく変わってくる C++は公式の情報少な過ぎ
BP使わず特定のボーン動かすの滅茶苦茶悩んだ 聞くほどに個人制作レベルだと問題の機能は避ける方が賢い選択に感じるな。 問題を見つけたら公式サイトに報告して改善されるのをじっと待つのが賢い選択 UE4のAPIよりブループリントの方が高機能だと思う
でもすぐゴチャゴチャする >>730
開発がガチでこんな意識だからUnity に追い上げられるんだろうな… >>734
Unrealの日本シェアなんて微々たるもんだし
ソシャゲ()大国になっちまって
Unreal使ったCSゲーなんて少ないしな
力入れるだけ無駄 ■ このスレッドは過去ログ倉庫に格納されています