Ku2zoff писал: второе солнышко игнорится компилятором от слова совсем.
Китаец писал что там какой-то надо добавлять на карту энтить info_sunlight, вероятно это в свенкупе такая специальная энтить. Потому что компилятор про нее не знает, только ругается, если солнц много, а info_sunlight нету. Ну да напиши такую энтить.
Это я сам дурак. Очень уж большую яркость выставил. Из-за множества переотражений даже противоположные от лайта стороны брашей светились, и не было теней.
Добавлено 16-12-2017 в 22:10:
Цитата:
Дядя Миша писал: Китаец писал что там какой-то надо добавлять на карту энтить info_sunlight
Это короче такая энтитя чисто для того, чтоб компилятор из неё взял единственно верные значения эмбиента и углы для освещения моделей при наличии нескольких солнышек:
Цитата:
Overrides light_environment light affecting, making all models affected by light_environment(s) picks lightning settings from this info_sunlight instead of environment lights. Helpful when light_environment produces dim light, but we need models to be more brightened. Also useful when multiple light_environments are used, and light doesn't suit both lights, so mapper can specify light color and brightness by his own for environmental lights.
Добавлено 16-12-2017 в 22:16:
З.Ы. Ну вот с двумя обычными лайтами всё получилось. Включаются и выключаются норм, единственное, что тени получаются темнее, т.к. механизм освещения не такой как от неба.
Ku2zoff писал: Ну вот с двумя обычными лайтами всё получилось. Включаются и выключаются норм, единственное, что тени получаются темнее, т.к. механизм освещения не такой как от неба.
// simulate qrad direct, ambient,and gamma adjustments, as well as engine scaling
20
r = pow( r / 114.0, 0.6 ) * 264;
21
g = pow( g / 114.0, 0.6 ) * 264;
22
b = pow( b / 114.0, 0.6 ) * 264;
23
24
pkvd->fHandled = TRUE;
25
sprintf( szColor, "%d", r );
26
CVAR_SET_STRING( "sv_skycolor_r", szColor );
27
sprintf( szColor, "%d", g );
28
CVAR_SET_STRING( "sv_skycolor_g", szColor );
29
sprintf( szColor, "%d", b );
30
CVAR_SET_STRING( "sv_skycolor_b", szColor );
31
}
32
else
33
{
34
CLight::KeyValue( pkvd );
35
}
36
}
Ты вот это вот видишь? Ты думаешь зачем нужны эти sv_skycolor? Вот как раз их на клиенте для освещения от солнца используют. А если у тебя два солнца, то последнее в списке перезапишет эти значения на себя да так и оставит. Тебе надо это вынести в Use и когда переключаешь два солнца менять эти квары тоже. Ну что непонятнова?
Дядя Миша да сделал я это всё. Освещение моделей меняется при переключении солнышек.
Второе солнышко не освещало мир. И знаешь, в чём была проблема? Именно в параметре -noskyfix. Видимо, если одно из солнышек изначально выключено флагом, то параметр не нужен. Всё заработало. Ну и эта, ещё важно, чтобы у солнышек были разные имена.
Уже неплохо для prop-модели.
1) Я так понял, через cycler лучше добавлять prop-модели, которые просто ничего не делают, а лишь наполняют локацию. Но что-то как-то неприятно смотреть в редакторе на разноцветные кубы, нежели чем на сами модели. Нельзя ли никак это сделать? Если что, то можно и свой fgd подправить.
2) Посмотрел исходник карты c1a0 (аномальные материалы). Мне кажется или большая часть объектов, наполняющих уровни сделаны из брашей? Просто для чего тогда в SDK такое большое количество prop-моделей. Вообщем, тут я хочу понять на что делать упор, либо создавать брашами модели, даже те, которые в 3ds уже неплохо сделал, либо всё же можно и с cycler работать.
3) в qc-файле мы можем указывать bbox'ы. В cycler они будут ли учитываться?
1). Нужно добавить особый параметр в свойства энтити, чтобы хаммер 3.5 или джек отображали студиомодель в 3D виде (джек и в 2D может):
code: model(studio) : "Model"
Значение имеет именно параметр (studio).
2). Ну в общем-то почти все украшательства в первохалфе сделаны брашами. У них есть несколько плюсов по сравнению с модельной детализацией: первый, и самый главный - правильное освещение. На брашевые пропы могут накладываться тени. Чтобы наложить аналогичную тень на модель, нужно химичить кастомный рендерер. Второй - на такие пропы накладываются декали. Третий - они без проблем коллайдят с игроком и всем остальным. Цыклеры коллайдят как монстры, по хуллу. Даже если твой цыклер - цветочный горшок - он всё равно имеет размеры, указанные в коде, т.е. размеры гуманоидного монстра.
3). Я этого наверняка не помню, но должны. Цыклер - это монстр, а значит трасса у него как у монстра. То есть, можно обозначить руки, ноги, живот, туловище и голову.
В обычной халфе лучше использовать monster_furniture вместо цыклера, т.к. первый может играть scripted_sequence. А вообще, я бы советовал своровать из спирита env_model для модельной детализации, если ты пишешь новый код на сервере.
Добавлено 17-12-2017 в 01:23:
Цитата:
semerjon писал: Делал когда-то я такую модель:
Хе, а у меня похожий сервант есть. Только слева в верхней части нет шкафчика, и он не на ножках, а полностью на полу стоит. semerjon, ты по фото делал или по реальному шкафу?
Дядя Миша писал: там наслоения совместимости. они противоречат друг-другу порой.
Вот это меня и запутало. Получается, если солнышек много, то параметр нужен, чтобы каждая часть карты была освещена по-своему. (Здесь как раз можно применить info_sunlight, чтобы модели были везде освещены одинаково, а не по параметрам от считанного первым солнышка). А если солнышек два (глобальных: день и ночь), он не нужен, т.к. ломает весь механизм, и работает только первое считанное компилятором солнышко.
Цитата:
Дядя Миша писал: Ну естественно, им же разные лайтстили даются по разным именам.
Эх, и где бы про это в учебниках по маппингу было написано? Ну правильно, нигде. Т.к. я не видел ни одной кс-карты со сменой дня и ночи.
Ждём-с новых компиляторов, чтобы компилить ими. Китайские сейчас управляются с заготовкой моей карты за 70 секунд. Будет интересно сравнить с новыми, что обсуждаются на ксм.
Добавлено 17-12-2017 в 01:40:
semerjon шикарная мебель. У меня стенка есть такого плана, только жёлтая, тоже на ножках.
Я тебе посоветую делать детали брашами (в халфе), но не миром и func_wall, а func_detail. Только слишком сложные или мелкие конструкции делай моделями. А для экономии MAX_MODELS в движке, ты можешь загружать брашевые пропы из внешних BSP, есть такой фокус. Только у них освещение всегда одинаковое, взятое из их "родного" BSP-файла. В ксаше (а тем более в п2) можно и моделями, Дядя Миша работает над этим, освещение выходит весьма и весьма годное.
Не будет ли проблем с диспропорцией, если я буду придерживаться реальным размерам объектов (для юнита буду делить на 2,54)?
И ещё, получается это тоже самое, если бы мы в 3ds делали все составляющие моделей из примитивов, и накладывали их друг на друга. Компилятор сможет "отрезать" лижние полигоны, которые не будут попадать в обзор камеры?
semerjon писал: Не будет ли проблем с диспропорцией, если я буду придерживаться реальным размерам объектов (для юнита буду делить на 2,54)?
Математически - нет. Визуально - да. Объекты будут выглядеть на халфовских картах довольно маленькими, а сами карты (коридоры, дверные проёмы, окна) будут тесными. Ориентируйся на размеры оригинальной халфы, пусть объекты и участки уровня будут больше, чем ИРЛ, но уровень будет просторным визуально в игре. Почитай статью "Разгадка реального размера юнита на CSM", чтобы вникнуть в подробности.
Цитата:
semerjon писал: Компилятор сможет "отрезать" лижние полигоны, которые не будут попадать в обзор камеры?
Удалять невидимые треугольники из моделей нужно ручками. studiomdl ничего не отрезает. Оптимизируй по максимуму сам. Это ещё один повод делать брашами, т.к. компиляторы карт отрезают невидимые фейсы.
Ku2zoff видимо, мне нужно было дописать про компилятор карт, про них и имел ввиду.
Хотел ещё спросить. Будет ли разница в удобстве между Джеком и VHE? Могли бы, несколько отличий сказать. Думаю сейчас купить себе.
semerjon покупай джек конечно. Он очень удобен. Преимущества перед хаммером значительные, начиная с отображения/скрытия служебных текстур и отображения триггеров полупрозрачными, и заканчивая кросслатформенностью и стабильностью в новых ОС. Также, можно без проблем мапать большие карты (больше 8192х8192х8192). А ещё можно багрепортить и засылать реквесты автору. Вполне возможно, что фича, нужная тебе, будет реализована в новом билде.
Главной причиной, по которой я когда-то перешёл на джек, было то, что он не вылетает, в отличие от хаммера 3.5. Сейчас я уже привык к этому редактору, и хаммер кажется мне деревянным и неподатливым. Одна только проблема - не дружит со встроенной графикой говноинтел.
semerjon
Длья объектов размером больше 2м можно придерживаться пропорции 1:1; для объектов размером с игрока , вроде дверных проёмов, узких комнат масштаб 1:1.1 .. 1:1.2 по горизонтали; для мелочёвки размером 50см и меньше -- 1:25 .. 1.5.
>Будет ли разница в удобстве между Джеком и VHE?
Да (в сторону улучшения, в том плане, что после джека от vhe хочется блевать).
>Могли бы, несколько отличий сказать.
Не вылетает (и не гробит сохранения); не тормозит (в том числе на больших картах); есть кнопки что бы: рисовать модели, рисовать небо, анимировать текстуры, прятать служебные текстуры; есть дополнительные инструменты брашворка: триангуляция и склейка брашей, примитив для создания камней; архиполезные при текстурировании режимы "scale lock" и "uv-lock"; автобекапы; толковый вьюер текстур.