Miglioramenti e modifiche

In Lumberyard Beta 1.20 sono stati implementati miglioramenti e modifiche a sistemi e funzionalità Lumberyard.

Animation Editor (Editor animazione)

Nella funzionalità Animation Editor (Editor animazione) sono stati implementati i seguenti miglioramenti e le seguenti modifiche:

• È ora possibile utilizzare l’estrazione dei movimenti per spostare un attore nel mondo del gioco senza la necessità di aggiungere un componente PhysX Character Controller (Controller dei personaggi PhysX). Aggiungere il componente PhysX Character Controller (Controller dei personaggi PhysX) è diventato facoltativo.

  Nota

  È ancora necessario utilizzare un componente PhysX Character Controller (Controller dei personaggi PhysX) per far sì che il personaggio interagisca con le entità nel mondo dotate di fisica.

Asset Pipeline (Pipeline asset)

Nella funzionalità Asset Pipeline (Pipeline asset) sono stati implementati i seguenti miglioramenti e modifiche.

Modifiche alla serializzazione dello shader

Le chiamate di funzione a RT_ParseShader non devono più analizzare tutti i file .cfx e .cfi per determinare le informazioni sulla riflessione dello shader in fase di runtime. r_shadersExport è abilitato per impostazione predefinita nel file ShaderCacheGen.cfg. In questo modo, ShaderCacheGen genera ora un file binario .fxb per ogni tipo di shader di base quando compili i pak dello shader.

RT_ParseShader ora dispone di un flusso di codice che varia in base al valore di r_shadersImport come segue:

• r_shadersImport=0 – Tutti i file .cfi e .cfx vengono analizzati in fase di runtime per determinare le informazioni sulla riflessione dello shader. Questa impostazione è identica al codice e al flusso di dati precedenti in Lumberyard.

• r_shadersImport=1– Importa informazioni sulla riflessione dello shader pre-analizzate dai file .fxb se esistenti per un file .cfx correlato. Questa operazione evita analisi costose dei file .cfx in RT_ParseShader. Se un file .fxb esiste per uno shader ma una singola permutazione è mancante, questa impostazione è in grado di tornare all’analisi lenta del file .cfx per quella permutazione.

• r_shadersImport=2 – Sono necessari i file .fxb per tutti gli shader e non è consentito alcun fallback. Lumberyard non analizza i file .cfx o .cfi in fase di runtime.

Nota

Se r_shadersAllowCompilation=1 è impostato e r_shadersImport=2, r_shadersAllowCompilation prevale e disattiva r_shadersImport. Poiché la compilazione di nuovi shader è in grado di generare nuovi file .fxb, questo comportamento è un'impostazione predefinita.

• r_shadersImport=3– (Nuova impostazione predefinita) in base alla configurazione della compilazione, l'impostazione predefinita invia una determinazione in fase di runtime per il modo in cui il caricamento, l'analisi e la compilazione dello shader devono comportarsi. Per le configurazioni di Debug o Profilo, compila lo shader. Per le compilazioni di Performance o Release, viene eseguito in modo ottimale, come dimostrano i seguenti equivalenti:

  • Per le compilazioni di Debug o Profilo, r_shadersImport=3 utilizza la stessa impostazione di r_shadersImport=0.

  • Per le configurazioni di Performance o Release, r_shadersImport=3 utilizza la stessa impostazione di r_shadersImport=1.

Modifiche dei flussi di lavoro

Non dovresti notare modifiche se utilizzi i seguenti standard del flusso di lavoro di Lumberyard:

• Per le compilazioni di Debug o Profilo, puoi generare permutazioni dello shader.

• Per le compilazioni di Performance o Release, puoi usare solo file pak dello shader precompilati,

Se segui un flusso di lavoro diverso per le compilazioni di Performance e Release, è necessario conoscere i seguenti punti:

• Ora le compilazioni di Performance e Release disabilitano la compilazione dello shader runtime per impostazione predefinita. Se desideri scoprire le permutazioni dello shader in fase di runtime nelle compilazioni di Performance e Release, utilizza l'impostazione r_shadersImport=0 nei file system_*_*.cfg della piattaforma.

• Se disponi di script personalizzati per la compilazione di file pak dello shader, assicurati che gli script aggiungano il file .fxb dello shader che ShaderCacheGen ora genera laddove gli script includono i file compilati dello shader .cfxb e .cfib.

• La compilazioni di Debug e Profilo funzionano esattamente come hanno funzionato nelle versioni precedenti di Lumberyard, indipendentemente dal fatto che si utilizzino shader liberi o pak dello shader.

Audio

Nel sistema audio sono stati implementati i seguenti miglioramenti e le seguenti modifiche:

• Sono stati aggiunti hook per AK::SoundEngine::Suspend e AK::SoundEngine::WakeFromSuspend per gli sviluppatori su console e dispositivi mobili. Per ulteriori informazioni, consulta Gestione di eventi specifici del sistema nella documentazione su Audiokinetic.

Debug

La variabile della console e_memoryProfiling visualizza statistiche sullo schermo che mostrano quanta memoria GPU è stata utilizzata.

Mobile

Ora puoi aggiungere un file AndroidManifest.xml personalizzato, che verrà unito al manifest finale incluso nel pacchetto Android (APK).

Per aggiungere un manifest personalizzato a un modulo

1. Inserire il file AndroidManifest.xml personalizzato nel modulo.

2. Nel file wscript del modulo, specificare il percorso del file manifest personalizzato.

   Esempio

   android_manifest_path = [ <path_to_custom_manifest> ]

Per un altro esempio di come aggiungere un manifest personalizzato, consulta l'argomento relativo al pacchetto gem Microphone (Microfono) nella Guida per l'utente di Amazon Lumberyard.

PhysX

• L’opzione di debug Draw Collider (Disegna elemento collisione) per il PhysX Collider (Componente di collisione PhysX) è ora attivata per impostazione predefinita

Compatibilità SDK

Lumberyard 1.20 è compatibile con le seguenti versioni di SDK:

• AWS SDK for C++ versione 1.4.34.3

• SDK Amazon GameLift Server versione 3.2.1

Varie

Le seguenti API, sistemi e strumenti saranno rimossi in una versione futura:

• CrySystem (specificamente, API che duplicano la funzionalità in AzCore)

• CryEntitySystem e CryAction

• CryScriptSystem

• CryPhysics

• CryAnimation

• CryInput

• CryAISystem

• Boid

• Editor CBaseObject (tra cui prefab Cry CSelectionGroup e codice correlato)

• AzCore: DirectSocket

• Strumenti

  • Strumento Woodpecker (Driller Visualizer)

  • Plugin Max e Maya (previsto per la sostituzione con FBX Pipeline)

  • Behavior Tree Editor

  • Il plug-in di controllo della sorgente legacy

  • Integrazione di Statoscope

  • LiveMocap

  • Plugin dell’editor:

    • Etichettatura degli asset

    • Editor di animazione

    • Riquadro di visualizzazione QML e cartella legacy

• Libreria PRT

• CryEntityRemoval Gem

• Test funzionalità legacy (/dev/Code/FeatureTests/...)