My Racing Simulator (Track and Rally)

(Aggiornata al 2019/01/07)

Col tempo perfeziono un simulatore di guida.
Riporto qui le scelte hardware/software che ho fatto, e qualche commento se vi interessa cimentarvi in un progetto simile.

Wheel

T500RS di ThrustMaster

Questione di gusti e budget.
Non ho alcun cambio manuale, preferisco il sequenziale essendo più orientato al genere track e non al rally.

Seat

Anche qui questione di gusti.

Prima di quella avevo una RSeat RS1, ma sfortunatamente era incompatibile con la piattaforma DOF che ho acquistato in seguito.

Wind

Fan Controller di Sim Projects e due SANYO high speed fan ( 16.000 RPM , 12V, 3A ).

Il software Sim Dash si collega ai dati di telemetria di diversi titoli (Projects Cars 2, Assetto Corsa, iRacing etc) per regolare il vento in base alla velocità.

E’ molto godibile, aumenta notevolmente la percezione della velocità, e molto piacevole d’estate perchè evita che si appanni l’headset se fa caldo.

Shake

Elite SRS ShakeCombo di Sim Racing Studio

Anche questo si collega ai dati di telemetria, il kit è visto dall’OS come scheda audio a cui il driver manda i bassi per le vibrazioni.
Tre aree: seduta, pedaliera, schienale.

Carino, ovviamente serve per sentire fisicamente quando si tocca un cordolo o si entra in una zona sterrata.

Motion Platform

P3 di DOF Reality

Le piattaforme son classificate a seconda di quanti assi gestiscono (da 1 a 6).
I primi tre assi sono rotazione sugli assi X, Y, Z. Gli altri 3 sono traslazione sugli assi.

Ho scelto il modello P3 (3 DOF) di DOF Reality per il costo contenuto (non avendo modo di provarne diversi), e perchè mi lascia la possibilità un domani di upgradare al modello P6 (6 DOF).

VR Headset / HMD

Pimax 5K+
Dual Customized CLPL panels with 5Kplus 2*2560*1440 
200° Diagonal FOV, physical IPD adjustment

Il visore non è dotato di audio, uso delle Sennheiser wireless.

La scelta è tra usare monitor 2D o un visore VR.
Monitor, di solito se ne usano 3 (più altri per stats e telemetria), ma preferisco la VR come realismo. Per questo ho optato per il Pimax, che ha un FOV (Field Of View) enorme riducendo notevolmente “l’effetto maschera” di altri headset (Oculus, Vive etc), oltre ad una risoluzione notevole contro lo screen-door effect.

Se optate per i 3 monitor, tenete presente che dovrebbero muoversi insieme alla piattaforma DOF.

Probabilmente per sessioni di ore ed ore da professionista, monitor 2D sono meno faticosi per la vista.

Tenete presente che i titoli di racing che supportano il VR sono pochi.

Video card

Asus ROG STRIX RTX 2080 Ti Advanced Edition 11 GB GDDR6 (Amazon.it)

Anche una scheda video minore può essere accettabile, a patto di rinunciare alla qualità grafica mantenendo i 90fps se utilizzate un headset VR. Il frame-rate è fondamentale per evitare il motion sickness, soprattutto agli ospiti/amici neofiti. Per questo tendo ad evitare qualsiasi interpolazione (reprojection) cercando di tenere il rate dell’headset, a discapito della grafica.

Se optate per monitor 2D, è sufficente una scheda minore.

PC

Un qualsiasi PC medio-alto (un I7 come minimo), adatto alla scheda video.

Software

Windows 10.

Sim Racing Studio, SimDash per l’hardware

fpsVR , PiTool, SteamVR per il VR.

Come simulatori, che supportano la VR ce ne sono pochi, attualmente uso

  • Projects Cars 2 – Entertainment, ad esempio giro Lamborghini in Costa Azzurra, o rally su neve. Il preferito per ospiti e neofiti. Il generale una configurazione che predilige la grafica e il divertimento alla precisione. Ad esempio, no danni reali.
  • Assetto Corsa – Simulazione, generalmente la F2004 di Michael Schumacher a Monza. Configurata per una esperienza il più realistica possibile.
  • iRacing ce l’ho configurato, ma preferisco Assetto Corsa nel suo target.

Nausea (Motion Sickness) in VR

Scrivo una articolo sul problema nausea nel VR (Virtual Reality), basandomi sulla mia esperienza.

E’ un problema molto importante per questa tecnologia. Quelli che pensano che sia il limite di QUESTA generazione di tecnologia VR sbagliano, il problema è più complesso e non è generalmente legato all’hardware in uso.

La nausea nel VR viene quando i sensori naturali del corpo umano trasmettono delle informazioni contraddittorie. Il vostro cervello pensa siate malati, e attiva una strategia di sicurezza: la nausea per vomitare.

Inoltre, più tempo si usa un sistema VR, più la nostra mente & corpo si abitua. Personalmente, uso prototipi VR da 3-4 anni, e non c’è più quasi nulla che mi provoca nausea.

Credo ci sia qualcosa anche legato all’età. Faccio provare i miei sistemi VR a parecchi amici (che mi chiedono spiegazioni, altro motivo di questo articolo). Non ho mai riscontrato alcun problema di nausea in ragazzi/e sotto i 16 anni, che riescono a giocarci anche per ore. Probabilmente un’adattamento più rapido del loro sistema vestibolare.

Parliamo di sistemi così evoluti (finalmente) che cercano di ingannare il cervello umano per fargli credere di essere davvero in un ambiente non reale. Il paragone delle tecnologie VR vs occhialini 3D mi fà rabbrividire ogni volta che lo sento.

Riassumo qui sotto le soluzioni software e hardware attualmente in uso che conosco. I link ai titoli di videogiochi sono i trailer su YouTube.

Soluzioni Software

  • Evitare completamente un movimento che non avviene nella realtà.

    Nella maggior parte dei casi richiede una configurazione dello spazio dedicato al sistema VR chiamato Room space.
    L’azione nel gioco può avvenire interamente nell’area fisica dedicata al VR. Fantastic Contraption è stato praticamente il primo titolo di questo genere.
    Ma non è strettamente necessario, in The Climb si può esplorare interi ambienti senza alcun movimento artificiale.

  • Collocare il giocatore in un ambiente virtuale fisso

    Se il giocatore è all’interno di un veicolo (una macchina, un’astronave, un mech) la nausea da movimento è ridotta. Anche perchè generalmente la vista periferica è statica (vedi Tunneling più avanti).

  • Anticipare la traiettoria di movimento

    Il movimento del giocatore nell’ambiente è prestabilito. Tipo una corsa su vagoni delle giostre.
    Metodo scelto da Until Dawn Rush Of Blood, Archangel e molti altri.
    Il sapere a priori quale sarà il movimento che sta per avvenire, riduce notevolmente la reazione negativa del sistema vestibolare. Se la velocità di corsa è alta, è consigliato mostrare graficamente il percorso per permettere al cervello di anticipare il movimento.

  • Teleporting

    Teleporting con orientamento

    Non è molto amato dai giocatori, perchè (oltre a essere innaturale ovviamente) nella maggior parte dei casi dopo il teleporting ci vuol del tempo perchè il giocatore si renda conto della nuova posizione (tipicamente l’orientamento).
    In Robo Recall han cercato di risolvere chiedendo al giocatore di impostare il futuro orientamento a priori.
    Deve inoltre essere introdotto con una dissolvenza (fade in/out), che anche questo spezza l’esperienza.
    Infine è ovviamente scorretto se usato per schivare nemici.

  • Tunnelling

    Tunneling: Comfort Mode in Google Earth VR

    Si tratta di nascondere la vista periferica durante il movimento, anche come segnale di movimento in corso.

    E’ il metodo scelto da Google Earth VR, chiamato “Comfort Mode” (disattivabile).

  • Ridurre o rimuovere al minimo le accelerazioni
    Le accelerazioni provocano nausea. Nel VR è meglio passare a una velocità di movimento secca al volo.
  • Ridurre al minimo la necessità di rotazione manuale (tipico Mouse Yaw, o la rotazione negli FPS muovendo orizzontalmente il thumbstick destro).Alcune esperienze VR sono chiamate forward-only, ad esempio Farpoint, se concepiti in modo da non richiedere MAI una rotazione manuale del giocatore, e quindi compatibili anche con ambienti VR da 180° e non 360°.

    Se la rotazione manuale è indispensabile, deve avvenire a step (45° o 90° tipicamente), e non in maniera fluida come avviene in qualsiasi gioco 2D.

Best practice

Se un gioco è nato per il 2D, o se deve supportare sia 2D che VR, ci sono diversi accorgimenti che van sistemati o radicalmente disattivati. Ne cito solo qualcuno come esempio.

  • Spesso elementi grafici nel 2D non sono reali oggetti nella scena, ma ‘overlay’ o come risultato di post-processing 2D. Un tipico esempio è la luce volumetrica da finestre. Questi elementi van corretti o rimossi nella versione VR.
  • Ci sono dei movimenti del giocatore che nel 2D sono tipici, ma nel VR vanno rimossi, ad esempio il bobbling (il fatto che nei giochi 2D mentre si cammina, la testa ondeggia per aumentare l’effetto), o l’ondeggiare nel salire una scala, etc.
  • Effetti di blur, soprattutto se di simulazione della messa a fuoco su un momento importante di una scena.

Se l’adattamento al VR è fatto male (anche semplicemente ombre sbagliate etc), il cervello reagisce male e fa scattare la nausea.

E’ sbagliato pensare che qualsiasi gioco in soggettiva possa essere adattato al VR con poco sforzo.

Soluzioni Hardware


La mia postazione Project Cars.
Una postura corrispondente
all’esperienza VR
aiuta ad evitar
la nausea
  • PC: Assicurarsi che il software giri constantemente al massimo degli FPS (90 nel caso di Oculus Rift e HTC Vive).

    Se il framerate scende, uno ‘scatto’ nel semplice movimento della testa provoca nausea.
    Questo è in assoluto l’accorgimento più importante che TUTTI devono verificare/sistemare prima di usare un sistema VR.

  • Headset: in teoria prossime generazioni di caschetti dovrebbero ulteriormente limitare la nausea, introducendo ad esempio FOV più ampi.
    Ma questo sarà comunque relativo, il grosso dei problemi NON è legato all’headset e non può essere risolto dalle generazioni future di hardware VR.
  • Controller corrispondenti alla realtà virtuale: Una postazione di guida, una vera chitarra in Rock Band VR, impugnare un fucile con Farpoint.
  • Esistono strumenti che usano un processo chiamato neuromodulation, impulsi elettrici che tentano di regolare il ritmo gastrico.
    Ad esempio Reliefband. Non ho idea se funzionano, mai provati.
    Ovviamente, soluzione correlata, farmaci per prevenire la nausea. Personalmente non prenderò mai un farmaco per giocare a un videogioco.
  • Treadmill Simulator: Hardware per simulare il movimento. Il più famoso credo sia il Virtuix Omni.
    Si indossano scarpe scivolose, che riportano il piede in posizione centrale per procedere con il passo successivo.

    Personalmente, mai provato nessuno. Che io sappia, non ci sono neanche titoli AAA che li supportano nativamente.
    Generalmente non fan nient’altro che simulare il tasto W della tastiera per il movimento del giocatore.

Per ora non mi viene in mente nient’altro. Aggiornerò l’articolo se mi salta in mente qualcos’altro, o scrivetemi nei commenti. Ciao!

Sample ODS video

I rendered with POV-Ray (using my approach) a sample 360 degree, omnidirectional, stereo video (top/bottom).
Can be used for stress testing VR Video players, HMD etc.

It’s a 120 frame animation, loopable. It mean one seconds at 120 FPS (for example PSVR), 1.25 seconds at 90 FPS (Oculus Rift, HTC Vive), etc.

YouTube Preview:

Real plain preview:

It took around 4 days for rendering on my i7 with eight cores.
Every frame have 7680 x 7680 pixels resolution (Stereo top/bottom), around 32 MB PNG each.
I encoded it in different FPS and resolution. As explained in my other post about ODS, x264 don’t support highest framerate at highest resolution.

ffmpeg command-line encoding:

ffmpeg\bin\ffmpeg.exe -framerate 60 -i sample%03d.png -c:v libx264 -preset veryslow -vf scale=1280:720 -x264-params crf=18 -c:a aac -strict experimental preview.mp4

Download links

Image:
Single shot image, 7680 x 7680 pixels (9370 KB)
Videos:
x264 – 30 FPS – 4K UHD
x265 – 60 FPS – 4K UHD
x265 – 90 FPS – 4K UHD
x265 – 90 FPS – 4K DCI
x265 – 90 FPS – 8K
x265 – 120 FPS – 8K

POV-Ray source code: .pov, .ini.

Omni­directional stereo (ODS) with POV-Ray

Omni­directional stereo (ODS) is a projection model for stereo 360 degree videos
It’s designed for VR viewing with a head­mounted display (HMD).
More information here.

I developed and tested for fun an approach for raytracing, open-source POV-Ray software.

How to render

Currently (2016-03-11), render ODS image require an alpha version of POV-Ray, that support user_defined camera. Download from here
Or use my POV-Ray fork. More information on this below.

With POV-Ray official (Alpha),
Use the following code for an ODS top-bottom (left eye on top, right eye on bottom):

// ODS Top/Bottom - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree. 

camera {
  user_defined
  location {
    function { odsLocationX + cos(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin(select(y, 1-2*(y+0.5), 1-2*y)*pi)), odsVerticalModulation))*select(-y,-1,+1) }
    function { odsLocationY }
    function { odsLocationZ + sin(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin(select(y, 1-2*(y+0.5), 1-2*y)*pi)), odsVerticalModulation))*select(-y,-1,+1) * odsHandedness }
  }
  direction {
    function { sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -select(y, 1-2*(y+0.5), 1-2*y) * pi) }
    function { sin(pi / 2 - select(y, 1-2*(y+0.5), 1-2*y) * pi) }
    function { -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -select(y, 1-2*(y+0.5), 1-2*y) * pi) * odsHandedness }
  }
}

Use the following code for an ODS side-by-side:

// ODS Side-by-Side - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree. 

camera {
  user_defined
  location {
    function {  odsLocationX + cos(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin((1-(y+0.5))*pi)), odsVerticalModulation))*select(x,-1,1) }
    function {  odsLocationY }
    function {  odsLocationZ + sin(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin((1-(y+0.5))*pi)), odsVerticalModulation))*select(x,-1,1) * odsHandedness }
  }
  direction {
    function {  sin(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) }
    function {  sin(pi / 2 - (1-(y+0.5)) * pi) }
    function {  -cos(((select(x,2*(x+0.5),2*x)+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) * odsHandedness }
  }
}     

Use the following code for single eye rendering:

// ODS Single Eye - Docs: https://www.clodo.it/blog/?p=80
#declare odsIPD = 0.065; // Interpupillary distance     
#declare odsVerticalModulation = 0.2; // Use 0.0001 if you don't care about Zenith & Nadir zones.
#declare odsLocationX = 0;
#declare odsLocationY = 0;
#declare odsLocationZ = 0;
#declare odsHandedness = -1; // "-1" for left-handed or "1" for right-handed
#declare odsAngle = 0; // Rotation, clockwise, in degree.              
#declare odsEye = -1; // -1 for Left eye, +1 for Right eye

camera {
  user_defined
  location {
    function {  odsLocationX + cos(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin((1-(y+0.5))*pi)), odsVerticalModulation))*odsEye }
    function {  odsLocationY }
    function {  odsLocationZ + sin(((x+0.5+odsAngle/360)) * 2 * pi - pi)*(odsIPD/2*pow(abs(sin((1-(y+0.5))*pi)), odsVerticalModulation))*odsEye * odsHandedness }
  }
  direction {
    function {  sin(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) }
    function {  sin(pi / 2 - (1-(y+0.5)) * pi) }
    function {  -cos(((x+0.5+odsAngle/360)) * 2 * pi - pi) * cos(pi / 2 -(1-(y+0.5)) * pi) * odsHandedness }
  }
}                               

Caveats

  • Camera Direction is actually not supported. It’s always look_at<0,0,1>. You can use the odsAngle parameter for a rotation (degree) around Y axis.
  • Zenith & Nadir Zones
    Base ODS algorithm have spiral/singularities towards the zenith and nadir points.To avoid that, i modulate the stereoscopic eye separation such that it begins at normal eye separation near the horizon, and is smoothly decreased, reaching zero by the time either the zenith or nadir points on the polar axis are visible to the user, producing a monoscopic image. 

    I use this formula:

    where 0.02 it’s the odsVerticalModulation and 0.065 the default IPD. Play with this value to understand how IPD are reduced near the Zenith (x:-0.5) and Nadir (x:0.5).

    In general, it’s recommended to avoid objects at zenith & nadir points, and use a odsVerticalModulation near 0 (0.0001), to obtain a perfect IPD / 3d effect.
    If you have objects at zenith & nadir points, use a odsVerticalModulation near 1 can be a good compromise.

    Other approach:
    Domemaster3D (Shader for 3DS Max, Mata, Softimage etc) recommend a texture to reduce the effect. link

    SolidAngle/Arnold use mixed approach. link

    Another kind of modulation: link

Best practice

  • Objects should remain at least 60cm from the camera (relative to an IPD of 6.5cm).
    Use this POV-Ray code to check (it’s auto adapt based on IPD): 

    sphere
    {
      <odsLocationX,odsLocationY,odsLocationZ>, 0.6*odsIPD/0.065
      pigment
      {
        color <1,0,0>
        filter 0.97
      }
      hollow
    }
    
  • Objects appearing directly above or below the camera should remain at least 3.5m from the camera (relative to an IPD of 6.5cm).
  • Antialiasing is very very very important on VR headset.

Recommended Resolutions

I recommend, at least for the current (year 2016) generation of VR headset (GearVR, Oculus Rift, HTC Vive), at least 6480 x 6480 pixels in top/bottom for static images. For videos, see below.

Resolution must have 2:1 aspect ratio (standard equirectangular), that become 4:1 for side-by-side or 1:1 for a top-bottom.

TL;DR;
It’s difficult to estimate a good resolution.
VR headset do a distortion for lenses, any every VR headset can have different lenses, different FOV, different panel resolution etc.

The GearVR for example has a 90° FOV on a 2560×1440 panel, but the center pixel covers 0.06° after distortion. This value is sometime called “pixel coverage” or “pixel density” or “pixel per display pixel” or “eye buffer scaling”. So, for the GearVR, 0.06° pixels means we need 360/0.06 = 6000 pixels to cover one monoscopic turn.

Rendering Animation/Video

This is actually problematic.

In theory, the resolution must be at least as explained above for images.

Any VR headset require a high frame-rate to avoid nausea.

  • Oculus Rift DK2 (Development Kit 2): 75 FPS
  • Oculus Rift CV1 (Customers Version 1): 90 FPS
  • HTC Vive: 90 FPS
  • Sony Playstation PSVR : 120 FPS

In general, future-generation VR headset: expected 120 FPS

But H264 don’t have any level profile compatible with this kind of resolution.
Also HEVC/H265 have the same problem.

But we also need a coded that is hardware-accelerated to obtain the high FPS requested, and generally only H264/H265 are optimized for this.

VR Players

Virtual Desktop – There isn’t any option about side-by-side vs top-bottom, it simply detect it from the aspect ratio: 4:1 for side-by-side, 1:1 for top/bottom.

MaxVR

Both player can’t reproduce H265 high resolution videos.

My POV-Ray fork on GIT-Hub

With a POV-Ray builded from my fork, you can simply use a spherical camera:

camera
{             
  spherical   
  //ipd 0.065
  ods 4 
  //ods_angle 0
  //ods_modulation 0.2
  //ods_handedness 1
  location <0,0,0>  
}             
  • ods: 0 for monoscopic image, 1 for left eye only, 2 for right eye only, 3 for side-by-side, 4 for top/bottom. 0 is default. 4 recommended.
  • Other parameters ipd, ods_angle, ods_modulation and ods_handedness are the same of the user_defined approach param described above.

Interesting Links

Kudos

Many, many thanks to:

Christoph Lipka, William F Pokorny, Jaime Vives Piqueres from POV-Ray newsgroup.
Joan from Oculus Forum.
Jakob Flierl (checkout is GIT-Hub repo about ODS).

Examples of rendering

Some example of rendering (6480 x 6480 pixels, Top-Bottom).

Mirrors – I made this

——————
Stacker Day – POV-Ray sample scene adapted for ODS

——————
Fractals 1 – POV-Ray sample scene adapted for ODS

——————
Fractals 2 – POV-Ray sample scene adapted for ODS

——————
Wineglass – POV-Ray sample scene adapted for ODS

——————
Axis – Test reference

I also rendered a sample video that can be used for stress-testing of VR video players.

QUICKRES.INI

Reference resolutions for POV-Ray quickres.ini

[ODS TB Quick Test - 512 x 512]
Width=512
Height=512
Antialias=Off

[ODS TB Test - 1024 x 1024]
Width=1024
Height=1024
Antialias=Off

[ODS TB Minimum - 3600 x 3600]
Width=3600
Height=3600
Antialias=On
Antialias_Threshold=0.3

[ODS TB High - 6480 x 6480]
Width=6480
Height=6480
Antialias=On
Antialias_Threshold=0.3

[ODS TB Ultra - 12288 x 12288]
Width=12288
Height=12288
Antialias=On
Antialias_Threshold=0.3

[ODS TB 1440p - 2560 x 1440]
Width=2560
Height=1440
Antialias=On
Antialias_Threshold=0.3

[ODS TB UHD-1 2160p - 3840 x 2160]
Width=3840
Height=2160
Antialias=On
Antialias_Threshold=0.3

[ODS TB DCI 4K - 4096 x 2160]
Width=4096
Height=2160
Antialias=On
Antialias_Threshold=0.3

[ODS TB 8K UHD - 7680 x 4320]
Width=7680
Height=4320
Antialias=On
Antialias_Threshold=0.3

[ODS LR Minimum - 7200 x 1800]
Width=7200
Height=1800
Antialias=On
Antialias_Threshold=0.3

[ODS LR High - 12960 x 3240]
Width=12960
Height=3240
Antialias=On
Antialias_Threshold=0.3

[ODS LR Ultra - 24576 x 6144]
Width=24576
Height=6144
Antialias=On
Antialias_Threshold=0.3
[ODS LR Low - 7200 x 1800]
Width=7200
Height=1800
Antialias=On
Antialias_Threshold=0.3

[ODS LR Normal - 12960 x 3240]
Width=12960
Height=3240
Antialias=On
Antialias_Threshold=0.3

[ODS LR High - 24576 x 6144]
Width=24576
Height=6144
Antialias=On
Antialias_Threshold=0.3

[ODS TB Low - 3600 x 3600]
Width=3600
Height=3600
Antialias=On
Antialias_Threshold=0.3

[ODS TB Normal - 6480 x 6480]
Width=6480
Height=6480
Antialias=On
Antialias_Threshold=0.3

[ODS TB High - 12288 x 12288]
Width=12288
Height=12288
Antialias=On
Antialias_Threshold=0.3

[ODS TB YouTube - 3840 x 2160]
Width=3840
Height=2160
Antialias=On
Antialias_Threshold=0.3