При хостинг поддержке Интернет-сообщества VBIOS CS-Mapping.com.ua
Вернуться   CS-Mapping.com.ua > Forum > Разработка игр > Xash3D Engine
Ник
Пароль
Регистрация Правила форума FAQ Пользователи Администрация Календарь Поиск За 24 часа Пометить все разделы прочитанными

Ответ
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.11.2017, 11:01  #481
Raid
Raid
Регистрация: 28.03.2037
Адрес: CSM-чат
Возраст: 26
Сообщения: 7,789


По умолчанию

[ Цитата ] Ты же в курсе что у вещественных плавает точность, вместе с точкой? Чем дальше планес от центра - тем меньше его точность координат
Оффтоп

Последний раз редактировалось Raid, 12.11.2017 в 11:06.
Raid вне форума Ответить с цитированием
Старый 12.11.2017, 11:51  #482
crystallize
crystallize
Лейтенант
Регистрация: 06.06.2014
Сообщения: 745


По умолчанию

[ Цитата ] Сообщение от Raid: Оффтоп
Оффтоп
crystallize вне форума Ответить с цитированием
Старый 12.11.2017, 14:14  #483
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

Чем сложнее брашворк - тем больше вероятность что что-нибудь покривиться.
Ну вспоминайте универсальный совет из учебников по маппингу - подвигать всю конструкцию.
Дядя Миша вне форума Ответить с цитированием
Старый 12.11.2017, 18:27  #484
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

Короче говоря никакого чуда не произошло.
Слева VHLT с отключённым блуром, справа со включённым.
Из-за малого разрешения лайтмапы, он просто убивает тени. Аналогичный результат наблюдается и при даунсэмплинге лайтмапы, безо всякого блура и по методу той же ку2, где делается пять проходов (на -extra), с небольшим смещением от центра пикселя во все стороны. Везде, абсолютно везде это говно лезет. Чтоже касается долго времени работы VHLT RAD, то оно объясняется очень просто - каждая лайтмапа рендерится в буффер, в ДЕВЯТЬ РАЗ превыщающий реальный размер конечной лайтмапы, а потом даунскейлится в итоговую. Теоретически это должно сглаживать огрехи, ступеньки, однако на практике сама технология с получением матриц соседних фейсов и возможности продолжить пограничные сэмплы там, сама по себе прекрасно справляется со сглаживанием даже в 1 проход. Таким образом все эти хитрости, примениемые для классических методов, только портят картинку и увеличивают время компиляции в десятки раз, про потребление памяти уже не говорю. Дополнительный смех в том, что после них еще и новые швы вылезают.
А нам всего-то надо сгладить ступеньки на тенях. Я попробую поэкспериментировать с порогом, за которым сглаживание не должно происходить, посмотрим что из этого получится.

Дядя Миша, подумав, добавил 12.11.2017 в 18:28
Хм. после переезда на новый форум ограничение на лимит аттача стало 20 байт.

Последний раз редактировалось Дядя Миша, 12.11.2017 в 18:28.
Дядя Миша вне форума Ответить с цитированием
Старый 13.11.2017, 00:20  #485
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

Вообщем по здравому размышлению я принял решение отказаться от экстрасемплов в принципе. Предварительно протестировав всё это дело с китайским блуром, с блуром от TyrUtils и классическими методом рендеринга лайтмапы пять раз с небольшим отступом (обычно 0.25 люкселя). Изначально, без китайского GROWSAMPLE, лайтмапы считались с очень большими огрехами. И вышеперечисленные методы, хотя и не убирали их полностью, но размывали и заглаживали. Таким образом кол-во артефактов уменьшалось, просто засчёт взвешенного смешения сэмплов. Однако здесь у нас случай строго обратный - поскольку GROWSAMPLE позволяет продолжить рендеринг лайтмапы с учётом соседних фейсов, то кол-во швов резко падает на классической схеме люксель к текселю, и исчезает практически полностью на матрице люксель к юниту.
Остаются только самые проблемные места, где текстура наложена настолько криво, что это заметно даже без лайтмапы. Плюс там еще какие-то щели-зазоры в самом браше. После чего любая попытка еще сильнее сгладить это классическими методами приводит к строго противоположному результату - время компиляции увеличивается в несколько раз, а щели - появляются. Почему так происходит? Все эти методы действуют в пределах одного фейса, а метод GROWSAMPLE учитывает соседей. И получается деградация. Единственный метод, который занимается сглаживанием с учётом соседних фейсов - это вот как раз вальвовский radial blur. У меня пока что не получилось заставить его работать идеально, но я думаю, это вопрос времени. К тому же, поскольку он работает в отдельном потоке и уже с готовыми фейсами, процесс ускоряется в разы. Для сравнения обычный китайский блур, даже при рендеринге в буффер, соответствующий финальному размеру лайтмапы увеличивает время BuildFaceLights в 2 раза. А радиальное размытие в FinalLightFace отнимает около 0.10 секунд. Еще один довод в пользу отказа от старой схемы стала возможность регулировки качества лайтмапы. Для лайтмапы максимального размера 16х16, тройной апскейл выдаст соответственно лайтмапу 48*48, а посчитайте для люкселя 8*8. Это уже будет лайтмапа 192*192. Про соотношение 4*4 вообще молчу. Время компиляции замедляется пропорционально, потребление памяти растёт аналогично. Безо всякого смысла.
Я полагаю, что после всех моих изменений рад никогда не превысит потребление памяти и надобность в 64-х битном раде попросту отпадёт, ведь для того же сорса его попросту нет и ничего - хватает.

Дядя Миша, подумав, добавил 13.11.2017 в 00:22
ЗЫ. если кому-то интересно, то сейчас финальное время компила c1a0d составляет три секунды.

Последний раз редактировалось Дядя Миша, 13.11.2017 в 00:22.
Дядя Миша вне форума Ответить с цитированием
Старый 13.11.2017, 01:25  #486
Raid
Raid
Регистрация: 28.03.2037
Адрес: CSM-чат
Возраст: 26
Сообщения: 7,789


По умолчанию

[ Цитата ] ЗЫ. если кому-то интересно, то сейчас финальное время компила c1a0d составляет три секунды.
Против?
Raid вне форума Ответить с цитированием
Старый 13.11.2017, 08:57  #487
FiEctro
FiEctro
Регистрация: 28.07.2006
Адрес: Эквестрия
Возраст: 26
Сообщения: 16,378


По умолчанию

[ Цитата ] Сообщение от Дядя Миша: Я полагаю, что после всех моих изменений рад никогда не превысит потребление памяти и надобность в 64-х битном раде попросту отпадёт, ведь для того же сорса его попросту нет и ничего - хватает.

640 килобайт должно хватить всем
FiEctro вне форума Ответить с цитированием
Старый 13.11.2017, 14:47  #488
mittorn
mittorn
Старший лейтенант
Регистрация: 22.04.2010
Сообщения: 824


По умолчанию

64 бита это не только указатели, но и удвоенный размер регистров и более быстрый вызов функций. Думаю что правильно работающий 64битный компилятор будет быстрее 32битного.
mittorn вне форума Ответить с цитированием
Старый 13.11.2017, 16:40  #489
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

2 mittorn: во первых 32-битные приложения на 64-битном проце и так работают быстрее, чем на 32-битном, в силу его архитектуры и наличия доп. регистров. Для этого не надо ничего перекомпиливать. Во вторых, на 64-битной системе 32-битные приложения работают хуже, поскольку аппаратная поддержка в проце заменяется на виндовый эмулятор, wow64 или как он там называется. Т.е. грубо говоря под 64-х битной виндой 32-битные приложения действительно работают медленее 64-х битных, но это проблема не приложений, а самой винды. Второй негативный момент - потребление памяти. По факту 64-х битному приложению её требуется минимум в полтора раза больше или в два.
Т.е. потреблял мой компилятор в пике 1 гигабайт, на 64-х битной версии - 2 гигабайта. Ты и правда веришь увеличение объема потребляемой памяти положительно сказывается на быстродействии?
К тому же 64-х битные компиляторы обожают подменять даблы и флоаты на SSE-табличные функции. из-за чего скорость может и растёт, но капитально падает точность, которой и так не особо хватает. Единственный разумный довод использования 64-х битных программ на клиентских машинах - это ограничение по памяти. Но на практике это было сделано вообще по другой причине - чтобы вместо одного высокооплачиваемого программиста, умеющего работать с памятью посадить десять обезъян, которые с памятью работать не умеют, допускают утечки на каждом шагу и всем на это плевать, потому что памяти теперь много. Ну и что в итоге? Опера жрёт по 700 мегабайт, скайп 300-400.
Сраный чат потребляет в себя 400 мегабайт. Это всё последствия повального перехода на 64-битные системы. Тормозить в конечном итоге начало еще сильнее. Теперь чтобы перестало тормозить надо покупать SSD. И ты же еще за это гамно мне тут агтируешь, вот зачем? Или ты может полагаешь, что SSE появились одновременно с 64-битными процами?

Дядя Миша, подумав, добавил 13.11.2017 в 16:42
Оптимизаторы: https://habrahabr.ru/post/75229/

Дядя Миша, подумав, добавил 13.11.2017 в 16:45
А вот это волшебное словосочетание
[ Цитата ] С 64-битной версией Windows компьютер может обрабатывать за единицу времени в два раза больше данных, чем с 32-битной
Источник: https://www.windxp.com.ru/articles91.htm
Но при этом забывают рассказать, что и потребление памяти тоже вдвое вырастает.

Последний раз редактировалось Дядя Миша, 13.11.2017 в 16:45.
Дядя Миша вне форума Ответить с цитированием
Старый 13.11.2017, 16:57  #490
FiEctro
FiEctro
Регистрация: 28.07.2006
Адрес: Эквестрия
Возраст: 26
Сообщения: 16,378


По умолчанию

[ Цитата ] Сообщение от Дядя Миша: 2 mittorn: во первых 32-битные приложения на 64-битном проце и так работают быстрее, чем на 32-битном, в силу его архитектуры и наличия доп. регистров. Для этого не надо ничего перекомпиливать. Во вторых, на 64-битной системе 32-битные приложения работают хуже, поскольку аппаратная поддержка в проце заменяется на виндовый эмулятор, wow64 или как он там называется. Т.е. грубо говоря под 64-х битной виндой 32-битные приложения действительно работают медленее 64-х битных, но это проблема не приложений, а самой винды. Второй негативный момент - потребление памяти. По факту 64-х битному приложению её требуется минимум в полтора раза больше или в два.
Т.е. потреблял мой компилятор в пике 1 гигабайт, на 64-х битной версии - 2 гигабайта. Ты и правда веришь увеличение объема потребляемой памяти положительно сказывается на быстродействии?
К тому же 64-х битные компиляторы обожают подменять даблы и флоаты на SSE-табличные функции. из-за чего скорость может и растёт, но капитально падает точность, которой и так не особо хватает. Единственный разумный довод использования 64-х битных программ на клиентских машинах - это ограничение по памяти. Но на практике это было сделано вообще по другой причине - чтобы вместо одного высокооплачиваемого программиста, умеющего работать с памятью посадить десять обезъян, которые с памятью работать не умеют, допускают утечки на каждом шагу и всем на это плевать, потому что памяти теперь много. Ну и что в итоге? Опера жрёт по 700 мегабайт, скайп 300-400.
Сраный чат потребляет в себя 400 мегабайт. Это всё последствия повального перехода на 64-битные системы. Тормозить в конечном итоге начало еще сильнее. Теперь чтобы перестало тормозить надо покупать SSD. И ты же еще за это гамно мне тут агтируешь, вот зачем? Или ты может полагаешь, что SSE появились одновременно с 64-битными процами?

Дядя Миша, подумав, добавил 13.11.2017 в 16:42
Оптимизаторы: https://habrahabr.ru/post/75229/

Дядя Миша, подумав, добавил 13.11.2017 в 16:45
А вот это волшебное словосочетание

Но при этом забывают рассказать, что и потребление памяти тоже вдвое вырастает.

Для рада нужен 64битный компилятор точно. Остальное не так критично. Ты попробуй сделать карту со скейлом текстур 0.25 и хорошим качеством лайтмап, и воистину оценишь сколько это "много" 2гб оперативки. А для c1a0d это и правда дофига, но кто такое кубает в 2017 году?

Раньше еще можно было бы сказать - юзайте движковые HD текстуры, но ты их вырезал.

Последний раз редактировалось FiEctro, 13.11.2017 в 17:00.
FiEctro вне форума Ответить с цитированием
Старый 13.11.2017, 18:13  #491
ncuxonaT
ncuxonaT
Лейтенант
Регистрация: 05.05.2013
Сообщения: 702


По умолчанию

[ Цитата ] Но при этом забывают рассказать, что и потребление памяти тоже вдвое вырастает.
это бабушка надвое сказала
ncuxonaT сейчас на форуме Ответить с цитированием
Старый 13.11.2017, 19:28  #492
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

[ Цитата ] Ты попробуй сделать карту со скейлом текстур 0.25 и хорошим качеством лайтмап
Да причём тут вообще скейл текстур? Я провёл кучу работы для того, чтобы отвязать скейл текстур от качества лайтмап, он опять про свой скейл текстур.
В том-то и дело, что там перерасход памяти на ровном месте. В девять раз. Ты понимаешь русский язык? В ДЕВЯТЬ РАЗ ПЕРЕРАСХОД ПАМЯТИ НА ЭКСТРА.
Подели 8 гигабайт на 9, сколько памяти понадобится?
2 ncuxonaT: бабушка ничего не сказала, бабушка Путина смотрит по телевизору.
Дядя Миша вне форума Ответить с цитированием
Старый 13.11.2017, 20:12  #493
GNU/Hurt
GNU/Hurt
Забаненный
Регистрация: 05.03.2014
Сообщения: 749


По умолчанию

2 Дядя Миша:
Я не поел. Ты собираешься вводить какие-то специальные конструкции что бы тулзы не собирались под 64 бита? Или о чём тогда срач?
GNU/Hurt вне форума Ответить с цитированием
Старый 13.11.2017, 20:42  #494
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

2 GNU/Hurt: да делать мне ото нехрен. Меня запарило, что я некоторые карты не могу скомпилить - памяти нехватает. Ну а на моих тулзах её должно будет хватить под все задачи. Вот об этом и речь.
Дядя Миша вне форума Ответить с цитированием
Старый 13.11.2017, 20:57  #495
ncuxonaT
ncuxonaT
Лейтенант
Регистрация: 05.05.2013
Сообщения: 702


По умолчанию

2 Дядя Миша: а без экстра какой был перерасход?
ncuxonaT сейчас на форуме Ответить с цитированием
Старый 13.11.2017, 21:36  #496
mittorn
mittorn
Старший лейтенант
Регистрация: 22.04.2010
Сообщения: 824


По умолчанию

Утверждать что 64 бита однозначно будет быстрее не буду, просто оно даёт больше возможностей C/C++ компилятору по оптимизации. Вполне возможно что количество обрабатываемых данных увеличится и это сведёт все преимущества на нет. Однако как я говорил выше, речь идёт о правильно работающем компиляторе. То есть если эти оптимизации приведут к значительной потере точности или неверному совсем результату, такой 64битный компилятор точно не нужен.

mittorn, подумав, добавил 13.11.2017 в 21:42
2 GNU/Hurt:
Ну Дядя Миша может вполне ввести. Например в ксаше добавлен указатель mempool в model_t вместо int оставшегося от кваки. В итоге если пересобрать мод который использует model_t под 64 бита, он останется несовместимым с 64битным ксашем. А если поправить в моде структуру, то он будет несовместимым с 64битным goldsource, который тоже вроде как существует. Конечно это не создаёт реальных проблем т.к при портировании на какую-то платформу, поддерживающую только 64 бита совместимость с gs не нужна, но это просто не приятно.
Избавляться от mempool тоже не вариант, он удобный

Последний раз редактировалось mittorn, 13.11.2017 в 21:42.
mittorn вне форума Ответить с цитированием
Старый 13.11.2017, 21:56  #497
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

2 ncuxonaT: ну соответственно в 9 раз меньше. Но можно еще уменьшить.
[ Цитата ] просто оно даёт больше возможностей C/C++ компилятору по оптимизации
Главным образом включённый SSE по дефолту, который пытаеся все FP-операции собой подменить.
Да об чём речь, я же сорцы выложу потом, скомпилите, протестируете.
Дядя Миша вне форума Ответить с цитированием
Старый 14.11.2017, 10:42  #498
Raid
Raid
Регистрация: 28.03.2037
Адрес: CSM-чат
Возраст: 26
Сообщения: 7,789


По умолчанию

Главное чтобы 32-х битные компиляторы тянули предельную нагрузку, на которую способен движок. Иначе не имеет смысла откатываться до 32х бит, если они не будут дотягивать до лимитов. Т.е. использовать ресурс системы "движок-инструменты" полностью.

А то я щас полезу компилировать и рад опять скажет что недостаточно памяти. Хотя 89 мегабайт для компиляции того, на что раньше не хватало двух гигов звучит профитно, если я правильно разделил 8 на 9. Если я правильно понял, предоставляемый запас памяти - предел, после которого рад откажется работать - составляет 18 гигов таким образом (9 раз по 2 гига), если конвертировать расходы памяти теоретического нового рада к текущему.

Последний раз редактировалось Raid, 14.11.2017 в 10:48.
Raid вне форума Ответить с цитированием
Старый 14.11.2017, 11:25  #499
Дядя Миша
Дядя Миша
Регистрация: 28.03.2010
Адрес: Кубань
Сообщения: 12,121


По умолчанию

Я тут озаботился подсчётом пикового потребления памяти и обнаружил что рад уже со старта жрёт 100 мегабайт. Удивился. Полез разбираться. А там эта старая зонеровская замута с аллоком текстурной даты, лайтдаты и делюксмап. Каждая по 32 мегабайта, в сумме 96. Переписал таким образом что теперь всё аллокается точно по размеру, а значит лимиты на лайтдату и тексдату полностью отошли в прошлое.

Дядя Миша, подумав, добавил 14.11.2017 в 11:27
На c1a0d пиковое потребление памяти у рада - 19 мегабайт, у виза 2.3 мегабайта.

Дядя Миша, подумав, добавил 14.11.2017 в 11:29
Вообще у рада минимальный пик будет наверное в раёне 150 мегабайт, это обусловлено тем, что сперва выделяется массив для всех патчей, а затем перевыделяется точно под их размер.

Последний раз редактировалось Дядя Миша, 14.11.2017 в 11:29.
Дядя Миша вне форума Ответить с цитированием
Старый 14.11.2017, 19:02  #500
Ku2zoff
Ku2zoff
Младший сержант
Регистрация: 12.08.2010
Возраст: 26
Сообщения: 131


По умолчанию

Ух ты, вон оно оказывается как... А у меня китайский рад на тестовой карте oldmansion жрёт около 2 гигабайт при скейле текстуры травы 0.5 на Build vis leafs. Это получается, новый компилятор будет тратить около 400 мб. Здорово. Ещё бы разобраться с AllocBlock, чтобы можно было обойти этот гадский лимит на скейл. Ну и клиподов поменьше. Именно эти два лимита не дают делать большие карты под голдсорсом.
Ku2zoff вне форума Ответить с цитированием
Ответ

Здесь присутствуют: 3 (пользователей - 2 , гостей - 1)
ncuxonaT
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать темы
Вы не можете отвечать на сообщения
Вы не можете прикреплять файлы
Вы не можете редактировать сообщения

BB-коды Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход



Часовой пояс GMT +3, время: 01:26.


Designed by FT-502, TRUP@C. Originally by Ulric Spaak
Hosted by: VBIOS.COM, Powered by: vBulletin
copyright © 2002 - 2017 by CS-Mapping.com.ua Community