thambs это мои материалы такие. К С++ это отношения не имеет.
Добавлено 19-10-2019 в 00:14:
Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек. Но пользователь не мог на это повлиять, он и не знал точно какие там настройки применяется, к тому же это зависело от типа модели. Моя идея в том, чтобы эти шаблоны по умолчанию создавал сам пользователь, так как ему нужно. То есть допускается иметь шаблоны с подсказкой - эти будут применяться автоматически к материалам, для которых вообще нет описания и шаблоны без подсказок - эти пользователь сам сможет применять к материалам, указывая их явным образом и перегружая нужные ему настройки.
В принципе для отдельно взятого материала можно перегрузить все настройки или вообще не использовать шаблон для его построения.
Кол-во настроек материала тоже задаётся пользователем. То есть к примеру можно не указывать шейдер, если материалу он по смыслу не требуется, будет осуществлён рендеринг на фиксированном функционале.
Теоретически на подобной системе легко эмулировать функционал как кутришных шейдеров, так и дуумтришных материалов, причём пользователь сам это создаёт скриптами и шейдерами. Аналогично, если не хочется ничего прописывать, можно обустроить тепичные шаблоны для всех материалов, прописать их один раз и не париться. Вообщем под разные задачи.
Дядя Миша писал: Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек.
Кажется, настал Великий день, когда Дядя Миша наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер". И перестанет пугать этим выдуманным фактом потенциальных пользователей Волатилы до полусмерти.
Ура, товарищи! Свершилось!!!
XaeroX писал: наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер"
Всегда знал, но хорошего в этом мало. Дефолты не перегрузишь, не переопределишь никак.
Добавлено 19-10-2019 в 11:13:
К тому же сам язык кутришных шейдеров устарел, это язык для FFP-фунционала, он просто не нужен в таком виде. Ну хотя Волатила и так неявно использует FFP-модель.
Добавлено 19-10-2019 в 11:22:
Вот вам кстати наглядный пример как программы усложняются со временем на ровном месте. В квейке для парсинга текстовых файлов использовалась простейшая функция COM_ParseFile и этого хватало для всех случаев. А теперь в новомодных движках все скрипты пытаются сделать на базе XML.
Уже не говоря о том, что лично мне представляется небесспорной сама идя XML, так его пытаются использовать для простейших вещей, типа сохранения тех же конфигов. На мой взгляд смысла в подобных скриптах нет никакого, интерпретаторы тех же крестов спокойно разбирают вполне человеческий код, без всяких идиотских тэгов. То есть оно по сути не нужно никому, ни человеку, который в блокноте XML уже не отредактирует, ни парсеру, который справится с любым форматом текста. Очевидно что под эти скрипты надо еще и свой редактор писать. Из вики мне особенно понравилась вот эта строчка:
Цитата:
− Примитивная библиотека может делать неоптимальный XML (например, <tag></tag> вместо <tag /> ). Работающая оптимально намного сложнее в программировании.
То есть у XML появилось еще и понятие оптимальности, хотя скрипты вообще должны быть лишены такого качества. А ведь есть люди, которые на XML сейв-рестор делают, ну чёб не париться. И так - в любой области. Просто сейчас аппаратный прогресс остановился и народ начал замечать, что их процессоры по большей части заняты непонятно чем.
Добавлено 19-10-2019 в 11:46:
Кстати вот к вопросу парсинга. Я учёт приходов\расходов веду в обычных .txt файлах. Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду. Я в своё время выработал свой формат записи, не предназначенный для парсинга вообще, просто обычные записи в блокноте, примерно такого плана:
C++ Source Code:
1
Месяц Год
2
3
Доходы:
4
5
дата
6
источник - сумма
7
8
дата
9
источник - сумма
10
11
...
12
13
дата
14
источник - сумма
15
16
Расходы:
17
18
дата
19
цель - сумма
20
21
дата
22
цель - сумма
23
24
...
25
26
дата
27
цель - сумма
28
29
Итого:
Должно быть понятно, что основную сложность представляло подведение баланса, считал вручную на калькуляторе, но это отнимало порядочно времени. В какой-то момент мне это надоело, я сел и написал маленькую консольную утилитку, которая не только парсит такой формат файлов, но еще и находит в них некоторые ошибки (например, если месяц с годом в шапке указан один, а в списке дата неверная), подбивает баланс и выводит итоговый отчёт, причём баланс за месяц она пишет в тот же самый файлик, сверяясь с текущей датой и убедившись, что месяц завершен, аналогично формируется промежуточный и годовой отчёт.
У нее нет никаких параметров, очередная кнопка сделать круто. Запустил и через полсекунды всё готово. Писал я её где-то часа четыре, весит 20 килобайт, отвечает всем поставленным задачам, прекрасно разбирает обычный человеческий текст, который вообще не предназначался для парсинга никогда. Так вот и какой смысл городить все огороды, спрашивается. Очевидный ответ - несолидно, надо больше всего, надо чтоб место занимало, надо чтоб интерфейс красивый, надо чтоб кнопок всяких и побольше. Главная цель за всем этим куда-то исчезла.
Дядя Миша писал: А теперь в новомодных движках все скрипты пытаются сделать на базе XML.
Я в старой волатиле тоже повёлся на это, и сделал XML-конфиги (для HUD). Даже tinyxml-парсер прикрутил. И всё время меня что-то беспокоило, но я не мог понять, что именно. Вроде и модно, и молодёжно, и современно - но кошки на душе скребут.
А потом я разобрался. Удалил в новой волатиле все эти xml-ы нафиг и сделал обычные парсеры на основе COM_Parse. И тут же стало легко и приятно на душе. И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.
Цитата:
Дядя Миша писал: Ну хотя Волатила и так неявно использует FFP-модель.
Я больше скажу - абсолютно все движки неявно используют FFP-модель. Просто раньше они напрямую использовали функции OpenGL (типа glTexGen и TNT combiners), а теперь пытаются всё это эмулировать через шейдеры. А по сути это тот же набор fixed-функций, ну разве что чуть более расширенный - например, не одна, а три модели освещения на выбор.
Добавлено 19-10-2019 в 15:50:
Цитата:
Дядя Миша писал: Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду.
XaeroX писал: И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.
С этими тэгами вообще вопрос очень интересный. Если их надо закрывать ровно в той же последовательности, в которой открывал, то чем это лучше фигурных скобок? Очевидно здесь выполняется бессмысленная работа, к тому же еще и увеличивающая размер файлов. Кому это надо? Да никому.
Зачем это сделано? А хрен его знает. Мне больше всего нравится, что эти тэги пользователь еще и вручную определяет, то есть вместо именованного блока, типа:
C++ Source Code:
blockname
{
}
нас заставляют писать
C++ Source Code:
<blockname></blockname>
И сразу же появляется вопрос оптимальности, оказывается можно еще писать
C++ Source Code:
<blockname />
я так понимаю на тот случай, если у нас всё умещается в одну строку. С фигурными скобками этой проблемы не возникает вообще. Я понимаю, что оно от SVG кажется наследуется, а тот в свою очередь был сделан гораздо раньше, но зачем было вообще плодить эти сущности?
Цитата:
XaeroX писал: Я больше скажу - абсолютно все движки неявно используют FFP-модель
Фиксированный функционал = мультипроходный рендеринг, он в первую очередь завязан на расположении текстурных юнитов. Потом добавили мультитекстурность и стало чуть попроще, но всё равно ты должен располагать эти юниты в определённом порядке, чтобы они правильно смешались между собой. В шейдерах это теряет всякий смысл, нам больше не надо городить блоки
{
map
}
в строго определённой последовательности в описании шейдера. Ну разве что мы будем эмулировать кутришный функционал.
Цитата:
XaeroX писал: Открой для себя Microsoft Excel...
Ну Эксель как минимум надо поставить, а то еще и купить, мы же чесные программисты и против пиратства? А блокнот изкаропки есть.
Добавлено 19-10-2019 в 12:41:
Материалы-материалами, но походу возникла потребность сделать еще какое-то описание для шейдеров.
vert u_ShaderVert = "glsl/<rendertype>/bmodelSolid_fp.glsl";
Вот так писать каждый раз в шаблоне еще нормально, а скажем в описании материала уже будет напрягать. К тому же этот объект скорее всего сможет переиспользовать одни и те же шейдеры множество раз, но с разными настройками #define, которые неплохо бы указать общими для такой сущности. То есть сделать для шейдерного объекта генеричное описание, с собственным именем. К тому же мне вероятно понадобится собрать в такой объект не один, а несколько шейдеров, понятно почему - для форварда основной проход, для форварда - освещение, для отложки построение G_BUffer, финальный рендеринг. Т.е. некая сущность над описанием шейдеров. И назвать её, ну скажем shaders.def, навряд ли их там будет слишком много, чтобы городить множество файликов.
Добавлено 19-10-2019 в 12:43:
Причём, я так полагаю формат описания логично унаследовать от описания материалов и шаблонов, чтобы получился настоящий полиморфизм. Это даст возможность конструировать любые типы объектов и перегружать любой параметр для отдельно взятого материала.
Добавлено 19-10-2019 в 13:09:
Посмотрел как в последнем крае это устроено. Ну там все техники, объявленные в шейдерах, жестко привязаны к вызовам этих имён из кода.
Это не то, что мне нужно.
Добавлено 19-10-2019 в 13:11:
То есть вот для примера technique SunShaftsDisplay - она жёстко объявлена в коде в движка, её нельзя переопределить или создать новую технику.
Можно только отредактировать сам шейдер.
Дядя Миша
А материал можно будет автоматически вывести из имени используемой текстуры? Например есть шаблон *wood*, и все текстуры содержащие *wood*, что отдельно не описаны, наследуют этот шаблон?
a1batross писал: а что если как раз дать переопределять дефолты?
ну я про это и говорю. Система наполовину существует в моём воображении, поэтому что-то будет скорее всего меняться, но пока концепция следующая:
1. мы можем создавать шаблоны для определённого типа моделей, типично это спрайты, студиомодели и брашы. Если придумаете по каким еще критериям можно отсортировать объекты на группы, то я могу включить и другие варианты в качестве хинтов, но пока что мне этот кажется наиболее логичным.
2. если у материала не прописан никакой тип и нет дефолтного шаблона, то скорее всего он будет рендериться как wireframe, чтобы наглядно это продемонстировать пользователю.
3. шаблон материалу можно указывать явным образом или не указывать совсем, если присутствуют шаблоны с подсказкой.
4. всё что указано в шаблоне можно переопределить в самом материале, но в большинстве случаев это просто не нужно.
5. наследование материала от материала сделать возможно, но я пожалуй воздержусь, т.к. это запутает юзера. К тому же, поскольку это всё же не язык программирования и здесь не требуется forward-declaration, то первое что сделает находчивый юзер, это унследует пару материалов друг от друга. чтобы посмотреть что из этого получится. Так что нет, это не слишком хорошая идея.
Цитата:
thambs писал: А материал можно будет автоматически вывести из имени используемой текстуры?
нет, такого нет. Мне не нравится эта идея, эти фильтры принципиально неконтролируемы юзером, как поиск по маске почти никогда не находит точно то, что требуется. Он всегда находит либо больше либо меньше, а остальное человек уже должен сам вычленить из списка.
Для описания шейдеров навскидку сделал вот такой формат. Это ни в коем случае не окончательный вариант, это первое приближение.
Добавлено 19-10-2019 в 14:05:
Я не знаю как люди пишут скриптовые языки или вообще какие-то стандарты скриптов, но я сперва пишу сам скрипт, как бы мне хотелось чтобы это выглядело, а потом под него уже пишу парсер. Наоборот у меня не получается.
Добавлено 19-10-2019 в 14:26:
Вообще я планирую сперва воссоздать forward-патч на основе шейдеров из паранои, т.е. таким образом, чтобы мне не пришлось их подключать в коде.
А потом уже можно будет задуматься насчёт остальных патчей и их кол-ве.
Вложение: scripts.rar (2.0 кб)
Этот файл был скачан 48 раз.
a1batross писал: нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.
Вот-вот. Поумнел народ с годами. Это радует.
Зато теперь появилось новое ругательство - "парсить джейсоны". Например, сделал человеку плохо, а он тебе - "шоб ты на работе парсил джейсоны!"
За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур
МБУГОГА. Изобрели новый формат и тут же облили грязью старый, да мол XML этот ваш - гавно. Слышали?
Цитата:
Запись — это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }»
Ребята взяли описание энтити от кваки, но чтобы у них всё было "совершенно по другому", добавили еще двоеточие. Впрочем для "сериализации сложных структур" это всё равно не годится. Помните ad_sepulcher для ArcaneDimensions? Ну где 8 тысяч энтить? А в кваке сейвы устроены что твой JSON, ну только без двоеточия. Корочи на этой карте сейв грузится секунд 20. Надо ли говорить что в кувраппере на этой же карте сейв грузится пару секунд? Скрипты для сериализации не годятся абсолютно. Суть скрипта именно вот в том, чтобы их человек мог писать и редактировать. А сохранять в них что-то дурацкая затея. Скажем в той же кваке можно было открыть скрипт в блокноте и написать себе сколько угодно здоровья и пушек. Или там шаблера удолить из сейва, если вы его пройти не можете.
Добавлено 19-10-2019 в 15:15:
Вообще самая быстрая парсилка это fgets + sscanf, я када был молодой и неопытный, то переделал studiomdl со sscanf на COM_ParseFile, ну типо так красивше. И очень удивился, что у меня время на чтение .smd выросло, ну так раз в 10.
Мне стало интересно что вообще творится со скриптами в остальных движках, ибо, как известно, современный движок этими самыми скриптами и силён. В этом его главное отличие от кваки, где наоборот всё захардкодено и крутись как хочешь. Ну вот открыл UnrealScript:
Вот к примеру структурки:
C++ Source Code:
1
struct {DOUBLE} double
2
{
3
var native constint A;
4
var native constint B;
5
};
6
7
struct BitArray_Mirror
8
{
9
var native const pointer IndirectData;
10
var native constint InlineData[4];
11
var native constint NumBits;
12
var native constint MaxBits;
13
};
Ну это то ладно. Вот АТД Vector
C++ Source Code:
1
struct immutable Vector
2
{
3
var() float X, Y, Z;
4
};
Что такое var я не знаю. А вот насчёт immulatble тоже непонятно. Разве это не тоже самое что final?
А вот наследование:
C++ Source Code:
1
struct immutable Plane extends Vector
2
{
3
var() float W;
4
};
Константы
C++ Source Code:
const MaxInt = 0x7fffffff;
const Pi = 3.1415926535897932;
Здесь другая крайность - у констант почему-то не указан тип.
Но самая жэсть начинается далее:
C++ Source Code:
1
native(133) static final operator(34) byte *= ( out byte A, byte B );
2
native(198) static final operator(34) byte *= ( out byte A, float B );
3
native(134) static final operator(34) byte /= ( out byte A, byte B );
4
native(135) static final operator(34) byte += ( out byte A, byte B );
5
native(136) static final operator(34) byte -= ( out byte A, byte B );
6
native(137) static final preoperator byte ++ ( out byte A );
7
native(138) static final preoperator byte -- ( out byte A );
8
native(139) static final postoperator byte ++ ( out byte A );
9
native(140) static final postoperator byte -- ( out byte A );
10
native(129) static final preoperator bool ! ( bool A );
11
native(242) static final k2pure operator(24) bool == ( bool A, bool B );
12
native(243) static final operator(26) bool != ( bool A, bool B );
13
native(130) static final operator(30) bool && ( bool A, skip bool B );
14
native(131) static final operator(30) bool ^^ ( bool A, bool B );
15
native(132) static final operator(32) bool || ( bool A, skip bool B );
Вот что это за хрень? Я плохо знаю С++, я даже не знаю, можно ли там перегружать постинскрмент, ну просто не возникало такой надобности, а проверять лениво. Ну здесь как мы видим можно. Но вот эти нативные номера смущают. Это типо как буллетины в первокваке штоли?
И что такое k2pure наконец?
Но вот мы добрались и до функций:
C++ Source Code:
1
static final function float FInterpEaseIn(float A, float B, float Alpha, float Exp)
2
{
3
return Lerp(A, B, Alpha**Exp);
4
}
5
6
static final simulated function k2pure float RandRange( float InMin, float InMax )
7
{
8
return InMin + (InMax - InMin) * FRand();
9
}
Опять загадочный k2pure. Обратите внимание, что интерпретатор даже не в состоянии догадаться что перед ним функция, ему надо прямо словами написать function. К тому же есть еще загадочный модификатор simulated. Ну вероятно есть и emulated. И вон там двойное умножение, не то взятие адреса, хотя из самой функции вообще непонятно зачем там брать адрес. Ну в принципе достаточно. А теперь ответьте мне на простой вопрос - неужели ВОТ ЭТО легче в освоении, чем кресты?
Мне кажется это тепичная подмена понятий по Конфуцию. Низкоуровневые языки сложны в освоении в первую очередь из-за необходимости "прямой" работы с памятью, в кавычках, потому что там минмум два слоя абстракции - защищеный режим процессора и ядро самой винды. Этож не 286-й, где можно было биосу тень херачить из паскаля. Ну не суть. Народ вообщем не любит когда исключения бросаются. Ну на то и песочница, чтобы разрулить проблемы с памятью. А вот зачем так усложнять синтаксис? Причём этих модификаторов там гораздо больше чем я показал, есть еще interface, event, cpptext, virtual кстати есть, transient, inherits. На кого это вообще рассчитано?
на дезигнеров? Не, ну серъезно.
Как бы на таком фоне неудивительно что они UC дропнули и замутили блупринты. Я их правда не видел, но они вероятно проще, раз с ними даже наш Жэка освоился.
Добавлено 19-10-2019 в 15:51:
Цитата:
thambs писал: А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?
ну щас парсер напишу и посмотрим.
Добавлено 19-10-2019 в 16:02:
C++ Source Code:
1
/** @return the name of the package this object resides in */