Войти
ПрограммированиеФорумГрафика

выравнивание текстуры GL_NEAREST по UV координатам в формате GLubyte (2 стр)

Страницы: 1 2
#15
8:12, 15 мар. 2017
Изображение

Извините.


#16
9:41, 15 мар. 2017
nonamezerox

вот такие текстуры нужно натягивать :)

#17
9:59, 15 мар. 2017

bigov
> Немного напрягает отсутствие аналогичного базового типа в С++, надо подбирать реализацию или рисовать свой вариант.
https://github.com/opencv/opencv/blob/master/3rdparty/openexr/Half/half.h

#18
10:23, 15 мар. 2017

Andrey
> https://github.com/opencv/opencv/blob/master/3rdparty/openexr/Half/half.h

Возьми с полки пирожок!

#19
11:28, 15 мар. 2017

innuendo

Тогда, дабы соответствовать нужно так:

tekctypa | выравнивание текстуры GL_NEAREST по UV координатам в формате GLubyte
#20
16:37, 15 мар. 2017

Ставлю пиво, тому кто найдет проблему в коде. Вот код:

+ Показать

Текстура - 256х256 разноцветных пикселей. Вот результат (правый и верхний ряд пикселей рубится):

тест текстур | выравнивание текстуры GL_NEAREST по UV координатам в формате GLubyte

По-моему и внизу тоже немного подрезано.

#21
16:44, 15 мар. 2017

nonamezerox
> Тогда, дабы соответствовать нужно так

это типа в виртуальной рельности. Ничего, я бы и такую натянул :-D

#22
19:46, 15 мар. 2017

bigov
> Ставлю пиво, тому кто найдет проблему в коде. Вот код:
Посмотрел твой код. Все правильно, о чем я и говорил. UBYTE нормализуется через деление на 255. Короче можно адресовать текстуру в 255*255, а не 256*256.

Вот смотри, например текстура у тебя 2*2. Тебе нужно адресовать не пиксели в текстуре, а границы пикселей:
UV | выравнивание текстуры GL_NEAREST по UV координатам в формате GLubyte
Несмотря что текстура 2 пикселя в ширину - для адресации границ тебе нужно 3 различных числа. Так что одним битом адресовать текстуру 2*2 не выйдет. Аналогично с текстурой 256*256.
Если уменьшишь текстуру до 255 в своем примере, то справа пример починится (а слева сломается конечно, но это уже из-за кривых текстурных координат)

#23
20:07, 15 мар. 2017

Короче, чтобы починить твой семпл - делай текстуру 255*255, а float координаты в своем примере меняй на:

  float tex_data[] = {
    0.11764705882352941176470588235294, 0.11764705882352941176470588235294, 0.17647058823529411764705882352941, 0.11764705882352941176470588235294, 0.17647058823529411764705882352941, 0.17647058823529411764705882352941,
    0.17647058823529411764705882352941, 0.17647058823529411764705882352941, 0.11764705882352941176470588235294, 0.17647058823529411764705882352941, 0.11764705882352941176470588235294, 0.11764705882352941176470588235294
  };
Тогда и левая и правая часть будет выглядить одинаково.

#24
20:14, 15 мар. 2017

не знал, что float может иметь столько циферов...

#25
20:18, 15 мар. 2017

innuendo
> не знал, что float может иметь столько циферов...
Домашнее задание тебе, обреж эти цифири до тех, которые влазят во флоат.

#26
3:09, 16 мар. 2017

MrShoor

Ммммать! Точно - глаз замылился!! Или мозг. Неделю не видел вроде как очевидной вещи - РАЗМЕР ТЕКСТУРНОЙ КАРТЫ ДОЛЖЕН БЫТЬ КРАТНЫМ РАЗМЕРНОСТИ ЧИСЕЛ ИСПОЛЬЗУЕМЫХ ДЛЯ АДРЕСАЦИИ.

> справа пример починится (а слева сломается

В GLubyte ничего не ломается. Чисто выбираются прямоугольники в любом месте, любого размера от пикселя до полной картинки.

Кстати, откуда взялась эта рекомендация (в каждом мануале!) о необходимости соблюдать размер текстурной карты кратным степени двойки?

Если у меня два десятка текстурных карт и десять миллионов вершин, то мне пофигу как в памяти лягут массивы с картами - принципиальной будет разница адресовать текстуры всего двумя (2*sizeof(GLubyte)) или по восемь байт (2*sizeof(GLfloat)) на каждую вершину (при одинаковом качестве!).

#27
3:16, 16 мар. 2017

MrShoor
> слева сломается конечно

Я понял - это про прямоугольник слева, а не про левую границу второго прямоугольника. Это понятно - я его нарисовал для "чистоты" теста. Мы уже выяснили, что для удобной работы с флоат нужна текстура кратная 256.

#28
3:17, 16 мар. 2017

bigov
> Кстати, откуда взялась эта рекомендация (в каждом мануале!) о необходимости
> соблюдать размер текстурной карты кратным степени двойки?
Текстурный кеш раньше был вот таким: https://en.wikipedia.org/wiki/Z-order_curve
Сейчас насколько я знаю там тоже Z curve оптимизации используются, но более хитрые, и они меньше бьют по производительности для NPOT текстур.

#29
3:34, 16 мар. 2017

MrShoor
> Z curve оптимизации

Понятно - на производительность будет влиять число пикселей, которым я оборачиваю фрагмент изображения. Его желательно делать кратным двойке. Размер полной карты не должен особо влиять. Буду тестить. Спасибо, за подсказку - помощь просто огромная!

Страницы: 1 2
ПрограммированиеФорумГрафика

Тема в архиве.