Я наткнулся на эту статью несколько недель назад и даже добавил их метод к себе в тестовый шейдер.
Мне кажется, что утверждение авторов, о доминировании над прочими методами слегка преувеличено. Тот же Van der Corput/Hammersley sequence на мой вкус даёт более равномерное покрытие https://www.shadertoy.com/view/wd2GzD (методы меняются дефайном в 657 строчке)
Не сказал бы, что POM уж очень дорогой. В шейдере, который я делаю сейчас, разница составляет около 1 FPS (без/с POM) для 100 объектов.
Для того, чтобы высоты не «прыгали» на границе уровней тесселяции в зависимости от расстояния до камеры, вам потребуется довольно большая степень разбиения и большое количество треугольников, а это как раз довольно затратно. Я возлагаю определённые надежды на гибридную технику Displacement+POM, но пока не дошли руки написать соответствующий код.
А так POM даёт прекрасный визуальный результат. В плоскости на картинке ниже всего 4 точки по краям, а остальное «обман зрения» — POM:
Но из того, что я видел в разных туториалах (в основном про Image Based Lighting), в cubemap рисуют последовательным проходом по 6 граням куба с 6 разными камерами, смотрящими на текущую грань.
Но, судя по отрывочным сведениям из Интернета, можно и правда использовать геометрический шейдер с указанием переменной gl_Layer для каждой вершины, но полноценного рабочего примера я увы не нашёл. Также я не уверен, что это выигрышно по скорости, учитывая что у вас по сути нет никакой геометрии, а шейдер будет выполнять математические манипуляции с текстурами.
P. S. Далее я фантазирую, но можно попробовать использовать Multiple Render Target во фрагментном шейдере, где в качестве GL_COLOR_ATTACHMENT«I» будут GL_TEXTURE_CUBE_MAP_POSITIVE_X + «I». Соотвественно в шейдере использовать 6 разных ViewProjection матриц для отрисовки в 6 текстур «параллельно».
normalMatrix это — обычно матрица которая преобразует нормали из пространства координат модели в пространство координат камеры. Если её не вычислили за вас, то она может быть вычислена из матрицы ModelView вот так:
Формулы выше нужны для общего случая(т.е. когда в ModelMatrix или ModelViewMatrix записано что угодно). Если у вас не используется неравномерное масштабирование по осям [то, что раньше было известно как glScale()] при переходе из model-->world, то формулу можно упростить до:
Неплохо бы картинку или чуть более подробное пояснение того, что вы хотите сделать.
Я не понял вашу задачу, но геометрический шейдер судя по набору слов вряд ли поможет.
Vertex shader в случае Geometry Pass это — обычный passthrough шейдер, который помимо основной функции передаёт интерполированные varying атрибуты (FragPos, TexCoords, Normal) во фрагментный шейдер. FragPos и Normal представлены в мировой системе координат (умножены на Model Matrix), но на сколько я понимаю с тем же успехом могли быть представлены и в координатах камеры.
Совсем недавно делал свою реализацию Bloom-а на основе оригинальной статьи и хочу поделиться несколькими соображениями.
1) Имеет смысл сразу делать реализацию, которая использует линейную фильтрацию исходной cutoff текстуры, получается почти в два раза меньшее количество сэмплов на фрагмент.
2) Я сделал реализацию, в которой задавалась «ширина» гауссовской кривой (при помощи указания среднеквадратичного отклонения), а также количество точек сэмплинга вокруг текущего фрагмента. Практика показала, что эти параметры в общем-то лишние. Степень размытия удобнее и быстрее задавать при помощи изменения (уменьшения) размера текстур pingpongBuffer[2]. Также, результат, получаемый при количестве точек сэмплинга в скажем 7, визуально не отличается от скажем 77, если размытие сделать по крайней мере два-три раза.
3) Для финального прохода, где размытие текстуры объединяются с исходной имеет смысл использовать несколько различных текстур-результатов размытия по Гауссу, но с разной степенью размытия, как и рекомендуется в статье How to do good bloom for HDR rendering. Кроме того, имеет смысл назначить различные веса для разных текстур-размытий чтобы можно было варьировать степень их влияния на конечный результат. К сожалению, каждое дополнительное размытие по Гауссу отъедает около 5-10 FPS на моей системе: манипуляции с FBO и текстурами увы не бесплатны.
Самой сложной частью, на мой взгляд, является подбор функции тональной компрессии. Ни один более или менее стандартный алгоритм (некоторые из них можно посмотреть например тут) не давал хорошего визуального результата: дело в том, что все они снижают контрастность на участках средней яркости. Поэтому, пока я остановился на алгоритме, который применяется только для ярких участков, т.е. участков, которые изначально попадают в cutoff текстуру. Краткий смысл таков, что HDR изображение преобразуется из пространства RGB в пространство xyY сжимается в нём в части Luminance (светимости) и потом преобразуется обратно в RGB. Функция сжатия используется самая простая, что-то вроде:
float mapY = pow(xyY.z, 0.5);
Нерешённой у меня осталось проблема излишнего блеска поверхностей, которые по идее «блумить» не должны, например specular участки воды, но тут уже сказывается ограничение моего движка, т.к. я реализовал Bloom как пост-процессинг эффект, а по уму его нужно делать только для emissive (излучающих) фрагментов сцены.
А помогают ли всяческие программы для коррекции изображения на экране смягчить дефицит восприятия того или иного цвета?
Я, например, некоторое время назад реализовал пару алгоритмов по «коррекции» дальтонизма в одной игре, но до сих пор не уверен работают ли они. Буду признателен, если кто-нибудь с описанной проблемой глянет на картинку:
1) www.shadertoy.com/view/XslyzX
2) www.shadertoy.com/view/XdsczX
В обоих кусках кода есть строчка вида blindnessType = <....>, где <....> может быть одним из нижеследующего:
NONE — картинка остаётся как есть,
PROTANOPIA — дефицит восприятия красного,
DEUTERANOPIA — дефицит восприятия зелёного,
TRITANOPIA — дефицит восприятия оттенков голубого и жёлтого,
Соответственно для обоих алгоритмов интересует отличие в качестве восприятия между NONE и типом вашего дальтонизма.
Также посетил ваш сайт: вы делаете интересные вещи. Если хотя бы половина от написанного на сайте близка к коммерческой готовности, то, я бы сказал, вы находитесь во вполне себе лидирующей группе, даже по мировым меркам.
Спасибо, интересно, в своё время читал что-то похожее то ли в исходниках OVS, то ли в коммит логах.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)? Опять Spanning Tree? Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.
Кстати еще несколько вопросов. Не ёрничаю, а спрашиваю, т.к. реально хотелось бы понять:
1) Вы пишите про потребности заказчика и OF как средство их удовлетворения. Не могли бы вы привести обезличенный пример о каких потребностях идёт речь? Как вы убеждаете своих клиентов строиться на OF, а не на «стандартных» протоколах?
2) Как решается проблема управления (management) коммутаторами OpenFlow? Out of band сеть управления или как-то хитрее? Помнится, что когда я пристально изучал OpenFlow, то спецификации хранили на этот счёт гордое молчание. Проблема in-band коммуникации для канала управления ведь серьёзная, из серии «что первично: курица или яйцо». Если не совсем понятно о чём речь, то спрошу так: кто/что прописывает flow для доступа между OF-element и OF-controller при первом(первоначальном) включении коммутатора?
3) Я так понимаю ЦПИКС делает контроллер и приложения для него? В мире как известно помимо чистых OpenFlow контроллеров, которых не меньше 5, есть еще и универсальные гиганты OpenDayLight и ONOS. Почти все контроллеры (по крайней мере ядро и большинство модулей) freeware/open-source. Вопрос: в чём конкурентное преимущество контроллера ЦПИКС, кроме того, что он сделан в РФ?
Протокол P4 не смотрели? Он тоже из «академии». Мне понравилась простота концепции и доступность к тестированию. Не прошло и часа как я смог сделать в нём свою версию ethernet (сделал 64 битный MAC адрес) или поменять логику обработки IPv4 TTL.
Что особенно приятно API для доступа к таблицам генерируется автоматически (сравните с портянками структур из OpenFlow — прошлый век)
Как мне кажется OpenFlow уже не взлетит, т.к. от былой простоты (и одновременно полной негодности из-за комбинаторного взрыва) версии 1.0 не осталось и следа. Текущая версия — монстр, поддерживающий более 50 типов заголовков, при этом далеко не факт, что в гетерогенной среде коммутаторы производителя A и B будут поддерживать необходимый общий набор типов полей.
Продукты с поддержкой OpenFlow в основном выпущены несколько лет назад, так сказать на пике ожиданий. Сейчас, как мне кажется, к-во новых продуктов с OF пойдёт на убыль. Кроме того, оказалось не так много желающих выкинуть в помойку свою архитектуру сети и произвести дорогостоящий апгрейд с целью перехода на чистую OpenFlow сеть. Говорю об этом как представитель вендора.
С другой стороны сейчас SDN стали понимать значительно более широко, чем просто стандартный API между forwarding plane коммутаторов и контроллером. В зависимости от производителя и целевой аудитории решения можно увидеть такие вещи как:
Открытая операционная система на «голом металле» (см. Cumulus, Open Network Linux)
Open Source API для взаимодействия с ASIC-ами или попытки написать универсальную обёртку над несколькими типами ASIC-ов (SAI, OpenNSL)
Открытые и стандартизированные API для доступа к возможностям устройства (a-la RESTCONF, NETCONF)
Универсальные языки описания конфигураций, транслируемые в конфигурации конкретных вендоров (например NAPALM)
Использование существующих протоколов (с небольшими расширениями) для построения маршрутов из центральной точки управления. Segment Routing, BGP-LS и прочее
Попытки использования статистики и аналитики для управления сетью как единой системой
В общем происходит очень много интересного, SDN в широком смысле этого слова растёт и развивается — уж больно солидные преимущества просматриваются в средне-дальней перспективе, но ставить на OF в конце 2016 года ИМХО ошибка.
У меня Lenovo T440p под управлением ArchBang (по сути ArchLinux с очеловеченной установкой системы).
Действительно, раньше сильно грелся. Вчера по мотивам статьи выполнил схожие манипуляции с TLP и очень доволен результатом: вентилятор почти не включается.
Да, слышал. Думаю, что за этим направлением будущее.
Уже сейчас есть некоторое количество современных лекарств, которые представляют собой моноклональные антитела, которые выражаясь рабоче-крестьянским языком цепляются к определённым участкам клеток и доставляют туда либо яд, либо источник радиации. Как я понял, многие такие исследования, увы застряли на стадии исследований или единичных успешных случаев: путь из лаборатории в аптеку крайне долог и тернист. Кроме того, есть проблема со стоимостью лечения. Например: цена одной инъекции Zevalin составляет больше $37K.
Вообщем мог бы описать подробнее: как себя чувствовал, как это развивалось, про врачей, про отношение семьи к этому итд.
Чувствовал себя в целом нормально, кроме так называемых B-симптомов: бывало страшновато, когда просыпался среди ночи, а твоё одеяло насквозь мокрое.
Как развивалось и про врачей, в принципе, всё как написано в статье. Ни добавить, ни убавить.
Про реакцию семьи писать не буду, т.к. это очень личное.
Тогда прошу прощения, что неверно вас понял. По статье ничего подобного не скажешь — конкретной информации мало, она вся размытая, больше похожа на подводку к рекламе какой нибудь израильской клиники.
Нет, зарубежных и платных клиник в моей истории нет, только хардкор.
Если вы настолько не хотите озвучивать диагноз — непонятно, зачем писали статью.
У статьи будет продолжение, возможно даже два. Там и напишу. Написать диагноз — не самоцель. Целью является скорее указать на количество врачебных ошибок на пути его получения, на мои сомнения в тех или иных случаях, на то, что я сделал так и что не так. Так сказать рассказать историю и сделать выводы.
Если у вас есть профессиональные исследователи (и вероятно деньги на оплату их услуг)
У меня лично исследователей нет. Я вероятно неверно выразился. Имелось в виду, что я не являюсь учёным и не могу делать выводов или предположений, т.к. полностью некомпетентен, а могу лишь собрать воедино и проанализировать ту информацию, которую добыли до меня компетентные люди.
Pubmed я штудировал, т.к. хотел иметь подобие гарантии, что меня лечат правильно и современно и чтобы разговаривать с врачом на одном языке. Кстати, пользуясь случаем, рекомендую этим не пренебрегать.
статистики (выживаемости, осложнений итд)
Увы, пока онкология это — статистика. Если у пациента будет +5% шанса к выживаемости, уже намного лучше.
А так да, это мои первые шейдеры, прям вот первый и второй.
Поэтому прошу строго не судить.
Мне кажется, что утверждение авторов, о доминировании над прочими методами слегка преувеличено. Тот же Van der Corput/Hammersley sequence на мой вкус даёт более равномерное покрытие https://www.shadertoy.com/view/wd2GzD (методы меняются дефайном в 657 строчке)
Для того, чтобы высоты не «прыгали» на границе уровней тесселяции в зависимости от расстояния до камеры, вам потребуется довольно большая степень разбиения и большое количество треугольников, а это как раз довольно затратно. Я возлагаю определённые надежды на гибридную технику Displacement+POM, но пока не дошли руки написать соответствующий код.
А так POM даёт прекрасный визуальный результат. В плоскости на картинке ниже всего 4 точки по краям, а остальное «обман зрения» — POM:
Но из того, что я видел в разных туториалах (в основном про Image Based Lighting), в cubemap рисуют последовательным проходом по 6 граням куба с 6 разными камерами, смотрящими на текущую грань.
Но, судя по отрывочным сведениям из Интернета, можно и правда использовать геометрический шейдер с указанием переменной gl_Layer для каждой вершины, но полноценного рабочего примера я увы не нашёл. Также я не уверен, что это выигрышно по скорости, учитывая что у вас по сути нет никакой геометрии, а шейдер будет выполнять математические манипуляции с текстурами.
P. S. Далее я фантазирую, но можно попробовать использовать Multiple Render Target во фрагментном шейдере, где в качестве GL_COLOR_ATTACHMENT«I» будут GL_TEXTURE_CUBE_MAP_POSITIVE_X + «I». Соотвественно в шейдере использовать 6 разных ViewProjection матриц для отрисовки в 6 текстур «параллельно».
Т.к. тут в текстуры решили записать значения в world space, то соответственно здесь преобразование будет такое же, но от другой исходной матрицы:
Формулы выше нужны для общего случая(т.е. когда в ModelMatrix или ModelViewMatrix записано что угодно). Если у вас не используется неравномерное масштабирование по осям [то, что раньше было известно как glScale()] при переходе из model-->world, то формулу можно упростить до:
Я не понял вашу задачу, но геометрический шейдер судя по набору слов вряд ли поможет.
Технику Forward+ не смотрели? Немного похоже по описанию на реализацию из вашего движка.
Vertex shader в случае Geometry Pass это — обычный passthrough шейдер, который помимо основной функции передаёт интерполированные varying атрибуты (FragPos, TexCoords, Normal) во фрагментный шейдер. FragPos и Normal представлены в мировой системе координат (умножены на Model Matrix), но на сколько я понимаю с тем же успехом могли быть представлены и в координатах камеры.
Вот исходники G-прохода из оригинальной статьи (учтите, адрес заблокирован на территории РФ):
learnopengl.com/code_viewer_gh.php?code=src/5.advanced_lighting/8.1.deferred_shading/8.1.g_buffer.vs
learnopengl.com/code_viewer_gh.php?code=src/5.advanced_lighting/8.1.deferred_shading/8.1.g_buffer.fs
Либо так, либо для последнего фреймбуфера.
1) Имеет смысл сразу делать реализацию, которая использует линейную фильтрацию исходной cutoff текстуры, получается почти в два раза меньшее количество сэмплов на фрагмент.
2) Я сделал реализацию, в которой задавалась «ширина» гауссовской кривой (при помощи указания среднеквадратичного отклонения), а также количество точек сэмплинга вокруг текущего фрагмента. Практика показала, что эти параметры в общем-то лишние. Степень размытия удобнее и быстрее задавать при помощи изменения (уменьшения) размера текстур pingpongBuffer[2]. Также, результат, получаемый при количестве точек сэмплинга в скажем 7, визуально не отличается от скажем 77, если размытие сделать по крайней мере два-три раза.
3) Для финального прохода, где размытие текстуры объединяются с исходной имеет смысл использовать несколько различных текстур-результатов размытия по Гауссу, но с разной степенью размытия, как и рекомендуется в статье How to do good bloom for HDR rendering. Кроме того, имеет смысл назначить различные веса для разных текстур-размытий чтобы можно было варьировать степень их влияния на конечный результат. К сожалению, каждое дополнительное размытие по Гауссу отъедает около 5-10 FPS на моей системе: манипуляции с FBO и текстурами увы не бесплатны.
Самой сложной частью, на мой взгляд, является подбор функции тональной компрессии. Ни один более или менее стандартный алгоритм (некоторые из них можно посмотреть например тут) не давал хорошего визуального результата: дело в том, что все они снижают контрастность на участках средней яркости. Поэтому, пока я остановился на алгоритме, который применяется только для ярких участков, т.е. участков, которые изначально попадают в cutoff текстуру. Краткий смысл таков, что HDR изображение преобразуется из пространства RGB в пространство xyY сжимается в нём в части Luminance (светимости) и потом преобразуется обратно в RGB. Функция сжатия используется самая простая, что-то вроде:
Нерешённой у меня осталось проблема излишнего блеска поверхностей, которые по идее «блумить» не должны, например specular участки воды, но тут уже сказывается ограничение моего движка, т.к. я реализовал Bloom как пост-процессинг эффект, а по уму его нужно делать только для emissive (излучающих) фрагментов сцены.
А помогают ли всяческие программы для коррекции изображения на экране смягчить дефицит восприятия того или иного цвета?
Я, например, некоторое время назад реализовал пару алгоритмов по «коррекции» дальтонизма в одной игре, но до сих пор не уверен работают ли они. Буду признателен, если кто-нибудь с описанной проблемой глянет на картинку:
1) www.shadertoy.com/view/XslyzX
2) www.shadertoy.com/view/XdsczX
В обоих кусках кода есть строчка вида blindnessType = <....>, где <....> может быть одним из нижеследующего:
NONE — картинка остаётся как есть,
PROTANOPIA — дефицит восприятия красного,
DEUTERANOPIA — дефицит восприятия зелёного,
TRITANOPIA — дефицит восприятия оттенков голубого и жёлтого,
Соответственно для обоих алгоритмов интересует отличие в качестве восприятия между NONE и типом вашего дальтонизма.
Спасибо!
Также посетил ваш сайт: вы делаете интересные вещи. Если хотя бы половина от написанного на сайте близка к коммерческой готовности, то, я бы сказал, вы находитесь во вполне себе лидирующей группе, даже по мировым меркам.
А как тогда решается вопрос отказоустойчивости и неизбежных в избыточносоединенённых топологиях бесконечных циркуляций BUM трафика (штормов)? Опять Spanning Tree? Хотел бы посмотреть как это всё работает в топологии из хотя бы 50 коммутаторов, организованной в несколько колец.
1) Вы пишите про потребности заказчика и OF как средство их удовлетворения. Не могли бы вы привести обезличенный пример о каких потребностях идёт речь? Как вы убеждаете своих клиентов строиться на OF, а не на «стандартных» протоколах?
2) Как решается проблема управления (management) коммутаторами OpenFlow? Out of band сеть управления или как-то хитрее? Помнится, что когда я пристально изучал OpenFlow, то спецификации хранили на этот счёт гордое молчание. Проблема in-band коммуникации для канала управления ведь серьёзная, из серии «что первично: курица или яйцо». Если не совсем понятно о чём речь, то спрошу так: кто/что прописывает flow для доступа между OF-element и OF-controller при первом(первоначальном) включении коммутатора?
3) Я так понимаю ЦПИКС делает контроллер и приложения для него? В мире как известно помимо чистых OpenFlow контроллеров, которых не меньше 5, есть еще и универсальные гиганты OpenDayLight и ONOS. Почти все контроллеры (по крайней мере ядро и большинство модулей) freeware/open-source. Вопрос: в чём конкурентное преимущество контроллера ЦПИКС, кроме того, что он сделан в РФ?
Что особенно приятно API для доступа к таблицам генерируется автоматически (сравните с портянками структур из OpenFlow — прошлый век)
Продукты с поддержкой OpenFlow в основном выпущены несколько лет назад, так сказать на пике ожиданий. Сейчас, как мне кажется, к-во новых продуктов с OF пойдёт на убыль. Кроме того, оказалось не так много желающих выкинуть в помойку свою архитектуру сети и произвести дорогостоящий апгрейд с целью перехода на чистую OpenFlow сеть. Говорю об этом как представитель вендора.
С другой стороны сейчас SDN стали понимать значительно более широко, чем просто стандартный API между forwarding plane коммутаторов и контроллером. В зависимости от производителя и целевой аудитории решения можно увидеть такие вещи как:
В общем происходит очень много интересного, SDN в широком смысле этого слова растёт и развивается — уж больно солидные преимущества просматриваются в средне-дальней перспективе, но ставить на OF в конце 2016 года ИМХО ошибка.
Действительно, раньше сильно грелся. Вчера по мотивам статьи выполнил схожие манипуляции с TLP и очень доволен результатом: вентилятор почти не включается.
Уже сейчас есть некоторое количество современных лекарств, которые представляют собой моноклональные антитела, которые выражаясь рабоче-крестьянским языком цепляются к определённым участкам клеток и доставляют туда либо яд, либо источник радиации. Как я понял, многие такие исследования, увы застряли на стадии исследований или единичных успешных случаев: путь из лаборатории в аптеку крайне долог и тернист. Кроме того, есть проблема со стоимостью лечения. Например: цена одной инъекции Zevalin составляет больше $37K.
Чувствовал себя в целом нормально, кроме так называемых B-симптомов: бывало страшновато, когда просыпался среди ночи, а твоё одеяло насквозь мокрое.
Как развивалось и про врачей, в принципе, всё как написано в статье. Ни добавить, ни убавить.
Про реакцию семьи писать не буду, т.к. это очень личное.
Нет, зарубежных и платных клиник в моей истории нет, только хардкор.
У статьи будет продолжение, возможно даже два. Там и напишу. Написать диагноз — не самоцель. Целью является скорее указать на количество врачебных ошибок на пути его получения, на мои сомнения в тех или иных случаях, на то, что я сделал так и что не так. Так сказать рассказать историю и сделать выводы.
У меня лично исследователей нет. Я вероятно неверно выразился. Имелось в виду, что я не являюсь учёным и не могу делать выводов или предположений, т.к. полностью некомпетентен, а могу лишь собрать воедино и проанализировать ту информацию, которую добыли до меня компетентные люди.
Pubmed я штудировал, т.к. хотел иметь подобие гарантии, что меня лечат правильно и современно и чтобы разговаривать с врачом на одном языке. Кстати, пользуясь случаем, рекомендую этим не пренебрегать.
Увы, пока онкология это — статистика. Если у пациента будет +5% шанса к выживаемости, уже намного лучше.
Да, знакомое чувство. Удачи!