Емае, пока Unreal Engine запускается как минимум на компьютерах НАСА...

Один человек с ником Mathis просто в соло собрал небольшой каскад яркости (новый подход к решению задачи глобального освещения) на GLSL в ShaderToy прямо в браузере... Дак еще оно стабильно держит 80 кадров в секунду!

Я думаю это стоит опробовать:
https://www.shadertoy.com/view/M3ycWt
(ЛКМ - Вращать камеру, WSAD - Перемещаться)

❤️ - Соберите это в Майнкрафте
🔥- Шах и мат Epic Games

Простить можно каждого, но не Эпиков

Конечно опыт штука интересная... Но кто ж знал, что спустя практически год в Unreal Engine, я только тогда пойму что можно легко избавляться от дублирующихся ассетов? Кстати такие штуки называются Redirector - Пока вы работаете с ассетом, думая что это оригинальный, Redirector сидит где-то в углу вечеринки и является оригиналом

Проще говоря - когда я перенес папку с ассетами в другой каталог, то новые ассеты перенеслись, а старые остались. Удалить их через Проводник? - Пропадут новые. Емае...

А теперь узнал, что такие фокусы называются Redirector. В общем хотфикс быстрый - нажимаем ПКМ по папке (в которой находятся старые ассеты) и кликаем по Update Redirector References (В UE4 - Fix Up Redirectors In Folder). Соглашаемся на удаление старых редиректоров и бинго

Кстати если интересно посмотреть на редиректор, то в Content Browser открываем фильтры и включаем показ редиректоров. Кликнув 2 раза по ним, они перенаправят на тот ассет, на который ссылаются

Итоги:
- Фантомные ассеты убраны (я их так целый год называл хвхвхвхвх)
- Проект отсортирован
- 559 Changed Files (Удалено 559 старых ассетов)
(Кстати довольно таки хорошо место почищено - владельцы репозиториев, берите на заметку)

Чтобы блог не пустовал, решил с вами начать разработку движка.
Шутка. Я точно не знаю какая точка с запятой застряла во мне, но решил начать писать собственный движок на С++

Да не просто движок, а с особой системой представления классов - смесь унаследованной (ООП) и компонентной (ECS)

Про ООП (Объектно-ориентированное программирование):

В ООП классы представляют как цепочку, унаследование. Например:
- Объект -> Сущность -> Компонент Сцены -> Пешка -> Игрок (логика игрока)
Или:
- Объект -> Сущность -> Компонент Сцены -> Пешка -> Зомби (логика зомби)

Но... Если я хочу, чтобы игрок был с логикой зомби? Тут уже начинается проблема ООП программирования, именуемой "Алмаз Смерти". Класс можно унаследовать только от 1 родителя, без пересечений. То есть я не могу просто соединить Игрока и Зомби 
(А еще вставлю свои 5 копеек - тот же "Актор" в области Unreal Engine имеет много лишнего из-за слишком большой цепочки унаследования, что усложняет структуру движка и в будущем может убить оптимизацию)

Про ECS (Entity-Component-System - Сущность-Компонент-Система):

В ECS все представлено 3-мя основными понятиями - Сущность, Компонент и Система

В двух словах:
- Сущность хранит в себе набор Компонентов
- Компоненты хранят в себе только нужные им данные (координаты для компонента перемещения, скорость для комопнента физики и тд.)
- Система лишь имеет ссылки на эти компоненты и только просчитывает всю логику внутри

И естетсвенно это решает проблему "Алмаза Смерти", ибо теперь игрока, зомби и зомби-игрока можно собрать из компонентов, а всю логику прописать в единственном центральном блоке (системе)

Но от такого подхода может пострадать структура движка, ведь тот же UI - зачем мне в нем компоненты? Когда надо обычное унаследование:
Главное меню -> Настройки -> Настройки графики

И скажу честно - сейчас в том же Портал Солвере реализована небольшой набросок система-компонент, когда я писал лазеры

По началу я объединил логику лазеров в 1 класс, но тут произошел конфликт - лазерные кубики унаследованы от общего класса кубиков, и поэтому я не могу его унаследовать еще и класса с лазерами, поэтому.... Написал компонент для лазерных объектов + подсистему для обработки лазеров

В принципе это можно считать чем-то ECS, не учитывая что это больше как костыль, чем решение
(А один мой знакомый на Юнити так вообще написал 15+ компонентов и систем в 1-м игроке!! Емае, слава этому герою хвхвхв)

В общем сложив А + Б, выходит что ООП и ECS хороши по своему, а учитывая постоянную константную МнеНечегоДелать, то можно попробовать так вообще написать свой движок. Поэтому представляю вам!

Root Engine
Движок, написанный на смешанности ECS и ООП. Да, я знаю - это безумно. В принципе еще никто особо не реализовывал это (Все говорят про минусы ООП в отличии от ECS, а никто не думал соединить их?)

Скажу сразу: Это чисто базовый эксперимент. У меня нет желания соревноваться с Unity, Unreal Engine, Godot и тд. Да, структура кода будет напоминать Unreal Engine - мне так привычней, как программисту на UE. Синтаксис интуитивно понятен и привычен

Немного про наш с вами план:
- Для начала напишем логику отображения окна и отделим логику от движка, чтобы в любой момент мы могли переписать модуль отображения окна и ничего не слетело
- Затем рааспишем структуру всего движка (рендера, математика и тд. - в дальнейшем расскажу)
- И самое главное... Рефлексия - это инструмент, который анализирует пользовательский код и разбивает его в понятный для движка код (раздрабливает) и загружает его в редактор (не перезапуская и не перекомпиируя сам движок). По сути этим можно назвать UHT - Unreal Header Tool, что генерирует файлы с вашим классом, но понятный для движка и затем движок применяет эти изменения. А вы думали откуда движок понимает, что такое UCLASS, UPROPERTY, UENUM и тд? :D (Интересный факт - почти у всех современных языков программирования С#, Java, Python и тд. - есть свои полностью реализованные под капотом инструменты рефлекси, А С++ увы... Будем учиться писать)

Вот такие пироги, считайте это наш 0-й день!

#RootEngine #PortalSolver