OpenGl Рисуем в Фоне, возможно ли?

[Alex2013]

Вообщем что-то такое получилось ...
Тестовая программа :
1 Ловит кадр с камеры.
2 Делает из битмапа контекст для OpenGL
3 Делает фоновую текстуру из захваченного кадра
4 Выводит на контекст загруженную из файла модель
5 Закрывает контекст и копирует нарисованное "в фоне" изображение на обычный Паинт Бокс (чтобы не мерцало )



Но файл не зря называется MoiaGadost01.jpg ...
Проблемы :
1 Почему-то переворачивает текстуру "вверх-тормашками"
(Временно "прибил" просто перевернув кадр до загрузки в текстуру... мелочь но быстродействие все-же немного ест )
2 Не ясно почему но фон видно только если рисовать кадр поверх загруженной из BMP картинки .
(Соотношение сторон ?)
Зы
Со "сдвигом по фазе" из предыдущего поста разобрался ... Просто не нужно делать в одной программе ДВА активных одновременно контекста (часть параметров свободно переходит из одного в другой )

Зы Зы
Тестовая программа "потолстела" но принципиально там ничего не изменилось. Так что выкладывать в эту тему не буду.
Все равно я её скоро сделаю частью полностью и регулярно заливаемой на форум "Подзорной трубы".

[olegy123]

5 Закрывает контекст и копирует нарисованное "в фоне" изображение на обычный Паинт Бокс (чтобы не мерцало )

Это лишнее и копирует действия драйвера, но в драйвере это сделано более эффективно и возможно без задействования CPU.. - DMA,GPU-GPU.
опция в OpenGL DoubleBuffer - спасает от мерцания. Можно еще включить VSync.

1 Почему-то переворачивает текстуру "вверх-тормашками"

текстурные координаты.

[Alex2013]

5 Закрывает контекст и копирует нарисованное "в фоне" изображение на обычный Паинт Бокс (чтобы не мерцало )

Это лишнее и копирует действия драйвера, но в драйвере это сделано более эффективно и возможно без задействования CPU.. - DMA,GPU-GPU.
опция в OpenGL DoubleBuffer - спасает от мерцания. Можно еще включить VSync.

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

1 Почему-то переворачивает текстуру "вверх-тормашками"

текстурные координаты.

Это понятно, не понятно почему в версии без вывода на битмап все было как надо .

Но вообще я от идеи "фонового битмапа" все равно отказался ... Сделал проще! Вывел модель на черный фон ...
И "сложил" с кадром ... Как-то так :


Дополнительно сделал красивую прозрачность ...

Код: Выделить всё

/ Прозрачность
procedure Blend2(Const Src1,Src2,Dst: TBitmap; CT: Integer;Amount: extended);
var w,h,x,y:integer;
    ps1,ps2,pd:pbytearray;
begin
w:=Src1.Width;
h:=Src1.Height;

for y:=0 to h-1 do begin
ps1:=Src1.ScanLine[y];
ps2:=Src2.ScanLine[y];
Dst.BeginUpdate; ;
pd:=Dst.ScanLine[y];
for x:=0 to w-1 do
If RGB(ps2[x*3+2],ps2[x*3+1],ps2[x*3])<>CT then
begin
If ABS(Amount-1)>=0.09   then begin
  pd[x*3]  :=round((1-Amount)*ps1[x*3]+Amount*ps2[x*3]);
  pd[x*3+1]:=round((1-Amount)*ps1[x*3+1]+Amount*ps2[x*3+1]);
  pd[x*3+2]:=round((1-Amount)*ps1[x*3+2]+Amount*ps2[x*3+2]);
  end else
  begin
   Move(ps2[x*3], pd[x*3],3);
  end
  end else Move(ps1[x*3], pd[x*3],3);
Dst.EndUpdate;
end;
end;


[olegy123]

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

не проще указывать перст в 3D мире, а не гнать текстуру туда сюда из CPU в GPU и обратно а потом посредством битмапа опять гнать в GPU..
Виртуальный перст легко превращается из экранных координат в 3D путем перемножения одной результатной матрицы MVP. Не надо гнать туда-сюда массив битмапа размероностью в 30мб.. что при FPS в 60сек легко уйти в за 1Гб/сек и это только в одну сторону (CPU->GPU).. А еще нужно раскрыть переписать, изменить и обратно перегнать в GPU..
Быть может, что еще не нашелся тот умелец, который бы выковал железо под ваши задачи.

Добавлено спустя 8 минут 17 секунд:
Лично я уперся в потолок PCIe 3.0х16 => 16Гб/с.. мне не хватило..
реально чувствовалось ширина и высота канала.. не могу с 30fps поднять до 60fps .. не когда не разгонял железку? Так чтобы NVIDIA крутила вентеляторы на максималке? А?
Надежда осталось в ведением в PCIe 4.0х16 там 31.5 Гбайт/с. https://ru.wikipedia.org/wiki/PCI_Express
но такого железа в моем магазине еще нет.
ах, PCIe 5.0х16 там 63.0 Гбайт/с

[Alex2013]

1 Разумеется можно вообще весь вывод графики делать в рамках OGL/Direct3D
НО есть "такая буква" OpenCV и разные основанные на нем расширения .
Плюс не забудь что проект пока "исследовательский" , а не прикладной.
(На этом этапе важна "прозрачность" и хотя-бы минимальное "сегментирование кода" там и так код постепенно приближается к уровню "черт ногу сломит"...
А представь, что там вместо относительно понятной 2д обработки все сразу "Бескомпромиссно" уходит в дебри OGL/Direct3D ... Ага ! Даже у винды будет один вопрос "Вешаться сразу или чуть погодя?" )


2 Как не покажется странно но "гонять туда-сюда" кадры целиком или с масштабированием не так уж и накладно (CopyMemory, BitBlt и StretchBlt работают очень быстро ) кроме основа программы ВИДЕО ПОТОК . В гонять его "в форме текстуры" занятие, как я убедился, совершенно не благодарное (Одно только "удивительное" преобразование BGR->RGB и внезапно фиксированное соотношение сторон ой как "приятно" меня удивили + почти неизбежное "мыло" . ).
Да "Прозрачность" в моем исполнении разумеется "не торт" в плане скорости (хотя особого торможения то-же не дает ) но там есть немалый резерв при использовании "блочно-построчной" обработки.

3 Скорость при "смешении жанров" 2Д и 3Д можно ускорить прорисовкой модели точно под "спрайт" . А тормоза "чисто 2Д" обработки (вроде распознавания метки) можно значительно уменьшить снижением разрешения и уменьшением регулярности поиска + привязкой к "детектору движения" .

[olegy123]

1 Разумеется можно вообще весь вывод графики делать в рамках OGL/Direct3D
НО есть "такая буква" OpenCV и разные основанные на нем расширения .

И? OpenCV нужен для анализа синтезированного OGL/Direct3D мира а не реального?

2 Как не покажется странно но "гонять туда-сюда" кадры целиком или с масштабированием не так уж и накладно (CopyMemory, BitBlt и StretchBlt работают очень быстро ) кроме основа программы ВИДЕО ПОТОК .

2К попробуй погонять.. Сейчас никто видеопоток не рисует напрямую в текстуру, для этого разработчики GPU предлагают решения которые напрямую декатируют в GPU и тамже есть доступ к памяти, можно объявить её текстурой. Также можно сделать наоборот - кодировать(стримить).при этому CPU к самой распаковки и упаковки не имеет прямого отношения. 25Мб/кадр(HD - 30fps ~ 750Мбайт/сек, 60fps - это уже 1,5Гбайт/сек что дотягивает до 16Гбит/с(2Гбайт/с) ширину канала PCIe3.0x16) против ~ 2мбит/с(H264) - есть разница?
всякие CopyMemory, BitBlt и StretchBlt - это не магические команды, они упираются в железки.

[Alex2013]

1 Желательно, иметь возможность анализировать в режиме "Смешанной реальности" (когда синтезирование объекты для программы равнозначны с реальными и взаимодействуют между собой .. ).

2 Мой уровень знаний "ускоренного мира" OGL/Direct3D пока в самом зачаточном состоянии . Он даже ниже чем мой (совсем невысокий) уровень понимания "обычной обработки изображений ". Возможно, что следующих итерациях разработки своих проектов я смогу более плотно подобраться к современной технологии 3д рэндаринга и использования возможностей GPU. Но "нельзя объять необъятное" . На этом этапе уровень реализации значительно проще .
Моя текущая цель приблизится к созданию Др-интерфейсов (Причем желательно с минимумом использования внешних библиотек, даже ОpenCV я надеюсь в ближайшем будущем банально "выпотрошить" скопировав и переписав алгоритмы )

3 OGL мне просто, что называется "под руку попался" (по идее разумнее было использовать Direct3D раз уж у меня к камере обращение идет через DirectХ )
Но не в этом суть . Мои "наполеоновские" планы пока достаточно просты и не требую разрешений уровня модного "4к". Все упирается в реальное разрешение камеры режиме видео потока .(Максимум примерно 1024х768 ...ну может еще х2 для стерео режима)

4 CopyMemory, BitBlt и StretchBlt, разумеется, не сказочные "заклинания"... Но ! Аппаратная поддержка того же BitBlt (и его аналогов ) всегда будет реализовываться в любой системе в первую очередь... (Без них не один браузер или редактор текста и просмотр картинок не обойдется. )

5 Все расчеты "пропускной способности" в программировании ДР немного не по адресу ... Есть поток кадров с камеры... есть способ вывода их на экран, без потерь скорости.... все, что происходит "под капотом" программы Др по хорошему другой поток обработки данных + где-то к этому "празднику жизни " подмешивается изображения от простенького 3д-движка (тоже некий параллельный поток ).

То есть, если в некой системе можно запустить параллельно:
А: Окошко просмотра изображения с камеры
Б: Игрушку уровня допустим первой "Халфы"(в том же разрешении что и поток с камеры)
В: некий пакетный обработчик картинок с поиском Qr кодов с частотой "слайд шоу"
/// то быстродействия и "пропускной способности" подобной системы ГАРАНТИРОВАННО ХВАТИТ на создание дополненной и смешанной реальности вполне современного уровня.

Ну а "раздуть миксированое изображение" без видимых потерь скорости и качества до полно-экранного (хоть в "4к"!), тривиальная задача, с которой справляются все современные GPU/CPU/OS.

[olegy123]

1 Желательно иметь возможность анализировать в режиме "Смешанной реальности" (когда синтезирование объекты для программы равнозначны с реальными и взаимодействуют между собой .. ).

Это как? объект который рисуете сами потом сами будете определять?
Вообще то виртуального мира не существует. Мы его посредством электроники воздействуем на наши органы чувств. Рисуем примитивы.. но зачем определять эти примитивы потом?
Это типа книгу оцифровать текст, который потом будет напечатан чтобы потом прочитать тот же текст

Аппаратная поддержка того же BitBlt (и его аналогов ) всегда будет реализовываться в любой системе первую очередь...

и они используют тут же шину PCIe. Скорость выполнения прямо зависит от ширины канала шины данных.

[Alex2013]

1 Желательно иметь возможность анализировать в режиме "Смешанной реальности" (когда синтезирование объекты для программы равнозначны с реальными и взаимодействуют между собой .. ).

Это как? объект который рисуете сами потом сами будете определять?
Вообще то виртуального мира не существует. Мы его посредством электроники воздействуем на наши органы чувств. Рисуем примитивы.. но зачем определять эти примитивы потом?
Это типа книгу оцифровать текст, который потом будет напечатан чтобы потом прочитать тот же текст

Не совсем ... Но, как я уже писал, например есть:
1 привязанная к метке "Виртуальная кнопка"
2 результат "хенд-трекинга" - изображение руки .
Разумеется, можно нарисовать "модель руки" по полученным координатам ...
Но! "К козе баян обычно не прилагается" ...
Что либо "Определять" по смешанному изображению при наличии рассчитанных заранее координат разумеется в общем случае не нужно
(Хотя как говорится "возможны варианты" где обработка "вторичного микса" будет проще ... ).
Но если нужно ПОКАЗАТЬ "взаимодействие реальностей" то нагляднее всего сделать, это в режиме "2Д-спрайта" .

Аппаратная поддержка того же BitBlt (и его аналогов ) всегда будет реализовываться в любой системе первую очередь...

и они используют тут же шину PCIe. Скорость выполнения прямо зависит от ширины канала шины данных.

Тут я имел в виду "чисто потребительское отношение" к АПИ . Мне не важно как оно реализовано важно что BitBlt и особенно StretchBlt умеют быстро выводить изображения из буфера на реально видимый элемент изображения (например тот же PaintBoх).
А "главный тормоз" обычно скрывается где угодно но не в StretchBlt (Проверка проще простого беру "чистый кадр" с камеры и вывожу его на "толстый" то бишь полный экран... - Тормоз не обнаружен? Ок! )

[Vlad04]

Проблемы :
1 Почему-то переворачивает текстуру "вверх-тормашками"

5 Закрывает контекст и копирует нарисованное "в фоне" изображение на обычный Паинт Бокс (чтобы не мерцало )

В OpenGL минимальные координаты в левом нижнем углу, а в TBitmap и PaintBox - в левом верхнем.
По поводу вывода OpenGL в TBitmap:
в Lazarus`e TBitmap реализован кривовато, вывод OpenGL в него происходит во много раз медленнее что в FBO, возможны артефакты. Для сравнения , в Дельфи скорость вывода того же рисунка примерно одинакова (по крайней мере "на глаз" незаметна), артефактов не встречал.

P.S. есть еще вариант с использованием pbuffer, но FBO быстрее и проще.