HLFX.Ru Forum - XashNT: блог разработчика

Страницы (255): « Первая ... « 20 21 22 23 [24] 25 26 27 28 » ... Последняя »
Показать все 3825 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)

Отправлено thambs 19-10-2019 в 13:09:

Цитата:

И вон там двойное умножение, не то взятие адреса

Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так. Это ведь только C, когда придумывали, то, видимо, на клавиатурах не было символов @, ни $, вот они и повесили по 4 действия на один литерал специально что бы текст как можно более нечитаемым сделать.

Цитата:

ВОТ ЭТО легче в освоении, чем кресты?

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

Цитата:

На кого это вообще рассчитано?

Потому что придумывают это погромисты, а не лингвисты.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено Дядя Миша 19-10-2019 в 13:30:

Цитата:

thambs писал:
Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так.

А если три звёздочки?

Цитата:

thambs писал:
Ну так потому что если что-то основывается на "идеях С", то в результате становится монстрообразным кошмаром

GLSL стал кошмаром? Да и потом, что вообще считать "идеями Си". Придумать как можно больше всяких модификаторов, это кто такое предлагал? А перед каждой функцией писать function это вообще зачем?
парсеру очевидно это не нужно. Значит для тупых юзеров. Юзер настолько туп, что даже не в состоянии осознать что перед ним функция?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено thambs 19-10-2019 в 14:00:

Дядя Миша

Цитата:

А если три звёздочки?

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

Цитата:

GLSL стал кошмаром?

Так он его не расширяет а сужает же. А кошмар начинается, когда С-шными приёмами описывают высокие абстракции. Вот плюсы наиболее характерный такой пример, они ведь стали настолько запустанными и переусложнёнными, что никто уже не понимает что там происходит. Уже и метапрограммирование есть, а такие полезные вещи как строгая типизация и иерархия типов (которые в том числе могли бы на этапе компиляции отловить сотни ошибок) — их не будет никогда, т.к. невозможно в С-шную парадигму впихнуть её не изломав всё.

__________________
http://www.moddb.com/mods/monorail-quest

Отправлено FiEctro 19-10-2019 в 15:24:

Походу, один только я пишу код сплошными ифами и кейсами в не зависимости от языка.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!

Отправлено Дядя Миша 19-10-2019 в 15:35:

Цитата:

thambs писал:
Вот плюсы наиболее характерный такой пример

Там не в языке проблема, а в выборе объектной модели. Причём, как я понимаю, тот же STL навязывает свою объектную модель, а boost - свою.
Потому что у каждого свое виденье, как это должно выглядеть.

Ну да ладно, оставим лингвистические споры. В процессе реализации парсера техники пришло понимание, что её в некоторой степени надо сделать похожей на DX-технику, точнее говоря включить в нее те настройки, которые недоступны из шейдера. Это блендфунк, альфа-функ, куллинг, дептчмаск, ну понятно. Не в том конечно виде, в котором они представлены в кутришных шейдерах, в максимально приближенном к обычному гл-вызову. Рассчёт в этом (да и аналогичных случаях), такой:
те, кто будут это ковырять, уже наверняка знают GLAPI. А тем, кто не знает не придётся учиться новой абстракции. Ну потихоньку уже что-то вырисовывается. Я тут текстом попытался изобразить, но помоему не очень понятно получилось

code:
VBOMesh
	|->material0
		|->textures
				|->texture0
				|->texture1
				|->systemTexture0 (e.g. lightmap)
				|->systemTexture1 (e.g. screencopy)
		|->shaderObject
				|->techique0 (shader, glstate, defines)	// ambient pass
				|->techique1 (shader, glstate, defines)	// spotlight pass
				|->techique1 (shader, glstate, defines)	// omnilight pass
	|->material1
	|->material2

Добавлено 19-10-2019 в 18:35:

Млять! И всё съехало нахер! Ксераааааакс

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено XaeroX 19-10-2019 в 17:10:

Цитата:

Дядя Миша писал:
Млять! И всё съехало нахер! Ксераааааакс

Ну ты как будто вчера на нашем форуме зарегался.

__________________

Отправлено Дядя Миша 19-10-2019 в 21:14:

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

Добавлено 20-10-2019 в 00:14:

Ну чтожы, потихоньку система собирается из тысячи кусочков в единый механизм

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено a1batross 20-10-2019 в 01:55:

Дядя Миша эка у меня сразу текстовый редактор сказал -- это исходный код на C.
Наверное из-за .def расширения.

code:
depthMask( GL_FALSE );
blendFunc( GL_ONE, GL_ONE );

А в чём смысл от приставки GL_ тут?

__________________
Xash3D FWGS форк

Отправлено XaeroX 20-10-2019 в 06:49:

Цитата:

a1batross писал:
А в чём смысл от приставки GL_ тут?

Как в ку3.

__________________

Отправлено Дядя Миша 20-10-2019 в 11:41:

Цитата:

a1batross писал:
А в чём смысл от приставки GL_ тут?

есть алиасы без нее. Кому што нравится.

Добавлено 20-10-2019 в 12:45:

Да, с юниформами надо в корне пересмотреть концепцию, то что я нагородил мне сейчас решительно не нравится.

Добавлено 20-10-2019 в 14:41:

Моя ошибка была в том, что я использовал старую концепцию юниформов, когда один тип содержал в себе все варианты использования. Это просто избыточно и неудобно. Разделил на три типа: макросы для препроцессинга, собсно сами юниформы со значениями и текстурные юниты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 20-10-2019 в 21:41:

Так, ну судя по всему от первоначального варианта вообще мало что останется. Не выдержал он столкновения с реальностью. А реальность нам дана в ощущениях в виде шейдеров из паранои.

Добавлено 21-10-2019 в 00:41:

Тимплейты под нож пойдут скорее всего, они не нужны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено AntiPlayer 21-10-2019 в 07:16:

Цитата:

Дядя Миша писал:
XML

XML это формат разметки документов. Довольно странная идея хранить в них конфиги.
JSON тоже избыточен как по мне, это формат созданный для передачи данных по сети. Хотя, для хранения сейвов сам по себе подошел бы, наверное.

Чем плох обычный .ini для конфигов?

Цитата:

XaeroX писал:
Зато теперь появилось новое ругательство - "парсить джейсоны"

Мое любимое занятие

__________________
I tell you to enjoy life

Отправлено XaeroX 21-10-2019 в 07:23:

Цитата:

AntiPlayer писал:
Мое любимое занятие

В нашем возрасте пора заставлять делать это подрастающее поколение джуниоров!

__________________

Отправлено Дядя Миша 21-10-2019 в 13:58:

Ну чтоже. После всех поправок и корректировок моих фантазий сообразно с реальностью и внутренней организацией конвейера, получилось вот такое вот. Это уже не абстрактный пример, оно парсится и генерит шейдеры.

Поясню что здесь к чему.
Каждый материал содержит ссылку на т.н. ShaderObject, который содержит в себе Techinques - техники. Назначение техник жестко определено в движке, это фиксированный набор, который нельзя изменить. На данный момент в наборе есть следующие типы:
base (ambient) - проход для рендеринга в паре с лайтмапами, статичный свет. Что рендерить в этом проходе выбирает конечно сам юзер, ему никто не навязывает непременно рисовать лайтмапы.
spot - освещение объекта для спот-лайтов
omni, sun - аналогично для всенаправленных и солнца.
shadow (depth) - для прохода теней.
в дальнейшем так же планируется проход для г-буффера, возможно для пост-процессинга, ну вообщем понятно. Все техники указывать необязательно, если вы например хотите чтобы какой-то конкретный материал (ну например полупрозрачный) не давал тени - просто не прописываете её технику в описание шейдер объекта. Или наоборот хотите, чтобы объект было видно только в лучах фонаря - для base строите пустой шейдер, который записывает только в буффер глубины, и для спот-лайта еще один. Ну это просто как пример использования.

В самих техниках можно настроить gl-state, практически весь набор, используемый в паре с шейдерами (который невозможно эмулировать из шейдера) - куллинг, запись в буффер глубины, полигоноффсет, ваерфрейм, итд. gl-state нельзя переопределить ниоткуда, он всегда существует только в самой технике. Если вам нужно непременно его переопределить для какого-то материала, то заведите отдельный шейдеробъект. Разные шейдер-объекты могут ссылаться на одни и те же техники. В техниках, как вы видите прописаны юниформы, которые используются в шейдерах, путь до которых задаётся там же. Кроме самих юниформов им назначаются дефолтные значения, как явные, так и относительные, в виде ссылок на какую-то информацию из движка.
Всего доступно несколько больших групп с переменными:
globals - глобальные параметры
light - для текущего источника света
entity - параметры энтити
render - позиция камеры, вьюматрица, ну понятно
lightProbe - типа R_LightForPoint
cvar - взять переменную, имя текстуры или индекс текстуры из квара.
materials.def - взять из описания материалов.
либо задать константу. Константы можно задавать и для vec2-vec3-vec4.
смешанные данные для векторов не поддерживаются, это всё же не язык программирования, а просто скрипты.

аналогично прописываются и текстурные юниты с относительными путями, конечно никто не мешает влепить туда константный путь.ъ

юниформы и текстурные юниты можно перегружать из любого материала в любом кол-ве. Хоть вообще все, но есть одна тонкость - всё что вы пропишете в материале будет применено ко всем техникам из шейдерного объекта. Разумеется для конкретного прохода будут использоваться только те юниформы, которые реально существуют в конкретном шейдере, т.е. объявлять лайтмапу для спотлайта имеет смысл, если сам шейдер обращается к ней.

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

Единственное что я еще планирую сделать на этом фоне - возможность постановки тех или иных макросов в шейдеробъекте в зависимости от условий. Т.е. ввести кондиции в шейдеробъект.

Задавайте вопросы, что непонятно, предлагайте что поменять. Вам же потом с этим работать.

Добавлено 21-10-2019 в 16:58:

Можете так же приводить примеры из других движков, если вам там что-то понравилось, какие-то идеи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Отправлено Дядя Миша 21-10-2019 в 18:33:

Ладно, раз молчите, расскажу немного о концепции всего этого дела.
Эта система возникла не на пустом места, а явилась итогом многолетних рассуждений на тему организации материалов в рендерере. Я изучал как это реализовано в других движках, как к этому относятся непосредственные пользователи и выяснил несколько любопытных вещей:

1. Если движок базируется на идеях Кармака или просто частичный форк - там непременно будут либо кутришные шейдеры, либо дуумтришные материалы, либо их симбиоз в самых разнообразных вариациях. Причём не имеет особого значения, был ли это движок куплен у Кармака в далёкие времена или это народная модификация на GPL-сорсах. Тут еще что любопытно, те, кто эти системы модифицирует, как правило сам никаких материалов не пишет.

2. Если движок принципиально отвергает идеи Кармака, то материалы представляют собой две крайности: или это полная минималка, как в сталкерах-метро, где можно настроить несколько параметров и указать путь к детальной текстуре, либо чуть ли не свой собственный язык с визуальным конструктором, как во всяких Unity\Unreal.

3. Пользователи так же делятся на два типа. Одним просто нравится играться с настройками материалов, но ихние игры почти никогда не идёт в продакшен, это просто хобби такое, ну максимум ассет выпустят когда-никогда. Причём они в этом ассете все настройки пару лет подбирали. Второй тип, это которые делают реальную игру и у них голова болит сразу за миллион вещей и им эти материалы как серпом об асфальт.

4. То есть со стороны реального пользователя имеем на первый взгляд такие взаимоисключающие требования - с одной стороны чтобы система была мощной, с другой, чтобы по дефолту не надо было ничего крутить.

Вот на четвертом пункте, я и строил свою систему. Какое-то время у меня безусловно крутились мысли насчёт того, чтобы использовать все эти кутришные и дуумтришные материалы. Но в них есть одна очевидная проблема: эти материалы создавались в первую очередь для фиксированного конвейера и пытались собою подменить его функционал. Очевидно, если бы это имело практический смысл, то производители видеокарт не стали бы делать программируемый конвейер и все бы радостно юзали материалы из д3. Но в настоящее время, когда мы имеем возможность программировать конвейер видеокарты, все эти устаревшие концепции только мешают эффективному рендерингу. И кстати очень сильно ограничивают возможности редактирования визуальной части со стороны пользователя (через материалы), но по большей части это довольно сложно понять, т.к. обилие настроек в этих кутришны-дуумтришных материалах по большей части сбивает с толку, кажется что там есть абсолютно всё. На практике куда ни ткнись, кастомизировать не возможно ничего. Ну вот взять простейший пример - интеракция с динамическим светом. Что можно сделать из кутришного шейдера? А ничего. Максимум что можно - это запретить освещение совсем. Поменять модель освещения, сделать какие-то вариации на тему Subsurface Scattering или в случае, если у нас там волосы, глаза, зубы, всё приехали - это только лезть в код и не факт, что это получится сделать красиво, потому что придется эти настройки еще и выводить в эти шейдеры.

В этом плане моя система является полной противоположностью такому подходу. Это Data-Driven концепция, когда пользователь сам полностью формирует этапы рендеринга, а движок лишь выполняет то, что ему задали, не внося никакой отсебятины, не имея дефолтных параметров.
В идеале бы конечно построить такой механизм, когда вся кастомная часть рендера окажется в пользовательских скриптах и шейдерах. Ну и второй момент - это, как выразился thambs - вменяемые дефолты.
Здесь активно используются относительные пути, если мы имеем дело с текстурами и ссылки на другие источники. Большинство материалов уложится в стандартные параметры, описать придётся лишь всякие специальные вещи, типа зеркал, мониторов, но я полагаю это небольшая проблема

Добавлено 21-10-2019 в 21:33:

ЗЫ. Как я уже говорил, лучше всего на этих кутришных шейдерах получается сделать всякие мигалки и бегущие текстуры. Ну собсно, именно их все и делали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'

Временная зона GMT. Текущее время 18:14.

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024