Mivel írtad, hogy sok a transparent rész, ezért jegyezném meg, ami nagyon tipikus az openBve-ben, viszont nem túlzottan javasolt. A szép megjelenítés érdekében a poligonokat rendezni kell, minden pillanatban a kamera távolságának megfelelően, ez az alpha sorting. Ez a hivatalos dokumentációban benne is foglaltatik az "Information and Tips" szekciónál. Tehát a gépnek minden képkocka kirajzolása előtt rendezni kell az áttetsző poligonokat a kamera pozíciójától függően. Ez sok poligon esetén már egyre lassabb lesz, ráadásul a teljesítmény egy rendezés esetén egyre több számnál egyre gyorsabban romlik.

A translate parancsnak pedig nem szabad lassúnak lennie, azt a program egyszer, a betöltésnél dolgozza fel, utána már egy olyan geometriával dolgozik, amire alkalmazva lettek a translate és rotate parancsok.

Ami az openBve betöltésénél lassulást okozhat, az a hosszú modellfájlok használata, vagy pontosabban fogalmazva bármilyen kollekcióból egy hosszú használata, például sok meshbuilder, sok material vagy sok pont. A program a forráskód tanulsága szerint minden újonnan definiált tömbelemnél, például új vertexnél vagy meshbuildernél, átméretezi az azt tartó tömböt, ezt viszont úgy teszi, hogy az addigi elemeket átmásolja egy új, tágasabb helyre. Így sok elem esetén ez egyre lassabb lesz. A route fájl betöltésnél úgy tűnik, ez már ki lett küszöbölve, a modellfájlok meg nem kell, hogy hosszúak legyenek, tehát a tervezés végső soron logikusnak is nevezhető, más kérdés, hogy az azóta felbukkanó nyelvi verziók már lehetővé teszik illetve elvárják a listák használatát, amelyek a tömbökkel ellentétben a dinamikus hozzáadásra lettek megvalósítva, azt pedig meglehetősen gyorsan végrehajtják. A route fájl betöltésénél egy saját lista-implementáció féleség található, azért is gyorsabb annak a feldolgozása.