__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
nemyax там нет какого-то особенного способа. Линейный перебор всех поверхностей.
Добавлено 05-03-2020 в 10:04:
Цитата:
thambs писал: А полноцветные декали удалось с туманом подружить?
там и не было особой проблемы никогда. Проблема была в том, что на старых радионах polygonOffset валился в эмуляцию почему-то.
Цитата:
FiEctro писал: Как ты боришься с этим ?
с чем именно?
Добавлено 05-03-2020 в 11:07:
Всё дело в том, что в разработке одно цепляется за другое, за третье в конечном итоге, я не могу ничего финализировать, потому что неясна финальная концепция. Ключевой элемент - это освещение. На нём завязано абсолютно всё. И как организован формат уровней и механизм сетевой интеракции и система материалов. Пора уже приступать к самому важному.
Динамический индирект это конечно хорошо, но если у нас в кадре сотня лампочек с тенями, производительность упадёт ниже плинтуса еще на этапе прямого света. Второй момент - генеричность. Освещение должно быть естественно увязано с уже существующей системой материалов, причём таким образом, чтобы реализация была снаружи - в скриптах.
У меня нет ни малейшего желания прописывать Get\Set для сотен юниформов внутри кода, как это сделал, например автор Unigine.
Впрочем в CryEngine точто такая же беда. Да и еще много где. Это гнилой подход, он не нужен. Внутри движка должны быть только общие механизмы.
Опять же надо продумать формат скрипта интеракции, где всё это будет описано, причём он должен описывать не только освещение, но весь путь рендеринга, включая множественные проходы. Это позволит создавать пользовательские модели рендеринга. В одной игре пусть будет форвард, в другой - отложка. И всё это должно быть реализовано в скриптах.
Эта задача прежде всего сложна тем, что я не вижу конечного решения, оно будет находится в процессе непрерывной корректировки, ну собсно как я пришёл к текущей системе материалов. В процессе я этот механизм переписывал не менее десяти раз, прежде чем получил текущую систему.
Причём зайчатки этот концепции я прорабатывал еще в 2015-м году, но тогда я писал на чистом Си и оч. быстро запутался. А может просто опыта нехватало, кто его знает.
Да и то что у меня получилось - далеко не окончательный вариант, к примеру сейчас доступ к тем или иным переменным жёстко прописан в коде, а там должно быть нечто вроде системы сейв-рестора с поиском переменной по имени в структуре. По крайней мере для энтить, потому что пользователь может расширять CBaseEntity. В том же дуум3, к слову. отвели просто набор из parm-parm7, что хочешь то и пихай в эти переменные. Но это конечно узкое решение.
Ну вот с механизмом интеракции всё это приобретёт уже законченный вид. Посмотрим, что получится в конечном итоге.
С растягиванием проекционных декалей. Я там даже сслыку на скрин дал.
__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!
Это параллельная проекция. Тебя же не удивляет, что тени солнца растягиваются точно так же?
Я же там еще и написал, что пока не определился с типом проекции.
Ну просто перспективную для декалей использовать как-то нелогично что ли.
Вообщем, что я решил с вадами. С одной стороны - полностью отказываться от них нельзя. По крайней мере на время переходного периода.
Во первых, чтобы редактор отображал какие-никакие, а всё же текстуры.
Потом редактор переобучим. Есть и второй момент - это поле "wad" в настройках. Туда обычно попадают имена использованых вадов. Так вот, поскольку большинство карт уже сделано таким образом, что вместо пути к текстурам там идёт только одно имя и нет никакой возможности это как-то автоматически преобразовать и разрулить, то я придумал вот какую штуку.
Сам движок вады конечно грузить не будет (на данный момент еще умеет, но скоро я их вырежу), но в системе материалов останется переменная <wadname>. Как она будет действовать?
При загрузке уровня поле "wad" будет прочитано и имена вадов сохранены в список. Затем, при поиске текстур в материалах, как вы помните можно задавать локации - где бы еще поискать текстуру.
Например - таким образом
и вот тут-то и вступают в дело те самые имена вадов, записанные в поле "wad". Каждый такой путь проверяется, на предмет валидности текстуры. перебирая имена вадов по списку точно так же, как это делала халфа.
Только вместо вадов у нас тут получаются реальные пути папок к текстурам, но алгоритм такой же. И вот мы просто раскладываем наши текстуры в textures\<имявада> и всё работает точно так же, как и нахалфе, в плане дублирующихся текстур в разных вадах. Разумеется этот путь я привёл просто для примера, пользователь сам его полностью определяет. Можно вообще отказаться от переменной <wadname> и слить все текстуры в одну папку, к примеру. Но для эмуляции старого функционала - вот такая переменная. Более подробно было в документации по системе материалов, кто успел - тот скачал.
Работаю над новым форматом шрифтов. Любопытно, что раньше я никогда не добирался до этого момента. Я конечно мог бы просто вытащить из вада старые шрифты, но они калечные, в них мало информации и ограничение на размер текстуры. В новых шрифтах я планирую сохранить больше всякой инфы про буквы, например размеры abc, а не только общую ширину.
А сам шрифт будет хранится в отдельной картинке.
Дядя Миша
Надо всё таки что бы они хоть налету кешировались из вектора при смене разрешения. Сейчас же у всех мониторы весьма широко варьируются, фиксированным растром на всех не обойдёшься.
Добавлено 10-03-2020 в 16:44:
Дядя Миша
Скажи, а p2st умеют читать внешние текстуры из папки? Я вот никак не подготовлю себе новый тулчайн, так что бы можно было с одним и тем же исходником работать и для nt и для xt, без ретекстуринга...
SNMetamorph писал: А почему для шрифтов просто не прикрутить .ttf?
TTF либо стандартными виндовыми средствами, либо на линуксе через FreeType2. Таскать вместе с движокм библиотеку, которая весит больше чем сам движок я не планирую. Значит остаётся виндовый функционал, который используется для создания растровых шрифтов.
Цитата:
thambs писал: Надо всё таки что бы они хоть налету кешировались из вектора при смене разрешения
Я не хочу со всем этим заморачиваться. Будет несколько разрешений, движок подберёт из них наиболее оптимальное.
Цитата:
thambs писал: Скажи, а p2st умеют читать внешние текстуры из папки?
Они умеют, но это недокументированная особенность. Они даже кутришные шейдеры умеют читать, но я об этом никогда не распространялся.
Добавлено 10-03-2020 в 20:12:
С этими шрифтами постоянно вылезают какие-то грёбаные заморочки.
Ну навскидку, DIB, как я понимаю не может быть более текущего размера экрана. Т.е. шрифты размером 72 и более отрендерить просто не получится - вылет. Конечно шрифты такого размера не нужны, но сам факт.
Потом другая шняга - на рабочем компе русские буквы генерятся при CHARSET_ANSI, на домашнем - только при CHARSET_RUSSIAN. Винда вроде бы с одного диска ставилась. Что за чертовщина, что там по дефолту так переключено, что на одной работает, а на другой нет.
Дядя Миша писал: Ну навскидку, DIB, как я понимаю не может быть более текущего размера экрана. Т.е. шрифты размером 72 и более отрендерить просто не получится - вылет.