⬀
⬁
⬂
⬃
⬄
⬅
⬆
⬇
⬈
⬉
⬊
⬋
⬌
⬍
⬎
⬏
⬐
⬑
⬒
⬓
⬔
⬕
⬖
⬗
⬘
⬙
⬚
⬛
⬜
⬝
⬞
⬟
⬠
⬡
⬢
⬣
⬤
⬥
⬦
⬧
⬨
⬩
⬪
⬫
⬬
⬭
⬮
⬯
⬰
⬱
⬲
⬳
⬴
⬵
⬶
⬷
⬸
⬹
⬺
⬻
⬼
⬽
⬾
⬿
⭀
⭁
⭂
⭃
⭄
⭅
⭆
⭇
⭈
⭉
⭊
⭋
⭌
⭍
⭎
⭏
⭐
⭑
⭒
⭓
⭔
⭕
⭖
⭗
⭘
⭙
⭚
⭛
⭜
⭝
⭞
⭟
⭠
⭡
⭢
⭣

☀
☁
☂
☃
☄
★
☆
☇
☈
☉
☊
☋
☌
☍
☎
☏
☐
☑
☒
☓
☔
☕
☖
☗
☘
☙
☚
☛
☜
☝
☞
☟
☠
☡
☢
☣
☤
☥
☦
☧
☨
☩
☪
☫
☬
☭
☮
☯
☰
☱
☲
☳
☴
☵
☶
☷
☸
☹
☺
☻
☼
☽
☾
☿
♀
♁
♂
♃
♄
♅
♆
♇
♈
♉
♊
♋
♌
♍
♎
♏
♐
♑
♒
♓
♔
♕
♖
♗
♘
♙
♚
♛
♜
♝
♞
♟
♠
♡
♢
♣

♤
♥
♦
♧
♨
♩
♪
♫
♬
♭
♮
♯
♰
♱
♲
♳
♴
♵
♶
♷
♸
♹
♺
♻
♼
♽
♾
♿
⚀
⚁
⚂
⚃
⚄
⚅
⚆
⚇
⚈
⚉
⚊
⚋
⚌
⚍
⚎
⚏
⚐
⚑
⚒
⚓
⚔
⚕
⚖
⚗
⚘
⚙
⚚
⚛
⚜
⚝
⚞
⚟
⚠
⚡
⚢
⚣
⚤
⚥
⚦
⚧
⚨
⚩
⚪
⚫
⚬
⚭
⚮
⚯
⚰
⚱
⚲
⚳
⚴
⚵
⚶
⚷
⚸
⚹
⚺
⚻
⚼
⚽
⚾
⚿
⛀
⛁
⛂
⛃
⛄
⛅
⛆
⛇

⛈
⛉
⛊
⛋
⛌
⛍
⛎
⛏
⛐
⛑
⛒
⛓
⛔
⛕
⛖
⛗
⛘
⛙
⛚
⛛
⛜
⛝
⛞
⛟
⛠
⛡
⛢
⛣
⛤
⛥
⛦
⛧
⛨
⛩
⛪
⛫
⛬
⛭
⛮
⛯
⛰
⛱
⛲
⛳
⛴
⛵
⛶
⛷
⛸
⛹
⛺
⛻
⛼
⛽
⛾
⛿

— т. е. материал стекла задаёт дефолтный color, который можно перекрыть в конкретном объекте. В итоге параметры, которые требует шейдер, приходится искать по именам непосредственно перед отрисовкой и заливать по одному. Это идиотизм, правильным вариантом были бы жёстко определённые блоки параметров, один в один проецирующиеся на буфер в видеопамяти — тогда, скажем, даже если чайник рисуется 5 шейдерами — а это норма, если учесть теневые карты там всякие, G-буфер для постэффектов, — блок с параметрами конкретного чайника существует в видеопамяти в единственном экземпляре и шарится всем, кому он нужен. Для тяжёлых данных, вроде скелетов, это становится критично. 150 костей = 150 × (3 ofs + 4 rot) × 4 байта, × 60 кадров/сек = 250 Кб/сек и несколько сотен API-вызовов, почему бы ещё 5 раз не повторить, всё равно же делать нечего?

Об устарелости, я не сделал всякие крутые штуки (от Deferred Shading и далее, да хотя бы даже нормальные преломления в воде) только потому, что у меня постпроцесс спроектирован a) кастрированным, b) опциональным. Тогда как рендеринг в текстуры и компонование из них финальной картинки вместо прямого рисования на экран делают уже, наверное, лет 15, и куча всяких эффектов и техник дешевле всего реализуются (а то и вообще — возможны) именно таким образом.

Отдельные потоки для окна и рендера были ещё более идиотской идеей, когда-то мне об этом говорили умные дядьки, я их не понимал. И оконная система, и видеодрайвер ведут очереди сообщений/команд (иногда за такой очередью вообще не стоит потока: https://habr.com/post/216659/), так что выделяя работу с ними в отдельный поток, ты ставишь в очередь команды, которые ставят в очередь команды. Не говоря уже о том, что основной цикл aka Input-Update-Draw принципиально не параллелится: для Update нужен результат Input, а для Draw — результат Update. Что нужно параллелить, так это подгрузку ресурсов, на которую у меня, естественно, нет и намёков.

В целом нужно лепить игру кубами и уделять внимание более фундаментальным и вместе с тем прямо ложащимся на код вещам. Инверсная кинематика или генерация помещений (CSG) так и остались на уровне влажных фантазий, потому что я пошёл по пути переусложнения обёрток над обёртками и завысил уровень абстракции, а ведь они не так сложно устроены и при этом открыли бы безграничные возможности. Поэтому больше всего на свете я хочу забыть слово virtual. Как говорил классик, «возьмем базовый класс „Кнопка“ и отнаследуем от него два класса — „Зеленая кнопка“ и „Красная кнопка“... Согласитесь — уже отдает какой-то бредятиной. Любой здравомыслящий человек напишет единственный класс „кнопка“, мембером которого будет „цвет“».