Come faccio a scegliere il fattore di ridimensionamento di un mondo di gioco 3D?

Sto realizzando un prototipo di gioco di carri armati 3D con alcune simulazioni fisiche, sto usando C ++. Una delle decisioni che devo prendere è la scala del mondo di gioco in relazione alla realtà. Ad esempio, potrei considerare 1 unità di misura in-game corrispondente a 1 metro nella realtà. Sembra intuitivo, ma mi sento come se potessi perdere qualcosa.

Posso pensare a quanto segue come potenziali problemi:

1. Compatibilità del programma di modellazione 3D. (?)
2. Precisione numerica. (Importa?) Soprattutto su larga scala, come giochi come Battlefield hanno enormi mappe: come non perdono la precisione numerica se usano la mappatura 1: 1 con scala del mondo reale, poiché la rappresentazione in virgola mobile tende a perdere più precisione con dimensioni maggiori numeri (ad es. con ray casting, simulazione fisica)?
3. Gameplay. Non voglio che il movimento delle unità si senta lento o veloce mentre uso valori quasi reali come -9.8 m/s^2per gravità. (Questo potrebbe essere soggettivo.)
4. Va bene ridimensionare / ridurre le risorse importate o si adatta meglio a un mondo con la sua scala originale?
5. Prestazioni di rendering. Le mesh di grandi dimensioni con lo stesso numero di vertici sono più lente per il rendering?

Mi chiedo se dovrei dividerlo in più domande ...

Generalmente dovresti fare qualunque cosa funzioni.

1. Dal momento che hai oggetti della vita reale ha senso abbinarli alla loro scala (le app di modellazione 3D di solito hanno unità di misura impostate, metri, piedi, ecc.), Ma una volta che ti allontani dai serbatoi e in alberi e altri oggetti di scenario, probabilmente avranno bisogno per essere personalizzato per adattarsi al tuo stile di gioco (in modo da modellare un albero e avere i mezzi per ridimensionarlo nell'editor di gioco per renderlo bello, molte volte riutilizzerai lo stesso albero ma con una scala diversa per aggiungere varietà).

2. Non spostare la videocamera lontano dall'origine dei mondi, ma spostare il mondo attorno alla videocamera posta vicino all'origine dei mondi. In questo modo si evitano molti problemi di precisione che sorgono quando la GPU / la fisica devono confrontare con precisione valori con scarsa precisione. Se sposti il ​​serbatoio e la telecamera a 10 km dall'origine, la tua precisione sarà nel giro di poche frazioni di millimetro con float32 e ciò può causare effetti simili al combattimento a Z tra modelli trasformati.

3. Dovrai modificare le costanti globali per far star bene il tuo gioco. È lo stesso modo in cui cambi la scala relativa dei mondi per saltare parti noiose e racchiudere cose più interessanti in una piccola area di 4x4 km (città, fiume, montagna, ecc.) Che sono lontani l'uno dall'altro nel mondo reale.

4. Se sembravano ridimensionati meglio, ridimensionali. Se si adattano così come sono, conservalo. I giochi e i film sono più un'arte che non la realtà della copia cieca. Quindi hai trovato un albero dall'aspetto gradevole, che è solo modellato a 2 m di altezza, ovviamente lo ridimensioni e adatti il ​​tuo gioco con altri mezzi (modifica della palette, dettaglio delle trame, ecc.)

5. Dubito che ci siano differenze purché impieghino la stessa quantità di pixel sullo schermo per la visualizzazione.

Eccolo.

1. I programmi di modellazione 3D tendono a consentire di selezionare la scala dell'unità. Potrebbe essere limitato a Imperial o Metrico, ma è solo un numero. I numeri possono essere convertiti / ridimensionati / regolati facilmente. Realmente non importa quale sistema di unità di utilizzare, fino a quando si utilizza quella uno . Rimani coerente, quindi 1 metro non diventa 1 piede.

   Modifica: Libro: codifica di gioco completata, terza aggiunta, capitolo 15, pag. 525, "Metri, piedi, cubiti o kellicam?"

2. I giochi con grossi pezzi di vertici possono fare diverse cose. Per uno, possono dividerlo in piccoli blocchi, quindi i dati che si riferiscono a quel blocco possono specificare un offset. Un po 'simile all'utilizzo di Octrees, che è un'ottimizzazione del rendering per evitare il rendering di grandi porzioni di vertici invisibili. In alternativa, un doppio può memorizzare 1.79769e + 308 , che è un numero piuttosto grande, ma dettagliato. Un float può contenere 3.40282e + 038, che non è neanche squallido.

   Modifica: codifica di gioco completata, terza aggiunta, capitolo 13, pag. 410, "Coordinate e sistemi di coordinate" (tabella aggiunta in fondo al post)

3. Probabilmente vorrai quindi utilizzare un sistema metrico o convertirlo nel tuo sistema di unità. Vale la pena notare che probabilmente modificherai un po 'quel valore. Certo, il tuo valore ottimizzato non sarà fisicamente accurato. Ma potrebbe sentirsi più accurato a, diciamo, -9.3 m/s^2.

4. È possibile farlo in entrambi i modi. Anche se direi di ridimensionare la risorsa. Se ridimensioni il mondo, dovrai attraversare e modificare la gravità, i calcoli della velocità e ogni sorta di altre cose. Quando si importano risorse in Unity3D, di solito devo regolare la scala del modello nelle impostazioni di importazione, quindi suppongo che Unity la ridimensioni. Se volevi qualcosa di più in questo senso.

5. Grande o piccola, la dimensione dei poligoni / mesh non ha importanza quasi quanto il numero di poligoni. Suppongo che potrebbe esserci un leggero cambiamento nelle prestazioni a seconda di quanti pixel occupa il modello, ma il gioco è fatto. A parte questo, un numero che è 10 o 100 non cambia nulla sul computer. È ancora lo stesso numero di bit da elaborare, è solo che bit diversi sono 0.

Modifica: la tabella incerta assume un numero in virgola mobile IEEE a 32 bit.

Game Coding Complete, Third Addition, Table 13.2, pg. 411
Smallest unit         Smallest Representable object  Upper Range    Description of
                      (As a textured polygon)                       largest area

100m                  A group of redwood trees       1.67x10^9      Earth/Moon System
1m                    A Human Being                  1.67x10^7      North and South America
1cm                   A coin                         1.67x10^6      California
1mm                   A flea                         1.67x10^5      San Francisco Bay Area
100 micrometer        A grain of pollen              1.67x10^4      Downtown San Francisco

Tutte queste informazioni e molto altro in Game-Coding Complete. Scritto da Mike McShaffry. Un professionista del settore che lavora a giochi che vanno da Black Jack a Thief: Deadly Shadows.