Там, по крайней мере, не на каждом фейсе швы были. И на скриншотах они какое-то странное место показали, на нём можно было лайтмапу одним куском сделать.
То есть если я в одном конце карты себе ещё один длинный коридор сделал или небо отодвинул, то в другом конце у меня от этого может покривиться мой сложный брашворк?Дядя Миша said:
ОффтопRaid said:
Короче говоря никакого чуда не произошло.
Слева VHLT с отключённым блуром, справа со включённым.
Из-за малого разрешения лайтмапы, он просто убивает тени. Аналогичный результат наблюдается и при даунсэмплинге лайтмапы, безо всякого блура и по методу той же ку2, где делается пять проходов (на -extra), с небольшим смещением от центра пикселя во все стороны. Везде, абсолютно везде это говно лезет. Чтоже касается долго времени работы VHLT RAD, то оно объясняется очень просто - каждая лайтмапа рендерится в буффер, в ДЕВЯТЬ РАЗ превыщающий реальный размер конечной лайтмапы, а потом даунскейлится в итоговую. Теоретически это должно сглаживать огрехи, ступеньки, однако на практике сама технология с получением матриц соседних фейсов и возможности продолжить пограничные сэмплы там, сама по себе прекрасно справляется со сглаживанием даже в 1 проход. Таким образом все эти хитрости, примениемые для классических методов, только портят картинку и увеличивают время компиляции в десятки раз, про потребление памяти уже не говорю. Дополнительный смех в том, что после них еще и новые швы вылезают.
А нам всего-то надо сгладить ступеньки на тенях. Я попробую поэкспериментировать с порогом, за которым сглаживание не должно происходить, посмотрим что из этого получится.
Хм. после переезда на новый форум ограничение на лимит аттача стало 20 байт.
Слева VHLT с отключённым блуром, справа со включённым.
Из-за малого разрешения лайтмапы, он просто убивает тени. Аналогичный результат наблюдается и при даунсэмплинге лайтмапы, безо всякого блура и по методу той же ку2, где делается пять проходов (на -extra), с небольшим смещением от центра пикселя во все стороны. Везде, абсолютно везде это говно лезет. Чтоже касается долго времени работы VHLT RAD, то оно объясняется очень просто - каждая лайтмапа рендерится в буффер, в ДЕВЯТЬ РАЗ превыщающий реальный размер конечной лайтмапы, а потом даунскейлится в итоговую. Теоретически это должно сглаживать огрехи, ступеньки, однако на практике сама технология с получением матриц соседних фейсов и возможности продолжить пограничные сэмплы там, сама по себе прекрасно справляется со сглаживанием даже в 1 проход. Таким образом все эти хитрости, примениемые для классических методов, только портят картинку и увеличивают время компиляции в десятки раз, про потребление памяти уже не говорю. Дополнительный смех в том, что после них еще и новые швы вылезают.
А нам всего-то надо сгладить ступеньки на тенях. Я попробую поэкспериментировать с порогом, за которым сглаживание не должно происходить, посмотрим что из этого получится.
Post automatically merged:
Хм. после переезда на новый форум ограничение на лимит аттача стало 20 байт.
Last edited:
Вообщем по здравому размышлению я принял решение отказаться от экстрасемплов в принципе. Предварительно протестировав всё это дело с китайским блуром, с блуром от TyrUtils и классическими методом рендеринга лайтмапы пять раз с небольшим отступом (обычно 0.25 люкселя). Изначально, без китайского GROWSAMPLE, лайтмапы считались с очень большими огрехами. И вышеперечисленные методы, хотя и не убирали их полностью, но размывали и заглаживали. Таким образом кол-во артефактов уменьшалось, просто засчёт взвешенного смешения сэмплов. Однако здесь у нас случай строго обратный - поскольку GROWSAMPLE позволяет продолжить рендеринг лайтмапы с учётом соседних фейсов, то кол-во швов резко падает на классической схеме люксель к текселю, и исчезает практически полностью на матрице люксель к юниту.
Остаются только самые проблемные места, где текстура наложена настолько криво, что это заметно даже без лайтмапы. Плюс там еще какие-то щели-зазоры в самом браше. После чего любая попытка еще сильнее сгладить это классическими методами приводит к строго противоположному результату - время компиляции увеличивается в несколько раз, а щели - появляются. Почему так происходит? Все эти методы действуют в пределах одного фейса, а метод GROWSAMPLE учитывает соседей. И получается деградация. Единственный метод, который занимается сглаживанием с учётом соседних фейсов - это вот как раз вальвовский radial blur. У меня пока что не получилось заставить его работать идеально, но я думаю, это вопрос времени. К тому же, поскольку он работает в отдельном потоке и уже с готовыми фейсами, процесс ускоряется в разы. Для сравнения обычный китайский блур, даже при рендеринге в буффер, соответствующий финальному размеру лайтмапы увеличивает время BuildFaceLights в 2 раза. А радиальное размытие в FinalLightFace отнимает около 0.10 секунд. Еще один довод в пользу отказа от старой схемы стала возможность регулировки качества лайтмапы. Для лайтмапы максимального размера 16х16, тройной апскейл выдаст соответственно лайтмапу 48*48, а посчитайте для люкселя 8*8. Это уже будет лайтмапа 192*192. Про соотношение 4*4 вообще молчу. Время компиляции замедляется пропорционально, потребление памяти растёт аналогично. Безо всякого смысла.
Я полагаю, что после всех моих изменений рад никогда не превысит потребление памяти и надобность в 64-х битном раде попросту отпадёт, ведь для того же сорса его попросту нет и ничего - хватает.
ЗЫ. если кому-то интересно, то сейчас финальное время компила c1a0d составляет три секунды.
Остаются только самые проблемные места, где текстура наложена настолько криво, что это заметно даже без лайтмапы. Плюс там еще какие-то щели-зазоры в самом браше. После чего любая попытка еще сильнее сгладить это классическими методами приводит к строго противоположному результату - время компиляции увеличивается в несколько раз, а щели - появляются. Почему так происходит? Все эти методы действуют в пределах одного фейса, а метод GROWSAMPLE учитывает соседей. И получается деградация. Единственный метод, который занимается сглаживанием с учётом соседних фейсов - это вот как раз вальвовский radial blur. У меня пока что не получилось заставить его работать идеально, но я думаю, это вопрос времени. К тому же, поскольку он работает в отдельном потоке и уже с готовыми фейсами, процесс ускоряется в разы. Для сравнения обычный китайский блур, даже при рендеринге в буффер, соответствующий финальному размеру лайтмапы увеличивает время BuildFaceLights в 2 раза. А радиальное размытие в FinalLightFace отнимает около 0.10 секунд. Еще один довод в пользу отказа от старой схемы стала возможность регулировки качества лайтмапы. Для лайтмапы максимального размера 16х16, тройной апскейл выдаст соответственно лайтмапу 48*48, а посчитайте для люкселя 8*8. Это уже будет лайтмапа 192*192. Про соотношение 4*4 вообще молчу. Время компиляции замедляется пропорционально, потребление памяти растёт аналогично. Безо всякого смысла.
Я полагаю, что после всех моих изменений рад никогда не превысит потребление памяти и надобность в 64-х битном раде попросту отпадёт, ведь для того же сорса его попросту нет и ничего - хватает.
Post automatically merged:
ЗЫ. если кому-то интересно, то сейчас финальное время компила c1a0d составляет три секунды.
Last edited:
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-битными процами?
Оптимизаторы: https://habrahabr.ru/post/75229/
А вот это волшебное словосочетание
Т.е. потреблял мой компилятор в пике 1 гигабайт, на 64-х битной версии - 2 гигабайта. Ты и правда веришь увеличение объема потребляемой памяти положительно сказывается на быстродействии?
К тому же 64-х битные компиляторы обожают подменять даблы и флоаты на SSE-табличные функции. из-за чего скорость может и растёт, но капитально падает точность, которой и так не особо хватает. Единственный разумный довод использования 64-х битных программ на клиентских машинах - это ограничение по памяти. Но на практике это было сделано вообще по другой причине - чтобы вместо одного высокооплачиваемого программиста, умеющего работать с памятью посадить десять обезъян, которые с памятью работать не умеют, допускают утечки на каждом шагу и всем на это плевать, потому что памяти теперь много. Ну и что в итоге? Опера жрёт по 700 мегабайт, скайп 300-400.
Сраный чат потребляет в себя 400 мегабайт. Это всё последствия повального перехода на 64-битные системы. Тормозить в конечном итоге начало еще сильнее. Теперь чтобы перестало тормозить надо покупать SSD. И ты же еще за это гамно мне тут агтируешь, вот зачем? Или ты может полагаешь, что SSE появились одновременно с 64-битными процами?
Post automatically merged:
Оптимизаторы: https://habrahabr.ru/post/75229/
Post automatically merged:
А вот это волшебное словосочетание
Но при этом забывают рассказать, что и потребление памяти тоже вдвое вырастает.
Last edited:
Для рада нужен 64битный компилятор точно. Остальное не так критично. Ты попробуй сделать карту со скейлом текстур 0.25 и хорошим качеством лайтмап, и воистину оценишь сколько это "много" 2гб оперативки. А для c1a0d это и правда дофига, но кто такое кубает в 2017 году?Дядя Миша said: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-битными процами?
Post automatically merged:
Оптимизаторы: https://habrahabr.ru/post/75229/
Post automatically merged:
А вот это волшебное словосочетание
Но при этом забывают рассказать, что и потребление памяти тоже вдвое вырастает.
Раньше еще можно было бы сказать - юзайте движковые HD текстуры, но ты их вырезал.
Last edited:
это бабушка надвое сказала
Да причём тут вообще скейл текстур? Я провёл кучу работы для того, чтобы отвязать скейл текстур от качества лайтмап, он опять про свой скейл текстур.
В том-то и дело, что там перерасход памяти на ровном месте. В девять раз. Ты понимаешь русский язык? В ДЕВЯТЬ РАЗ ПЕРЕРАСХОД ПАМЯТИ НА ЭКСТРА.
Подели 8 гигабайт на 9, сколько памяти понадобится?
2 ncuxonaT: бабушка ничего не сказала, бабушка Путина смотрит по телевизору.
2 Дядя Миша:
Я не поел. Ты собираешься вводить какие-то специальные конструкции что бы тулзы не собирались под 64 бита? Или о чём тогда срач?
Я не поел. Ты собираешься вводить какие-то специальные конструкции что бы тулзы не собирались под 64 бита? Или о чём тогда срач?
2 Дядя Миша: а без экстра какой был перерасход?
Утверждать что 64 бита однозначно будет быстрее не буду, просто оно даёт больше возможностей C/C++ компилятору по оптимизации. Вполне возможно что количество обрабатываемых данных увеличится и это сведёт все преимущества на нет. Однако как я говорил выше, речь идёт о правильно работающем компиляторе. То есть если эти оптимизации приведут к значительной потере точности или неверному совсем результату, такой 64битный компилятор точно не нужен.
2 GNU/Hurt:
Ну Дядя Миша может вполне ввести. Например в ксаше добавлен указатель mempool в model_t вместо int оставшегося от кваки. В итоге если пересобрать мод который использует model_t под 64 бита, он останется несовместимым с 64битным ксашем. А если поправить в моде структуру, то он будет несовместимым с 64битным goldsource, который тоже вроде как существует. Конечно это не создаёт реальных проблем т.к при портировании на какую-то платформу, поддерживающую только 64 бита совместимость с gs не нужна, но это просто не приятно.
Избавляться от mempool тоже не вариант, он удобный
Post automatically merged:
2 GNU/Hurt:
Ну Дядя Миша может вполне ввести. Например в ксаше добавлен указатель mempool в model_t вместо int оставшегося от кваки. В итоге если пересобрать мод который использует model_t под 64 бита, он останется несовместимым с 64битным ксашем. А если поправить в моде структуру, то он будет несовместимым с 64битным goldsource, который тоже вроде как существует. Конечно это не создаёт реальных проблем т.к при портировании на какую-то платформу, поддерживающую только 64 бита совместимость с gs не нужна, но это просто не приятно.
Избавляться от mempool тоже не вариант, он удобный
Last edited:
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00