Перейти к содержимому


Свернуть чат Чат Открыть чат во всплывающем окне

Yakim (Watco... : (5 дней назад) бугага
lz : (неделю назад) Вытаскивал из блока.
lz : (неделю назад) Блэт, мои серваки на амазоне под раздачу попали.
Yakim (Watco... : (3 недель назад) :ph34r:
Гость : (22 Март 2018 - 09:37) Благодарю :) (предпочитаю постоянный стабильный заработок)
Yakim (Watco... : (21 Март 2018 - 19:56) пхахаха
lz : (21 Март 2018 - 16:46) Может быть, хочешь знать, как поднять бабла?
lz : (21 Март 2018 - 16:46) Кстати, а проблем с доступом к джойказино у тебя нет?
lz : (21 Март 2018 - 16:02) Активировал.
Гость : (21 Март 2018 - 15:32) Проблемы с активацией аккаунта на форуме... =)
Yakim (Watco... : (19 Март 2018 - 21:37) :ph34r:
Yakim (Watco... : (01 Февраль 2018 - 21:44) ?
Yandersen : (01 Февраль 2018 - 19:04) Проблемы?..
Yakim (Watco... : (31 Январь 2018 - 13:18) Какие проблемы?
lz : (30 Январь 2018 - 16:17) Какие проблемы? Проблемы с другими движками?
GranMinigun : (30 Январь 2018 - 12:45) Где я предлагал заняться рефакторингом? Я спрашивал, в чём именно проблемы.
Гость : (30 Январь 2018 - 07:55) пускай они там как нибудь сами, без меня)
GranMinigun : (29 Январь 2018 - 21:19) Анрил с видимым исходным кодом таки. Но да, у СруДвижка только сырцы самого движка и свободны. А что конкретно за проблемы в коде СруДвижка? Я видел, что у них в планах провести рефакторинг в ближайший апдейт или два. С точки зрения инструментария, к слову, СруДвижок серьёзно подтянулся в последних версиях, я даже решил таки поближе ознакомиться. (А вообще, мне он понравился графическими технологиями, особенно подходом к освещению.)
Yakim (Watco... : (29 Январь 2018 - 18:01) люто плюсую Егор)
lz : (29 Январь 2018 - 14:29) Движок большой, функционала много, код качественный (не как у крузис енгине) и всё такое.
lz : (29 Январь 2018 - 14:28) Анреал открытый, взрослый, на С++. Пока проект некоммерческий денег заносить никому не надо.
lz : (29 Январь 2018 - 14:27) Да не, на самом деле у меня даже где-то описано, что графический движок можно заменить при необходимости.
lz : (29 Январь 2018 - 14:27) Потому что анреал - офигенная тема.
GranMinigun : (29 Январь 2018 - 01:03) Кстати, Егор. А почему выбор движка пал именно на UE4? Какие-то предпосылки к этому были?
lz : (27 Январь 2018 - 18:39) Я подумал на карту механоидов побольше добавить для фана, а надо ж запаковывать ещё.
lz : (27 Январь 2018 - 18:39) Спс, это я и писал)
GranMinigun : (27 Январь 2018 - 18:20) Только распаковщик. Сторонний. Точнее, его создал lz.
Гость : (27 Январь 2018 - 03:45) а интересно, есть ли где упаковщик для м1? в сдк или может где встроен в саму игру или редактор
Folgen : (19 Январь 2018 - 08:31) Спс.
GranMinigun : (19 Январь 2018 - 05:43) Готово. Добро пожаловать на форум, механоид.
GranMinigun : (19 Январь 2018 - 05:42) Указать, кого именно активировать, например.
Гость : (19 Январь 2018 - 00:49) Активируйте акк. Хз, нужно что-либо указывать дополнительно для этого в чате, или админы сами всех подряд активируют, кто в очереди на активацию?
GranMinigun : (13 Январь 2018 - 05:42) https://forums.unrea...sed-on-gis-data
Yakim (Watco... : (09 Январь 2018 - 00:24) Аа да? Ну окей)
GranMinigun : (08 Январь 2018 - 20:06) А это даже не обсуждается!
Yakim (Watco... : (08 Январь 2018 - 19:55) А кто сказал что мы пьянели?)
GranMinigun : (08 Январь 2018 - 19:48) Ну что, товарищи, протрезвели?
Yakim (Watco... : (02 Январь 2018 - 20:56) сяп)
Гость : (01 Январь 2018 - 23:57) Егорыч на праздники с каникул вернулся. За это тост! Всем маны!
lz : (30 Декабрь 2017 - 23:52) Наоборот.
Гость : (30 Декабрь 2017 - 23:16) Позвольте уточнить, для будущего наркомана прошлое это будущее или наоборот?
lz : (30 Декабрь 2017 - 22:08) Как ты его поймаешь, когда он знает, где ты его будешь ловить?
GranMinigun : (30 Декабрь 2017 - 09:12) Ловите наркомана из будущего!
PA3UJIb : (30 Декабрь 2017 - 06:37) С новым 2018 годом! А то старый-то 2018 мы и не видели даже
Yakim (Watco... : (29 Декабрь 2017 - 19:46) С наступающим)

Yandersen

Регистрация: 06 Июл 2014
OFFLINE Активность: неделю назад
*****

#1308 Конструктор глайдеров

Написано Yandersen 19 Март 2015 - 12:07

Первой моделькой слота и устройства я выбрал грави-эффектор:

Прикрепленный файл  GraviEffector.rar   596,34К   93 - Раз(а) скачано

Слот под устройство:

Slot_Gravik.jpg

Один из типов гравиков, идущих в такой слот:

Gravik_TypeA.jpg

 

Слот по сути - это крепление для устройства определённого класса. На картинке у слота видны шарики (4 у основания и один покрупнее на крышке, не виден) - это узлы для крепления балок.

 

З.Ы.: моделю в Rhinoceros. Легко и приятно, советую.




#1307 Конструктор глайдеров

Написано Yandersen 19 Март 2015 - 12:03

Концепция конструктора позволит упростить процесс создания моделей глайдеров и позволит ввести точечные повреждения и поломки устройств.

 

Согласно концепции, глайдер состоит из слотов для функциональных девайсов, балок и узлов, формирующих каркас (цилиндрические палки скалируемой длины, концами стыкующиеся к узлам) и брони.

 

Слоты разных типов предназначены для установки в них соответствующих функциональных устройств (грави-эффекторы, реакторы, аккумуляторы, камеры, пушки, трюмовый приёмник, трюмовые накопители, механоид и пр.). Устройства имеют уникальные графические модельки, но в силу своих небольших размеров по отношению к глайдеру имеют шаровую модель повреждений. К тому же у устройств, взаимодействующих со внешней средой (гравики, камеры, пушки, трюмовый приёмник) есть "зона вз.-я" - физическая моделька, актуальная на момент сборки глайда: она огораживает зону пространства для устройства, которая должна быть свободна от других элементов конструкции глайдера (для камеры, например, это пирамида видимости, для трюмового приёмника - конус всоса, для грави-эффекторов - конус отталкивания, для пушек - цилиндрический объём за дулом).

Каждый слот имеет 1 или более узлов, к которым стыкуются балки. Таким образом, расположив слоты устройств глайда в пространстве и протянув между узлами слотов балки мы получаем каркас глайдера. От расположения устройств и их количества глайдер приобретает набор уникальных свойств поведения. Например, широко разнесённые грави-эффекторы дают бОльший момент силы при развороте, что должно увеличить маневренность; слот под аккумулятор высокого стандарта позволяет обойтись без реактора, бесплатно подзаряжаясь при залёте в строения. В основном на лётные характеристики будет влиять пространственное расположение и число грави-эффекторов. Теоретически, минимально необходимо три девайса, чтобы дать глайдеру три точки опоры, но такой глайдер тяжело будет балансировать, и при этом уничтожение одного из гравиков сделает машину неуправляемой. Поэтому предлагаю не скупиться на них.

 

Узлы имеют статичное расположение на слотах, но также могут использоваться и отдельно. К самостоятельным узлам может крепиться сколько угодно балок, образуя звёздчатые соединения.

Ну и четвёртый элемент конструкции глайдера после слотов с узлами и балок - это броня. Броня состоит из криволинейных сегментов на трёх точках опоры каждый. Опоры брони - это небольшие штырьки, крепящиеся к узлам. Повернув установленную на узле опору в нужном направлении мы определяем нормаль к поверхности брони в данной точке крепления. Все сегменты брони, крепящиеся к данной опоре, перпендикулярны ей, благодаря чему листы изгибаются и смежные сегменты идеально стыкуются, придавая глайдеру обтекаемую форму. Текстура сегмента зависит от установленного на глайдере типа брони, толщина листа зависит от стандарта, указанного для данного сегмента брони.
Энергощит в виде шара предлагаю упразднить и сделать для брони "поглощающий слой" - часть хэлов, которая восстанавливается. Типа, энергетическая оболочка брони. У каждого сегмента своё количество хэлов, зависящее от размера сегмента, типа брони и её толщины.

Разумеется, глайдер не обязан быть полностью покрыт бронёй, т.ё. в нём могут быть дыры, через которые видна внутренняя конструкция. Поэтому излишняя детализация моделей устройств глайдера будет неуместной и даст тормоза.

Провода и шланги уходят в небытие. Подразумевается, что обмен энергией и передача нуль-сжатых предметов между устройствами осуществляется внутри балок.

 

---

Для подобной системы необходим конструктор глайдеров - программа, позволяющая выбирать устройства из набора имеющихся, располагать их в пространстве, соединять их балками и натягивать броню. Очжелательно иметь доступ к этой программе прямо внутри игры, дав возможность игроку создавать новые модели глайдеров (конструктор глайдеров), но тогда необходим сложный симуляторный движок, управляющий грави-эффекторами вне зависимости от их числа и расположения на корпусе, положения центра масс и момента энерции - движок переводящий кнопочномышковые желания движения игрока в переспределение сил отталкивания гравиков.




#1248 Наш бюджет

Написано Yandersen 10 Март 2015 - 21:23

Слышал, у Якима видюха полетела. Не годно UE4 на встроенной графике гонять. Яким, может, закажем тебе новую, если никто не против на это бюджет пустить?




#1184 Наш бюджет

Написано Yandersen 03 Март 2015 - 08:18

Товарищи механоиды!

Пришла мне в голову альтруистическая идея. Одна из немногих мыслей, достойных настоящего механоида. Раз креатива и другой пользы от меня как от козла молока, решил я открыть нашему клану небольшой фонд. Каждый месяц он будет увеличиваться на 50 баксов. Если кому какой полезный софт и контент понадобится, который желательно купить, а не пиратить, оглашайте запрос, не стесняйтесь, и если соклановцы не против потратить на это нашу копилку, я проставляюсь.

Не обязательно софт кому-то конкретно - ещё на оплату сайта ($40/год), и, в дальнейшем, возможно, хост сервера вообще потребует наших (моих) вложений. Итак, включаем счётчик:

 

$0 (+0ед./мес.)

 

Если кому ещё вдруг подобная моча в голову стукнет, вливайтесь.

З.Ы.: если что-то позарез надо, но оверлимит копилки - могу сделать исключение, правда, возможно, копилка будет в нуле некоторое время.  :)




#1150 Механоиды Онлайн на Unreal Engine 4

Написано Yandersen 01 Март 2015 - 13:08

Ну, такие варианты:

1) создать в Ангаре кучу топов: модели глайдеров, модели строений, модели окружения (деревца, кустики, грыбочки) из М2 и занятся экспортом этих ресурсов туда из М2;

2) создать диздок для М3::онлайн (хотя бы черновик, до ума доведём вместе);

3) расковыривать файлы объектов на локациях (файлы *.MMO), чтобы извлекать оттуда позицию, масштаб, ориентацию и модель объектов;

4) делать то же, что и Микс с Якимом - изучать UE4.7, пытаться М3::онлайн клепать.




#1137 Обсуждения

Написано Yandersen 28 Февраль 2015 - 08:29

Евреи нашептали.  :)

 

20140702-174443-63883181.jpg




#1121 Обсуждения

Написано Yandersen 26 Февраль 2015 - 20:04

Ну для глайдеров это прокатит. Даже бамп добавить можно будет, поковыряв текстуры CrazyBamp'ом чутка. Но вот строения в мехах пипец какие квадратные, тут уж ремоделлинг нужен, одна лишь текстура дело не поправит. Другое дело, что для начала всё можно импортнуть как есть, но оставить лазейку для энтузиастов-художников, чтоб можно было потом просто заменять старые модели и текстуры новыми - типа как МОДы к игре прикручивать.




#1119 Механоиды Онлайн на Unreal Engine 4

Написано Yandersen 26 Февраль 2015 - 19:55

Хех, прикольно :) Я вот только пару недель назад загорелся идеей создать мультиплеерных Механоидов. Сначала думал использовать голый DirectX11 (благо, наработки есть), но потом взглянул в сторону UE4 и (офигев от его мощи, простоты и доступности) решил по-быстренькому освоить его. Не знал, что кто-то уже этим занимается :) На счёт ремейка от комьюнити - бесполезная трата времени, ИМХО. Зачем делать то, что уже есть, если можно направить свои силы на что-то новое.

Ну окей, тогда второй вариант: мехи-онлайн. Ответвление как Гонки. Насчёт онлайна разрабы тоже заявили, что делать не будут, так что можно сюда дунуть.

Ну или всё-таки можно полный ремейк М1-М2 сделать, оставив лишь ключевые моменты сюжета типа Супера, Наблюдтеля, Наутилуса и Создателей. Но я не очень ЗА за такое вмешательство во вселенную Дуста, это как над чем-то святым надругаться. Лучше в ремейке просто проапгрэйдить геймплей и графику. Ведь даже если модельки глайдеров заменить на физически-осмысленные с локализованными устройствами на них для физически-реалистичной симуляции, это уже изменит дух оригинальных мехов, даже если сторилайн останется тот же. Так что хз.

Вапще, делать продолжение истории мехов требует сюжетной линии. Если это будет делать не папа мехов, Дуст, то это будет уже что-то левое, это будет сквозить по-любому. Так что либо мы переделываем М1-М2, копируя сюжет (максимум что можно, это добавить что-то от себя, что не противоречит вселенной мехов), либо делаем полный релоад, придумывая новую историю (которую я хз из какого пальца высосать), либо идём в онлайн-вариант, который истории не требует (только предыстория, т.е. "Мехи вышли во В.М. и столкнулись там с Синигр"). Никому ничё не указываю, просто делюсь размышлениями с дивана.  :)




#1090 Спам

Написано Yandersen 24 Февраль 2015 - 20:35

Ага, спс за наводку, нашёл и поправил. Это в управлении форумами в правах доступа каждого конкретного форума можно указывать кто может читать, качать и постить. Там гостям было разрешено постить почему-то.




#706 Детали глайдера

Написано Yandersen 08 Февраль 2015 - 04:27

Если бы этот нулевой элемент постоянно испускал отталкивающее поле, то бы было проблематично сделать оболочку вокруг него.

Нет же, отталкивающее взаимодействие [между поверхностью образца Ez и внешними частицами, обладающими массой] возникает в ответ на приложение внешнего магнитного поля. Работа отталкивающего взаимодействия приводит к усилению/ослаблению приложенного магнитного поля, таким образом закон сохренения энергии не нарушается.

Без внешнего магнитного поля шарик из Ez ничего не отталкивает, поэтому когда грави-эффектор выключен, шарик легко помещается внутрь камеры прямо через выходное отверстие. Затем на соленоид подаётся напряжение, ток нарастает, магнитное поле усиливается и в ответ на это возникает отталкивающее взаимодействие между поверхностью шарика из Ez и стенками камеры (и внешней средой, через дырочку). Чем сильнее магнитное поле, тем больше сила отталкивающего взаимодействия. Работа, совершаемая отталкивающим полем увеличивает/уменьшает энергию магнитного поля, таким образом когда гравик отталкивает поверхность, ток в соленоиде падает и соленоид приходится подкачивать от аккумулятора снова.

 

...при воздействии положительного заряда электрического тока он начинал бы испускать отталкивающее поле...

У электрического тока нет "заряда" - эл. ток есть перемещение заряжённых частиц. Если всё же попробовать понять твою мысль как "поглощение заряжённых частиц", то суммарный заряд в итоге меняется, что недопустимо. Если понять твою мысль как электризацию образца (разделение зарядов - один на образец Ez, другой заряд - куда-то подальше), то это не даёт ответа на вопрос, откуда берётся энергия, затрачиваемая на работу, совершаемую отталкивающим взаимодействием. Если же понять твою мысль как "пропускание тока через образец Ez в одном направлении приводит к возникновению отталкивающего взаимодействия, а в другом - притягивающего", то вопрос в том, откуда в образце однородного материала взятся явлению такой вот выборочной полярности?

 

P.S. такая конструкция антиграва крайне уязвима к минам, ведь любое повреждение ядра дестабилезует его, и отталкивающее поле было бы хаотичным.

Не более чем все остальные детали глайдера. Хотя да, сверхпрочная внутренняя оболочка должна быть предельно твёрдой, а значит, скорее всего, хрупкой, иначе бы из этого панацейного материала непробиваемую броню клепали бы. Энергетически-честная модель антиграва подразумевает трудности иного рода. Если глайдер падает с большой высоты, рекуперация энергии эффекторами может привести к перенапряжению аккумулятора, что чревато нагревом или пробоем с последующим взрывом. Если же блок управления мониторит выходное напряжение, и по достижению максимума отключает соленоид от аккумулятора, то ток в соленоиде будет возрастать, магнитное поле усиливаться, и в один прекрасный момент достигнет такого значения, при котором сверхпроводник выйдет из состояния сверхпроводимости и почти моментально перегреется, расплавится и испарится, т.е. взорвётся.

 

Какие интересности мы получаем от такой схемы взаимодействия устройств глайдера?

1) Движки глайдеру не нужны - эффекторы выполняют их роль при соответствующей ориентации.

2) У каждого устройства есть свой Блок управления, позволяющий Игроку откалибровать некоторые его характеристики. Например, для эффекторов - оптимальную силу отталкивания для обычного режима, для прыжка, для боевого режима (для лучшей маневренности лучше прижаться к земле), максимальное внешнее напряжение, при котором рекуперация недопустима (для предотвращения взрыва аккумулятора). Для реактора глайдера, в его БУ можно настроить уровень напряжения, при котором выработка энергии должна приостанавливаться (опасно держать аккум заряженным под 100% если возможен вброс от рекуперирующих эффекторов).

3) У разных моделей устройств одного типа могут быть разные функции. Например, навороченный аккумулятор при перенапряжении нагревается, а аккумулятор более дешёвой модели - выходит из строя или вообще взрывается. Эффекторы СБП дорогой модели могут иметь электроплазменные форсунки вокруг сопла, позволяя совершать резкие прыжки или таким же образом автоматически сбрасывать излишнюю энергию при падении, в то время как стандартные эффекторы СБП при перенапряжении взрываются как мины, и позволяют лишь плавно взлетать, а не прыгать.

 

Таким образом выживание Механоида зависит от понимания работы устройств его глайдера и стратегии их настройки, а не только от скорострельности пушки и толщины брони. Непредусмотрительно откалиброванный глайдер можно взорвать просто прыгнув на него или уронив сверху бомбу, придавив его резко к земле, что вызовет перенапряжение его эффекторов СБП или выход аккумулятора из строя.




#701 Детали глайдера

Написано Yandersen 07 Февраль 2015 - 17:28

У меня свой взгляд на систему Антиграва глайдера. Согласно нему "Антиграв" называется так не потому, что как-то вз.-ет с гравитационным полем, а лишь потому, что предназначен для противодействия гравитационному притяжению, не давая глайдеру упасть на землю. Т.е. "Антиграв" - это своего рода запатентованное коммерческое название системы бесконтактной подвески глайдера (СБП). Такая альтернативная точка зрения возникла из-за того, что глайдеры парят на некторой высоте над ландшафтом, а не сохраняют желаемую высоту, как это было бы, если бы Антиграв "отключал" влияние гравитации на глайдер.

 

Продолжая эту мысль легко прийти к выводу, что отталкивание от поверхностей окружающего ландшафта требует устройств направленного действия, расположенных на поверхности самогО глайдера, что не отражено в деталях моделей существующих глайдеров. Ведь если бы отталкивающие устройства располагались внутри глайдера, то отталкиванию подверглась бы обшивка глайдера, что разорвало бы его на куски (по механике отталкивания от ландшафта чётко видно, что чем ближе поверхность, тем сильнее сила отталкивания).

 

Таким образом на модели глайдеров из М1-М2 можно смотреть не более чем на размалёванные фигурки абстрактной формы. Чтобы игру действительно можно было отнести в жанр симулятора, нужно либо доработать модели существующих глайдеров и механику отталкивающего взаимодействия, либо создать конструктор глайдера из функциональных элементов и отправить существующие модельки в небытие.

 

Как бы то ни было, я опишу физическое устройство эффектора системы бесконтактной подвески (ЭСБП), или "Эффектора Антиграва", с вовлечением минимально необходимого набора магических элементов, чтобы хоть немного придать реализьму и логичности поведению этого устройства, что даст возможность просимулировать его работу.

 

Принцип работы основан на свойстве неизвестного нашей науке материала из сверхтяжёлого элемента "Element Zero" оказывать отталкивающее взаимодействие лучегого типа на частицы, обладающие массой в ответ на приложение магнитного давления к образцу.

 

Иллюстрация строения аксиально-симметричного устройства (в разрезе):

Gravik Description.PNG

 

Как видно на схеме, шарик из материала Ez находится в центре сферы из сверхпрочного немагнитного материала и магнитное давление прикладывается к образцу путём электронакачки соленоида. Шарик из Ez самостабилизируется примерно в центре устройства за счёт своего отталкивающего взаимодействия со стенками сверхпрочной камеры, через небольшое отверсие которой отталкивание распространяется на внешние объекты, создавая вектор отталкивания устройства. Если внешний объект под действием силы отталкивания удаляется, магнитное поле ослабляется, ток в соленоиде падает, и устройство потребляет порцию энергии из аккумулятора глайдера для восстановления энергобаланса соленоида. Если внешний объект приближается впротиводействие силе отталкивания (глайдер падает на брюхо после прыжка), энергия магнитного поля усиливается, ток в соленоиде возрастает, и устройство переключается в режим рекуперации, т.е. возвращает излишнюю энергию в аккумулятор.

 

Нужно отметить, что молекулы воздуха точно так же отталкиваются устройством, поэтому эффекторы постоянно потребляют некторое количество энергии и оказывают слабое отталкивание на любой высоте и создают воздушные/пылевые вихри под собой.




#666 [GLSL.hpp] - векторная математика как в GLSL

Написано Yandersen 07 Январь 2015 - 23:25

Передрал с GLSL всю векторную математику. Единственное отличие в том, что выделение свиззлнутых субкомпонентов вектора выглядит не как в оригинале "MyVec.xwzz" а со скобочками на конце: "MyVec.xwzz()". В остальном всё так же (названия классов, функций, работа операторов).

Передирал с официальной документации, т.к. онлайн-документация, как оказалось, полна багов и неточностей, как будто мартышки копипастали.

Все функции описаны на ассемблере; операторы - пока что нет (инлайнами).

 

Так что вот, официальный релиз такскать, готовый к использованию. Однохеадерная альтернатива библиотеки glm.




#638 Спам

Написано Yandersen 19 Декабрь 2014 - 16:18

Тихо уже два дня. Я ввёл два вопроса, каждый из которых спрашивает никнейм одного из администраторов этого сайта (у нас их три). Как считаете, это не очень сложно для обычных юзверей?

 

К слову, вопрос

2+2=

не сработал - видимо, боты рандомом перебирают ответы и бычтро находят 4 либо это очень стандартный вопрос. Интересно, правда, как боты капчу проходят? Наверное, набор картинок им известен.




#560 [GLSL.hpp] - векторная математика как в GLSL

Написано Yandersen 07 Декабрь 2014 - 01:40

Векторная математика, максимально приближённая к OpenGL Shading Language (GLSL):
 
GLSL.hpp
 
Хеадер содержит базовые классы наподобие GLSL'евских (bvec2, vec3, ivec4, mat3, dmat4...) и операторы для них, а также написанные на ассемблере GLSL-функции (dot, cross, length, normalize, sin, sqrt, abs, mod, tanh, imulExtended, inverse, round, packHalf2x16 и пр.).
GLSL.hpp является однофайловой альтернативой известной библиотеки glm. Также как и в glm, тут упор сделан на максимальное соответствие синтаксиса официальной GLSL документации, однако есть несколько упрощений. В GLSL.hpp нет поддержки half-векторов, а выделение субкомпонентов вектора при свиззлинге выглядит как вызов функции:

vec3 veca(0), vecb(1.f, 2.f, 3.f);
veca.yz() = vecb.zx(); //In GLSL and glm it will look like "veca.yz = vecb.xz;"

Само собой разумеется, в GLSL.hpp нет самплеров, функций работы с ними и пр. элементов GLSL, специфичных для кода шейдеров. Всё остальное есть.

 

Среди функций GLSL часть применима не только к векторам, но и НЕвекторным типам данных (функции типа sqrt, pow и пр.). Чтобы избежать конфликта имён с фукциями стандартной библиотеки math.h эти функции скрыты под неймспейсом "GLSL". Доступиться до них можно так:

#include "GLSL.hpp"
#include <math.h>
//...
float x;
float y = GLSL::sqrt(x);  //sqrt() function from GLSL.hpp is used
float z = sqrt(x);        //sqrt() function from math.h is used
//...
vec2 u;
vec2 v = sqrt(u); //Vector functions do not require namespace selection

Если инструментария GLSL Вам достаточно и math.h подключать нет желания, можно сделать так:

#include "GLSL.hpp"
using namespace GLSL; //Will conflict if <math.h> included as well
//...
float x;
float y = sqrt(x);  //sqrt() function from GLSL.hpp is used

Напоследок добавлю, что в некоторых написанных на ассемблере функциях использованы команды SSE4.1. Это ставит соответствующие требования к компиллятору, жующему GLSL.hpp, а также процессору, грызущему полученный ехе-шник (SSE4.1 начались с Intel Core).




#521 OpenGL

Написано Yandersen 02 Декабрь 2014 - 03:31

Итак, древняя проблема: точность буффера глубины падает с расстоянием, из-за чего дальние объекты начинают "просвечивать" друг через друга, мерцать и дрожать. Решается проблема отодвиганием ближней плоскости отсечения как можно дальше и придвиганием дальней плоскости отсечения как можно ближе. Как результат - сложившаяся традиция не рисовать персонажа (в шутерах тела и ног не видно, нет тени от модели игрока), а также "взгляд сквозь стены" (это уже не так часто).

 

Чтобы максимально реалистично моделировать камеру, нам нужно иметь возможность установить ближнюю плоскость отсечения на расстоянии в несколько миллиметров (а не метров, как практикуется), а также избавиться от искусственной по своей природе дальней плоскости отсечения. Если не пользоваться w-buffer'ом от DirectX, то средствами OpenGL это должно решаться следующим образом...

 

Построим нестандартную матрицу перспективной проекции. Для этого нам сперва нужно выбрать несколько констант:

zNear - расстояние до ближней плоскости отсечения. Скажем, 1 мм или даже ближе.

Viewport.x, Viewport.y - ширина и высота экрана (в пикселях).

View_Angle_Vertical - угол обзора, по вертикали (мы имеем дело с перспективной проекцией).

Препрощитаем парочку констант (использующихся также и в обычной матрице перспективной проекции):

f = ctan(View_Angle_Vertical / 2);
aspect = Viewport.x / Viewport.y;

Теперь всё готово для построения матрицы проекции по моему "особому" рецепту:

    | f/aspect  0      0      0    |
    |                              |
    |    0      f      0      0    |
P = |                              |
    |    0      0      0    zNear  |
    |                              |
    |    0      0     -1      0    |

Посмотрим, как происходит трансформация точки с координатами v={x,y,z,1} при помощи такой матрицы:

Xc = x * (f/aspect);
Yc = y * f;
Zc = zNear;
Wc = -z;

Тут Xc,Yc,Zc,Wc - это т.н. "clipped coordinates" - конечный результат трансформаций. Называются эти координаты "clipped" потому, что их кушает clipper - не управляемый шейдерами участок пайплайна примитивов, занимающийся clipping'ом, т.е. обрезанием тех частей примитивов, что не попадают в рендеримый объём виртуального пространства. Внутрь видимого объёма попадают только те фрагменты, координаты которых удовлетворяют всем 6-ти неравенствам:

-Wc <= Xc <= Wc;
-Wc <= Yc <= Wc;
-Wc <= Zc <= Wc;

После клиппинга осуществляется деление компонент {Xc,Yc,Zc} на Wc и получаются "normalized device coordinates", значения которых оказываются всегда в диапазоне [-1...1]:

Xndc = Xc / Wc;
Yndc = Yc / Wc;
Zndc = Zc / Wc;

Ну и последнее преобразование - из нормализованных координат в оконные. В результате Xndc и Yndc конвертируются в координаты пиксела на экране, а Zndc преобразуется в значение глубины (depth), что идёт в z-buffer.

 

Но вернёмся к нашей необычной матрице перспективной проекции. Для компонент Xndc и Yndc трансформация ничем не отличается от того, что мы привыкли видеть при трансформации стандартной матрицей перспективной проекции. Отличие лишь в способе вычисления значения Zndc. Взглянем поподробнее:

//Result of the perspective transformation:
Xc = ...;
Yc = ...;
Zc = zNear;  // = const = 0.001 (which is 1mm)
Wc = -z;

//clipping:
-Wc <= Zc <= Wc
//is the same as:
z <= zNear <= -z
//or:
z <= zNear && z <= -zNear
//it is equivalent to:
z <= -zNear //z ≡ [-0.001...-inf)

Таким образом получается, что будут отсечены все части примитивов, что находятся позади ближней плоскости отсечения (позади камеры), а эффект дальней плоскости отсечения исчезает - ВСЁ, что впереди камеры, попадёт в видимый объём:

z ≡ [-zNear...-inf)

Напомню, что из-за того, что в системе координат OpenGL точкой отсчёта выбран левый нижний угол экрана, ось z тычет юзеру прямо в глаз, так что камера сканирует сцену в направлении -z, оттого и такая отрицательность везде, где интуитивно хочется чего-то положительного.

 

Теперь посмотрим, какая в результате получится нормализованная Z координата:

//Zndc = Zc / Wc
Zndc = zNear / -z;

Учитывая, при каком диапазоне значений z фрагменты попадают в видимый объём, можно сказать, что

Zndc ≡ [1...0)

Это значит, что для фрагментов, лежащих на ближней плоскости отсечения значение Zndc будет равно 1, а по мере удаления объекта вдаль от камеры значение Zndc будет стремиться к нулю. Т.е. чем дальше объект, тем меньше значение глубины. Из этого следует, что тест глубины нужно инверсировать по отношению к дефолтному значению:

glDepthFunc(GL_GREATER); //Default is GL_LESS

Если этого не сделать, то дальние объекты будут накладываться на близлежащие - что противоположно реальности.

 

Теперь ключевой момент. Подавляющее число фрагментов будут иметь значение Zndc около нуля. Прикинем, почему так:

    z          |  Zndc
 -0.001 (1mm)  |  1
 -0.01  (1cm)  |  0.1
 -0.1   (0.1m) |  0.01
 -1     (1m)   |  0.001
 -10    (10m)  |  1e-4
 -100   (100m) |  1e-5
 -1000  (1km)  |  1e-6

Заметна обратноэкспоненциальная зависимость. И поскольку большинство отображаемых на экран фрагментов сцены находятся на расстоянии в 1-100 метров, то и глубина получается в диапазоне 1е-3..1е-5. Однако поскольку графические процессоры оперируют с числами в формате float, т.е. с плавающей запятой, околонулёвость не страшна до тех пор, пока значение Zndc не приблизится к пределу, при котором ещё сохраняется 23 бита точности (что-то около 1e-104, если не ошибаюсь) - ну т.е. тысячи километров рисовать как бы можно. Теоретиццки. На практике подвох заключается в том, что по стандарту буффер глубины имеет формат не float, а int, причём 24-битный. Результат конверсии - все околонулевые значения фрагментов, хорошо различимые в формате float внезапно примут одно и то же значение, перейдя в формат int - нуль.

 

Чтобы этого избежать нам необходимо отказаться от стандартного буффера глубины и использовать 32-битный float z-buffer (это расширение, к счастью, уже давным давно в стандарт вошло). Для этого нам придётся рендерить в отдельный FBO, что не так уж страшно, ибо в стандартный фреймбуффер никто серьёзный напрямую и не рендерит сегодня (deffered shading, antialiazing и пр. изъёбы в стандартном фреймбуффере не провернёшь).

 

И всё было бы гладко, и конец сказке, если бы не один маленький гвоздь в заднице, специфичный именно для проклятых судьбой OpenGL-неудачников. Дело в том, что глубина фрагмента (depth), которая записывается в буффер глубины, получается путём преобразования Zndc в оконные координаты. По традиции считается, что Zndc должен лежать в симметричном диапазоне [-1...1], и этот диапазон должен быть приведён к диапазону значений, специфичному для буффера глубины, т.е. [0...1]:

depth = a * Zndc + b (в простейшем стандартном случае: depth = 0.5 * Zndc + 0.5)

Проблема в том, что при прибавлении 0.5 к 1е-ххх мы получим те же 0.5, т.е. точность потеряется - все наши околонулевые значения станут неразличимыми после прибавления к ним числа, на много порядков бОльшего. Чтобы этого избежать, нам необходим прямой маппинг (a=1,b=0), тогда глубина фрагментов пойдёт в буффер глубины без изменений, и наши околонулевые значения глубины фрагментов таковыми и останутся, сохранив свои 23 бита мантиссы:

depth = 1 * Zndc + 0 = Zndc

 

К сожалению, эта фича прямого маппинга, изначально доступная счастливым пользователям DirectX стала доступна ОпенГЛьщикам лишь недавно с введением расширения ARB_clip_control в составе OpenGL4.5. Вот так она включается:

glClipControl(GL_LOWER_LEFT,GL_ZERO_TO_ONE);

Если мои прикидки верны, то буффер глубины, организованный по изложенному выше алгоритму должен быть способен различать поверхности с точностью 12см на расстоянии в 1000 км (!) при ближней плоскости отсечения в 1мм. Весьма не дурно, не правда ли?  ;)

Ну т.е. фишка в том, что точность линейно падает с расстоянием. Учитывая то, что и детализация объектов, рисуемых в отдалении, также уменьшается с расстоянием, можно сказать, что панацея от z-fighting'а скоро станет доступной и пользователям OpenGL, как только версия 4.5 войдёт в состав релиз-версий драйверов (сейчас только в бета-версиях идёт). Однако "скоро" значит далеко не завтра, к сожалению...  :P

 

Бета-дрова для nVidia скачать можно тут:

https://developer.nv...m/opengl-driver

Вот поставил щас 340.82 - из 4.5. не поддерживается только версия шейдерного языка (ну и пёс с ней). А glClipControl, вроде, пашет.  :)

 

Апдэйт (13 Апреля 2015):

Накатал статейку по новому способу построения камер для ОпенГЛ.