Ога, да, действительноДядя Миша said:
Я-то из браузера смотрел, не в полном экране. Ну що тут сказати. Китайский действительно лучше, но если речь об оптимизации, то лучше вальвовский. Красиво - это конечно хорошо, но ждать до конца вселенной пока скомпилируется карта времени нет. Между вторым и третьим потери минимальны, плюс насколько это удачная идея - сглаживать углы там где они должны быть углами - вопрос на миллион люкселей.
У вальвовского метода проблема в том что верх центрального пилона теряет любые полутона (кроме самых краёв) и становится как бы пластмассовый.Дядя Миша said:Методы интерполяции слева направо: дефолтная из ку2, китайская из VHLT, вальвовская из хл2.
Легко заметить что китайская самая гладенькая, однако этот метод интерполяции суммарно превышает время рассчёта всего света
Так что я попытаюсь допилить вальвовскую чтобы избавиться от швов. Она вообще не жрёт время.
Вообще говоря, у тебя же там на колонне лайтмапа всё ещё перевёрнута, откуда мы знаем где ещё что перевёрнуто может быть?
А там, насколько я помню, в китайских компиляторах фича присутствует: там текстура воды (и стекол) раздрабливается на несколько тайлов, и для каждого тайла расчитывается новая текстура со вшитой лайтмапой. Такой вот трюк для имитации освещения на воде.Дядя Миша said:
В халфовских компиляторах есть одна мерзость, связанная с тем, что плоскости создаются в мультипотоке. Из-за этой особенности порядок их положения в массиве каждый раз меняется, что на первый взгляд не должно влиять ни на что, однако на практике это приводит к тому, что дерево каждый раз создаётся немного по разному и кол-во лифов и нодов всё время гуляет. Проверить легко - компилим любую карту связкой csg+bsp, запускаем ксаш вводим mapstats, сохраняем статистику из лога, компилим заново, опять вводим mapstats, сохраняем вторую статистику, третью, четвертую. А потом сравниваем. Будете очень удивлены.
PS. Вылазит оно не всех картах, к слову, а на достаточно больших. Т.е. на c1a0d такое поймать практически нереально, а на моём грасс_тесте - запросто.
Post automatically merged:
PS. Вылазит оно не всех картах, к слову, а на достаточно больших. Т.е. на c1a0d такое поймать практически нереально, а на моём грасс_тесте - запросто.
Last edited:
С компиляторами творится натуральный ад (я VHLT имею в виду).
Вот результаты первой компиляции (глубина дерева 62)
А вот результаты второй компиляции этой же карты (глубина дерева 77)
Это происходит из-за заполнения массива плоскостей в мультипотоке, в результате чего, хотя сами плоскости и их кол-во всегда одинаковы, порядок их следования каждый раз немного меняется случайным образом. Я профиксил это дело в лоб - сгенерировал все плоскости в сингл-потоке и затем еще отсортировал на всякий случай. Но сам факт, что это влияет. А ведь от глубины рекурсии еще зависит скорость обсчёта виза, рада, наконец артефакты на лайтмапе, которые то пропадают то появляются от компиляции к компиляции.
наконец при каких-то условиях наверное даже дырки могут вылезти на карте, хотя до этого никаких дырок не было.
Вот вам картинки для наглядности.
Теперь условия при которых это происходит.
1. сложная карта, типа грасс_теста
2. во время работы компиляторов вы параллельно можете запустить еще что-то.
в VHLT гадость точно есть, затрундяюсь сказать насчёт ZHLT. Я еще не локализовал место бага.
Вот результаты первой компиляции (глубина дерева 62)
Code:
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 2/1024 128/65536 ( 0.2)
planes 5399/65536 107980/1310720 ( 8.2)
vertexes 9778/65535 117336/786420 (14.9)
nodes 11661/32767 279864/786408 (35.6)
texinfos 7582/65535 303280/2621400 (11.6)
faces 13681/65535 273620/1310700 (20.9)
clipnodes 0/524288 0/4194304 ( 0.0)
leaves 6140/32767 171920/917476 (18.7)
marksurfaces 16250/65535 32500/131070 (24.8)
surfedges 47280/2097152 189120/8388608 ( 2.3)
edges 24317/1048576 97268/4194304 ( 2.3)
texdata [variable] 1248/33554432 ( 0.0)
lightdata [variable] 0/33554432 ( 0.0)
deluxemap [variable] 0/33554432 ( 0.0)
visdata [variable] 0/16777216 ( 0.0)
entdata [variable] 516/524288 ( 0.1)
Code:
Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 2/1024 128/65536 ( 0.2)
planes 5399/65536 107980/1310720 ( 8.2)
vertexes 9796/65535 117552/786420 (14.9)
nodes 11684/32767 280416/786408 (35.7)
texinfos 7582/65535 303280/2621400 (11.6)
faces 13736/65535 274720/1310700 (21.0)
clipnodes 0/524288 0/4194304 ( 0.0)
leaves 6125/32767 171500/917476 (18.7)
marksurfaces 16352/65535 32704/131070 (25.0)
surfedges 47467/2097152 189868/8388608 ( 2.3)
edges 24368/1048576 97472/4194304 ( 2.3)
texdata [variable] 1248/33554432 ( 0.0)
lightdata [variable] 0/33554432 ( 0.0)
deluxemap [variable] 0/33554432 ( 0.0)
visdata [variable] 0/16777216 ( 0.0)
entdata [variable] 516/524288 ( 0.1)наконец при каких-то условиях наверное даже дырки могут вылезти на карте, хотя до этого никаких дырок не было.
Post automatically merged:
Вот вам картинки для наглядности.
Теперь условия при которых это происходит.
1. сложная карта, типа грасс_теста
2. во время работы компиляторов вы параллельно можете запустить еще что-то.
в VHLT гадость точно есть, затрундяюсь сказать насчёт ZHLT. Я еще не локализовал место бага.
Attachments
Last edited:
Тебе не кажутся хреновыми оба варианта? В смысле, там не должно получаться что-то типа такого?
2 Дядя Миша:
почему оно разбивается не на треугольники, а на какое-то дерьмо?
почему оно разбивается не на треугольники, а на какое-то дерьмо?2 Дядя Миша: но зачем?
Как я понимаю, для BSP нет разницы, коридоры это или ландшафт, поэтому разбивает одинаковым образом.
Кстати, есть ли смысл бить ландшафты на еще большее количество полигонов?
Кстати, есть ли смысл бить ландшафты на еще большее количество полигонов?
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00