- Dmitry_Milk
- Участник
war_zes
> какое из двух скринов визуально правильное?
Правильное первое, но играть на нем будет сложнее, чем на втором.
Просто в реале глаз умеет в адаптацию к общей яркости, а в случае изображеня на мониторе - не может, т.к. помимо изображения на мониторе в глаз попадает много постороннего света.
Dmitry_Milk
> Правильное первое,
мне в основном интересно -почему это оно правильное, если оно искажает цвет?
ведь художник не сидит такой, "а вот это я покрашу в цвет "127;127;127".
он выбирает конкретный оттенок цвета, конкретный контраст, конкретную цветовую гамму и палитру где каждый оттенток подобран вручную
а игра такая - ну я тут цвет правильно считаю, поэтому твой серый, это не серый, это темный, потому что я пересчитал твой линейный цвет в другой, по формуле и получил 187;187;187. Ну и что что на экране оно по разному выглядит, вот послушай как работают мониторы....
war_zes
> пересчитал твой линейный цвет в другой, по формуле и получил 187;187;187.
Это у тебя пайплайн сломан. Ты берешь цвет от художника и преобразуешь по линейным формулам (ошибка здесь), а потом результат шейдера преобразуешь по sRGB формулам. Судя по всему, вот это
> текстура diffuse у моделек создана также с R8G8B8A8_SRGB
у тебя сломано.
}:+()___ [Smile]
> у тебя сломано.
там не сломано. там так и должно быть. итоговый цвет соответствует тому что должно быть на экране с srgb
но я не понимаю логики. если у художника получился серый цвет как 0.5, то почему на экране он должен рисоваться как 0.8? и наоборот, если художник же хочет чистый серый, то рисовать он должен 0.2 цветом.
в статьях же начинают писать про какие-то там особенности мониторов - как это влияет на то что я получаю совершенно другие цвета, а не те которые задал художник?
собственно вот пример,
типа слева художник подобрал зеленый цвет для своей текстурки (пеинт). он же не циферки по формулам высчитывает - он конкретно подобрал нужный оттенок на глаз. возможно под определенную палитру и прочие художественные фишки.
и вот натягивает на плоскость земли и получает... совершенно другой цвет (справа сцена с этой текстурой, никакого света - просто натягивается и все).
и все уверяют что вот это физически корректная передача цвета. wtf? я десять лет назад не мог этого понять. и сейчас не понимаю
=========================================
единственное что я допускаю, что возможно это все рассуждения в вакууме и оно все выпрямится потом, когда будут источники света, тун мапинги и прочее, ведь они все тоже осветляют сцену и возможно вернут нужный цвет. хз короче.
проверил в юнити 6.
также искажает цвета, но менее заметно
с включенным srgb на текстуре
цвет моей текстуры 34;177;76
а в юнити чуточку темнеее 33;162;77
c другой стороны если в юнити отключить srgb у текстуры - оно наоборот там ее сильно корежит
то есть с файла она мою текстуру (34;177;76) грузит уже в другом цвете уже как 101;188;142 - совершенно другой цвет
ну я так понимаю она это и делает чтобы с включенным srgb текстура была близка тому что рисовал художник и никто не спрашивал почему текстуры других цветов (хоть из преобразований оно все равно не то)
Если рисовать без смешивания и вообще какого-либо освещения, вот как на картинке выше, то не должно же быть никакой разницы, включен srgb или нет, не? С включенным просто делается два раза преобразование - это всё равно что ничего не делать.
entryway
> сли рисовать без смешивания и вообще какого-либо освещения, вот как на картинке выше, то не должно же быть никакой разницы,
иишка говорит что должно и это нормально что на экран выводятся более темные цвета чем в текстурах
блин, теперь и иишка сломалась. и я теперь не знаю как же оно блин должно быть правильно.
и какая черт возьми магия делает (128,128,128) как (187,187,187), но чтобы при этом цвет оставался тем же для пипетки с экрана.
реально все запуталось
хорошо, я гружу текстуру через stb image из обычного png файла. это тупо массив байт.
я создаю текстуру для этого файла и формат определяю через glTextureStorage2D как GL_SRGB8 или GL_SRGB8_ALPHA8
я рендерю сцену в текстуру фреймбуфера, которую в свою очередь также создал GL_SRGB8_ALPHA8
и наконец я фреймбуфер бличу на свопчейн через glBlitNamedFramebuffer
у меня глобально включено glEnable(GL_FRAMEBUFFER_SRGB)
я все это проверил через RenderDoc - именно все такое там и стоит.
иишка тут мелькнула что возможно при блитинке на свопчейн оно дважды делает это srgb, и предложило отключить глобальное GL_FRAMEBUFFER_SRGB перед финальным выводом на экран... но это вот вообще никак не влияет на результат
все, нашел проблему - я текстур грузил как float (и в stb и opengl такой тип данных). вернул обратно байты и цвета стали нужными.
наверное stb что-то там внутри всеже делает при загрузке флоатом (хотя ии говорила что нет)
(и мне непонятно чего мне иишка доказывала что потемнение сцены это правильная работа и даже тесты писала для проверки именно этого потемнения)
ладно, работает и ладно.
и мне непонятно чего мне иишка доказывала что потемнение сцены это правильная работа и даже тесты писала для проверки именно этого потемнения
Индус какой-то наверное :)
war_zes
https://github.com/azhirnov/as-en/blob/dev/AE/samples/res_editor/… GB-Present.as
У меня есть таблица по sRGB, но для GL нужно свою составлять.
При блите в sRGB происходит конвертация, а при копировании - нет.
Все что работает как memcpy копирует sRGB значения, а то что через шейдер - читает линейное значение и записывает в зависимости от своего формата.
war_zes
> наверное stb что-то там внутри всеже делает при загрузке флоатом (хотя ии говорила что нет)
Да, если загрузить как unsigned char, и циклом переделать во float (побайтно поделив на 255.f), то яркость не меняется.
Либо вызвать:
stbi_ldr_to_hdr_gamma(1.0f);
Это что получается, если включить GL_SAMPLE_ALPHA_TO_COVERAGE, то сортировать прозрачные по расстоянию и не нужно?
А в чём подвох? ну разве что это работает только с MSAA, но я в принципе не против.
Бонусом к тому же у листвы пропадает мерзкое мерцание.
master-sheff
> А в чём подвох? ну разве что это работает только с MSAA, но я в принципе не против.
Ограниченное количество степеней прозрачности?
