Лайфхак 2: Как сделать плавный переход, пренебрегая таймерам

Возможно бывали проблемы, когда надо сделать плавный переход, интерполяцию (Как например затемнение). Использовать Tick - неплохое решение, но нагружает CPU. Таймеры? Та же история. Та и у способа с таймером есть проблема с "шагами", которая исправляется или увеличением вызова таймера, или использование тика. Но то и другое - нагрузка на CPU. Ситуация не очень...

Но чисто случайно, методом проб и ошибок, разработал решение - отправлять на видеокарту время начала перехода, а дальше переход будет делать видеокарта, разгружая процессор! Как никак видеокарта работает быстрее и четче

Расклад такой - в материале создаем скалярный параметр StartTime и задаем какое-нибудь отрицательное число, чтобы он не активировался по началу игры (Ноль - чтобы он активировался сразу, или просто положительное число, активируется через какое-то время после начала игры)

Поясню - Активация означает, что StartTime сравнялся с глобальным временем, а так как глобальное время идет дальше, а StartTime остается, то их разность будет давать кол-во секунд после активации.

В этом и заключается особенность моего подхода, ибо теперь можно использовать прошедшее кол-во времени как альфа-значение для интерполяции и тд.

Умножая - Вы ускоряете значение

Деля - Ограничиваете значение от 0 до 1, где 1 будет через столько секунд, сколько в делителе (3 класс не забыли? :D)

Думаю уже догадались как это использовать - создаете UMaterialInstanceDynamic (MID). Или же задейсвуем Material Parameter Collection Instance - тоже удобная вещь (напишу реализацию сразу двух способов)

Такой способ думаю очевидно выигрышный, ибо:
[+] Автоматическая синхронизация — Не зависит от тика или таймеров.
[+] Плавность — Использует встроенный (глобальный) и независимый Time
[+] Гибкость - Если правильно распределить значения, то можно сделать 2-х и 3-х этапные переходы из 1-го значения от 0 до бесконечности. В любом случае можно не ограничиваться диапазоном значений, а также не забываем про функции внутри самого материала - их гораздо больше и они более универсальные
[+] Автономная работа - Процессор только отправляет информацию о начале перехода, а дальше все делает видеокарта, разгружая процессор

Оптимизируемся :D

========
#news #special #offtop
========

========
Встречайте, 𝗘.𝗖.𝗛.𝗢. !
Ваш помощник и ассистент в 𝗔𝗯𝘀𝗼𝗹𝘂𝘁𝗲 𝗟𝗮𝗯𝗼𝗿𝗮𝘁𝗼𝗿𝗶𝗲𝘀
Предназначен для навигации и имеет самый базовый функционал, но тем не менее, окажется довольно полезным !
========

========
• 🧪 Принимает анкеты для вступления в Absolute Science
• 📢 Помогает найти Telegram Канал
• 💬 Помогает найти Discord Сервер
• ⬇️ Помогает найти GameJolt Страницу
========

@PortalSolver_bot

Теперь у нас есть тг-бот!

В дискорде у нас есть прием заявок на вступление в команду, но т.к. до дискорд сейчас не достучаться без особых методов, то слышали просьбы людей сделать прием заявок в тг - и этот день настал!

Бот полностью навайбкоден написан на Python с использованием библиотеки python-telegram-bot. Абсолютно простая логика работы, тяжелее было только Атому, который делал стилистику сообщений, ибо текст с форматированием Markdown2 выглядит супер-нечитабельно, но зато результат!

Дальше запуск этого шедевра на арендованном серваке за 140 рублей в месяц, там-то и пригодился мой бывший опыт работы с линукс на Raspberry Pi - SSH, apt, генерация ключей и тд.

В целом все, увидимся

(Кто будет спамить - лично приеду с толстым справочником по С++)

Знаете, а я тут подумал...

Емае, пока 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