opengl z buffer

[Serg2016_1]

Ты крут.Ну ого-го, судя по картинке, перфектно, а чего там конкретно от шейдеров?
А все говорят полигоны-полигоны:))))
Если будет нечего делать, присоединяйся ко мне. У меня вакансий много (3 типа:программист/сочувствующий программист/сочувствующий),сам то я художник, а программист только по совместительству и 10 лет не брал в руки зубило.
А директX я уже делал версию, переписывал ради ликбезного интереса на многом (action script,builder,vc,builder,vb,vc,mingw,vc,dx,gldx,gl),
Устроен конечно dx жутко, я всегда не понимал зачем Билли написал второй opengl и назвал его Ха (наверное Хороший), но по моему под Виндой dx действительно побыстрее иногда чудодейственно (Это не потому, что мелкие Винду написали, а потому, что у них хорошие программисты:))))

[Sapersky]

Цитата

Не пошло́

Поправил. Хотя texture1D формально deprecated в старших версиях GLSL, компилятор AMD её почему-то пропускал. Наверное, выдавал ворнинг, но кто ж их читает...
Прикреплённый файлVoxGL2.zip (99,42 Кбайт, скачиваний: 181)

Цитата

Ну ого-го, судя по картинке, перфектно, а чего там конкретно от шейдеров?

Там всё рисование в шейдере.
Сейчас в шейдерах можно писать на почти полноценном C - условия, циклы, всё достаточно быстро отрабатывается на современном железе. Конкретно compute shaders хоть и называются "шейдерами", но по факту ближе к CUDA/OpenCL, в том смысле что не привязаны к пикселям-полигонам. Можно перенести на GPU почти любой алгоритм, при условии что он хорошо параллелится, т.е. отдельные элементы данных (в данном случае столбцы картинки) можно обрабатывать независимо друг от друга.
А недостатков и ограничений у воксельного рендера тоже хватает. Несглаженные данные с резкими пиками плохо переваривает, особенно вертикальные поверхности - билинейный фильтр при попадании на ребро усредняет верхнюю и нижнюю точки.

[Славян]

Цитата Sapersky @ 30.03.16, 16:06

Поправил.

Увы, токмо чёрный экран рисуется. FPS=200..2000. OpenGL 4.5 поддерживается. Что-то ещё не так...

[Sapersky]

Если FPS меняется, то вероятно оно рисуется, но не выводится на экран.
Добавил проверок на ошибки, ещё S теперь сохраняет в файл текстуру, в которую всё рендерится. Может хоть так можно будет что-то увидеть.
Прикреплённый файлVoxGL3.zip (98,79 Кбайт, скачиваний: 171)

[Славян]

Цитата Sapersky @ 30.03.16, 22:42

Добавил проверок на ошибки, ещё S теперь сохраняет в файл текстуру, в которую всё рендерится. Может хоть так можно будет что-то увидеть.

= Файлы создаются. Такие же чёрные, одноцветные. =

[Sapersky]

Действительно, на Nvidia не работало, но сейчас починил.
Прикреплённый файлVoxGL4.zip (100,07 Кбайт, скачиваний: 196)

[Славян]

Цитата Sapersky @ 31.03.16, 12:19

сейчас починил.

Да, сейчас работает! А можно ли какой-то куб/шар сверху рельефа нарисовать, дабы убедиться, что расчёт идёт не по правилу z=f(x,y) ? Или же в отрисовке существенно используется, что есть непрерывный=нескончаемый слой вокселов вниз, а потому 'летающие острова' сей механизм пока не сможет показать?..

[Sapersky]

Вообще-то там именно z=f(x,y).
Я брал за основу алгоритм от Comanche 92-го рода, он достаточно ограниченный, в частности, наклона камеры вправо-влево нет.
http://www.flipcode.com/archives/Realtime_...Structure.shtml
Хотя движок Voxlap, который (как утверждают) работает на модифицированной версии того же алгоритма, поддерживает трёхмерные структуры и наклон камеры.
http://www.advsys.net/ken/voxlap/voxlap03.htm
Но c ним я ещё не разбирался.

С трёхмерными структурами проблема вообще не столько в алгоритме рендера, сколько в хранении данных. Объёмы резко возрастают, в несжатую 3D-текстуру уже ничего высокодетального не запихнёшь. А с древовидными структурами (sparsed voxel octrees) на GPU пока не хочется заморачиваться.
Демка Volcanic с ShaderToy ничего не хранит, она генерирует пещеры "на лету" 3D-перлином или чем-то подобным, но опять же по детализации есть ограничения, иначе генератор будет слишком тормозить.

[Serg2016_1]

Вот я и как-раз хотел спросить про voxlap, я немного подумал над ним, а потом нашел нирвану в вэйвсерфинге и забыл, где сейчас и нахожусь. Очень классные демки Сильвермана с домиком, где копать можно и воксельштейн. Лучшее что мне ответили в сети: Присоединяйся к копающим Вокслап, а страшное типа того: Да там все просто, квадратизируешь пачками кубы и октодерево здесь не причем........ А между тем очень интересно как он работает..... Работает на древних компах, криомозг не нужен... От него походу пошел Автомонтаж кажется...
Предмет моей мечты - это true3d flight simulator на вокселях, а еще хочу сделать скроллшутер с космонавтом с воксельным фоном...

Сообщение отредактировано: Serg2016_1 - 01.04.16, 09:05

[Serg2016_1]

А, что в dx ограничен fps 60? Непонятно почему упал фпс... Блок не имеющий отношения к gl/dx раньше по rdtsc был 26 мегатиков, стал 40.... И финальный вопрос: Как перебросить збуффер в текстуру? Впочем с фпс разобрался -o3 стало 23 вместо 26, плюс теряю 5 кадров наверное на цикл перебора текстуры....

Сообщение отредактировано: Serg2016_1 - 02.04.16, 11:07

[Sapersky]

Цитата

квадратизируешь пачками кубы и октодерево здесь не причем

Сильверман в конечном итоге пришёл именно к октодереву в последней демке.
"I'd rather not get into details yet, but I will say that PND3D is a SVO-based front-to-back splatter with extensive use of assembly language"
http://www.advsys.net/ken/voxlap/pnd3d.htm
https://www.reddit.com/r/VoxelGameDev/comme...o_voxlap_pnd3d/

Цитата

А, что в dx ограничен fps 60? <...> И финальный вопрос: Как перебросить збуффер в текстуру?

FPS может по умолчанию привязываться частоте монитора.
Если это DX9, задать при инициализации девайса D3DPresentParameters.PresentationInterval := D3DPRESENT_INTERVAL_IMMEDIATE;
Z-буфер - CreateTexture c D3DUSAGE_DEPTHSTENCIL, потом Device.SetDepthStencilSurface, потом наверное использовать текстуру как обычно. Или через шейдер, в OGL, насколько помню, depth-текстура "как обычно" не работает.

Сообщение отредактировано: Sapersky - 02.04.16, 21:24

[Serg2016_1]

Ну, буду копать.......... ))
А я тут озадачился, что если использовать вместо доступа к массиву (readpixels)/(unlock/read/lock). Еще не успел сделать замеры, но дело в том, что при непоследовательном доступе к большим массивам время доступа меняется от 0.1-20 мс (как правило 20 ((). Тормозит ли чего unlock/lock? Это все если конечно без Куды (Как я понял там доступ к массивам в видеопамяти поставлен на конвейер) И можно-ли достать из текстуры интерполированное значение в точке, типа read(3.5454,5.34432........... Я, хоть и враг анизотропной белины, но для рельефа полезно...

[Sapersky]

Каких-то чудес от unlock/read/lock ждать не стоит, на современных системах оно быстро не работает.
Вообще постоянные пересылки в видеокарту и обратно не могут работать очень быстро, я вроде бы с самого начала об этом писал. Даже в CUDA/OpenCL лучше ими не злоупотреблять.

А кстати, зачем читать Z-буфер в софтверном воксельном движке? Можно же наоборот - генерировать Z-буфер при рендере ландшафта, загонять всё в видеокарту и потом выводить полигональные объекты. Опять же можно пересылать только небольшие фрагменты вокруг 3D-объектов. С lock/unlock для пересылки я бы не связывался, мне кажется, лучше загнать Z-буфер в текстуру, а потом в шейдере (простые шейдеры должна поддерживать любая карта) писать собственно в Z-буфер.
В целом на 100% не поручусь, что это будет быстрее чтения Z-буфера (не всегда пересылка "туда" быстрее пересылки "обратно", иногда и почти одинаково), но попробовать можно.

Интерполированное значение - разве что вручную посчитать билинейную интерполяцию. Можно нагуглить готовое по запросам "bilinear filter c++" и т.п.

[Serg2016_1]

unlock приходится делать все равно, практика показала, что для заделки дыр лучше пройти массив после рендера (по ср. с gl не тормозит). А второй вариант с збуффером, постоянно где-то лежит у меня в мозге, правда, реализация выглядит для меня немного муторной. Текстуру с моим забором надо куда-то приделать, чтобы при рендере дх учитывал ее и складывал со своим забором? А как рендер будет рисовать мою плоскость с ландшафтом, тоже учитывая суммарный результат?
Именно софт-фильтрацией я сейчас и интерполирую кубы рельефа, отъедает порядком кусок фпс... Если не хард, может алгоритм, какой получше есть...
И вообще, там впереди много графической ерунды предстоит, так, что повторюсь: если кому интересно и нечего делать присоединяйтесь, одному мне этого слона трудно будет передвинуть...

Сообщение отредактировано: Serg2016_1 - 03.04.16, 12:21

[Sapersky]

Я полагал, что ландшафт софтверно рендерится c уже нужным положением камеры, и в 3D картинка просто растягивается на весь экран перпендикулярно камере (можно сказать, выводится как 2D-картинка).
С Z-буфером возможно придётся повозиться, чтобы он корректно рассчитывался по стандартам DX/OGL. Но и при чтении из него всё равно нужно эти стандарты учитывать.

Цитата

Если не хард, может алгоритм, какой получше есть...

Вроде нет, билинейный фильтр по 4-м точкам - самое быстрое сглаживание, разве что SSE к нему прикрутить.
http://fastcpp.blogspot.ru/2011/06/bilinea...-using-sse.html

Цитата

если кому интересно и нечего делать присоединяйтесь

Ну, для меня воксели не любовь на всю жизнь, а скорее сиюминутное увлечение... попробую написать статью про воксели в шейдерах, выложу исходники и на этом наверное успокоюсь.