Nell'unità, supponiamo che nella mia scena ci siano alcuni oggetti di gioco che non sono visibili alla telecamera e quindi non vengono renderizzati mentre il gioco è in esecuzione.
Questi oggetti di gioco consumeranno risorse computer / mobili quando il gioco è in esecuzione?
Dove posso trovare dettagli sull'utilizzo come questi?
Risposte:
Quello che vuoi è un profiler di memoria, che Unity ha. Qui: http://docs.unity3d.com/Manual/ProfilerMemory.html
Ma il tuo presupposto è per lo più corretto, se un gameObject non è visibile alla telecamera non viene disegnato e utilizza meno risorse, ma deve comunque consumarne un po '. GameObject esiste ancora in memoria, comprese tutte le trame, gli script dei modelli, ecc., Inoltre consuma ancora tempo della CPU attraverso i metodi Update e FixedUpdate (e vari altri qui descritti ).
Ma di solito il principale rallentamento è il disegno, una piccola quantità di tempo della CPU viene utilizzata per determinare che l'oggetto è al di fuori del frustum della fotocamera (limiti), ma non viene eseguito alcun disegno.
Penso che dovresti anche conoscere Frustrum Culling o rimozione della superficie hiden: http://en.wikipedia.org/wiki/Hidden_surface_determination
Questo è un aspetto importante per l'ottimizzazione di un gioco, perché anche se i tuoi oggetti non si trovano all'interno del frustrum in un determinato frame (cioè visibili), alcune chiamate di disegno (shader) vengono comunque lanciate per loro, riducendo quindi le prestazioni.
La risposta breve è "sì"; tutto ciò che è pronto per essere utilizzato nel gioco sta occupando memoria.
L'altra cosa da considerare è il costo per il frame rate:
5 oggetti, con 5 trame separate, disegnati separatamente richiedono cambiamenti di stato nel mezzo. Potresti riuscire a risparmiare un po 'di memoria scaricando le trame non utilizzate.
Caricando tutte le trame separate in una singola trama di atlante, l'impronta della memoria si fissa e non è più possibile scaricare una singola trama. Una volta creato, devi solo legare l'atlante una volta per disegnare tutti i tuoi oggetti.
Un altro esempio è un semplice vertice e buffer di indice. Se molti dei punti si alternano spesso tra visibile e non, è più veloce lasciare i punti "non aggiornati" nel buffer dei vertici e caricare solo un nuovo buffer di indice.
Ci sono molte altre volte in cui un aumento del costo della memoria iniziale è preferibile a molti cambiamenti di stato.
Se ruoti la videocamera, sicuramente non distruggerai quegli oggetti a meno che tu non lo sappia, quella videocamera non ruoterà indietro per controllare quell'oggetto. "- Katu
Usando uno scroller laterale come esempio, se puoi muoverti solo a destra (la mappa scorre solo a sinistra), qualsiasi oggetto che scorre fuori dal lato sinistro dello schermo può essere scaricato in modo permanente poiché non lo userai mai più. Inoltre, il contenuto per gli oggetti può essere caricato a richiesta prima che l'oggetto scorra nella vista da destra.
Molte risposte stanno prendendo in considerazione principalmente l'aspetto grafico della tua domanda.
Il fatto è che occuperanno varie risorse, e quanto sono costosi rispetto al disegno dell'oggetto non è fisso. Non è insolito come alcune risposte implicite per i componenti che stanno facendo operazioni più costose rispetto al disegno, ma è possibile ridurre al minimo quante risorse usano. Inoltre, tieni presente che un GameObject occupa una piccola quantità di memoria e quindi anche i suoi componenti. I componenti potrebbero anche fare cose che occupano un bel po 'di memoria.
Il modo più semplice per ridurre al minimo l'effetto dei componenti fuori schermo è un sistema basato sui callback OnBecameVisible e OnBecameInvisible .
void OnBecameVisible()
{
myComplexComponent.enabled = true;
}
void OnBecameInvisble()
{
myComplexComponent.enabled = false;
}Ovviamente, questo è di utilità molto limitata poiché ci sono molte volte in cui vorrai che un oggetto fuori schermo influisca sul gioco. Ma è possibile espandere un modello di questo tipo per un sistema a grana fine in grado di ridurre al minimo l'effetto dei calcoli più costosi. Anche qualcosa di semplice come ridurre qualcosa come la qualità di un percorso che segue lo script quando l'oggetto è fuori dallo schermo può portare a grandi risparmi nel lungo periodo.
Ci vuole memoria per tenerlo in vita e aggiornare la sua posizione e altre proprietà.
Ma non consuma risorse grafiche per computer / dispositivi mobili poiché non è visibile.
Tutto ciò che è in un programma consuma risorse; Non pensi che i programmi girino semplicemente su speranze e sogni, vero?
La domanda dovrebbe essere quante risorse consuma un oggetto di gioco, e a tal fine penso che questa sia una risposta abbastanza solida: http://answers.unity3d.com/questions/280455/how-much-memory-a-gameobject- consume.html
In breve, consumano risorse trascurabili per conto proprio. Ma perché dovresti desiderare un mucchio di oggetti di gioco semplicemente seduti nel tuo gioco senza fare nulla? Alla fine della giornata, ciò che in realtà fai "fare" a quegli oggetti di gioco, è ciò che causerà qualsiasi tipo di sovraccarico e quante risorse che richiedono sono molto caso per caso.