| Гость |
Вы не зарегистрированны? Нажмите здесь для регистрации.
Забыли пароль? Запросите новый здесь.
|
|
| Сейчас на сайте |
Гостей: 2
На сайте нет зарегистрированных пользователей
Пользователей: 1,795
новичок: BlitzID
|
|
|
| Обсуждение «Вертикальный мусор в OpenGL» |
|
| Опубликовано 27.04.2021 04:21 (5 лет назад) # |
Всем!
Обратил внимание, что при некоторых масштабах изображения, отличных от "чистых" х1 х2 х3, при выводе на OpenGL появляется "мусор", в виде вертикальных линий. Может кто сталкивался с таким и знает как это забороть? Это связано с тестами глубины или куда рыть?
(проекция орто, если что, тест глубины выключен)
|
|
|
|
|
| Опубликовано 27.04.2021 04:56 (5 лет назад) # |
Повнимательнее присмотрелся к этм полосам, решил поСЧупать текстурные и вертексные координаты.
Вобщем, похоже OpenGL нахватывает лишнего при выемке части тектуры из одной большой. Атлас у меня 512х1024, вот что-то там явно не так с округлениями при ХХХ/512, хотя использую GLdouble.
Вобщем, вроде решил проблему, причём ломовым способом - по горизонтали поджал текстурные координаты на 0.0001 и мусор пропал (впроде как). Надеюсь, кому-нибудь пригодится. |
|
|
|
|
| Опубликовано 27.04.2021 05:12 (5 лет назад) # |
| возможно вопрос не по теме, но почему именно атлас, а не TImageList? |
|
|
|
|
| Опубликовано 27.04.2021 05:59 (5 лет назад) # |
TImageList содержит изображения для работы в VCL, а я всю графику написал на OpenGL. Вообще, вещи из разряда "мягкое vs тёплое"
Можно, конечно, загружать тонну картинок в отдельные тектсуры (я так раньше и делал), но с одной текстуры рендер работает заметно быстрее.
А TImageList, по сути, жопа капризная. Ни разнородных по размеру спрайтов загрузить, ни вменяемо прозрачность поддержать. В VCL с ним мириться ещё можно, но для OpenGL он вообще не в тему.
Я для себя вывел "формулу успеха" - текстурный атлас PNG. Решаются все проблемы скопом (для моих целей, конечно же, это не убервафельное решение на все случаи жизни).
редакция от Shirson, 27.04.2021 06:00 |
|
|
|
|
| Опубликовано 27.04.2021 06:43 (5 лет назад) # |
хм, буду знать
просто планирую чуть позже тоже на делфе что то собрать, но только на firemonkey
прошлый опыт загружал процессор чуть бы не на 100%) |
|
|
|
|
| Опубликовано 27.04.2021 07:42 (5 лет назад) # |
| Вероятно, поможет GL_CLAMP_TO_EDGE. |
|
|
|
|
| Опубликовано 27.04.2021 13:45 (5 лет назад) # |
В некотором роде помогло... :) (после конкурса буду разбраться)
редакция от Shirson, 27.04.2021 13:46 |
|
|
|
Инженер‑космогоник
|
| Опубликовано 27.04.2021 20:04 (5 лет назад) # |
Это реально похоже на режим развертки текстур
Нужен Clamp, а используется repeat, он стандартный.
|
|
|
|
|
| Опубликовано 03.05.2021 11:22 (5 лет назад) # |
| Не хватает деталей: как выглядит атлас и какой режим текстурной фильтрации в OpenGL выбран. Кажется, что нужно (1) либо в атласе сделать отступ в 1 пиксель вокруг каждой текстурки с цветом пограничного пикселя, (2) либо полностью отключить в OpenGL текстурную фильтрацию, чтобы соседние пиксели не замешивались. |
|
|
|
|
| Опубликовано 03.05.2021 20:49 (5 лет назад) # |
Я грешу на ошибку округления/деления, потому что изначально текстурная фильтрация (я в этом деле ещё не очень волоку, это мой первый обёртК для OpenGL) изначльно задана как GL_NEAREST для обоих случаев скейла. Тем более, что проявляется загон только по вертикали (т.е. при обработке тектурных координат по малой стороне атласа, который 512х1024).
Поджатые тектурные координаты вполне себе работают.
Я эксперементировал с разными вариантами, включая и пустое пространство и клампинг, но это всё больше роляет при фильтрации отличной от манхетенновской (т.е. не GL_NEAREST, а GL_LINEAR, например)
Пока результат фикса с поджатием меня устроил, для текущих условий, посмотрим, как будет дальше. Судя по экспериментам, клампинг на фильтр и экструд на текстуре (как раз отсутуп в один пиксель с цветом границы) с этим справляется. |
|
|
|
Перейти на форум:
|
|
|
|
| Конкурсы |
|
Открытые конкурсы:
|
|
|