問題タブ [unity3d-editor]

私は問題があります。

上記の「a」には、「b」を参照するフィールドが含まれています。同様に、'b' には 'a' を参照するフィールドがあります。

上記のコードを実行した後に元に戻すと、「b」のフィールドに「欠落」した世代が表示されます。

この問題をどのように処理すればよいですか?

NASA の高いマップ定義 (21000x21000 の 4x2 タイル) を使用しようとしています。したがって、基本的に合計テクスチャは 84000x42000 です。そのために、4x2 シェーダーを作成しました。残念ながら、各テクスチャの「最大テクスチャ サイズ」は 16k で、生成された EXE は使用できません (~9go -> 開始時にクラッシュ)。

• 8k タイルの 8x4 シェーダーを使用した方がうまくいくでしょうか?
• 各タイルのサイズを最大テクスチャ サイズに変更したほうがよいですか? 例: 16384 または 8192?

あまり品質を落とさずにこのテクスチャを使用できるようにする他のアイデアがあれば、遠慮なくアドバイスをください!

どうもありがとう

クリックすると、ランタイム中に Unity3D の AudioSource を更新しています。

Cube ゲーム オブジェクトを作成しました。

立方体をクリックすると、AudioSource にプロパティが送信されます。

注:これは最終的に、パイプ区切りの wav ファイル (Assets Audio フォルダーに存在する) の文字列配列を介して渡される他の多くの wav ファイルを再生するためのものです。

したがって、各 CLICK EVENT で AudioSource を更新する必要があります。これにより、配列から選択された新しいファイルがロードされるたびに。

わかりました。Unity3D エディターは、スクリプトからパブリック変数を表示し、実行時に (キューブをクリックすると) それらを入力します。

私のパス変数は、Unity3D エディターに完全に表示されます。

しかし問題は、エディターのオーディオ クリップ プロパティに小さなオレンジ色のオーディオ ロゴが表示されている (何かがそこにある/ロードされているかのように) ことですが、Assets/Audio フォルダーから取得したファイルの名前は常に空です。

何も再生されませんが、エラーは発生しません!

プロパティplayOnAwake、volumeなど。_ すべてが、スクリプトを介して彼らに何をするように表現するかを正確に示しています。

注:最初のイメージでは、パス 変数は .wav ファイルを正しく指しています。

.wav が再生されないのはなぜですか?

オーディオ クリップのテキスト ボックス領域に .wav ファイル名が表示されないのはなぜですか?

Visual Studio と Resharper には非常に便利な「使用箇所の検索」機能がありますが、Unity3D Editor には同じ機能がありません。Unity3d では「依存関係の選択」しか表示されませんが、反対のものが必要です。それは存在しますか？

再生中にC#スクリプトでこのパネルのオン/オフを切り替えたいです。これは可能ですか？このためのエディター API 関数は見つかりませんでした。

私は Unity エディターの拡張に非常に慣れていないため、階層内の選択されたオブジェクトを強調表示するこのスクリプトをまとめました。問題は、私がエディターにいて、スタック (シーン名) の一番上がツリーに表示されると、階層全体が見えなくなることです! 下にスクロールしてシーン名が見えなくなると、自動的に修正されます。何が起こっているのかをよりよく理解できるように、画像を添付しました。オブジェクトがたくさんある場合、この問題は軽微ですが、新しいシーンでは使用できません。

コンソールには、「オブジェクト参照がオブジェクトのインスタンスに設定されていません」と表示されます。

画像： 正常に機能しています

正常に機能していない

ご協力ありがとうございました！

私はいくつかの場所でこの質問をしましたが、まだ完全には理解していません。

プロジェクトでプレハブの深くネストされた階層を維持する最良の方法は何ですか? 小さい汎用コンポーネントで構成された GUI 画面がいくつかあるとします。簡単にするために、前者を「ビュー」、後者を「コンポーネント」と呼びましょう。ビューはセマンティクスを扱います (在庫ビュー、店舗ビューなど)。コンポーネントは構成可能ですが、ビジネス ロジックはまったく関連付けられていません (たとえば、ボタンはその OnTap コールバック/イベント ハンドラーのみを考慮します)。

ビューとコンポーネントの両方をネストできます。

GUI ビューは複数のシーンで再利用する必要があります。

Unity でのこのアプローチの主な問題は、ネストされた階層が一度プレハブに変換されると、次の (完全に作成されたがまだ有効な) 例のように、その子プレハブへの参照が失われるという事実です。

- storeView - UIViewHeader - UIHeaderLabel<Text> - UIList - UIListItem - UIThumbnail - UITitleLabel<Text> - UISubTitleLabel<Text> - UIPrimaryButton<Button> - ...

これらすべての小さな UI* コンポーネントを個別のプレハブに保持したいと考えていますが、別のシーンに簡単に追加できるように storeView プレハブも保持したいと考えています。残念ながら、storeView プレハブを作成するとすぐに、すべての UI* プレハブ参照が失われます。その場合、別のアプローチを試すことができます。コンテンツを含む storeView プレハブを用意する代わりに、空のままにして、次のいくつかのオプションのいずれかを選択します。

1. 動作を storeView にアタッチし、実行時に子プレハブをロードする
   • 短所：デザイナーのワークフローがより複雑になり、スクリプトが複雑になり、開発者の観点からもエラーが発生しやすくなる可能性があります
   • 長所: シーン間での storeView の再利用が容易になり、コンポーネント プレハブのスタイル設定やグローバルな変更が可能
2. storeView を空のプレハブとして保持し、それを必要とするすべてのシーンで再構築します
   • 短所: コンポーネントを手動で接続する必要があります。storeView 全体を誤って保存して、プレハブの参照を失うことは依然として簡単です。
   • 長所：コンポーネントのプレハブ参照が維持されることを保証し、ビュー間のわずかな違いを許容します（これらは構成レイヤーに属する必要があるため、実際には問題です）
3. storeView 全体をプレハブとして保存する
   • 短所: 拡張性が非常に高く、新しい機能や小さな UX の変更の繰り返しに時間がかかります (追加の QA、受け入れテストなど...)。
   • 長所：小規模なプロジェクトでうまく機能する、迅速で汚いソリューションです
4. Prefab Evolution などを使用する
   • 短所: パッケージは、ロードマップにある入れ子になったプレハブによって廃止されると思いますか? サードパーティのコードに依存する必要があり、十分な柔軟性がない可能性があります (意見はありますか?)
   • 長所：私が見た多くの（さまざまな）レビューから、いくつかは非常に肯定的でした. ただし、プロジェクトが複雑になるほど、これらのレビューは肯定的ではなくなります。
5. 大量のカスタム エディター スクリプトを作成します。
   • 短所: 時間がかかります。また、主にゲームを扱っている場合でも、プラットフォームによって提供されるべきもののように思えます。
   • 長所: 動作を完全に制御でき、開発者がデザイナーのフィードバックを得て改善できます。機能要件として実装、テスト、および設計者にとって使いやすいツールを持つことについて規律を守ることは、優れた設計慣行のように聞こえると主張する人もいるかもしれません (結果として、技術的負債が少なくなり、保守が容易になります)。

これが私の個人的な対理想主義的で非現実的な解決策です*：

コンポーネント化されたアーキテクチャを使用します。デフォルトでは、子のプレハブ参照が複雑なプレハブに格納されます。内部的には、モバイル (Cocoa) の UIView とサブビュー、または React のコンポーネント クラスまたはそれ以上の機能コンポーネント (React/Cycle/Elm/FRP と相性の良いもの) と考えてください (はい、これらのアプローチが非常に多くの点で異なることはわかっています。しかし、重要なのは構成可能性であり、機能的構成、デコレータなどによって達成されます...)。

• 短所：ここでの私の困難は、Unityの経験が不足していることに起因すると思います。より明白で、おそらく慣用的な解決策があります（親切にお願いしています:)）

• 長所：新しい機能のテストと反復がはるかに簡単になり、プレハブがより強力になり、その利点を失うことはありません（間違っている場合は訂正してください。私はまだ Unity に慣れています）

• Unity にすべてを期待しているとは思わないでください。ただし、その 1% が真実であっても、それは可能な方向性の 1 つです。

はっきりさせておきますが、これは Unity に関する暴言ではありません。以前にモバイル (ネイティブ) と Web で働いていた開発者として、Unity で解決できる問題の数と、これらのソリューションのいくつかが非常に単純であることに感銘を受けました。