Полный исходный код P2:Savior 1.51, включая компиляторы и модельвьювер
Как и обещал - выкладываю полный комплект исходников. Прошло время и для меня они более не представляют какой-то ценности. Теперь дело за вами. Можно доисправлять то, до чего у меня так и не дошли руки, можно портировать на андроид или заняться дальнейшим сопровождением побочных проектов, например модельвьювера.
Что включено в архив:
клиентская часть игры
серверная часть игры
меню
утилита миграции с устаревшего формата BSP31
конвертор декалей в tga
модельвьювер
спрайтвьювер
генератор fonts.wad
упаковщик текстур в dxt
генератор вадов
полный комплект параноевских компиляторов уровней (p2st)
маленькая утилитка проверки системных требований
конвертор сталкеровских текстур в tga
компилятор спрайтов
компилятор моделей
Скрытый текст:
Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.
Вопросы по коду, какие-то предложения по дальнейшему развитию можете задавать в этой теме.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено nemyax 31-08-2020 в 08:34:
Дело нужное и благородное.
Отправлено Cybermax 31-08-2020 в 12:10:
У кого получилось собрать?
Отправлено Lev 31-08-2020 в 12:26:
Cybermax пока нет, на семёрке студия поставилась но компилит с ошибками. А ты смог?
Отправлено Cybermax 31-08-2020 в 15:35:
Lev На семерке 64 Microsoft Visual C++ 6.0 не собирает, Microsoft Visual Studio 2010 тоже не хочет. По началу решил поставить ХР на виртуалку или bare metal.
Отправлено Lev 31-08-2020 в 15:52:
Cybermax завтра на XPsp2 попробую. 2012-ая студия тоже не хочет. Конвертация проекта проходит с ошибками. А по поводу 6-ой студии ДМ говорит, что нужен обязательно SP5 и процессоропак 5. Я всё это вроде скачал - попробую поставить.
Отправлено Cybermax 31-08-2020 в 16:37:
Цитата:
Lev писал:нужен обязательно SP5
На 7-ке vs6sp5.exe не является приложение Win32.
Цитата:
Lev писал: Я всё это вроде скачал - попробую поставить.
У тебя ссылки остались на скачивание? Проверю на 7, хотя подозреваю что не встанет.
Добавлено 31-08-2020 в 19:37:
Результат выдачи гугла на запрос процессоропак 5Отправлено Lev 31-08-2020 в 17:16:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 04-09-2020 в 22:14:
Для нормального стыка поверхностей надо глубину фрагмента писать через gl_FragDepth, а это значит прощай ранний тест глубины
Отправлено Crystallize 05-09-2020 в 09:29:
Цитата:
Lev писал: thambs У него неприятный артефакт есть, когда смотришь на поверхность под очень острым углом - текстура начинает "уплывать" по направлению от игрока.
Ууу, падла, вот в Doom 3 Relief Mapping mod эта штука всё настроение играть отбивала.
Отправлено Lev 05-09-2020 в 12:08:
Crystallize поэтому я оставил простой параллакс, у него нет такой проблемы.
Отправлено Next Day 05-09-2020 в 19:34:
Спасибо Дядя Миша!
Добавлено 05-09-2020 в 22:34:
М-да что бы скачать нужно не менее 100 сообщений на форуме необщительным фигу или это принципиально.
Вот ещё 87 сообщений и я у цели
Отправлено KiQ 05-09-2020 в 20:01:
Отлично, отлично Шестеркой компилится?
__________________
-Brain is dead-
Отправлено Lev 05-09-2020 в 20:21:
KiQ Да, нужна профешшинал или ентерпрайс, чёб сервис пак пять и процессоропак поставились.
Добавлено 06-09-2020 в 01:21:
Aynekko Для адаптации глаз нужен автоматический выбор экспозиции - как я прочёл.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Lev 08-09-2020 в 16:51:
Cybermax Так тут же рядом выложены исходники преальфы от 2014 года - оттуда и вытащил. Правда всё равно, походу не совсем правильно работает. Ну то есть без артефактов конечно, но я там не до конца понял чехорды с экранными квадами и первый шейдер, который отбрасывает тёмные фрагменты, как-будто не юзается.
thambs это не полосы, это дождег капает) Разницы там и не должно особой быть, если выкручивать ssao то выглядеть будет ублюдошно. Лучше всего видно на мелких перекрывающих друг-друга объектах или растительности:
Отправлено Дядя Миша 14-09-2020 в 10:47:
Строго говоря SSAO ближе всего к настоящему радиосити, но слишком уж мал радиус действия. Ему бы помочь какой-то дополнительной информацией, да хотя бы бент-нормалями, как в Unigine.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 14-09-2020 в 15:43:
Цитата:
Lev писал: если выкручивать ssao то выглядеть будет ублюдошно
там разрешение эффекта должно ещё где-то настраиваться.
Отправлено ncuxonaT 15-09-2020 в 23:46:
Как сделать, чтобы фреймбуферы были во флоат формате? И постэффекты, соответственно, тоже. Вроде бы я везде, где можно, добавил TF_ARB_FLOAT, но это не сработало.
Отправлено KiQ 16-09-2020 в 01:13:
ncuxonaT задать формат GL_RGBA16F?
__________________
-Brain is dead-
Отправлено ncuxonaT 16-09-2020 в 01:56:
KiQ не так всё просто
При форвард рендере всё рисуется сразу на экран в дефолтный фреймбуфер? Поэтому формат пикселя нужно задавать при создании контекста, а контекст создаётся движком, а не модом?
Отправлено Дядя Миша 16-09-2020 в 10:23:
в opengl.cfg смотри чтобы gl_texture_float 1 было.
Добавлено 16-09-2020 в 10:45:
Ну и да, в имидж надо добавлять флаги IMAGE_HAS_COLOR|IMAGE_HAS_ALPHA.
Добавлено 16-09-2020 в 10:46:
Цитата:
ncuxonaT писал: Поэтому формат пикселя нужно задавать при создании контекста
дефолтное окно не меняется.
Добавлено 16-09-2020 в 13:22:
Вообще, если я не путаю, создать WGL-контекст с флоатами невозможно, мы создаём FBO, ставим его в качестве основного буффера и просто рендерим в него, вместо дефолтного. А FBO уже создаём флоатный, как нам потребно.
Сами флоатные текстуры точно работают, т.к. я в них храню BSP-дерево и планесы для трассировки теней. Очевидно этот рейтрейсинг бы не работал, если бы не создавались флоатные текстуры.
Добавлено 16-09-2020 в 13:23:
ЗЫ. Да у Нвидии даже была демка как создать Z-Buffer с 32-х битной точностью. И там был рендеринг именно в кастомный FBO. а контекст оставался прежним.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 16-09-2020 в 16:15:
Цитата:
Дядя Миша писал: мы создаём FBO, ставим его в качестве основного буффера и просто рендерим в него, вместо дефолтного. А FBO уже создаём флоатный, как нам потребно.
Сейчас рендер идет в дефолтный буфер, промежуточный мне нужно самому сделать, верно?
Отправлено Дядя Миша 16-09-2020 в 18:39:
ncuxonaT ну да, создаёшь фбо, аттачишь к нему флоат-текстуры и рендеришь туда.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Lev 20-09-2020 в 12:06:
Отправлено ncuxonaT 22-09-2020 в 18:34:
Дядя Миша благодарю, всё получилось. TF_ARB_FLOAT - это же GL_RGBA32F? Текстуру GL_RGBA16 или GL_RGBA16F стандартными средствами не сделать?
И еще вопрос, все спрайты и частицы рендерятся без шейдеров?
Отправлено Дядя Миша 22-09-2020 в 19:04:
Цитата:
ncuxonaT писал: Текстуру GL_RGBA16 или GL_RGBA16F стандартными средствами не сделать?
Ну отчего же не сделать? Используй TF_ARB_16BIT. Только буфферу глубины его не проставляй.
Добавлено 22-09-2020 в 22:04:
Цитата:
ncuxonaT писал: И еще вопрос, все спрайты и частицы рендерятся без шейдеров?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 24-09-2020 в 19:54:
Смотрю, как работает запеченное вершинное освещение. У моделей без нормалмапы в делюксмапе (attr_LightVecs) нули. Так и должно быть? Это можно отключить?
Отправлено Дядя Миша 25-09-2020 в 07:26:
Цитата:
ncuxonaT писал: Смотрю, как работает запеченное вершинное освещение
Не там смотришь
Если у модели есть нормалмапа, выставляется #define COMPUTE_TBN
а лайтвекторы валидные в любом случае.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-09-2020 в 13:33:
Дядя Миша выходит, что не валидные, потому что в attr_LightVecs нули.
Выведи var_LightDir в диффузный цвет и посмотри сам, если не веришь.
Отправлено Дядя Миша 25-09-2020 в 14:58:
А, ну тада смотри client\render\gl_studiovbo.cpp
он там выбирает подходящий вертекс-формат в зависимости от типа отрисовки. Если нет нормалмапы, то он не запишет делюкс.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-09-2020 в 15:41:
Дядя Миша заработало, спасибо
Отправлено Дядя Миша 25-09-2020 в 17:51:
В NT эта система еще более усовершенствована, ну я писал уже. Она смотрит, используется ли атрибут реально в шейдере и налету формирует уникальный вертекс-формат.
Еще одну мелочь добавил - паразитное освещение у фонарика. Всегда меня расстраивало, что про него забывают, а оно и реалистичности добавляет, и играть комфортнее.
Отправлено Lev 26-09-2020 в 06:00:
ncuxonaT Красота да и только)
Отправлено Дядя Миша 26-09-2020 в 08:44:
Там еще много работы. Декали бы починить, к примеру.
Точнее их освещение для декалей с альфа-каналом.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Flash 26-09-2020 в 18:04:
Всё таки свет слабо проработан.
__________________ Tiger! Tiger! burning bright
In the forests of the night,
What immortal hand or eye
Could frame thy fearful symmetry?
Отправлено Casperx69x 30-09-2020 в 14:42:
Cпасибо за исходники!
Отправлено KiQ 30-09-2020 в 17:25:
Цитата:
Дядя Миша писал: Вообще, если я не путаю, создать WGL-контекст с флоатами невозможно, мы создаём FBO, ставим его в качестве основного буффера и просто рендерим в него
А кто-то щас вообще рендерит прямо в примарный буффер?
__________________
-Brain is dead-
Отправлено XaeroX 30-09-2020 в 18:34:
Цитата:
KiQ писал: А кто-то щас вообще рендерит прямо в примарный буффер?
Глубина из текстуры и gl_FragCoord.z ремапятся с 0-0,8 до 0-1. Зачем это нужно? От буфера глубины используется только часть диапазона? Почему?
Если для линеаризации глубины использовать u_zFar, то расстояние от поверхности воды до дна зависит от расстояния от камеры до воды:
Но если вытащить zFar из gl_ProjectionMatrix в вершинном шейдере, и использовать его, то такой проблемы нет:
Что тогда передается через u_zFar?
Отправлено Дядя Миша 03-10-2020 в 17:30:
Цитата:
ncuxonaT писал: Глубина из текстуры и gl_FragCoord.z ремапятся с 0-0,8 до 0-1. Зачем это нужно?
Потому что BUzer, когда делал первую параною искуственно ограничил диапазон нормального прохода от 0 до 0.8. В диапазоне 0.8-0.9 он нарисовал скайэнтити от 3д неба, а в диапазоне 0.9-1.0 соответственно задники скайбокса. Это единственный момент, который я поленился переделывать во второй параное, поскольку, мне бы тогда пришлось рисовать небо в отдельном проходе.
Цитата:
ncuxonaT писал: Что тогда передается через u_zFar?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 09-10-2020 в 23:53:
Дядя Миша благодарю, с водой в какой-то степени справился
Теперь вопрос по кубемапам. Я правильно понял, что рендерятся они на стороне движка, и из самой Паранойи нельзя прописать им дефайны в шейдеры или сделать, чтобы они сохранялись с альфа-каналом? Нужно лезть в движок?
Добавлено 10-10-2020 в 02:53:
Вообще нет, с водой не всё ясно. Подводный туман не работает. В gl_backend.cpp идет проверка, если игрок под водой, то функцией WATER_ENTITY находится энтитя воды, и её параметры подставляются заместо глобального тумана.
Но WATER_ENTITY почему-то возвращает отрицательное значение. Как такое может быть?
Отправлено Дядя Миша 10-10-2020 в 08:14:
Цитата:
ncuxonaT писал: Я правильно понял, что рендерятся они на стороне движка
Не совсем. На движок идёт команда - добавить скриншот кубемапы в очередь. На следующем кадре она выполняется и вызывает функцию VID_CubemapShot, которая в свою очередь шесть раз вызывает функцию R_DrawCubemapView, эта функция ставит флажки рендеринга RF_DRAW_WORLD и RF_DRAW_CUBEMAP, после чего вызывает обычный R_RenderFrame и вот он-то подхватывает встроенный рендер самой паранои и рендерит кубемапы её средствами. Таким образом параноя сама для себя рендерит кубемапы, движок только сохраняет их в файл и добавляет задание в очередь.
Цитата:
ncuxonaT писал: из самой Паранойи нельзя прописать им дефайны в шейдеры
вот это вот не понял.
Цитата:
ncuxonaT писал: сделать, чтобы они сохранялись с альфа-каналом
насчёт скриншотов с альфаканалом - я вообще таким никогда не баловался. Но да, это в движке, client\gl_backend.c->VID_CubemapShot там надо добавить флаг IMAGE_HAS_ALPHA и у glReadPixels поставить GL_RGBA. Только смысл?
Цитата:
ncuxonaT писал: то функцией WATER_ENTITY находится энтитя воды, и её параметры подставляются заместо глобального тумана.
а водичка на картинке это точно func_water? Плавать можно в ней?
Подводный туман слегка недоделан.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Lev 10-10-2020 в 09:01:
ncuxonaT Кубеманые отражения? Приятно выглядят)
Отправлено ncuxonaT 10-10-2020 в 14:15:
Цитата:
Дядя Миша писал: вот это вот не понял.
Я имею в виду, можно ли прописать в шейдерах #if defined( CUBEMAP_BUILDING ) и выставлять соответствующую директиву во время рендера кубемап?
Цитата:
Дядя Миша писал: насчёт скриншотов с альфаканалом - я вообще таким никогда не баловался. Но да, это в движке, client\gl_backend.c->VID_CubemapShot там надо добавить флаг IMAGE_HAS_ALPHA и у glReadPixels поставить GL_RGBA. Только смысл?
Смысл в сохранении HDR кубемап в формате RGBM или RGBD.
Цитата:
Дядя Миша писал: Проверьте на других картах, на том же грасс_тесте, к примеру.
Проверил, на грасс_тесте то же самое, WATER_ENTITY возвращает -1, хотя плавать в воде можно, и эффект растягивания фова присутствует.
Цитата:
Lev писал: ncuxonaT Кубеманые отражения? Приятно выглядят)
Кубемапные-кубемапные. Выглядят приятно, но на оригинальный паранойевских картах есть артефакты. Наверное, Элбер не расставлял кубемапы в коридорах с водой.
Отправлено Дядя Миша 10-10-2020 в 14:54:
Цитата:
ncuxonaT писал: Я имею в виду, можно ли прописать в шейдерах #if defined( CUBEMAP_BUILDING ) и выставлять соответствующую директиву во время рендера кубемап?
Ну это в коде надо делать. В HUD_RenderFrame есть флажок
if( FBitSet( rvp->flags, RF_DRAW_CUBEMAP )) - это состояние вот как раз, когда кубемапы рендерятся. Ну или скайбокс. Надо его расшарить через ref_globals_t например. И дальше, где у нас функции формирования убер-шейдера, Mod_ShaderSceneForward делаем проверку.
Псевдокод:
C++ Source Code:
if( tr.render_cubemaps ) // этой переменной нет, её надо завести и в HUD_RenderFRame ставить значение
Ну и собсно всё, механизм убер-шейдеров далее сам разберётся, что шейдер изменился и загрузит новый. Но естественно это надо сделать для всех функций формирования убер-шейдеров, для студиомоделей, для мировых брашей.
Цитата:
ncuxonaT писал: эффект растягивания фова присутствует
он на waterlevel проверяется. Тебе, собственно зачем знать номер этой WATER_ENTITY? Цвет тумана взять?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 11-10-2020 в 18:23:
Цитата:
Дядя Миша писал: Ну и собсно всё, механизм убер-шейдеров далее сам разберётся, что шейдер изменился и загрузит новый. Но естественно это надо сделать для всех функций формирования убер-шейдеров, для студиомоделей, для мировых брашей.
Это вроде бы получилось, только куда нужно засунуть GL_AddShaderDirective( options, "CUBEMAP_BUILDING" ); для рендера неба?
Отправлено Дядя Миша 11-10-2020 в 20:20:
gl_shader.cpp->GL_InitGPUShaders небо там.
Надо еще третий тип сделать, ну и массив tr.skyboxEnv увеличить.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 12-10-2020 в 12:29:
Дядя Миша мне тоже интересно
Отправлено ncuxonaT 12-10-2020 в 14:45:
Цитата:
Crystallize писал: А это физично что дальняя кромка чёткая?
Не физично, что ближняя кромка размытая, потому что вода либо есть, либо нет. Мягкий край делают, чтобы скрыть мерзкий стык с низкополигональным ландшафтом. А ИРЛ вода начинается резко:
Но вообще дальняя кромка такая же, как и ближняя.
Цитата:
Lev писал: Насколько я помню, в П2 никогда не было мягких краёв воды как в хл2.
Да вроде бы были.
Цитата:
Дядя Миша писал: ncuxonaT что ты там делаешь? Вы вместе с Lev работаете над игрой?
Лев попросил помочь с шейдерами, я начал ковыряться и втянулся. Теперь мне интересно, до чего можно допилить паранойевский графоний.
Отправлено Cybermax 12-10-2020 в 15:01:
Цитата:
ncuxonaT писал: А ИРЛ вода начинается резко:
На пляж придешь, вода прозрачная, что есть что нет, только гальку видно.
Отправлено Lev 12-10-2020 в 15:14:
Цитата:
ncuxonaT писал: Мягкий край делают, чтобы скрыть мерзкий стык с низкополигональным ландшафтом.
Именно, особенно этот край мерзко выглядит, если на него фонариком посветить.
Добавлено 12-10-2020 в 20:14:
Цитата:
ncuxonaT писал: Лев попросил помочь с шейдерами, я начал ковыряться и втянулся. Теперь мне интересно, до чего можно допилить паранойевский графоний.
С учётом того, сколько ncuxonaT уже сделал, то да, помогает).
Отправлено thambs 12-10-2020 в 15:14:
Цитата:
мерзкий стык с низкополигональным ландшафтом
Так места стыков нужно делать высокополигональными. Это как скалы с песком -- сами скалы можно делать крупными полигонами, а там где они с песком контактируют нужно повышать детальность. Тогда будет смотреться гораздо естественней.
ncuxonaT галька может быть и серая, но суть не меняется, если вода чистая и нет больших волн, то хоть на каменистом, хоть на мелкопесчаном пляже кромки воды не видно.
Отправлено ncuxonaT 12-10-2020 в 15:40:
Cybermax только если на неё перпендикулярно смотреть.
Отправлено Дядя Миша 12-10-2020 в 16:38:
Цитата:
ncuxonaT писал: Теперь мне интересно, до чего можно допилить паранойевский графоний.
Там большой задел оставлен. Много чего можно придумать.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 15-10-2020 в 14:00:
У несжатых DDS текстур не работает альфа-канал, потому что флаг IMAGE_HAS_ALPHA ставится только для DXT3 и DXT5. Если вдруг кто захочет использовать DDS с несжатым RGBA, имейте это в виду.
Отправлено Дядя Миша 15-10-2020 в 14:37:
Цитата:
ncuxonaT писал: Если вдруг кто захочет использовать DDS с несжатым RGBA, имейте это в виду.
Изначально поддержка несжатых DDS вообще не планировалась, т.к. смысла в ней немного. Мипы разве что.
JPEG Оптимизация это дело хорошее. Но оптимизировать в 2020-ом году игры под железо уровня 2005-го года это неразумно, как по мне. Никогда не понимал вот этих вот "играть на встроеной графике". У неё предназначение изначально совсем другое. Хотя тот же 8800GTX из 2006-го года(как я понял)должен иметь все необходимые расширения для полноценной работы П2. Хотя, на минуточку, многие аспекты рендеринга в П2 довольно-таки современные.
Отправлено Дядя Миша 16-10-2020 в 10:51:
Цитата:
Lev писал: Хотя тот же 8800GTX из 2006-го года(как я понял)должен иметь все необходимые расширения для полноценной работы П2
8800 это последнее поколение, на которое еще можно ориентироваться, т.к. там есть всё необходимое для работы.
А doom3, hl2 используют софтварную трансформацию вертексов для костей.
Насчёт сталкера не знаю, его-то R9800 с трудом тянул, какой там нафиг интел
Добавлено 16-10-2020 в 13:51:
Вообще я в шоке от некоторых наших товарищей. Сейчас вполне приличные железки года 2012-го можно купить за сущие копейки, но нет, они упорно продолжают сидеть на каком-то говне из музея и плакаться, что у них там что-то не работает. Один раз не сходить в магнит - вот тебе и новый компьютер.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Lev 16-10-2020 в 11:07:
Цитата:
Дядя Миша писал: Сейчас вполне приличные железки года 2012-го можно купить за сущие копейки
Нерасфуфыренная версия GTX1050 стоит меньше 4000 деревянных на вторичке, карты 9-ой и 7-ой серии я бы уже брать не стал(кроме случаев, когда последние достаются реально по цене похода в магнит), всё же они уже долго в эксплуатации, а живучесть видеокарт на порядок ниже, нежели процессоров и оперативки например. К тому же, непосвящённый человек, полезший искать б/у карту на авито, может с удивлением обнаружить там GTX660 по цене 2500р. Ну и нахрен оно нужно? Не сходи ещё один раз в надоевший магнит на 1500р, и получишь относительно современную карточку с маленьким потреблением и теплопакетотом, на которой можно почти не опасаться, что чего-то там не запустится.
Отправлено Дядя Миша 16-10-2020 в 13:11:
Если вы с Психопатом настроены серъезно, относительно работ над игрой и рендерером, я потом с вами поделюсь кодом симплификации дерева, который фпс подымает в несколько раз. Правда совместимость пойдет к чёрту, но для вас оно некритично.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено JPEG 16-10-2020 в 13:47:
Цитата:
Дядя Миша писал: Вообще я в шоке от некоторых наших товарищей. Сейчас вполне приличные железки года 2012-го можно купить за сущие копейки, но нет, они упорно продолжают сидеть на каком-то говне из музея и плакаться, что у них там что-то не работает. Один раз не сходить в магнит - вот тебе и новый компьютер.
да это ноут просто, модель 12-го года. Ну ладно
Отправлено Дядя Миша 16-10-2020 в 13:53:
JPEG драва обновлял? Хотя да, там у интела была проблема с мультислоёными текстурами, которую признали даже инженеры ихней техподдержки, в сети где-то оригинал письма валяется. Признали, но ничего делать с этим не стали.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 16-10-2020 в 16:42:
Цитата:
Lev писал: ncuxonaT С водой то как? Фпс ощутимо выше, чем со старыми отражениями?
В среднем процентов на 15. В каких-то адовых случаях может быть в полтора раза. Вообще для оптимизации можно много чего сделать. Например, делать окна одним куском, а не десятком
Дядя Миша что нужен будет делать с этим кодом? Внедрить в паранойю и компилятор и карты пересобрать?
Отправлено Дядя Миша 16-10-2020 в 17:36:
Цитата:
ncuxonaT писал: Например, делать окна одним куском, а не десятком
Ну выгадаешь пару фпс в лучшем случае. А может и того не будет.
Там диллема. С одной стороны - оверхед на пересечённых областях, сделаешь одним куском - AABB захватит куда больший участок, чем сейчас.
Шило на мыло.
Цитата:
ncuxonaT писал: что нужен будет делать с этим кодом? Внедрить в паранойю и компилятор и карты пересобрать?
нет, карты пересобирать не нужно, этот код налету оптимизирует любое дерево. На сложнейших картах, типа сипульчера время работы около одной секунды, на маленьких, практически неощутимо. На выходе получается оптимизированное дерево, из 100 тысяч узлов получается 2-3 тысячи. Ну зависит от того сколько детайлов было использовано, но по факту можно оптимизировать деревья оригинальных карт, где некоких детайлов не было.
Смысл в том, чтобы потом использовать именно это дерево, а не оригинальное. Т.е. код сам по себе ничего не ускоряет, он просто даёт оптимальные дерево. Ключевой тормоз, который убивает фпс - это функция ENGINE_CHECK_VISIBILITY. Поясню почему так происходит.
дерево слишком подробное, там адское кол-во лифов. А стандартная энтить может вмещать только первые 16 лифов. В квейке на эту проблему вообще забили, типа ну влезло 16 и ладно. В халфе при оверфлове эти же лифы помечаются отрицательными значениями.
И при вызове функции ENGINE_CHECK_VISIBILITY вызывается Mod_HeadnodeVisible (название из ксаша). Для дерева в котором десятки тысяч лифов... И так - для каждого монстра, для каждой энтити, каждый кадр. Фпс убивает со страшной силой. Вопрос только в том, как бы этот симплификатор адекватно встроить в движок, я его на С++ писал.
Дядя Миша писал: Если вы с Психопатом настроены серъезно, относительно работ над игрой и рендерером, я потом с вами поделюсь кодом симплификации дерева, который фпс подымает в несколько раз. Правда совместимость пойдет к чёрту, но для вас оно некритично.
А что понимается под совместимостью? Халфовские монстры перестанут работать или оригинальные бсп из хл не запустятся? Если только второе, то этот магический код не помешало бы в ксаш-мод добавить, мне бы пригодился (карты открытые местами, приходится ограничиваться). Вот только я использую халфовских монстров.
Дядя Миша писал: Ну выгадаешь пару фпс в лучшем случае. А может и того не будет.
Там диллема. С одной стороны - оверхед на пересечённых областях, сделаешь одним куском - AABB захватит куда больший участок, чем сейчас.
Шило на мыло.
Думаешь, несколько вызовов glCopyTexSubImage2D вместо одного, а также сопутствующие расходы на передачу юниформов, биндинг текстур каждому куску и т.д. на фпс влияют незначительно?
Цитата:
Дядя Миша писал: Вопрос только в том, как бы этот симплификатор адекватно встроить в движок, я его на С++ писал.
Моих навыков для этого точно не хватит. Полагаю, как и навыков кого-либо из присутствующих.
Отправлено Дядя Миша 16-10-2020 в 20:38:
Цитата:
SNMetamorph писал: Можно будет загружать карты голдсурсовского BSP формата и их симплифицировывать?
Дерево придётся куда-то сохранять, потом загружать - в два раза больше работы. Но можно и так. В компилятор встроить.
Цитата:
Aynekko писал: А что понимается под совместимостью?
бинарная совместимость с халфовскими библиотеками.
Цитата:
ncuxonaT писал: Думаешь, несколько вызовов glCopyTexSubImage2D вместо одного, а также сопутствующие расходы на передачу юниформов, биндинг текстур каждому куску и т.д. на фпс влияют незначительно?
Юниформы, текстуры биндятся один раз в начале секвенции отрисовки.
Если бы каждое стекло целиком копировало весь экран - там было бы что оптимзировать. Но вызывается subImage, и копируется только тот кусочек, который дебаг ограничивает жёлтым квадратиком. Поэтому вопрос только в том, насколько дорог сам вызов subImage. Второй момент - объединять имеет смысл только там, где ровный полигон порезало на части, например шаг лайтмапы. Это чисто мапперский косяк, надо в настройках подкрутить шаг разбиения лайтмапы. А рисовать смежные стёкла с одной копией экрана - так себе идейка. Потому что во первых финальный скиссор скорее всего будет больше площади отдельно взятых окошек, а во вторых тебе еще придётся гарантировать что эти поверхности относительно взгляда игрока ВСЕГДА лежат на одной плоскости, что для полупрозрачных поверхностей неразрешимая задача.
Т.е. ты на эту аналитику потратишь больше ресурсов чем выгадаешь.
Но дело твоё конечно - пробуй, потом расскажешь.
Цитата:
ncuxonaT писал: Моих навыков для этого точно не хватит
ну ты же как-то с Дельфи перескочил на С++? Значит способности есть.
Я вот к примеру Петон вряд ли смогу освоить, мне его автора придушить хочется.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 16-10-2020 в 20:55:
Цитата:
Дядя Миша писал: ну ты же как-то с Дельфи перескочил на С++?
Никуда не перескакивал. 20-30 строчек, что я добавил в паранойю - это вообще ни о чем.
Отправлено nemyax 16-10-2020 в 22:01:
Цитата:
Дядя Миша писал:
Я вот к примеру Петон вряд ли смогу освоить, мне его автора придушить хочется.
Автор уже уволился, его негры линчевали выбил на обочину прогрессивный демократический процесс.
ncuxonaT
А ты как-то постил си-подобный код, но не сишный. Это щас так паскаль выглядит?
Отправлено ncuxonaT 17-10-2020 в 01:25:
nemyax может, то были шейдеры?
Отправлено Дядя Миша 17-10-2020 в 07:10:
Питон как будто нарочно делали, чтобы выбесить:
1. выбросили точку с запятой
2. выбросили фигурные скобки
3. комментарии начинаются с #
Но при этом основные ключевые слова по большому счёту остались теми же - return, if, else. Добавили лямбды, убрали типизацию. Вот нахрена так делать, спрашивается?
В Сишарпе наоборот ударились в другую крайность - зачем-то добавили из явы магическое заклинание public static void.
Как будто за каждым разрабом языка стоит дьявол-маркетоид и нашёптывает ему - испорти синтаксис, испорти.
В GLSL\HLSL подобной задачи не стояло, на удивление. И никто ничего не ломал.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 17-10-2020 в 07:39:
Цитата:
Дядя Миша писал: Питон как будто нарочно делали, чтобы выбесить:
А чем петон сильно лучше C, что на нём так много всякого полезного говна пишут? Прям как на джаве под винду.
Отправлено thambs 17-10-2020 в 07:45:
Цитата:
выбросили точку с запятой
Она опциальна, так-то ставь сколько хочешь. Так-то, как правило синтаксическая единица пишется в одну строку и эти точки с запятыми только загромождают текст.
Цитата:
выбросили фигурные скобки
Тоже спорный момент, загромождают текст сильно, но при этом дублируются отступами. Так-то они для словарей по назначению используются.
Цитата:
убрали типизацию. Вот нахрена так делать, спрашивается?
Не совсем убрали. Но вообще, python это не совсем язык, это скорее фрэймворк для прототипирования и рабочая среда. Что-то вроде очень продвинутой версии консоли с блекджеком и библиотеками на все случаи жизни. Заменяет собой матлабы, и прочие лабвью.
Ku2zoff
Память не дают портить и в стандартной библиотеке всё готовенькое.
Отправлено Дядя Миша 17-10-2020 в 08:28:
Цитата:
Ku2zoff писал: А чем петон сильно лучше C
чем песочница лучше языка низкого уровня? Очевидно у каждого свои задачи.
Цитата:
thambs писал: Так-то, как правило синтаксическая единица пишется в одну строку и эти точки с запятыми только загромождают текст.
нет такого правила. Я к примеру инициализацию однобуквенных переменных в конструкторе очень часто пишу в одну строку.
C++ Source Code:
x = _x; y = _y; z = _z;
В любом случае полагаться на непечатный невидимый символ - так себе идейка. Особенно если учесть, что он бывает /r/n или просто /n
Цитата:
thambs писал: Тоже спорный момент, загромождают текст сильно, но при этом дублируются отступами.
А представь, что у тебя где-то вместо серии пробелов - табуляция. И что? Код не соберётся? Мне Ксер рассказывал за какой-то язык, где надо было прям жостка табулировать, иначе ошибка компиляции.
А загромождают код не фигурные скобки, а ключевые слова "конецЕсли".
Цитата:
thambs писал: скорее фрэймворк для прототипирования и рабочая среда
Я вот какую вещь заметил. Если на языке предполагается писать что-то большое, он скорее всего будет иметь Си-подобный синтаксис.
А если какие-то мелкие саброутины, там да в таикх языках каждый извращается как только может.
Дядя Миша писал:
А представь, что у тебя где-то вместо серии пробелов - табуляция. И что? Код не соберётся?
У меня было такое. Нужно было добавить строчку в скрипт для блендера, и я весь вечер с ним бился, потому что он не работал и выдавал ошибку, хотя визуально всё было правильно. Потом только догадался включить непечатаемые символы и увидел, что мой отступ не такой как другие.
Отправлено Дядя Миша 17-10-2020 в 13:29:
Ладно.
ncuxonaT у тебя вообще какие-то конкретные планы есть по параное?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено KiQ 17-10-2020 в 21:36:
У меня вот давно проект под это дело валяется, в сеттинге зимней российской глубинки конца 19-го века. Надо бы сесть запилить диздок. Я как-то кидал скрины таверны оттуда на древней версии ксаша
__________________
-Brain is dead-
Отправлено Lev 18-10-2020 в 05:29:
Цитата:
ncuxonaT писал: с правленными под пбр текстурами
Что именно нужно сделать с текстурами для пбр?
Отправлено KorteZZ 18-10-2020 в 16:44:
Цитата:
KiQ писал: У меня вот давно проект под это дело валяется, в сеттинге зимней российской глубинки конца 19-го века. Надо бы сесть запилить диздок. Я как-то кидал скрины таверны оттуда на древней версии ксаша
Оо, это очень интересно. Необычный сеттинг. Как надумаешь чего - дай знать)
Так эти же, ещё личинки заглотных коммунистов тогда как раз бегали тут и там — их-то за это тогдашние имперские карательные органы адски били, да вот не добили. Ну вот, например, можно играть молодым Джугавшили или командой жандармов, и грабить корованы, конечно.
Если у скина заменить >= на ==, то всё работает, вода попадает в список. Вероятно, скин воды равен 0.
Отправлено Дядя Миша 19-10-2020 в 18:35:
Цитата:
ncuxonaT писал: Если у скина заменить >= на ==, то всё работает
ну это только для проверки, верни назад.
У водички на карте вроде бы skin -3 стоял. Может по сети не доходит на клиент?
Добавлено 19-10-2020 в 21:35:
Что можно проверить:
1. убедиться что у func_water стоит skin -3
2. пошукать в папке мода на предмет кастомной delta.lst и посмотреть как объявлен skin в секции Entity_Encode (оригинальный лежит в scripts.pak).
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 19-10-2020 в 18:47:
Цитата:
Дядя Миша писал: убедиться что у func_water стоит skin -3
Это в самом бсп? Да, там -3.
Цитата:
Дядя Миша писал: пошукать в папке мода на предмет кастомной delta.lst и посмотреть как объявлен skin в секции Entity_Encode (оригинальный лежит в scripts.pak)
Кастомного нету, в оригинальном DEFINE_DELTA( skin, DT_SHORT | DT_SIGNED, 9, 1.0 ).
Отправлено Дядя Миша 19-10-2020 в 19:22:
Всё верно. Почему жы оно на клиент не приходит.
Добавлено 19-10-2020 в 22:21:
Попробуй в поле skin прописать положительные числа, надо понять оно только отрицательные отсекает или вообще все.
Добавлено 19-10-2020 в 22:22:
В настройках двери имею в виду. Можно в entpatch прописать, чтобы карту не компилить.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 19-10-2020 в 21:22:
Дядя Миша только отрицательные, заменяет их на 255
Отправлено Дядя Миша 20-10-2020 в 07:47:
В движке Delta_ClampIntegerField
C++ Source Code:
1
if( numbits < 32 )
2
{
3
int signbits = bSigned ? (numbits - 1) : numbits;
4
int maxnum = BIT( signbits ) - 1;
5
int minnum = bSigned ? -maxnum : 0;
6
iValue = bound( minnum, iValue, maxnum );
7
}
где-то здесь бяка по идее. Я эту функцию переписывал почти перед финальным релизом. Но вообще странно, вроде бы тестировал и всё было корректно. В любом случае это достаточно серъезный баг, я вероятно сам потом проверю всё.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 21-10-2020 в 13:09:
Такой вопрос, текстуры из вадов и корня папки textures - они все используются только для брашей? Я составил список текстур, прописанных внутри всех bsp, и сопоставил одно с другим. Вышло, что около 130 текстур не используются в игре. Можно их смело удалять?
Отправлено Aynekko 21-10-2020 в 13:45:
Цитата:
ncuxonaT писал: Я составил список текстур, прописанных внутри всех bsp, и сопоставил одно с другим.
Как ты это сделал? Это можно как-то быстро сделать?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 21-10-2020 в 15:42:
Цитата:
Aynekko писал: Как ты это сделал? Это можно как-то быстро сделать?
Я бы использовал Notepad++ и windiff наверное. Или питонскрипт в нотепаде.
Отправлено ncuxonaT 21-10-2020 в 18:28:
Aynekko я прогу для этого набросал
Отправлено Lev 21-10-2020 в 18:56:
ncuxonaT Есть ещё вариант, когда текстуры нет в ваде, но в карте используется - ландшафты. В одной карте П2, на сколько я помню, был задействован ландшафт(p_savior11link).
Добавлено 21-10-2020 в 23:56:
Проверил - там видимо Элбер старыми компиляторами собирал, на момент выхода П2 не было ещё текущей системы ландшафтов, там просто текстура из вада.
Отправлено ncuxonaT 21-10-2020 в 19:18:
Lev ландшафты я не учел, да. Ну их уж вручную смотреть.
Отправлено Aynekko 21-10-2020 в 19:35:
Цитата:
ncuxonaT писал: Aynekko я прогу для этого набросал
Отличная прога! Спасибо! Единственное half-life.wad не переваривает - виснет намертво.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Aynekko 21-10-2020 в 19:47:
Цитата:
Дядя Миша писал: Aynekko мб просто слишком долго анализирует?
Ага, так и есть. Просто я закинул 17 вадников общим размеров как 1 хл-вад (без хл-вада есесно) и почти моментально все открылось. Этот секунд 20 открывал.
nemyax писал: А экшен по какому поводу? В тот период ничего такого не приключалось.
А там не экшен, там детектифф (ну с элементами экшена и мистики, куда без них)
__________________
-Brain is dead-
Отправлено ncuxonaT 24-10-2020 в 00:23:
Паранойя у меня сыпала ошибками опенгла, начал разбираться. Оказалось, что когда биндится tr.screencolor движковой функцией GL_Bind, то pglEnable(GL_TEXTURE_2D) порождает ошибку GL_INVALID_VALUE. Но, согласно документации, glEnable в принципе не может дать GL_INVALID_VALUE. Есть мысли, как такое может быть?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 24-10-2020 в 15:13:
Дядя Миша включил, ясности не очень добавило
В логе бесконечное количество ошибок OpenGL Error: glGetObjectParameterivARB parameter <pname> has an invalid enum '0x8741' (GL_INVALID_ENUM)
Я не нашел никакой документации на glGetObjectParameterivARB, но также не нашел примеров использования, где бы в качестве pname стояло GL_PROGRAM_BINARY_LENGTH (0x8741).
Еще периодически вылазит Error: GL_SelectTexture: bad tmu state 3553, возможно это является причиной ошибки при glEnable(GL_TEXTURE_2D)? Куда копать? Tmu же должен быть в диапазоне 0-15 или что-то типа того?
Отправлено Дядя Миша 24-10-2020 в 17:30:
Цитата:
ncuxonaT писал: но также не нашел примеров использования, где бы в качестве pname стояло GL_PROGRAM_BINARY_LENGTH
gl_shader.cpp->GL_SaveGPUBinaryShader
Поставь в opengl.cfg gl_binaryshader "0"
посмотри, исчезнет ли ошибка.
Цитата:
ncuxonaT писал: Еще периодически вылазит Error: GL_SelectTexture: bad tmu state 3553, возможно это является причиной ошибки при glEnable(GL_TEXTURE_2D)?
Именно так. Это движок ругается. Где-то в GL_BindTexture или GL_SelectTexture недопустимое значение.
Добавлено 24-10-2020 в 20:30:
Ты может новый юниформ добавлял и неправильно его настроил.
Я имел в виду, что в энторнетах никто такого не делает. GL_PROGRAM_BINARY_LENGTH используется только в glGetProgramiv.
Цитата:
Дядя Миша писал: Поставь в opengl.cfg gl_binaryshader "0"
посмотри, исчезнет ли ошибка.
Исчезла, но теперь в логе бесконечное число сообщений о том, что type = GL_BYTE size = 3 у VERTEX_ATTRIB[2] и VERTEX_ATTRIB[3] не поддерживается нативно, и что 15 и 18 не являются оптимальными оффсетами, используйте выравнивание по 4 байта.
Цитата:
Дядя Миша писал: Ты может новый юниформ добавлял и неправильно его настроил.
Не, новых не добавлял. Tmu не автоматом назначается?
Добавлено 24-10-2020 в 21:12:
Заменил в общем pglGetObjectParameterivARB на pglGetProgramivARB, теперь у меня работает кэш шейдеров
Отправлено Дядя Миша 24-10-2020 в 18:21:
Цитата:
ncuxonaT писал: Заменил в общем pglGetObjectParameterivARB на pglGetProgramivARB
на нвидии оба варианта работают. Вообще странно.
Добавлено 24-10-2020 в 21:17:
Цитата:
ncuxonaT писал: и что 15 и 18 не являются оптимальными оффсетами, используйте выравнивание по 4 байта.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 24-10-2020 в 18:27:
Цитата:
Дядя Миша писал: про too small offset ругался?
нет, такого нет
code:OpenGL Notify: glDrawRangeElements uses input attribute 'VERTEX_ATTRIB[2]' which is specified as 'type = GL_BYTE size = 3'; this combination is not a natively supported input attribute type
OpenGL Notify: glDrawRangeElements uses input attribute 'VERTEX_ATTRIB[2]' with offset '15' that is not optimally aligned; consider aligning on a 4-byte boundary
OpenGL Notify: glDrawRangeElements uses input attribute 'VERTEX_ATTRIB[3]' which is specified as 'type = GL_BYTE size = 3'; this combination is not a natively supported input attribute type
OpenGL Notify: glDrawRangeElements uses input attribute 'VERTEX_ATTRIB[3]' with offset '18' that is not optimally aligned; consider aligning on a 4-byte boundary
вот это идёт нон-стопом
Отправлено Дядя Миша 24-10-2020 в 19:51:
это править gl_studiovbo, gl_world_new и vertex_fmt?
Нашел у себя ошибку, которая вызывала bad tmu state 3553, я неправильно биндил текстуру из фбо, которая в конце на экран рисуется. Но к glEnable GL_INVALID_VALUE оно никак не относится, дело в чем-то еще.
Отправлено Дядя Миша 25-10-2020 в 07:43:
Цитата:
ncuxonaT писал: Но к glEnable GL_INVALID_VALUE оно никак не относится, дело в чем-то еще.
Может какая-то текстура загрузилась с ошибкой?
Добавлено 25-10-2020 в 10:43:
Цитата:
ncuxonaT писал: это править gl_studiovbo, gl_world_new и vertex_fmt?
Можешь принудительно переключиться в режим буфферов gl20, там нет этой ошибки.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено kotar.sys 27-10-2020 в 15:25:
Интересно будет глянуть
__________________
Ржака
Отправлено ncuxonaT 03-11-2020 в 15:59:
Каким образом сейчас определяется плотность лайтмапы? Раньше было 16 для бсп30 и 8 для бсп31, потом бсп31 стал депрекейтед, и в бсп30 был добавлен параметр опциональный параметр zhlt_texturestep, но в паранойевских картах он не фигурирует.
Отправлено Дядя Миша 03-11-2020 в 16:09:
C++ Source Code:
1
typedefstruct
2
{
3
char landname[16]; // name of decsription in mapname_land.txt
4
word texture_step; // default is 16, pixels\luxels ratio
5
word max_extent; // default is 16, subdivision step ((texture_step * max_extent) - texture_step)
6
short groupid; // to determine equal landscapes from various groups, -1 - no group
7
} dfaceinfo_t;
Если этого лумпа нет, по умолчанию texture_step принимается равным 16.
В параноевских картах он не фигурирует, поскольку эта фича там не использовалась.
Но повторюсь, этот лумп может вообще отсутствовать в карте. Или иметь всего одну структуру с глобальными настройками.
Добавлено 03-11-2020 в 19:08:
А и еще. Для поддержки конвертации из BSP31 был введён флаг TEX_EXTRA_LIGHTMAP
если он присутствует - дефолтное разрешение лайтмапы не 16, а 8.
mtexinfo_t->flags - здесь смотреть.
Добавлено 03-11-2020 в 19:09:
В сорцах второй паранои претоился даже фейковый лайтмаппер для моего римейка Doom, но этого так никто и не заметил
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено KiQ 23-11-2020 в 08:32:
ncuxonaT игроку это разве так заметно?
__________________
-Brain is dead-
Отправлено Дядя Миша 23-11-2020 в 11:54:
Цитата:
ncuxonaT писал: Автоматический расчет ААВВ лажает же часто
ДЛя BPCEM критически важна точность комнаты. Если вбить туда значения от балды, будет гораздо хуже, нежели слажавшая автоматика.
Мапперам просто надо помнить о том, как работает кубемапа и не ставить её напротив дверных проёмов.
По хорошему надо бы завести особый тип материала, который бы коллидил только с тестовыми лучами кубемапы, но понятное дело, это уже не в параное.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 23-11-2020 в 13:25:
KiQ по видео разве ж не видно? На 0:42 или на 2:25, к примеру. Нет, ну если запрятать кубемапы, чтобы их не было видно, как в ванильной версии, то не заметно, конечно.
Цитата:
Дядя Миша писал: Если вбить туда значения от балды, будет гораздо хуже, нежели слажавшая автоматика.
Зачем вбивать значение от балды, если можно ставить браши? И сразу видеть, какие будут границы у ВРСЕМ, а не полагаться на то, что там потом автоматика рассчитает. WYSIWYG
Отправлено Дядя Миша 23-11-2020 в 14:41:
Идея может и хорошая, но придётся ломать бинарную совместимость.
в dcubemap_t нет для этого места.
Дядя Миша а ты не пробовал заюзать лайтстили для всего света, а не только для мигания. Например, в трех лайстилях три самые яркие лампочки, а в четвертом амбиент.
А то как-то странно выглядит этот блик, туда-сюда прыгающий. Или вообще забить на него, и для гладких материалов ограничиться кубемапой?
Отправлено Дядя Миша 29-11-2020 в 07:15:
Там предусмотрен лерпинг на 2 кубемапы, но я его отключил, потому что у кого-то юниформов не хватало.
Добавлено 29-11-2020 в 10:15:
Цитата:
ncuxonaT писал: А то как-то странно выглядит этот блик, туда-сюда прыгающий
для статики он никуда не прыгает. А мобы не блестят как твой шарик.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Lev 29-11-2020 в 07:24:
ncuxonaT Ты уже капсульные тени запилил, приятно смотрится.
Отправлено ncuxonaT 29-11-2020 в 16:40:
Дядя Миша если просто смешивать кубемапы, отражение будет двоиться. Lev тень, считай, фейковая. Только от шара на месте модели игрока. Для приемлемой реализации мне нужны матрицы хитбоксов моделей, но хз, как их вытащить.
Отправлено Дядя Миша 29-11-2020 в 16:52:
Цитата:
ncuxonaT писал: Для приемлемой реализации мне нужны матрицы хитбоксов моделей, но хз, как их вытащить.
Матриц хитбоксов не существует. Каждый хитбокс прилинкован к какой-то кости. Вот матрица этой кости и есть матрица хитбокса. Посмотри как они рисуются в дебаг-режиме.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-11-2020 в 17:13:
Дядя Миша посмотрел уже. У хитбоксов же есть размеры еще. Как проще сделать скукоживание мира до состояния, когда хитбокс представляет собой АА куб от -1 до 1? Умножать на обратную матрицу кости и делить на размеры?
Отправлено Дядя Миша 29-11-2020 в 17:31:
Цитата:
ncuxonaT писал: Как проще сделать скукоживание мира до состояния, когда хитбокс представляет собой АА куб от -1 до 1?
Понятия не имею. Никогда не возникало такой надобности. Да и хитбокс наверное лучше заменить хиткапсулой.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-11-2020 в 18:24:
Дядя Миша не капсулой, трехосным эллипсоидом, вписанным в хитбокс
Но сама тень считается от сферы, поэтому эллипсоид и всё пространство вместе с ним нужно скукожить.
Отправлено Дядя Миша 29-11-2020 в 19:32:
Не, я никогда не занимался параметрическими тенями. Так что ничо не могу сказать. Может там реальных элипсоидов нагенерить и кидать тени от них? Не проще?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-11-2020 в 20:35:
Тень в любом случае считается от сферы.
Чтобы кинуть тень от эллипсоида, нужно сжимать пространство, пока эллипсоид не станет сферой.
Отправлено ncuxonaT 11-12-2020 в 00:23:
Дядя Миша у меня в памяти всплыло, что ты писал, будто бы нашел древний баг, когда студиомодель берет освещение с лайтмапы, то делает это неправильно. То ли трасса не туда попадает, не в нужный фейс, то ли есть сдвиг при чтении из лайтмапы. Что-то в этом роде.
В Паранойе это исправлено? Или не было вообще такого события?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 12-12-2020 в 16:52:
Вот без векторов
Отправлено Дядя Миша 12-12-2020 в 18:14:
Ничо сказать не могу. Это же не регулярная сетка, а трасса вниз. Может Элбер там что-то поставил.
Добавлено 12-12-2020 в 21:14:
Но к исправленному багу это отношения точно не имеет. Он ведь как проявлялся. На границе света и тени, когда перс стоял на освещённом участке, свет брался из соседнего тёмного люкселя. А тут совершенно другая ситуация. Может свет вообще с потолка берётся в этот момент. Оно же там проверяет, до куда ближе, до пола или до потолка. Может там как раз балка в этом месте. Отключи gl_renderer и проверь на чистом ксаше.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 13-12-2020 в 14:53:
На p_savior2 такого много, но там есть балки на потолке. Хотя непонятно, почему внезапно только в некоторых местах свет начинает с них браться, если, конечно, в этом причина.
Отправлено Crystallize 13-12-2020 в 15:48:
Была же такая шняга на КСМ в связи с какой-то картой КС. Может очень давно правда. Там кажется оказалось что ГС делает трейс вверх наискосок и оттуда берет яркость.
Отправлено Дядя Миша 13-12-2020 в 18:39:
ncuxonaT эти карты Элбер компилил не помню чьими компиляторами, но моих тогда не было в природе. Может там какая-то невидимая срань, в которую трасса упирается. Может быть трасса берётся с потолка, может что-то еще. Оно там радикально чёрное или мал-мала освещается?
Добавлено 13-12-2020 в 21:37:
Надо пихать алерты и смотреть как трасса отрабатывает. На каком этапе происходит отказ.
Добавлено 13-12-2020 в 21:39:
Есть еще квар r_lighting_extended 0\1 можно его выключить и потестить.
Если освещение исправится, значит там точно какая-то невидимая срань.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 17-12-2020 в 16:00:
Хочу скомпилить рад из обычного p2st. Там не хватает заголовочников про SSE и векторы. Если начинаешь дергать их из сорса то огребаешь больше ошибок чем имел.
И ещё там не распознается функция CompressRGBABufferToDXT хотя она в том же файле выше объявлена.
Отправлено ncuxonaT 17-12-2020 в 17:07:
Crystallize sseconst.cpp не используется, можно удалить его объявление
Отправлено ncuxonaT 18-12-2020 в 19:35:
Оригиналов карт нет, да?
Отправлено Дядя Миша 18-12-2020 в 19:41:
Что есть - всё в общем доступе. Как в целом дела протекают? Есть чем похвастаться?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 18-12-2020 в 23:58:
Нечем пока хвастаться. Сделана бОльшая часть брашевых текстур и малая часть моделей. Капсульные тени и объемное освещение с туманом даже не трогал. Еще нужно сделать, чтобы спрайты и частицы с шейдером рендерились, для гамма-коррекции.
Хотел перепечь освещение лайтбейкером, даже поддержку лайтстилей в нем запилил, но есть две проблемы. Во-первых, не могу запечь вертексное освещение, потому что не могу понять формат хранения. Во-вторых, на картах есть дыры, через которые светит небо:
Добавлено 19-12-2020 в 02:58:
Еще кстати не могу разобраться.
C++ Source Code:
1
typedefstruct
2
{
3
byte emittype;
4
byte style;
5
byte flags; // will be set in ComputeLeafAmbientLighting
6
short origin[3]; // light abs origin
7
float intensity[3]; // RGB
8
float normal[3]; // for surfaces and spotlights
9
float stopdot; // for spotlights
10
float stopdot2; // for spotlights
11
float fade; // falloff scaling for linear and inverse square falloff (0.5 = farther, 2.0 = shorter etc)
unsignedshort facenum; // face number for emit_surface
16
short modelnumber; // g-cont. we can't link lights with entities by entity number so we link it by bmodel number
17
} dworldlight_t;
Тут же 56 байтов? А в бсп как будто бы структуры по 60 байтов записаны.
Отправлено Дядя Миша 19-12-2020 в 06:58:
Цитата:
ncuxonaT писал: даже поддержку лайтстилей в нем запилил
А её не было?
Цитата:
ncuxonaT писал: Во-первых, не могу запечь вертексное освещение, потому что не могу понять формат хранения
Что именно непонятно? Повертексное освещение чем-то похоже на механизм хранения текстур.
C++ Source Code:
1
typedefstruct
2
{
3
int ident; // to differentiate from previous lump LUMP_LEAF_LIGHTING
4
int version; // data package version
5
int nummodels;
6
int dataofs[4]; // [nummodels]
7
} dvlightlump_t;
dataofs - это массив смещений, каждое смещение указывает на начало dmodelvertlight_t.
C++ Source Code:
1
typedefstruct
2
{
3
unsignedint modelCRC; // catch for model changes
4
int numverts;
5
byte styles[MAXLIGHTMAPS];
6
dvlightofs_t submodels[32]; // MAXSTUDIOMODELS
7
dvertlight_t verts[3]; // variable sized
8
} dmodelvertlight_t;
Хидер плюс все вертексы размером с numverts. dvlightofs_t фиксированная структурка, нужна для того, чтобы все индексированные вертексы точно попали на свои места в реальной модели. Правда в этом формате есть привязка к механизму построения VBO нпосредственно в рендере паранои. Ну впрочем можно ксаш-мод посмотреть, вероятно там будет проще разобраться. Вся эта замута появилась из-за уродского метода хранения вертексов в mdl там к ним нет нормального доступа. Я бы не стал этот огород городить, если бы в mdl можно было получить доступ к уникальным вертексам. Но там - только через сабмодели, которые могут чередоваться, дублироваться итд. Т.е. сначала надо построить лист уникальных мешей. Для лайтмап аналогичный механизм, но чуть попроще.
Добавлено 19-12-2020 в 09:58:
Цитата:
ncuxonaT писал: Тут же 56 байтов? А в бсп как будто бы структуры по 60 байтов записаны.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 20-12-2020 в 18:43:
fatal error C1600: unsupported data type
Если поставить Processor Pack это пропадёт? А то мне для него вообще другая ревизия 6 студии нужна, на Standard Edition он не ставится.
Отправлено Lev 21-12-2020 в 05:59:
Crystallize Ставь Enterprise версию и сервис пак 5.
Отправлено Дядя Миша 21-12-2020 в 06:31:
Эта студия с пятым сервис-паком она очень непростая. Это единственная шестёрка которая умеет в SSE. В шестом сервиспаке это уже выбросили.
Микрософт иногда любит так делать. К примеру WinXP SP1 видел более 3 гигабайт оперативы. А потом они испугались и заблокировали эту возможность.
KiQ хех, раньше у меня хотя бы Standard Edition запускался, теперь уже и он не хочет.
Отправлено Crystallize 27-12-2020 в 19:06:
ага, установщик почему-то копирует не все файлы что должны быть в bin и bin\ide, копируешь их вручную и студия запускается.
Отправлено Crystallize 30-12-2020 в 17:50:
Цитата:
Crystallize писал: fatal error C1600: unsupported data type
Если поставить Processor Pack это пропадёт?
Цитата:
Lev писал: Ставь Enterprise версию и сервис пак 5.
А дело было реально в Процессор-Паке.
Но почему всё-таки установщик Enterprise-версии забывает скопировать пару десятков файлов? Может быть XP-шный Windows Installer последних версий тоже потерял какой-то функционал на полпути?
Отправлено Ku2zoff 30-12-2020 в 18:40:
Цитата:
Crystallize писал: Может быть XP-шный Windows Installer последних версий тоже потерял какой-то функционал на полпути?
Майкрософт потеряли половину свих мозгов на полпути. Что держит их продукты на плаву - обратная совместимость. Вы попробуйте новые Дебианы, например, в сравнении с Squeeze. Начнёте плеваться не только от интерфейса, но и от того, что они повыпилили из новых дистров много годных пакетов. Чтобы завести ту же Жырнокрысу, придётся собрать её из сорцев. А, ИМХО, это лучший менеджер закачек для линуксов. А чё? Сосите убогий Трансмишн или ставьте KTorrent на Мыш-DE с кучей зависимостей.
У майкрософта ситуация другая - большинство софта для XP так или иначе заведёдтся даже под десяткой. А что не заведётся, то либо делали сами мелкомягкие и нарочно сломали совместимость, чтобы народ юзал более свежие версии, либо софт был написан рукожопами, вроде Jed'а, когда его простейший HLMV ломается под семёркой.
Отправлено froqus 07-01-2021 в 21:35:
задолбали вы своими скрытыми текстами пипец. я десять лет на форуме этом, но если блин пишу редко то что - надо отметиться в каждой теме обязательно хоть разок? )
Отправлено JPEG 07-01-2021 в 22:51:
Цитата:
Ku2zoff писал: рукожопами, вроде Jed'а
он кстати не так давно, года пол назад писал у себя на сайте, что хочет обновить его) сейчас правда не нашёл пост, мб передумал
Ku2zoff писал: Майкрософт потеряли половину свих мозгов на полпути.
Да это у меня реестр был замусорен, почистил-всё заработало.
Добавлено 08-01-2021 в 17:57:
Вручную.
Отправлено ncuxonaT 25-01-2021 в 19:27:
В effects.cpp при загрузке env_dynlight его радиус делится на 8 с комментарием "// to prevent disapperaing from PVS (renderamt is premultiplied by 0.125)". Зачем это нужно? Почему для омнилайта радиус потом еще домножается на 4?
Еще по поводу динлайтов. Такое впечатление, что при рендере в шадовмапу они используют PVS игрока, а не свой собственный. Это возможно пофиксить?
Отправлено Дядя Миша 25-01-2021 в 20:12:
Цитата:
ncuxonaT писал: Зачем это нужно?
чтобы влезть в сетевые границы для переменной renderamt (0-255).
На клиенте умножается обратно.
Цитата:
ncuxonaT писал: они используют PVS игрока, а не свой собственный
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-01-2021 в 21:00:
Дядя Миша так в тень может попасть то, что игрок не видит
Отправлено Lev 25-01-2021 в 21:42:
ncuxonaT Так вот что это было, когда я динлайты ставил - они именно так просвечивали в зависимости от положения камеры игрока, и так же просвечивал динамический свет от солнца на открытой карте через крышу здания, когда игрок внутри и солнышко у него за спиной.
Отправлено Дядя Миша 26-01-2021 в 06:17:
Цитата:
ncuxonaT писал: так в тень может попасть то, что игрок не видит
так PVS строится с учётом полного радиуса лайта. Там в чём-то другом дело.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 26-01-2021 в 11:15:
Дядя Миша а при чем тут радиус? Может, я неправильно использую термин PVS? Как называется куллинг невидимой геометрии через бсп дерево?
Короче, когда геометрия перестает отрисовываться для игрока, тогда же она пропадает из шадовмапы:
Отправлено Дядя Миша 26-01-2021 в 12:30:
Цитата:
ncuxonaT писал: а при чем тут радиус?
Вообще-то там мержится пвс лайта с пвс игрока.
Это же старая карта, ей только освещение перекомпиливали.
Может там глюк какой-то, я не помню уже.
На то я вам и дал, так сказать, сорцы, чтобы вы сами во всём разобрались и починили если где-то что-то сломано.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 27-01-2021 в 18:02:
Цитата:
Дядя Миша писал: Вообще-то там мержится пвс лайта с пвс игрока.
Почему? Они же не связаны друг с другом. На этапе рендеринга в шадовмапу.
Частично проблему решает принудительный fullvis в R_SetupViewCache. Тени от решеток так и пропадают, а вот от стен вроде бы нет.
Я, кажется, нашел последнее звено, откуда Элбер тащил текстуры. Вы, может быть, удивитесь, но это Параграф 78.
Отправлено Дядя Миша 28-01-2021 в 09:01:
Цитата:
ncuxonaT писал: На этапе рендеринга в шадовмапу.
Так пропадает-то не тень, а весь свет? Там просто еще статический источник запечён в этом месте.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 28-01-2021 в 12:28:
Пропадает тень от некоторых фейсов, если их не видит игрок.
Отправлено Дядя Миша 28-01-2021 в 12:35:
Цитата:
ncuxonaT писал: Пропадает тень от некоторых фейсов, если их не видит игрок.
Кроме вот того момента на видео, на картах паранои еще много таких мест?
Добавлено 28-01-2021 в 15:34:
Освежил в памяти код шадовмаппинга, там нету стрёмных мест, функция использует тот же маркер, что и для обычного прохода, там просто не могут пропадать отдельные фейсы, т.е. баг скорее всего неверно классифицирован и сделаны неправильные выводы. Я поэтому тебя и подталкиваю к правильной мысли. Для начала надо определиться, что именно мы чиним.
Добавлено 28-01-2021 в 15:35:
Можно отключить pvs (r_novis 1) и посмотреть что из етова получится.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 28-01-2021 в 13:30:
Цитата:
Дядя Миша писал:
Кроме вот того момента на видео, на картах паранои еще много таких мест?
Все места с динамическими лайтами, где это можно было бы заметить.
Цитата:
Дядя Миша писал: Можно отключить pvs (r_novis 1) и посмотреть что из етова получится.
Чинится всё кроме решеток на p_savior9 (потому что они энтитя?)
r_novis 0 - теней от колонн нет, r_novis 1 - тени от колонн есть Отправлено Дядя Миша 28-01-2021 в 14:13:
А если в функции R_RenderShadowmaps
закомментировать проверку
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 28-01-2021 в 14:53:
Ничего не изменилось. И у директ лайтов такой проверки нет, а баг есть.
Отправлено Дядя Миша 28-01-2021 в 15:17:
Да оно и не должно было, это я так на всякий случай.
Ну тогда навскиду ничего не подскажу. И эта - директлайты в общую картину не включай, там свой механизм.
Может имеет смысл немного увеличить общий ббокс лайтов. Но вообще - странно, так быть не должно. В оригинале так же себя ведёт?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 22-02-2021 в 14:45:
Дядя Миша благодарю!
Отправлено ncuxonaT 26-02-2021 в 02:44:
Большинство ламп сделано моделями с фуллбрайт или люма текстурой. Есть ли какой-то относительно простой способ а) рендерить их в кубемапы вместе с миром, б) менять яркость мигающих лампочек вместе с соответствующим лайтстилем?
Отправлено Дядя Миша 26-02-2021 в 06:17:
Цитата:
ncuxonaT писал: рендерить их в кубемапы вместе с миром
gl_rmain.cpp:590
C++ Source Code:
// don't draw the entities while render skybox or cubemap
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 15-03-2021 в 14:59:
Дядя Миша не помнишь, что ты менял в коде фонаря у солдат? В версии 1.2 он светил нормально из аттачмента на голове, а в 1.51 светит под ноги и неадекватно вращается. Не могу понять по коду, к чему он цепляется вообще. Там есть строка pev->body = 3; //TESTTEST, но это же не аттачмент?
Отправлено Дядя Миша 15-03-2021 в 15:24:
Я саму систему аттачментов переделывал, а фонарик уже толком не тестил.
Да там ерунда какая-то, навряд ли что-то серъезное.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 24-03-2021 в 18:33:
Неа, не могу понять, где проблема. GetAngles у матриц точно правильный?
Добавлено 24-03-2021 в 21:33:
Оригин же верно считается. Может, кватернионы забрались куда не нужно?
Отправлено Дядя Миша 24-03-2021 в 18:47:
Визуализируй аттачменты во вьювере. Может у самих моделек прицел сбился. Куда смотрит вектор аттачмента, туда и будет направлен луч фонарика. Т.е. направление считается как normalize( bonepos - attachment )
У вспышек оружия-то маззлы верно направлены? Они тоже эту систему используют.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-03-2021 в 09:33:
Дядя Миша а ты сможешь запилить в Р2 физику, нетупящий ИИ и недёргающиеся анимации? Какие вообще характерные черты освещения в HL:A? Хорошо бы иметь какую-то техническую информацию. Анализа рендера кадра я в интернетах не нашел, а Вульва новых публикаций не выкладывала с 2016.
Кстати по поводу анимаций. Где взять пример модели с блендингами, ИК и прочими штуками? Я декомпилировал модель гмана из ксашхт, а обратно она не компилируется. В Р2 работает наложение анимаций? Если я хочу сделать, чтобы SMALL_FLINCH не прерывал текущую анимацию, а накладывался поверх неё, это реально вообще?
Зачем ты, кстати, звуки шагов НПЦ отключил прямо в коде?
Отправлено Дядя Миша 25-03-2021 в 09:42:
Цитата:
ncuxonaT писал: а ты сможешь запилить в Р2 физику, нетупящий ИИ и недёргающиеся анимации?
Так тыж теперь с ней ковыряешься, а не я
Цитата:
ncuxonaT писал: Где взять пример модели с блендингами, ИК и прочими штуками?
Ну например скомпилить любую модельку, которая предназначена для ХЛ2.
Цитата:
ncuxonaT писал: В Р2 работает наложение анимаций?
сам механизм есть, но он не подключен.
Цитата:
ncuxonaT писал: не прерывал текущую анимацию, а накладывался поверх неё, это реально вообще?
да, вполне.
Цитата:
ncuxonaT писал: Зачем ты, кстати, звуки шагов НПЦ отключил прямо в коде?
Помоему меня Элбер об этом попросил. А вообще не помню.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-03-2021 в 17:06:
Цитата:
Дядя Миша писал: Ну например скомпилить любую модельку, которая предназначена для ХЛ2.
В сдк у людей анимации отдельно, модели отдельно, ничего не компилируется. Есть готовый адаптированный образец модели для паранойи?
Отправлено Дядя Миша 25-03-2021 в 18:51:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 25-03-2021 в 19:57:
Дядя Миша неа
Отправлено Дядя Миша 25-03-2021 в 20:10:
Со мной этими моделями кто-то на CSM делился.
Я потом попробовал поискать их сорцы и удивился, что сорцы хл2 моделей в природе почти не встречаются, везде декмопил поганый.
Да, надо будет их выложить, напомни на выходных.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Luciferchik 25-03-2021 в 22:23:
Огромное спасибо ДМ <3 Жаль конечно, что я так поздно решил посетить форум ведь эти сорцы настоящий клондайк для модинга под старушку goldsrc.
__________________
Sometimes you have to get knocked down lower than you've even been to stand up taller than you everwere.
You so sad. No, i just die everyday...
I can't do anything around here without everybody getting up in my shit...
The aim of life is self-development.
Отправлено ncuxonaT 27-03-2021 в 11:53:
Дядя Миша выходные-выходные!
Отправлено Дядя Миша 27-03-2021 в 13:48:
Ага, выложу сегодня.
Кстати, я не помню, предлагал тебе уже или нет, насчёт того чтобы завести отдельную тему и там расписать какие ты поставил перед собой цели, что уже реализовал, а что планируешь. Было бы интересно почитать.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 28-03-2021 в 15:59:
Дядя Миша посмотрю, может сделаю тему. Только боюсь, что если распишу задачи, то в подсознании отложится, будто уже их выполнил, и в итоге делать вообще ничего не буду. За модели спасибо, буду разбираться.
Отправлено Дядя Миша 28-03-2021 в 16:42:
Цитата:
ncuxonaT писал: в подсознании отложится, будто уже их выполнил, и в итоге делать вообще ничего не буду
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено JPEG 28-03-2021 в 17:24:
Цитата:
Дядя Миша писал:
кстати известная проблема, если бы темы со скринами wip-разработки не было, то, вполне возможно, вышло бы больше готовых проектов) А так, пилишь что-то, хочешь поскорее доделать, поделиться с миром, выкладываешь скрин, его оценили и после этого уже часто пропадает мотивация доделывать, ведь уже как бы "получил лайк"
JPEG писал: А так, пилишь что-то, хочешь поскорее доделать, поделиться с миром, выкладываешь скрин, его оценили и после этого уже часто пропадает мотивация доделывать, ведь уже как бы "получил лайк"
Жиза, я ток спустя 6 лет разработки мода завел страницу на моддб, иначе бы еще дольше делал. Изначально вообще планировал выложить только уже готовый
Лично для меня главным демотиватором работы выступает факт, когда я не могу в голове заранее всё наперёд просчитать и точно знаю, что придётся вести итеративную разработку с двойной и тройной переделкой.
И наоборот - если в голове всё сложилось, могу несколько сотен строк кода за полдня набросать и оно заработает с первого же раза, так как и задумывалось.
ncuxonaT писал: Кстати во вьювере она еще и рендерится криво, хотя в игре нормально.
Когда в П2 происходят глюки рендеринга, где-то в модельвьювере грустит один НПС ncuxonaTAynekko у вас видеокарты какие? У меня на нвидиях всё всегда было нормально с п2.
Отправлено Aynekko 29-03-2021 в 07:13:
Цитата:
Ku2zoff писал: ncuxonaT Aynekko у вас видеокарты какие? У меня на нвидиях всё всегда было нормально с п2.
3070, до этого была 970, в ксаш моде один фиг все так же с фонариком. Вряд ли проблема в видюхе. В п2 я не замечал такого с персонажем, наверное не было такой ситуации (стоя с фонариком и близко).
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-03-2021 в 09:26:
Цитата:
Crystallize писал: ncuxonaT а чего она голову дергает вбок?
Вот такая беда в п2 с анимациями - то резко переключаются, то плавно, то дергается, то трясется. Пока что я хз, что с этим делать.
Цитата:
Ku2zoff писал: У меня на нвидиях всё всегда было нормально с п2.
Цитата:
Aynekko писал: В п2 я не замечал такого с персонажем, наверное не было такой ситуации (стоя с фонариком и близко).
У вас не было моделей с развесовкой. Если эту модель собрать без ключа $boneweights, глюков не будет.
Отправлено Дядя Миша 29-03-2021 в 10:49:
Я ж говорю, модель с развесовкой может потенциально по другому отсекаться лайт-фрустумом. Следует его вообще отключить для теста.
Или другой вариант - подменить модель Полины на гымена и сравнить, будут ли глюки там. Может быть дело в самой модели, что-то не так.
Цитата:
ncuxonaT писал: Кстати во вьювере она еще и рендерится криво
Принцип сортировки во вьювере и в рендере паранои отличается.
Добавлено 29-03-2021 в 13:49:
Цитата:
ncuxonaT писал: то резко переключаются, то плавно, то дергается, то трясется
ну это известный халфовский баг, просто в самой халфе он реже проявлется. Там в чём суть - когда меняется активность монстра, переключение анимации происходит через ACT_RESET, к которому никакая анимация не привязана. Вот лерпинг периодически и сходит с ума.
Причём в халфе это могло компенсироваться еще и тем фактом, что там был всего один блендинг с предидущей секвенцией, а в параное - с четырьмя последними. Т.е. оно пытается сблендится еще и с этим виртуальным ACT_RESET и скорее всего при этом секвенция -1.
Точнее не скажу, т.к. уже довольно давно этим занимался.
Но в прототипе NT 2015-го года я эту пакость успешно фиксил, правда с маленькой поправкой - там серверная часть всегда тикала с постоянным фпс 20.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-03-2021 в 10:54:
У развесованного пирогова тоже куски пропадают. И с r_nocull 1 глюка нет.
Отправлено Aynekko 29-03-2021 в 11:06:
Цитата:
Дядя Миша писал: Но в прототипе NT 2015-го года я эту пакость успешно фиксил, правда с маленькой поправкой - там серверная часть всегда тикала с постоянным фпс 20
А можно поинтересоваться, почему имнно это число? Что будет, если выставить 5 или 60, к примеру?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 29-03-2021 в 14:59:
Просто выкинуть ACT_RESET нельзя?
Отправлено Ku2zoff 29-03-2021 в 15:16:
Цитата:
Дядя Миша писал: Потому что 10 - маловато. А 20 хорошо делится и на 60 и на 100. Без остатка.
ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс. Дядя Миша насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс? И как себя в теории поведут физика и AI при клиентских фпс свыше 100? 120, 144, например? Не за горами момент, когда такие матрицы массово войдут в обиход. Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается. Из-за умножения на gpGlobals->frametime.
Отправлено Aynekko 29-03-2021 в 15:39:
Цитата:
Ku2zoff писал: Я уже где-то видел зависимость pev->yaw_speed от фпс - чем выше, тем медленнее монстр поворачивается.
В стим-версии халфы это уже пофиксили. Вроде благодаря Солокиллеру - брал код с гитхаба.
Помимо этого обратил внимание на пару других вещей - на высоких фпс функция Draw в худе быстрее выполняется (я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание). Повороты trigger_camera так же стали быстрыми - и там все тот же фреймтайм.
Из энумератора - конечно нельзя. Из механизма смены анимаций думаю можно, если ориентироваться на его устройство в хл2. Они там много багов посадили, но в хл2 это уже исправлено. С Кутузовым попробуй объединится, он много работал над монстрами, наверняка кое-что знает.
Цитата:
Ku2zoff писал: ЕМНИП, то в халфе как раз сервер тчинкает 10 раз в секунду, отсюда 10 серверных фпс.
в халфе клиент-сервер тикают одинаково.
Цитата:
Ku2zoff писал: насколько вважно, чтобы герцовка монитора (клиентский фпс) была кратной серверному фпс?
меньше ошибок накапливаться будет в дробной части. Хуже всего периодическая дробь.
Цитата:
Ku2zoff писал: Из-за умножения на gpGlobals->frametime.
Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Добавлено 29-03-2021 в 18:58:
Цитата:
Aynekko писал: я там двигаю один спрайт с помощью y +=1, поэтому обратил внимание
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Aynekko 29-03-2021 в 16:09:
Цитата:
Дядя Миша писал: Ну вот был бы там чисто серверный фреймтайм, так и не было бы проблемы.
Сейчас залез в код камеры и заменил ->frametime на 0.01
C++ Source Code:
vecAvel.x = dx * SnapSpeed * 0.01;
vecAvel.y = dy * SnapSpeed * 0.01;
vecAvel.z = 0;
Скорость камеры стала одинаковой (кажись) на всех фпс (сверял 60 и 240). Надо было раньше так сделать.
До этого еще смотрел, чему равен этот самый frametime. На 60 фпс он 0.0167, на 240 кажется 0.0045. Отсюда все эти разности в поведении…
Aynekko писал: я там двигаю один спрайт с помощью y +=1
Цитата:
Дядя Миша писал: у тебя код не time-based.
Aynekko умножай значение на клиентский фреймтайм или gHUD.m_flTimeDelta. Тогда при разных фпс спрайт будет проходить одинаковое расстояние за одинаковое время. Это типичная ошибка - что-то анимировать, считать или перемещать, используя фиксированные значения. Умножение на фреймтайм компенсирует погрешность при разной частоте кадров.
Добавлено 29-03-2021 в 23:22:
Цитата:
Aynekko писал: Скорость камеры стала одинаковой (кажись)
Где-то на гитхабе был фикс avelocity для камеры, погугли. Это из той же оперы, что и фикс yaw_speed для монстряков.
Добавлено 29-03-2021 в 23:24:
Цитата:
Aynekko писал: сверял 60 и 240
На 240 фпс матриц нет в природе. Они выдают 120-144, значения выше - фикция, матрица отвечает видимокарте и системе, что рисует 240, но по факту в два раза меньше. Чтобы нарот покупал "игровые" недобуки за космические ценники. Может быть, ситуация уже изменилась, и есть мониторы, которые выдают реальные 240 герц, но тут надо смотреть на тип матрицы. Цем лучше цветопередача - тем выше время отклика пикселя.
Отправлено Aynekko 29-03-2021 в 16:35:
Цитата:
Ku2zoff писал: Тогда при разных фпс спрайт будет проходить одинаковое расстояние за одинаковое время.
Ага, спасибо, сейчас помимо этого еще пофиксил плавный зум арбалета у себя. Несмотря на то, что у меня стоял nexthink = gpGlobals->time + 0.01, зум все равно был быстрее на больших фпс. Задал временную переменную, а think поставил просто каждый кадр и все пришло в норму.
Цитата:
Ku2zoff писал: Где-то на гитхабе был фикс avelocity для камеры, погугли.
Ku2zoff писал: На 240 фпс матриц нет в природе. Они выдают 120-144, значения выше - фикция
Это хорошая новость, ящитаю. А я задал этот порог на случай, если у кого-то будет такой моник. У меня так-то 75 Гц, но все равно тестирую очень высокий фпс на предмет всяких косяков.
Aynekko писал: помимо этого еще пофиксил плавный зум арбалета у себя
Плавный зум - устаревшая тема. Это было в Инвазионе, в XDM и ещё в нескольких модах. Намного интереснее комбинация ступенчатый зум (как в кс) с плавным изменением FOV. Типа как в первой Паранойе, но не на одно значение и ещё с возможностью приближать и отдалять колесом мыши.
Странно, что никто этого ещё не сделал. Если интересует, напишу тутор.
Отправлено ncuxonaT 29-03-2021 в 16:56:
Ku2zoff давай объединяться по анимациям. И ИИ.
Цитата:
Ku2zoff писал: Это типичная ошибка - что-то анимировать, считать или перемещать, используя фиксированные значения. Умножение на фреймтайм компенсирует погрешность при разной частоте кадров.
Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования. Лучше считать с постоянным шагом, а промежуточные значения интерполировать. Кажется, мы это уже обсуждали.
Отправлено Дядя Миша 29-03-2021 в 17:23:
Цитата:
ncuxonaT писал: Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования.
надо менять саму архитектуру движка значит. Иначе никак.
Изменения не особенно сложные, но потом долгое время будет лезть всякое мелкое говно.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 30-03-2021 в 06:31:
Цитата:
ncuxonaT писал: Не надо умножать на фреймтайм, это же будет переменный шаг интегрирования.
Как интегрирование связано с физикой-движением? Этому где-то учат? У меня после института осталось впечатление что интегрирование-дифференцирование суть математический фокус поприколу.
Отправлено ncuxonaT 31-03-2021 в 02:56:
Crystallize в школе же проходят, что перемещение - это интеграл скорости по времени, а скорость - это интеграл ускорения по времени. Очень странное впечатление у тебя об интегралах
Отправлено Crystallize 31-03-2021 в 03:26:
ncuxonaT В школе мы проходили что скорость-время-расстояние, и ещё производные в 10 или 11 классе. А первообразные пошли не раньше 2 курса института. Это то что я помню более-менее точно. Не помню чтобы матан кто-то связывал с реальными физическими величинами. Ну т.е. может там и была в учебнике фраза про интеграл скорости по времени, но ведь надо понимать суть интегрирования, интегрирования по времени и т.д. Я не помню чтобы мы, скажем, брали уравнение движения объекта, и через интегрирование находили перемещение.
Отправлено ncuxonaT 01-04-2021 в 14:46:
Crystallize ну не знаю, вот Мордкович за 10-11 класс, он объяснение первообразных начинает с уравнения движения https://naurok.su/urok/algebra/10/014/281.html . Может, если бы при обучении матану больше времени уделяли практическому применению, он был бы не таким унылым. Вообще я периодически читаю какие-то статьи по программированию графики, и там везде интегралы. Правда, они по большей части не вычисляются аналитически, только численными методами.
В П2 баги с дробовиком - при переключении с него на любое другое оружие появляется мазлфлеш, даже с длайтом и дымом. Помимо этого, если попытаться выстрелить во время перезарядки при отсутствии патронов в магазине, то анимация перезарядки начинает проигрываться с начала. Это всё нужно фиксить в коде, в скриптах или в самой модели? Заметил, что у декомпилированных вьюмоделей у каждой секвенции прописана активити вида ACT_число. Это имеет какой-то смысл или просто прикол декомпилятора?
Отправлено Дядя Миша 01-04-2021 в 15:48:
Цитата:
ncuxonaT писал: Это всё нужно фиксить в коде, в скриптах или в самой модели?
Хороший вопрос. Код для всех оружий в параное один. Но этот код ориентируется на акты в самой модели, т.е. меняет поведение.
Может быть и в ней дело.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено avegamer 17-04-2021 в 18:53:
Интересная новость. А по другому можно увидеть исходники? Просто некогда строчить сообщения
Отправлено ncuxonaT 01-05-2021 в 22:21:
Цитата:
Дядя Миша писал: gl_rmain.cpp:590
C++ Source Code:
// don't draw the entities while render skybox or cubemap
if( !FBitSet( RI->params, ( RP_ENVVIEW|RP_SKYVIEW )))
{
надо как-то видоизменить условие, пропускать отдельные модели в рендеринг кубемапы.
Убрал условие, в кубемапу рендерятся только те модели, что видит камера игрока. Как это починить? Добавил проверку на RP_CUBEPASS в Mod_CheckBoxVisible и R_CullBox, но не помогло.
Отправлено Дядя Миша 02-05-2021 в 04:35:
ncuxonaT для начала сделай r_nocull 1, r_novis 1, sv_novis 1, потом rebuildcubemaps и посмотри что получится.
Потом выключай квары по одному и найди тот, который влияет.
А потом я что-нибудь подскажу.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 02-05-2021 в 14:04:
Дядя Миша sv_novis 1 влияет. С ним модели рендерятся, и даже тени от решеток перестают пропадать.
Отправлено Дядя Миша 02-05-2021 в 14:30:
Значит с сервера не успевает прийти пакет обновления, хотя виз и выключается. Это в движке. Может надо сделать больше отсрочку, не 1 клиентский кадр, а 3-5.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 02-06-2021 в 22:54:
Мутные стекла по мотивам дума
Отправлено ncuxonaT 02-08-2021 в 23:28:
Иногда паранойя вылетает при запуске со словами
code:Console initialized.
Mem_Free: not allocated or double freed (free at C:\xash_source\engine\common\filesystem.c:1261)
Sys_FreeLibrary: Unloading xash.dll
Это чё хоть такое тоооо? На той строчке в FS_ReadGameInfo Mem_Free( afile );
Почему в одном случае из двадцати с этим возникают проблемы?
Отправлено KorteZZ 03-08-2021 в 00:45:
Цитата:
ncuxonaT писал: Мутные стекла по мотивам дума
Блин, классно! Атмосфера загадочной и трагичной лаборатории меня всегда привлекала
SNMetamorph писал: А можно просто сразу в пиксельном шейдере блюрить в зависимости от шероховатости? Какие подводные?
Можно, но нужно много семплов, иначе мутные стекла будут шуметь. Вариант с мипами, как правило, быстрее. Если бы в паранойе стекла батчились, а не рисовались по одному, то мипы были бы однозначно быстрее.
Отправлено Crystallize 04-08-2021 в 01:15:
ncuxonaT Спасибо!
Отправлено Дядя Миша 04-08-2021 в 06:16:
Цитата:
ncuxonaT писал: просто заменить одно на другое с указанием MAX_STRING?
Можно, но лучше использовать sizeof( string ), где string - имя переменной в которую пишется конечная строка. Ну или по крайней мере убедиться, что везде, где ты меняешь это дело, размер строки реально равен MAX_STRING.
Цитата:
ncuxonaT писал: Если бы в паранойе стекла батчились, а не рисовались по одному
Стёкла не могут батчиться, для каждого стекла делается новая копия экрана.
Ну хоть бы подумал сначала.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 04-08-2021 в 06:33:
Crystallize 👍🏿
Цитата:
Дядя Миша писал: Стёкла не могут батчиться, для каждого стекла делается новая копия экрана.
Ну хоть бы подумал сначала.
Надо группировать неперекрывающиеся стекла и делать им общую копию. Можно наверное софтварно проецировать треугольники в экранные координаты и проверять на пересечение.
Отправлено Дядя Миша 04-08-2021 в 06:41:
Цитата:
ncuxonaT писал: Надо группировать неперекрывающиеся стекла и делать им общую копию
Даже если мы с гарантией уверены, что нашли такие стёкла, нам надо записать в буффер экрана несколько обновлённых копий. А сделать это можно только чередой последовательных вызовов subImage. Далее, стекло, это практически всегда квадрат, два треугольника. Полигонаж стёкол на экране редко когда превышает 100-200 треугольников. А для такого кол-ва батчинг просто бессмыслица, ты не увидишь никакой разницы абсолютно.
Добавлено 04-08-2021 в 09:41:
Цитата:
ncuxonaT писал: Можно наверное софтварно проецировать треугольники в экранные координаты и проверять на пересечение.
Именно так сейчас и происходит. Копии делаются для квадов, а не для треугольников, если ты не заметил.
Для студиомоделей и вовсе делается один вызов для всего меша, например если это шлем на голове NPC.
Ну включи r_scissor_glass_debug 1
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 04-08-2021 в 08:33:
Цитата:
ncuxonaT писал: 👍🏿
два квадрата
Отправлено ncuxonaT 04-08-2021 в 15:13:
Crystallize браузер или ОС не поддерживают эмодзи. Там было
Дядя Миша ну ты думай ширше. Каждое стекло - это не только копирование экрана (glCopyTexSubImage2D клампит в 0-1, поэтому только glBlitFramebuffer, только хардкор), это еще блюр мипов. В паранойе большинство стекол, которые можно было бы копировать/блюрить за один раз, разбиты на 33 куска. И ААВВ в экранном пространстве у этих кусков естественно будут перекрываться.
Отправлено Дядя Миша 04-08-2021 в 18:05:
Цитата:
ncuxonaT писал: браузер или ОС не поддерживают эмодзи
а я эту хрень кстати вижу.
Цитата:
ncuxonaT писал: это еще блюр мипов
Не понял. А зачем блюрить мипы?
Цитата:
ncuxonaT писал: которые можно было бы копировать/блюрить за один раз, разбиты на 33 куска.
их можно при загрузке клеить в группы и подсчитать для них локальный AABB.
Вариант да. Впрочем на третьем скрине лучше ничего не клеить.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 04-08-2021 в 22:39:
Цитата:
Дядя Миша писал:
Не понял. А зачем блюрить мипы?
Чтобы делать мутные стекла.
Кстати у моделей с развесовкой проблемы не только с динамическим освещением, но и со скиссором для стекол. Куда копать? Отправлено Crystallize 05-08-2021 в 02:56:
Цитата:
ncuxonaT писал: Crystallize браузер или ОС не поддерживают эмодзи. Там было
Хром последний и семерка
Цитата:
Дядя Миша писал: а я эту хрень кстати вижу.
На Опере 12?
Отправлено Дядя Миша 05-08-2021 в 05:29:
Цитата:
ncuxonaT писал: Чтобы делать мутные стекла.
Так мип уже предполагает некий разблюр за счёт даунскейла.
Цитата:
ncuxonaT писал: Куда копать?
либо в MeshCreateBuffer, где AABB конструируется, надо вертексы предварительно умножать на матрицу кости, либо уже при трансформации во время рендеринга. А может и там и там.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 05-08-2021 в 16:59:
Цитата:
Дядя Миша писал: либо в MeshCreateBuffer, где AABB конструируется, надо вертексы предварительно умножать на матрицу кости, либо уже при трансформации во время рендеринга. А может и там и там.
ААВВ считается при загрузке, а потом трансформируется? Даже без развесовки, если у меша больше одной кости, это не будет нормально работать. Отправлено Дядя Миша 05-08-2021 в 18:34:
Цитата:
ncuxonaT писал: Даже без развесовки, если у меша больше одной кости, это не будет нормально работать.
Оно лезет вверх по иерархии, пока не найдет родительскую кость.
Так что моделлер может это контролировать.
Цитата:
ncuxonaT писал: ААВВ считается при загрузке, а потом трансформируется?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 05-08-2021 в 19:54:
Тогда надо в MeshCreateBuffer пробежать по всем анимациям, чтобы получить максимальный ААВВ. Либо хранить отдельный ААВВ на каждый кадр каждой анимации.
Добавлено 05-08-2021 в 22:54:
Цитата:
Дядя Миша писал: Так мип уже предполагает некий разблюр за счёт даунскейла.
Это будет выглядеть вот так Отправлено Дядя Миша 06-08-2021 в 06:40:
Цитата:
ncuxonaT писал: Тогда надо в MeshCreateBuffer пробежать по всем анимациям, чтобы получить максимальный ААВВ. Либо хранить отдельный ААВВ на каждый кадр каждой анимации.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 15-08-2021 в 11:08:
Цитата:
Дядя Миша писал: Можно, но лучше использовать sizeof( string ), где string - имя переменной в которую пишется конечная строка. Ну или по крайней мере убедиться, что везде, где ты меняешь это дело, размер строки реально равен MAX_STRING.
Корочи, это не помогло, всё равно вылетает. Да и непонятно, как могло помочь, вылетает же не на записи строки, а на Mem_Free( afile ).
Отправлено Дядя Миша 19-08-2021 в 11:08:
Так товарищи. Через 11 дней йубилей - ровно год со дня обнародования исходников P2:Savior. Надеюсь у вас уже есть что показать к этой дате.
Свежих скриншотов или хотя бы геймплейного видео?
А то может и демкой порадуете
Добавлено 19-08-2021 в 14:08:
ncuxonaT по поводу вылета - слишком мало информации. На ванильной п2 вылетает? И если да, то при каких условиях.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено SNMetamorph 19-08-2021 в 17:39:
Цитата:
Дядя Миша писал: Так товарищи. Через 11 дней йубилей - ровно год со дня обнародования исходников P2:Savior. Надеюсь у вас уже есть что показать к этой дате.
Свежих скриншотов или хотя бы геймплейного видео?
А то может и демкой порадуете
Добавлено 19-08-2021 в 14:08:
ncuxonaT по поводу вылета - слишком мало информации. На ванильной п2 вылетает? И если да, то при каких условиях.
Сегодня мне показали первую параною, переведённую на прайм с рендером п2. Позже залью видео сюда
SNMetamorph писал: ncuxonaT по поводу вылета - слишком мало информации. На ванильной п2 вылетает? И если да, то при каких условиях.
Оно так редко вылетает, что про ванильную пока ничего сказать не могу. Если поймаю вылет, то напишу.
Я хочу лампочкам енв_статикам прописать лайтстили, чтобы они мигали вместе с соответствующими им лайтами. В какое поле лучше записать, в iuser4?
Отправлено Дядя Миша 19-08-2021 в 22:20:
Цитата:
ncuxonaT писал: Оно так редко вылетает, что про ванильную пока ничего сказать не могу. Если поймаю вылет, то напишу.
Это вероятно тот самый гейзенбаг, о котором так долго твердили большевики. Вылет в движке, как-то связан с логом.
Условия появления:
1. Только на P2
2. Только в режиме -dev (без -dev или в режиме -dev 2 не проявляется).
Возникает на самом начальном этапе инициализации.
Я так и не понял, что это такое, и откуда взялось, но это точно связано с ведением лога.
Цитата:
ncuxonaT писал: Я хочу лампочкам енв_статикам прописать лайтстили, чтобы они мигали вместе с соответствующими им лайтами
Имеешь в виду, чтобы лампочки освещали только эти статики и больше ничего?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 19-08-2021 в 22:47:
Цитата:
Дядя Миша писал: Имеешь в виду, чтобы лампочки освещали только эти статики и больше ничего?
Нет, чтобы яркость люма текстуры менялась вместе с лайстилем.
Отправлено Crystallize 20-08-2021 в 01:37:
Цитата:
Дядя Миша писал: Так товарищи. Через 11 дней йубилей - ровно год со дня обнародования исходников P2:Savior. Надеюсь у вас уже есть что показать к этой дате.
Свежих скриншотов или хотя бы геймплейного видео?
В пандемию два года идёт за год, окстись.
Отправлено Дядя Миша 20-08-2021 в 07:30:
Цитата:
ncuxonaT писал: Нет, чтобы яркость люма текстуры менялась вместе с лайстилем.
так у тебя же лайтстиль и так уже есть в шейдере. Зачем городить огород?
Цитата:
Crystallize писал: В пандемию два года идёт за год, окстись.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 20-08-2021 в 07:52:
Дядя Миша пражыл. Я ещё с конца 2019 делал диплом так что оно всё ощущается как один бесконечный долгий год.
Отправлено [CFR] B@N@N 20-08-2021 в 10:28:
Тогда зачем транслируеш свои мироощущения на других?
Вообще лучше для проэкта лучше брать более современные движки там гораздо больше много всяких возможностей и они лучше проработаны. В этих же проэктах попадается много багов
Отправлено ncuxonaT 20-08-2021 в 10:43:
Цитата:
Дядя Миша писал: так у тебя же лайтстиль и так уже есть в шейдере. Зачем городить огород?
Какой ещё лайтстиль у меня в шейдере?
Отправлено Дядя Миша 20-08-2021 в 11:30:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 20-08-2021 в 11:42:
Мне нужно прописать моделям лампочек номер лайстиля, чтобы они мигали. Всё, что сейчас есть в шейдере, для этого не подходит.
Могу ли я передавать номер лайтстиля env_static через iuser4? Если нет, то через что могу?
Отправлено Дядя Миша 20-08-2021 в 12:22:
Я не буду пытаться вникать в то, что ты там задумал, раз ты так этого не хочешь, но обращу внимание, что на клиенте в функции GL_InitModelLightCache происходит парсинг настроек энв_статиков и стиль можно взять сразу оттуда, вместо того, чтобы городить какие-то костыли с передачей по сети.
Добавлено 20-08-2021 в 15:22:
Цитата:
ncuxonaT писал: номер лайтстиля env_static
Один вопрос всё же задам. Откуда у статиков взялся номер лайтстиля?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 20-08-2021 в 12:39:
Цитата:
Дядя Миша писал: Откуда у статиков взялся номер лайтстиля?
Пропишу его руками. Заведу у энтити поле style, как у лайтов, пропишу там номер, в effects.cpp добавлю у CEnvStatic, чтобы это поле считывалось. Дальше надо, чтобы оно передавалось. Номер лайткеша ты передаешь через pev->colormap, я пытаюсь аналогично передать через pev->iuser4, но это не работает.
Отправлено Дядя Миша 20-08-2021 в 13:32:
Цитата:
ncuxonaT писал: я пытаюсь аналогично передать через pev->iuser4, но это не работает.
Дак с чего же ему работать, если ты в delta.lst строчки не отсортировалпрописал.
Цитата:
ncuxonaT писал: Пропишу его руками. Заведу у энтити поле style, как у лайтов, пропишу там номер, в effects.cpp добавлю у CEnvStatic, чтобы это поле считывалось
Сорцы XDM вдоль и поперёк перепаханы, за 20 лет переписано всё, даже то, что нет смысла переписывать. В итоге, самая стабильная версия 3.0.3.4 от 2007-го что ли года. Последняя 3.0.3.8 глючит то там, то здесь. Тот самый случай, когда код пишется ради написания кода. Конечно, в некоторых моментах 3.0.3.8 заметно продвинутее, нежели 3.0.3.4, но все эти добавки можно было внести не так радикально. Интересующиеся могут сравнить RenderSystem, какой она была и какой стала. Визуальных отличий немного, а вот быстродействие и стабильность пострадали. Но это мой опыт, возможно, у кого-то новая версия не вылетает, и снег в ней просаживает фпс.
Добавлено 21-08-2021 в 22:15:
Цитата:
ncuxonaT писал: Чтобы лампочки мигали же. И выключались.
А что, вторая паранойя унаследовала от первой те самые два состояния "лампочка светит" и "лампочка не светит"? Я точно помню, что лумпы лайтстилей (или что там) в бсп в первой части заняты под бамп, поэтому создать мигающие/мерцающие/угасающие источники средствами компилятора невозможно, онли динлайты. А вот включаемые/выключаемые вроде бы можно делать, поправьте, если я ошибся. BUzer мог бы сделать сохранение этой инфы hlrad'ом во внешний файл, который потом грузил бы кастомный рендерер. Но, похоже, команда посчитала, что особой надобности в лайтстилях нету, и никто не стал морочиться. На мой взгляд, мигающее освещение добавило бы мрачности, учитывая, что добрую половину мода игрок шарится в подземной лаборатории.
Отправлено Дядя Миша 21-08-2021 в 15:55:
Нет, во второй Параное нормальные лайтстили с бампом. Всё работает.
И на моделях тоже.
Дядя Миша писал: во второй Параное нормальные лайтстили с бампом. Всё работает.
А почему тогда у ncuxonaT'а возникли с этим трудности, что он даже полез в дельту и взялся за иузеры/фузеры/вузеры?
Отправлено ncuxonaT 21-08-2021 в 16:34:
Ku2zoff потому что психопат хотел, чтобы светящаяся текстура модели мигала вместе с лайтстилем
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 21-08-2021 в 18:48:
Дядя Миша всё без повертексного
Отправлено Дядя Миша 21-08-2021 в 18:53:
Лампочка энв_моделью сделана? Можно попробовать отредактировать лумп энтить, пересобрать свет, чтобы появилось повертексное и лайтстили.
Это более муторно, но и более корректно, чем такие хаки.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 21-08-2021 в 19:48:
Откуда повертексное освещение узнает, где на модели лампочка, которая должна ярко светиться?
Отправлено Дядя Миша 21-08-2021 в 20:17:
Повертексному освещению этого знать как раз-таки и не надо.
Достаточно того, что полигоны колбы получат нужный лайтстиль.
И для фуллбрайт-поверхностей ты сможешь его использовать.
Только лайтстиль-фактор, игнорируя яркость свечения.
Понял мысль?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 21-08-2021 в 20:30:
Это настолько неудобно, геморройно и негибко, что я даже не знаю, что сказать. Ради одного значения лайстиля городить такой огород.
Отправлено Дядя Миша 21-08-2021 в 21:36:
Огород уже нагорожен. Всё что требуется - это лампочки сделать статиками (насколько я помню, сейчас они env_model). Ну и в шейдере дописать немного кода.
Цитата:
ncuxonaT писал: Ради одного значения лайстиля городить такой огород
Вот смотри, ради одной лампочки на всю игру, ты заюзал важную сетевую переменную, которых и так ограниченное кол-во.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 21-08-2021 в 21:59:
Цитата:
Дядя Миша писал: Огород уже нагорожен. Всё что требуется - это лампочки сделать статиками (насколько я помню, сейчас они env_model). Ну и в шейдере дописать немного кода.
Сначала отредактировать модели, повесив светящейся колбе отдельную текстуру, чтобы выставить ей флаг фуллбрайт. Потом непонятным образом записать в повертексное освещение значение лайстиля (если просто запечь освещение, получится хрень), да еще тащить с собой само повертексное освещение. Чем это лучше важной сетевой переменной, которая все равно нигде не используется?
Отправлено Дядя Миша 22-08-2021 в 08:36:
Модельку по хорошему всё равно надо переделывать, разделить нить накала и колбу, сейчас одним мешем сделано.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено SNMetamorph 22-08-2021 в 14:22:
Почему для стёкол используются именно скринкопии? В ксашмоде вроде и без них стекла рендерились вполне нормально. Сейчас на карте hg_industrialzone ловлю 460 скринкопий при 30 фпс на GTX 1050
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 22-08-2021 в 15:42:
Я думал, это только для стекол с нормалмапой сделано. В чем проблема наложить освещение при блендинге?
Отправлено Дядя Миша 22-08-2021 в 15:53:
Нет доступа к правильному порядку умножения. Впрочем есть еще мультипроходной способ, Кармак так стёкла лайтмаппил в ку3, но проблема в том, что это нельзя сделать внутри одного шейдера, это способ для фиксированного конвейера. Вот и приходится заниматься подобными вещами.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 22-08-2021 в 17:00:
Хм, вроде бы можно за один проход, если стекло transparent или multiply. В смысле, не прокатит вариант с комбинациями, чтобы вот тут было просто прозрачное, а тут с умножением.
Отправлено Дядя Миша 22-08-2021 в 17:57:
Сделать можно, ктож спорит. Выглядеть будет некорректно.
Допустим мы задаём бленд-мод. Это значит железка смешивает пиксели за стеклом с пикселями текстуры стекла и получившееся значение мы умножаем на лайтмапу. А нам надо сперва умножить пиксели текстуры стекла на лайтмапу и потом смешать с пикселями за стеклом.
И вот этот порядок на x86 ты никак иначе не провернёшь, кроме как через копию экрана. Как бы ты не смешивал стекло с тем, что сквозь него видно, это не имеет ровным счётом никакого значения, потому что меняется порядок сложения\умножения.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 22-08-2021 в 18:22:
Эээ. Железка смешивает пиксели за стеклом с тем, что вышло из шейдера (gl_FragColor). Текстура стекла умножается на лайтмапу в шейдере, по желанию прибавляется спекуляр с модификацией альфы. Больше никуда ничего не умножается.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Cybermax 22-08-2021 в 18:42:
Залил на https://gamebanana.com/games/12828 всё что касается П2, зачем не знаю, может ради того, чтобы было откуда скачать если что, может чтобы привлечь внимание народа. Там раньше был раздел про П2 https://gamebanana.com/games/5539 но его выпилили. Для описания тупо использовал гугл транслейт с ссылкой на тему форума. Полезно для привлечения модеров - написать Ксаш-Параноя-2 оружейная система руководство, о том как писать конфиги, что прописывать в qc файлах моделей.
Отправлено ncuxonaT 25-08-2021 в 16:14:
Что-то неладное в паранойе со временем. Дёргаются не только анимации у моделей, но даже искры.
Это движковый баг, где-то в коде интерполяции там со временем беды, что бывало даже проскакивали кадры с отрицательным фреймтаймом. Погляди мои коммиты в FWGS ксаше, я это фиксил.
Добавлено 25-08-2021 в 23:07:
А ещё, там в дельте был баг с полями с типом DT_TIMEWINDOW, из-за него у энтить скакал animtime сильно и анимации были отвратные. Это тоже в FWGS пофикшено не так давно.
Объясните, в чем смысл этого условия? Почему нельзя просто умножить?
Отправлено SNMetamorph 25-08-2021 в 20:16:
Цитата:
ncuxonaT писал: Объясните, в чем смысл этого условия? Почему нельзя просто умножить?
Приколы с представлением вещественных чисел в компьютерах.
Если к примеру у нас изначально было в переменной записано число 10.0, и мы например его разделили на 2, а зачем умножили на 2, то если где-то далее в коде будет проверка типа "число == 10.0" то остаётся лишь гадать, сработает она или нет, поэтому чтобы таких неопределенностей не возникало, проверяют не равенство между числами, а вхождение числа в какой-то маленький числовой диапазон.
SNMetamorph это я понимаю. Я не понимаю, почему нельзя просто умножить на единицу, ничего не сравнивая.
Отправлено SNMetamorph 26-08-2021 в 06:44:
Цитата:
ncuxonaT писал: Я не понимаю, почему нельзя просто умножить на единицу, ничего не сравнивая.
Насколько я помню, чтобы лишний раз не трогать флоаты вообще. Понятно, что при умножении на единицу получится то же самое число, но побитово переменная вполне себе может поменяться как-то, и тогда дельта заметит изменение и отправит это число, хотя т.к. фактически оно не изменилось, этого можно было бы и не делать.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 26-08-2021 в 13:46:
Цитата:
Дядя Миша писал: Вещественное с плавающей точкой хранит не значение, а выражение, грубо говоря. Ну чтобы тебе было понятнее, 4 * 12 = 48 и 6 * 8 = 48.
Согласно стандарту, одно и то же число всегда будет записано одинаково.
"Некоторые числа могут иметь несколько представлений в формате, в котором они были только что описаны. Например, если b = 10 и р = 7, то число −12,345 может быть представлено как: −12345 × 10−3, −123450 × 10−4 или −1234500 × 10−5.
Для десятичных форматов любое представление справедливо, и совокупность этих представлений называется когортами. Когда результат может иметь несколько представлений, стандарт определяет, какой выбран членом когорты.
Для бинарных форматов представление делается уникальным путём выбора наименьшего представляемого показателя. Для чисел с показателем в нормальном диапазоне (не все из них или все нули), ведущий бит мантиссы всегда будет равен 1. Следовательно, ведущий 1 бит может подразумеваться, а не сохраняться явно в памяти. Это правило называется ведущей битной конвенцией или скрытой битной конвенцией. Правило позволяет сберечь 1 бит памяти, чтобы иметь ещё один бит точности. Ведущий бит конвенции не используется для субнормальных чисел; их показатель находится за пределами нормального диапазона значений. "
Отправлено SNMetamorph 26-08-2021 в 15:46:
Цитата:
Дядя Миша писал: Для того же, для чего и в Халфе - сохранять информацию между уровнями.
Но оно в данном случае хранит кастомную информацию не для конкретных энтить, а просто какой-то глобальный стейт?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 26-08-2021 в 18:25:
Цитата:
Дядя Миша писал: Это вероятно тот самый гейзенбаг, о котором так долго твердили большевики. Вылет в движке, как-то связан с логом.
Условия появления:
1. Только на P2
2. Только в режиме -dev (без -dev или в режиме -dev 2 не проявляется).
Возникает на самом начальном этапе инициализации.
Я так и не понял, что это такое, и откуда взялось, но это точно связано с ведением лога.
Поймал вылет на ванильной паранойе, запускал с параметрами -console -log +sv_cheats 1 -dev 7
code:
=================================================================================
Xash3D 0.99 (build 4511) started at Aug26 2021 [21:22.42]
=================================================================================
Console initialized.
Mem_Free: not allocated or double freed (free at D:\Xash3D\src_main\engine\common\filesystem.c:1261)
Отправлено SNMetamorph 27-08-2021 в 17:37:
Зачем в шейдерах в texfetch.h в функции normalmap2D инвертируется Y-координата нормали?
Cg Pixel Shader:
N.y = -N.y; // !!!
N = normalize( N );
Добавлено 27-08-2021 в 21:37:
Цитата:
SNMetamorph писал: Зачем в шейдерах в texfetch.h в функции normalmap2D инвертируется Y-координата нормали?
Cg Pixel Shader:
N.y = -N.y; // !!!
N = normalize( N );
Ага. Без этой инверсии нормалка начинает выглядеть неправильно.
Также, параллакс маппинг не заработал нормально, пока я в viewDir векторе не инвертировал Y координату. Это уже получается какая-то проблема типа SQB, только с TBN в шейдерах. Получается, TBN как-то не совсем правильно строится?
Это еще с даркплейса тянется. Для паранои первую версию компиляторов делал китаец (Кастомный VHLT). Я предложил ему взять имплементацию делюкс-маппинга из Darkplaces. Просто, чтобы иметь возможность контролировать контент под сторонним движком (и кстати я этим активно пользовался на начальных этапах). А там тангента инвертирована почему-то была. Ну вот и пришлось так всё оставить.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 27-08-2021 в 18:15:
SNMetamorph потому что в паранойе нормалмапы были вразнобой, половина в директикс спейсе, половина в опенгл спейсе.
Инвертирование было попыткой сделать так, чтобы большая часть нормалмап выглядела правильно.
Плюс у моделей неправильно строится TBN в случае отзеркаленной развертки.
Вроде я это исправил, в gl_studio_init.cpp строчки 1524 и далее:
C++ Source Code:
1
if( !smooth_tbn )
2
{
3
Vector tmpVect = CrossProduct( sVect, tVect );
4
bool leftHanded = DotProduct( tmpVect, normal ) < 0.0f;
5
6
if( !leftHanded )
7
{
8
tVect = CrossProduct( normal, sVect );
9
sVect = CrossProduct( tVect, normal );
10
}
11
else
12
{
13
tVect = CrossProduct( sVect, normal );
14
//sVect = CrossProduct( normal, tVect );
15
//nc fix?
16
sVect = CrossProduct( tVect, normal );
17
}
18
}
И для нормалмап в опенгл спейсе инвертирование игрека не нужно, если что.
Отправлено Дядя Миша 27-08-2021 в 18:18:
ncuxonaT Элбер текстуры брал с разных игр. Во всех этих играх совпадает стандарт? Или тоже вразнобой?
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено SNMetamorph 27-08-2021 в 18:26:
Цитата:
ncuxonaT писал: SNMetamorph потому что в паранойе нормалмапы были вразнобой, половина в директикс спейсе, половина в опенгл спейсе.
Инвертирование было попыткой сделать так, чтобы большая часть нормалмап выглядела правильно.
Плюс у моделей неправильно строится TBN в случае отзеркаленной развертки.
Вроде я это исправил, в gl_studio_init.cpp строчки 1524 и далее:
C++ Source Code:
1
if( !smooth_tbn )
2
{
3
Vector tmpVect = CrossProduct( sVect, tVect );
4
bool leftHanded = DotProduct( tmpVect, normal ) < 0.0f;
5
6
if( !leftHanded )
7
{
8
tVect = CrossProduct( normal, sVect );
9
sVect = CrossProduct( tVect, normal );
10
}
11
else
12
{
13
tVect = CrossProduct( sVect, normal );
14
//sVect = CrossProduct( normal, tVect );
15
//nc fix?
16
sVect = CrossProduct( tVect, normal );
17
}
18
}
И для нормалмап в опенгл спейсе инвертирование игрека не нужно, если что.
Вроде понял, а вроде и нет. Ведь в случае с параллаксом я вообще нормалмапы не юзаю, а для корректного результата делать инвертирование все же приходится. Т.е. что-то не так с TBN внутри шейдера. Я думаю, нужно что-то в самом TBN поменять, чтоб не приходилось везде ставить инверсии.
Дядя Миша Элбер большую часть нормалмап генерировал сам из диффуза каким-то суперуродским способом, что всё покрывалось мерзким шумом. А из тех игр, откуда он брал, только в параграфе 78 нормали вразнобой, в остальных вроде бы всё прилично.
SNMetamorph на мировых полигонах TBN тоже как-то не так считается при отзеркаленной развертке, возможно, параллакс к этому чувствителен. Можешь сделать карту с двумя стенами, чтобы на одной текстура была слева направо, а на другой справа налево? Параллакс на обеих будет одинаково работать, или на одной чудить?
Отправлено Дядя Миша 27-08-2021 в 19:13:
Разница в освещении будет заметна, естественно. Но на рельеф нормалмапа не влияет.
А как в П2 рендере сделано, что на картах которые собраны п2шным компилятором с включенным динамическим солнцем улица корректно затемняется полностью? А при этом то, что в помещении, и лампы, остаётся светлым? По идее же эмбиент должен вообще всё освещение на локации затрагивать, и должно темнеть все, кроме динлайтов.
TBN для декалей строится из текстурных координат декали, с TBN браша он не совпадает, поэтому вектор из делюксмапы для декали не валидный, так?
Отправлено Дядя Миша 27-09-2021 в 10:19:
Нормаль совпадает, этого достаточно.
Добавлено 27-09-2021 в 13:19:
Для умножения делюксмапы на нормалмапу TBN вообще не используется, поскольку оба-два находятся в локальном текстурном пространстве.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 27-09-2021 в 10:31:
Цитата:
Дядя Миша писал:
Для умножения делюксмапы на нормалмапу TBN вообще не используется, поскольку оба-два находятся в локальном текстурном пространстве.
У брашей да, так как делюксмапа записана в касательном пространстве браша. Но у декалей-то свой TBN, своё касательное пространство.
Отправлено Дядя Миша 27-09-2021 в 12:26:
Я же говорю, самое главное, что плоскости совпадают. У браша и у декали.
Добавлено 27-09-2021 в 15:26:
Я тут посравнивал наложение одних и тех же декалей под разными углами.
Ну что можно сказать. У большинства декалей в параное нормалей нет, следовательно там это неактуально. Там где нормали есть, рельеф как правило слабовыражен и в глаза это не бросается. Единственное где это будет заметно - декали с параллаксом. Но в оригинале их нет, а я своё время так и не успел доделать этот механизм.
Можно оба текстурных пространства привести обратно в модельное и умножать уже там. Тогда будет правильно.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 27-09-2021 в 13:00:
Еще будет заметно на декалях со спекуляром
Отправлено Дядя Миша 27-09-2021 в 13:06:
"Дешевый" вариант - выровнять наложение декали по основной текстуре, как в халфе сделано. Правда для табличек это не всегда подходит.
Иначе придётся в вертекс передавать два касательных.
Можно передать два общих TBN через юниформы, но это нежелательно, т.к. декаль необязательно покрывает плоскость. Иногда она заворачивается на углы до 45 градусов, т.к. там проекция. Или можно по примеру Крайтека превратить касательные пространства в кватернионы для экономии места.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 27-09-2021 в 13:08:
Проще, наверное, хранить делюксмапу в волрдспейсе
Отправлено Дядя Миша 27-09-2021 в 13:15:
Я в своё время так декали и не доделал, потому что там много неочевидных проблем вылезало. Ну скажем, если декали с альфа-каналом и лежат друг-на-друге, им нельзя использовать Z-offset, т.к. они будут з-файтить друг с другом. Значит им надо программный на CPU делать. Или переносить его в вертексный шейдер. Потом были проблемы со скейлом на статиках, но я вроде бы успел это решить.
Добавлено 27-09-2021 в 16:15:
Цитата:
ncuxonaT писал: Проще, наверное, хранить делюксмапу в волрдспейсе
C++ Source Code:
1
// texture flags
2
#define TEX_SPECIAL BIT( 0 ) // sky or slime, no lightmap or 256 subdivision
3
#define TEX_WORLD_LUXELS BIT( 1 ) // alternative lightmap matrix will be used (luxels per world units instead of luxels per texels)
4
#define TEX_AXIAL_LUXELS BIT( 2 ) // force world luxels to axial positive scales
5
#define TEX_EXTRA_LIGHTMAP BIT( 3 ) // bsp31 legacy - using 8 texels per luxel instead of 16 texels per luxel
6
#define TEX_NOSHADOW BIT( 4 )
7
#define TEX_NODIRT BIT( 5 )
8
#define TEX_SCROLL BIT( 6 ) // Doom special FX
Можешь в формат добавить еще один флажок, типа TEX_WORLDSPACE_DELUX или что-то вроде этого.
Оно избыточно, но информация о типе должна быть в любом случае.
Мне кажется вы неправильно поняли концепцию китайца: индирект у ДМ и так светлее китайца, а параметр balance его ещё и дополнительно подсвечивает.
Отправлено Crystallize 20-11-2021 в 16:02:
По поводу вылетов п2рад на картах из They Hunger. Попробовал отдебажить, не знаю как лучше отрепортить, потому что шестерка в этот раз сорцы упорно не показывает. Там Unhandled Exception c0000005 NTDLL.dll access violation по адресу 7С90120E int 3. VS2005 показывает место в сорцах, но там дебажная закомментированная функция, и я не уверен что VS2005 в этом случае адекватно срабатывает, т.к. скомпилировано более старой версией.
Отправлено Crystallize 24-11-2021 в 17:01:
Цитата:
Crystallize писал: Мне кажется вы неправильно поняли концепцию китайца: индирект у ДМ и так светлее китайца, а параметр balance его ещё и дополнительно подсвечивает.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Crystallize 24-11-2021 в 18:35:
Дядя Миша СЛАУ не сойдётся, или что? цепная реакция будет? Вон у китайца ставишь все что угодно и всё ок.
Отправлено ncuxonaT 24-11-2021 в 22:01:
Crystallize надо было печь лайтбейкером
Добавлено 25-11-2021 в 01:01:
Crystallize а скинь, пожалуйста, запеченную с p2st, хочу посмотреть на саму лайтмапу.
Отправлено Crystallize 25-11-2021 в 02:24:
ncuxonaT ок вечером. Это у тебя с деталками скрин?
Добавлено 25-11-2021 в 09:24:
А Рейд печет лайтбейкером?
Отправлено ncuxonaT 25-11-2021 в 05:13:
Crystallize с деталками, но это под старым ксашмодом, гамма 1 и r_lighting_modulate 0.5. И солнце я сделал в 10 раз слабее. Вот оригинальная лайтмапа, бейкер с оригинальным солнцем и со слабым.
Отправлено Дядя Миша 25-11-2021 в 06:16:
Цитата:
Crystallize писал: СЛАУ не сойдётся, или что? цепная реакция будет? Вон у китайца ставишь все что угодно и всё ок.
В p2st half-float используются для экономии памяти. Трансферы могут выйти из берегов и получится вот это. Я там не делал ограничение.
Crystallize благодарю! Че-т тут вообще половина теней отсутствует.
Отправлено Crystallize 25-11-2021 в 18:05:
ну я ж говорю
Отправлено ncuxonaT 25-11-2021 в 18:09:
Но от наклонного вагона нет тени, потому что он func_wall без флага.
Отправлено Crystallize 25-11-2021 в 18:17:
Цитата:
Дядя Миша писал: В p2st half-float используются для экономии памяти. Трансферы могут выйти из берегов и получится вот это. Я там не делал ограничение.
А, ну если это особенность кода конкретно твоих компиляторов, то к чему ты удивлялся что нигде не пишут об этом? Так, присказка?
Отправлено ncuxonaT 25-11-2021 в 19:03:
Удивительно, что нигде не упоминается о том, что ксаш при запуске включает в винде ускорение мыши
Отправлено Дядя Миша 26-11-2021 в 07:59:
Вы для начала поставьте свет от солнца 255, а потом уж и сравнивайте.
Добавлено 26-11-2021 в 10:56:
Ну или если так уж хочется ставить большие значения, пересоберите p2rad с отключенным HLRAD_SHRINK_MEMORY
Добавлено 26-11-2021 в 10:59:
Цитата:
ncuxonaT писал: Удивительно, что нигде не упоминается о том, что ксаш при запуске включает в винде ускорение мыши
В ксаше НЕТ кода, включающего ускорение мыши. Этот код находится в client.dll, которая от халфы. И в халфе это ускорение включается точно так же. Но там никто не жалуется.
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено ncuxonaT 26-11-2021 в 14:21:
Цитата:
Дядя Миша писал: И в халфе это ускорение включается точно так же. Но там никто не жалуется.
Потому что халфа не падает и не оставляет свои настройки в системе, кек. Непонятно, зачем это сделано. Если там в inputw32.cpp прописать нули, чтоб не включалось ускорение, мышка тупо лучше работает, камерой комфортнее крутить.
Отправлено Дядя Миша 26-11-2021 в 20:02:
Цитата:
ncuxonaT писал: Потому что халфа не падает и не оставляет свои настройки в системе, кек.
Очень смелое заявление. Тянет на распространение ложных слухов.
Насколько сложно будет восстановить предиктинг оружия? Без скриптовых стволов.
Отправлено Alexander Pafos 20-07-2024 в 13:42:
пригодится
Отправлено MrKabanovich 03-08-2024 в 22:49:
Код мне потребуется
__________________
Daniedov
Отправлено Дядя Миша 10-08-2024 в 19:53:
Кстати по поводу этой статьи: https://gafferongames.com/post/fix_your_timestep/ что хочу сказать. В кваковской физике переменный шаг интеграции никоим образом не влияет на её стабильность.
В NT аналогичная физика, но там фиксированный таймпстеп с аккумулятором и микросекундный таймер. Чтобы не было глюков на сверхвысоком фпс.
Ну и да, интерполяция на клиенте как раз осуществляется, полагаясь на накопленную дельту. Т.е. и сервер и клиент могут тикать 60 фпс, а рендер - 1000 фпс. И интерполяция будет осуществляется примерно каждые 16 кадров рендера. Это самый продвинутый и надёжный способ.
Ну и конечно тот факт, что я ушёл от плавающей точки в таймере не потеряв при этом в точности.
необщительным фигу или это принципиально.
