Судя по теням, угол солнца неправильно выставлен.
1) Для начала проверяем, правильно ли выставлены параметры лампочек и солнца в сравнении с оригиналом, можно просто через блокнот проверить в мап и бсп. Тоже самое со стенами, вдруг там некоторые стенки, ящики в func_wall и т.п. Не забываем подключить de_dust2.rad. Судя по съехавшим текстурам, декомпил не ахти
2) Далее качаем ZHLT 2.5.3, кс карты компилились более ранними версиями, то там нет отличий в картинке. Компилим карту в них, если освещение не совпадает, значит в раде использовались кастомные параметры, их придётся подбирать.
3) И уже подобрав точные параметры, дописываем их к вхлт вместе с -dscale 1(а может и 2, надо проверить) -vismatrix normal -blur 0 и компилим, сравниваем
Post automatically merged:
вот кстати https://csm.dev/threads/svet-na-isxodnike-de_dust2.8611/
Post automatically merged:
Нашёл один свой старый пост https://csm.dev/threads/isxodniki-cs_estate.27947/page-2#post-963305 с точки зрения картинки ZHLT 3.4f/Custom Build 1.7 и ZHLT 2.5.3 отличаются друг от друга дефолтным значением nodynbounce
Post automatically merged:
У солнца нужно дописать параметр "angle" "43". На скрине зхлт с быстрой компиляцией
Attachments
Last edited:
Сейчас сидел делал исходник. В украденных сорцах сорса были карты из кс, сохраненные в формате vmf, т.е. это на 100% точная геометрия карты и правильное разбиение брашей. Перегнал в map через Jack, ибо через Hammer 4.1 результат получается менее точным из-за большего округления координат, через джек всё ок. Правда скейл текстур на стенах там не всегда совпадает, связанно это видимо с переходом на неквадратные текстуры, в принципе это не сложно поправить, нужно просто выставлять у всех текстур одинаковые X и Y, к примеру у двери скейл 0.75 на 0.56, выставляем у обоих сторон 0.75. У стен 1.0 на 0.94, логично, что в гс было 1.0 на 1.0. На скринах видно, что в оригинале текстуры стен постоянно меняются, снизу мой рекомпил с нескейленными текстурами. Тени чуть съехали, это как раз из-за скейла, ведь лайтмапы растягиваются по текстурам
Post automatically merged:
Я не проверял все энтити, но по-крайней мере солнце настроил правильно, а так, не долго скопировать их из декомпила. Компилил в zhlt быстрой компиляцией
hlcsg %mapname%
hlbsp %mapname%
hlvis %mapname% -fast
hlrad %mapname% -chop 128
Позже проверю, как в вхлт будет
Attachments
@JPEG спасибо.
Попробовал -dscale 2, это действительно оказалось верным, теперь прямой свет совпадает. (хоть рад и ругается на то, что значение должно быть 1 для финальной компиляции, и советует -texreflectscale и -texreflectgamma)
Осталось несоответствие со всеми местами куда не падает прямой свет. (стены в тени темнее чем надо)
Какой параметр за это отвечает?
Я помню давно ремейкал fy_snow и там боролся с освещением, и было так, что _diffuse_light у солнца отвечал за свет/цвет теней. Но думаю в этот раз это не то что нужно, должен быть параметр рада который отвечает за непрямое освещение (затененные участки).
Попробовал -dscale 2, это действительно оказалось верным, теперь прямой свет совпадает. (хоть рад и ругается на то, что значение должно быть 1 для финальной компиляции, и советует -texreflectscale и -texreflectgamma)
Осталось несоответствие со всеми местами куда не падает прямой свет. (стены в тени темнее чем надо)
Какой параметр за это отвечает?
Я помню давно ремейкал fy_snow и там боролся с освещением, и было так, что _diffuse_light у солнца отвечал за свет/цвет теней. Но думаю в этот раз это не то что нужно, должен быть параметр рада который отвечает за непрямое освещение (затененные участки).
Last edited:
-bounce
Между 8 (по дефолту) и 12 не увидел никакой разницы. Что ставить?
так-с, для вхлт нужно вписать -notextures к раду, это отключит корявое окрашивание света цветом текстур, ну в общем сильно приблизит в дефолтному зхлт. Осталось с тенями разобраться
Чтобы понимать разницу. Все стандартные кс-карты делались в оригинальном зхлт, последняя версия котрого 2.5.3, давал он такой свет:
Далее другой человек (некто Merl, а затем XP-Cagey) сделал мод: 2.5.3 cb17, в нём по-умолчанию тени намного более светлые:
Затем на его основе ещё один человек (amckern) сделал мод 3.4, с точки зрения освещения там всё тоже самое. Если раду задать параметр -nodynbounce, то можно было вернуть изначальное Зоннеровское освещение из 2.5.3.
Далее на их основе появились VHLT, где освещение ещё более плавное:
Но как на их основе выставить освещение 2.5.3 я не знаю, возможно есть аналог уже вырезанному -nodynbounce, нужно гуглить, читать документацию, мне кажется, ДМ знает, что и как.
Стандартное освещение даста, используется только флаг -extra на зхлт 2.5.3:
На vhlt с параметрами -notextures -texreflectscale 0.25 -gamma 0.42 получилось лишь чуть-чуть приблизить в оригиналу, но это не то и костыль (но оно действительно более красивое)
Post automatically merged:
Чтобы понимать разницу. Все стандартные кс-карты делались в оригинальном зхлт, последняя версия котрого 2.5.3, давал он такой свет:
Далее другой человек (некто Merl, а затем XP-Cagey) сделал мод: 2.5.3 cb17, в нём по-умолчанию тени намного более светлые:
Затем на его основе ещё один человек (amckern) сделал мод 3.4, с точки зрения освещения там всё тоже самое. Если раду задать параметр -nodynbounce, то можно было вернуть изначальное Зоннеровское освещение из 2.5.3.
Далее на их основе появились VHLT, где освещение ещё более плавное:
Но как на их основе выставить освещение 2.5.3 я не знаю, возможно есть аналог уже вырезанному -nodynbounce, нужно гуглить, читать документацию, мне кажется, ДМ знает, что и как.
Стандартное освещение даста, используется только флаг -extra на зхлт 2.5.3:
На vhlt с параметрами -notextures -texreflectscale 0.25 -gamma 0.42 получилось лишь чуть-чуть приблизить в оригиналу, но это не то и костыль (но оно действительно более красивое)
Last edited:
Вот лучшее чего получилось добиться на данный момент:
hlrad: -extra -notextures -dscale 2 -bounce 10
light_environment: "_diffuse_light" "255 255 128 255"
hlrad: -extra -notextures -dscale 2 -bounce 10
light_environment: "_diffuse_light" "255 255 128 255"
Казалось бы полезная фича детейла — перекрытие текстур, однако такой режим не работает для энтить. То есть если надо мне поверх текстуры щитка наложить ещё сверху текстуру лампочек щитка с параметром аддитив, то придётся по старинке, с отступом в юнит, на одном уровне увы нельзя.
Wiki: Tutorial: Modelling for Goldsource with Gmax
[cat:Tutorials] [cat:Beginner Tutorials] [cat:Goldsource Tutorials] [cat:Modelling] [credit:Original author|user:1120] == Modelling for Goldsource == Part 1 [b]Introduction:[/b] First off, you must have the necessary tools. This tutorial teaches how to accomplish a modeled asset with...
Привет! У меня возникла пара вопросов по поводу дверОК и по поводу освещения.
Как создать несколько двойных дверей от кнопки, которые во время закрытия не наносят игроку урон и не открываются заново при защемлении? На с0а0е например можно охранника затолкать и он не давится, в с1а0е учёных двери не раздавливают, на с1а0с можно запрыгнуть в окно дверки, которую открывает негр сканером и ничего.
Я хочу, чтобы если игрок встал между дверями, то они его давили с 2х сторон без нанесения урона и дохлапывались, как только он отойдёт.
Второй вопрос: как добиться качественного освещения? Я хотел бы, чтоб от брашевых ентити тоже тень отбрасывалась.
Не подскажете ли рекомендуемые настройки или компилятор rad?
У меня в св-вах func_wall'ов "Light Flags" стоит даже "Opaque + Concave Fix" и всё равно никак. Компиляторы стандартные, J.A.C.K.'овские. Я скачивал даже VHLT и нужного результата я не добился. Попробую скомпилировать компилами для 64 битной версии.
И да, тоже вопросик про освещение брашевых ентитей: если их несколько разных объектов превратить ентити (фонарь, ящик и стул) и выставить освещение, то они все начнут отбрасывать тень или будет огромная тёмнота?
Как создать несколько двойных дверей от кнопки, которые во время закрытия не наносят игроку урон и не открываются заново при защемлении? На с0а0е например можно охранника затолкать и он не давится, в с1а0е учёных двери не раздавливают, на с1а0с можно запрыгнуть в окно дверки, которую открывает негр сканером и ничего.
Я хочу, чтобы если игрок встал между дверями, то они его давили с 2х сторон без нанесения урона и дохлапывались, как только он отойдёт.
Второй вопрос: как добиться качественного освещения? Я хотел бы, чтоб от брашевых ентити тоже тень отбрасывалась.
Не подскажете ли рекомендуемые настройки или компилятор rad?
У меня в св-вах func_wall'ов "Light Flags" стоит даже "Opaque + Concave Fix" и всё равно никак. Компиляторы стандартные, J.A.C.K.'овские. Я скачивал даже VHLT и нужного результата я не добился. Попробую скомпилировать компилами для 64 битной версии.
И да, тоже вопросик про освещение брашевых ентитей: если их несколько разных объектов превратить ентити (фонарь, ящик и стул) и выставить освещение, то они все начнут отбрасывать тень или будет огромная тёмнота?
Насчет дверей могу сказать, что можно в момент закрытия дверей поставить триггер_пуш, чтобы гарантированно вытолкнуть игрока и дверь захлопнулась. Будет выглядеть так себе, но зато дверь закроется 
да ну, хреновая идея, которую лучше не воплощать, будет выглядеть странно это
У меня есть парочка проблем с компиляцией и запуском игры.
Когда начинает просчитываться vis, пишет max portals on leaf. Карта весила со светом около 15мбайт, переделывать вообще не хочется, ни csg, ни bsp, ни alt p на битые браши и ентити не жаловались. Как решить проблему? Искал решение на форуме, но там пишут постоянно про «leaf portal saw into leaf”. В справочниках советуют одно и то же: либо много коридоров (у меня в каждой комнате практически 2-4 выхода), либо форма браша кривая.
Ещё кс любит вылетать на стадии «Запуск игрового сервера». Скорее всего, он вылетает из-за func_breakable. Непонятно, почему сначала большинство этих объектов нормально работало в одно время, теперь из-за них даже карта не может нормально запуститься. Брейкейблов на карте 58, из них глючные 37. Если выделить их, удалить/поменять на func detail, карта норм запускается. Что делать, чтобы карта нормально запустилась, не потеряв ни единого объекта?
Когда начинает просчитываться vis, пишет max portals on leaf. Карта весила со светом около 15мбайт, переделывать вообще не хочется, ни csg, ни bsp, ни alt p на битые браши и ентити не жаловались. Как решить проблему? Искал решение на форуме, но там пишут постоянно про «leaf portal saw into leaf”. В справочниках советуют одно и то же: либо много коридоров (у меня в каждой комнате практически 2-4 выхода), либо форма браша кривая.
Ещё кс любит вылетать на стадии «Запуск игрового сервера». Скорее всего, он вылетает из-за func_breakable. Непонятно, почему сначала большинство этих объектов нормально работало в одно время, теперь из-за них даже карта не может нормально запуститься. Брейкейблов на карте 58, из них глючные 37. Если выделить их, удалить/поменять на func detail, карта норм запускается. Что делать, чтобы карта нормально запустилась, не потеряв ни единого объекта?
Видимость vis'ом обчитывается, имхо, исходя из брашевой структуры карты. Энтити при этом не учитываются. Размер игрока тоже.
Предполагаю, что ошибка max portals on leaf вызвана сложностью брашевой архитектуры карты. Как вариант: стык двух брашевых стен, а скругление выполнено из брашевой энтити, вот стык брашевых стен - это усложнение архитектуры. Или в брашевой стене сделано углубление, типа кратера от взрыва, а та часть стены, которая при взрыве должна исчезнуть (разрушиться), выполнена как func_breakable. С точки зрения vis'a углубление - это усложнение брашевой архитектуры. Еще как вариант: отверстие в брашевой стене закрытое брашевой энтитей (func_breakable) - вот и портал получился. И если таких отверстий много в одном помещении и таких помещений тоже много - получается превышение предельного лимита, в итоге - ошибка.
Перешли исходник в ПМ, гляну, может что более подробно напишу.
p.s. возможно написал не совсем корректно, надеюсь более опытные мапперы меня поправят.
По поводу дверок и освещения.
Освещение или тени от брашевых энтитей - выставляешь Light Flag - Opaque (Blocks Light) и все - тень от энтити есть. Если брашевая энтитя покрыта текстурой с маской (типа решетки с прозначными местами) делаешь так же. Только ее толщина должна быть больше 2 юнитов. Если тоньше то в строке запуска RAD утилиты нужно добавить параметр -depth 1 (1 - это для примера, обычно тоньше 1 юнита не делают). Если энтитей группа и для каждой выставлен такой же флаг, компилятор для каждой и рассчитает тень.
Дверки, которые сдвливают игрока без урона и закрываются, как только игрок выскочит - попробуй сами двери сделать на базе энтитей func_train полагаю должно получиться. Получится для каждой двери по два path_corner'а: один в открытом состоянии двери, другой - в закрытом. Параметры: для func_train (типа: скорость перемещения, ожидать повторной активации для продолжения движения (открытия), подсветку, звуки если подойдут) и для path_corner выстави как нужно для реализации замысла.
Предполагаю, что ошибка max portals on leaf вызвана сложностью брашевой архитектуры карты. Как вариант: стык двух брашевых стен, а скругление выполнено из брашевой энтити, вот стык брашевых стен - это усложнение архитектуры. Или в брашевой стене сделано углубление, типа кратера от взрыва, а та часть стены, которая при взрыве должна исчезнуть (разрушиться), выполнена как func_breakable. С точки зрения vis'a углубление - это усложнение брашевой архитектуры. Еще как вариант: отверстие в брашевой стене закрытое брашевой энтитей (func_breakable) - вот и портал получился. И если таких отверстий много в одном помещении и таких помещений тоже много - получается превышение предельного лимита, в итоге - ошибка.
Перешли исходник в ПМ, гляну, может что более подробно напишу.
p.s. возможно написал не совсем корректно, надеюсь более опытные мапперы меня поправят.
Post automatically merged:
По поводу дверок и освещения.
Освещение или тени от брашевых энтитей - выставляешь Light Flag - Opaque (Blocks Light) и все - тень от энтити есть. Если брашевая энтитя покрыта текстурой с маской (типа решетки с прозначными местами) делаешь так же. Только ее толщина должна быть больше 2 юнитов. Если тоньше то в строке запуска RAD утилиты нужно добавить параметр -depth 1 (1 - это для примера, обычно тоньше 1 юнита не делают). Если энтитей группа и для каждой выставлен такой же флаг, компилятор для каждой и рассчитает тень.
Дверки, которые сдвливают игрока без урона и закрываются, как только игрок выскочит - попробуй сами двери сделать на базе энтитей func_train полагаю должно получиться. Получится для каждой двери по два path_corner'а: один в открытом состоянии двери, другой - в закрытом. Параметры: для func_train (типа: скорость перемещения, ожидать повторной активации для продолжения движения (открытия), подсветку, звуки если подойдут) и для path_corner выстави как нужно для реализации замысла.
Last edited:
Скорее всего да, вис игнорит ентити , нельзя же элемент геометрии (стену или пол) в func_wall превратить, будет дырка, большой р спидс и в большинстве случаев глобальное освещение. За ящиком не получаеться укрыться так, чтобы движок не рисовал большую часть комнаты.
Leaf ошибка как то сама решила пофикситься то ли после удаления пфаба, который был за картой; то ли после закрывания null'ом большую часть Func_breakablы теперь не глючные, также не выяснил: либо от того, что убрал свойство разбиваться при касании гранаты, либо либо убрал отбрасывание теней (на бомб плейсах).
Про освещение:имеются тени, наконец. Я ставил blocks light, но не отбрасывали тени из-за слишком маленькой толщины. Я пробовал ещё hlrad версии аж ещё 2006 года, но сразу же гасился из-за огромного веса текстур (MAX_MAP_MIPTEX.
Дверки заменил func train'ом и они зажимают, но урон то наносится, даже в два раза больше, ибо дверки то две. Я снижал "damage if blocked" на 0, но урон всё равно наносится. Может, в минус поставить что-ли. Ладно, пусть наносит ). Ещё есть такая проблема: в начале второго раунда, двери сами захлапывтся, но затем по моему сами открываются. Посмотрю, откроются ли они, если их активирует trigger_relay с именем game_playerspawn и значением на off
Спасибо большое за помощь )
Leaf ошибка как то сама решила пофикситься то ли после удаления пфаба, который был за картой; то ли после закрывания null'ом большую часть Func_breakablы теперь не глючные, также не выяснил: либо от того, что убрал свойство разбиваться при касании гранаты, либо либо убрал отбрасывание теней (на бомб плейсах).
Про освещение:имеются тени, наконец. Я ставил blocks light, но не отбрасывали тени из-за слишком маленькой толщины. Я пробовал ещё hlrad версии аж ещё 2006 года, но сразу же гасился из-за огромного веса текстур (MAX_MAP_MIPTEX.
Дверки заменил func train'ом и они зажимают, но урон то наносится, даже в два раза больше, ибо дверки то две. Я снижал "damage if blocked" на 0, но урон всё равно наносится. Может, в минус поставить что-ли. Ладно, пусть наносит ). Ещё есть такая проблема: в начале второго раунда, двери сами захлапывтся, но затем по моему сами открываются. Посмотрю, откроются ли они, если их активирует trigger_relay с именем game_playerspawn и значением на off
Спасибо большое за помощь )
Ну вот вариант за 10 минут и то потому что был невнимателен
Урон поставь в 0.001 - тогда звук есть, а урона нет.
Урон поставь в 0.001 - тогда звук есть, а урона нет.
Доноры Красавчики
-
AHTu6uoTuK$285.00 -
TRUP@C$136.00 -
PoD-Stas$100.00 -
Somano$60.00 -
MAPA3MATuK$55.00
Members online
No members online now.