Главное чтобы 32-х битные компиляторы тянули предельную нагрузку, на которую способен движок. Иначе не имеет смысла откатываться до 32х бит, если они не будут дотягивать до лимитов. Т.е. использовать ресурс системы "движок-инструменты" полностью.
А то я щас полезу компилировать и рад опять скажет что недостаточно памяти. Хотя 89 мегабайт для компиляции того, на что раньше не хватало двух гигов звучит профитно, если я правильно разделил 8 на 9. Если я правильно понял, предоставляемый запас памяти - предел, после которого рад откажется работать - составляет 18 гигов таким образом (9 раз по 2 гига), если конвертировать расходы памяти теоретического нового рада к текущему.
А то я щас полезу компилировать и рад опять скажет что недостаточно памяти. Хотя 89 мегабайт для компиляции того, на что раньше не хватало двух гигов звучит профитно, если я правильно разделил 8 на 9. Если я правильно понял, предоставляемый запас памяти - предел, после которого рад откажется работать - составляет 18 гигов таким образом (9 раз по 2 гига), если конвертировать расходы памяти теоретического нового рада к текущему.
Last edited:
Я тут озаботился подсчётом пикового потребления памяти и обнаружил что рад уже со старта жрёт 100 мегабайт. Удивился. Полез разбираться. А там эта старая зонеровская замута с аллоком текстурной даты, лайтдаты и делюксмап. Каждая по 32 мегабайта, в сумме 96. Переписал таким образом что теперь всё аллокается точно по размеру, а значит лимиты на лайтдату и тексдату полностью отошли в прошлое.
На c1a0d пиковое потребление памяти у рада - 19 мегабайт, у виза 2.3 мегабайта.
Вообще у рада минимальный пик будет наверное в раёне 150 мегабайт, это обусловлено тем, что сперва выделяется массив для всех патчей, а затем перевыделяется точно под их размер.
Post automatically merged:
На c1a0d пиковое потребление памяти у рада - 19 мегабайт, у виза 2.3 мегабайта.
Post automatically merged:
Вообще у рада минимальный пик будет наверное в раёне 150 мегабайт, это обусловлено тем, что сперва выделяется массив для всех патчей, а затем перевыделяется точно под их размер.
Last edited:
Ух ты, вон оно оказывается как... А у меня китайский рад на тестовой карте oldmansion жрёт около 2 гигабайт при скейле текстуры травы 0.5 на Build vis leafs. Это получается, новый компилятор будет тратить около 400 мб. Здорово. Ещё бы разобраться с AllocBlock, чтобы можно было обойти этот гадский лимит на скейл. Ну и клиподов поменьше. Именно эти два лимита не дают делать большие карты под голдсорсом.
Ну что, рад потихоньку приближается к финальной версии. Осталось сделать триангуляцию для патчей и разные вкусности. типо теней от решеток и студиомоделей. А потом вернусь к тому, ради чего всё и начиналось - сохраню радиосити отдельно, шадовмапу отдельно. Может трёхвекторный бумп апробую.
Но сначала оттестируем на тежолых картах.
Но сначала оттестируем на тежолых картах.
Когда ждать первые билды для изв... тестов?
Пока не знаю. Там еще много места для экспериментов. Я возьму китайскую локальную триангуляцию для сглаживания патчей, но как мне показалось вальвовское радиальное сглаживание ничуть не хуже спровляется. При том, что код в десятки раз проще. Там основная причина тормозов - механизм деления патчей. Чем больше патчей - тем соответственно больше лампочек и размеры трансферов. Оригинальный вальвовский (кармаковский из ку2) код, генерит совсем немного патчей, однако при таком подходе не получается монолитного света от протяженных светотекстур, мне помнится еще Кристалалйз спрашивал, мол что за звёздочки возле лампы. Китаец это дело переписал чтобы свет казался сплошным, путём увеличения кол-ва патчей. Однако затем он еще внедерил механизмы точного сбора освещения с этих патчей, что в свою очередь сделало ненужным такое кол-во. А увеличивает расход прилично, там раза в два-три точно. Так что я еще с этим буду экспериментировать.
Вообще в раде, который со стороны зонеров подвергся наибольшему вниманию, огромное количество какого-то стрёмного кода, который работает как-то очень странно с точки зрения простого пользователя, но видимо должен был давать какие-то интересные эффекты с точки зрения разработчика. Ну вот например вы в курсе за существование энтити info_translucent? Настройки там прописываются по аналогии с info_texlights, только параметров не четыре, а три - цвет текстуры. Не то сквозь такую текстуру должна пройти цветная тень, не то сам свет должен окрасится. Корочи я с ней полчаса промудохался, так и не понял что она делает. И там еще много такого. Но я к себе это брать не стал.
Вообще в раде, который со стороны зонеров подвергся наибольшему вниманию, огромное количество какого-то стрёмного кода, который работает как-то очень странно с точки зрения простого пользователя, но видимо должен был давать какие-то интересные эффекты с точки зрения разработчика. Ну вот например вы в курсе за существование энтити info_translucent? Настройки там прописываются по аналогии с info_texlights, только параметров не четыре, а три - цвет текстуры. Не то сквозь такую текстуру должна пройти цветная тень, не то сам свет должен окрасится. Корочи я с ней полчаса промудохался, так и не понял что она делает. И там еще много такого. Но я к себе это брать не стал.
ЕМНИП, она позволяет указать текстурку, лицевая сторона браша окрешенного ей будет освещена так же как оборотная. Ну и процент "светопропускания" задается. Например, иллюзию занавески непрозрачной между помещениями можно сделать.
Last edited:
Ну вообщем толщина этих занавесок почему-то регулируется глобальным параметром. Нафиг такое счастье. Я лучше нормальный SSS к модельками приделаю.
Скарж когда-то выкладывал интересные скриншоты, когда у него сквозь витражи цветные тени рисуются, если я ничего не путаю. Ну на кутри такое можно изкаробки, а на халфе вот не уверен. Гдеж я видел эти скриншоты. Там ещо на витражах бабы какие-то были с сиськаме.
Post automatically merged:
Скарж когда-то выкладывал интересные скриншоты, когда у него сквозь витражи цветные тени рисуются, если я ничего не путаю. Ну на кутри такое можно изкаробки, а на халфе вот не уверен. Гдеж я видел эти скриншоты. Там ещо на витражах бабы какие-то были с сиськаме.
Last edited:
Это свойства энтить zhlt custom shadow, вроде.
Методы интерполяции слева направо: дефолтная из ку2, китайская из VHLT, вальвовская из хл2.
Легко заметить что китайская самая гладенькая, однако этот метод интерполяции суммарно превышает время рассчёта всего света
Так что я попытаюсь допилить вальвовскую чтобы избавиться от швов. Она вообще не жрёт время.
Вообще, как я и предполагал, некоторые нововведения довольно спорные, в одном месте поправляем, в другом портим, пишем очередной метод, который это исправляет, код разрастается, замедляется, теряет универсальность.
Легко заметить что китайская самая гладенькая, однако этот метод интерполяции суммарно превышает время рассчёта всего света
Так что я попытаюсь допилить вальвовскую чтобы избавиться от швов. Она вообще не жрёт время.
Post automatically merged:
Вообще, как я и предполагал, некоторые нововведения довольно спорные, в одном месте поправляем, в другом портим, пишем очередной метод, который это исправляет, код разрастается, замедляется, теряет универсальность.
Attachments
Last edited:
На первом он тоже немного есть. Китайское сглаживание рулит в этом смысле.Raid said:
про него жеRaid said:
2 Raid: надо между скриншотами быстро переключаться. Начал отладку компиляторов на больших и тежолых картах. Некоторые вещи надо специально подкорректировать для разного разрешения текстур. Еще момент интересный - китаец зачем-то считает лайтмапу для воды, я так и не понял зачем. Оно очень сильно тормозит процесс на том же грасс_тесте, куда я впихнул водяной браш размерами с карту.
Чтобы лайтмапа была на воде, очевидно. Раньше вся вода была без освещения.
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00