Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[52.14.150.55] |
|
Страницы: (4) 1 2 [3] 4 все ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
Ты крут.Ну ого-го, судя по картинке, перфектно, а чего там конкретно от шейдеров?
А все говорят полигоны-полигоны:)))) Если будет нечего делать, присоединяйся ко мне. У меня вакансий много (3 типа:программист/сочувствующий программист/сочувствующий),сам то я художник, а программист только по совместительству и 10 лет не брал в руки зубило. А директX я уже делал версию, переписывал ради ликбезного интереса на многом (action script,builder,vc,builder,vb,vc,mingw,vc,dx,gldx,gl), Устроен конечно dx жутко, я всегда не понимал зачем Билли написал второй opengl и назвал его Ха (наверное Хороший), но по моему под Виндой dx действительно побыстрее иногда чудодейственно (Это не потому, что мелкие Винду написали, а потому, что у них хорошие программисты:)))) |
Сообщ.
#32
,
|
|
|
Цитата Поправил. Хотя texture1D формально deprecated в старших версиях GLSL, компилятор AMD её почему-то пропускал. Наверное, выдавал ворнинг, но кто ж их читает...Не пошло́ Прикреплённый файлVoxGL2.zip (99,42 Кбайт, скачиваний: 181) Цитата Там всё рисование в шейдере. Ну ого-го, судя по картинке, перфектно, а чего там конкретно от шейдеров? Сейчас в шейдерах можно писать на почти полноценном C - условия, циклы, всё достаточно быстро отрабатывается на современном железе. Конкретно compute shaders хоть и называются "шейдерами", но по факту ближе к CUDA/OpenCL, в том смысле что не привязаны к пикселям-полигонам. Можно перенести на GPU почти любой алгоритм, при условии что он хорошо параллелится, т.е. отдельные элементы данных (в данном случае столбцы картинки) можно обрабатывать независимо друг от друга. А недостатков и ограничений у воксельного рендера тоже хватает. Несглаженные данные с резкими пиками плохо переваривает, особенно вертикальные поверхности - билинейный фильтр при попадании на ребро усредняет верхнюю и нижнюю точки. |
Сообщ.
#33
,
|
|
|
Цитата Sapersky @ Увы, токмо чёрный экран рисуется. FPS=200..2000. OpenGL 4.5 поддерживается. Что-то ещё не так... Поправил. |
Сообщ.
#34
,
|
|
|
Если FPS меняется, то вероятно оно рисуется, но не выводится на экран.
Добавил проверок на ошибки, ещё S теперь сохраняет в файл текстуру, в которую всё рендерится. Может хоть так можно будет что-то увидеть. Прикреплённый файлVoxGL3.zip (98,79 Кбайт, скачиваний: 171) |
Сообщ.
#35
,
|
|
|
Цитата Sapersky @ = Файлы создаются. Такие же чёрные, одноцветные. = Добавил проверок на ошибки, ещё S теперь сохраняет в файл текстуру, в которую всё рендерится. Может хоть так можно будет что-то увидеть. |
Сообщ.
#36
,
|
|
|
Действительно, на Nvidia не работало, но сейчас починил.
Прикреплённый файлVoxGL4.zip (100,07 Кбайт, скачиваний: 196) |
Сообщ.
#37
,
|
|
|
Цитата Sapersky @ Да, сейчас работает! А можно ли какой-то куб/шар сверху рельефа нарисовать, дабы убедиться, что расчёт идёт не по правилу z=f(x,y) ? Или же в отрисовке существенно используется, что есть непрерывный=нескончаемый слой вокселов вниз, а потому 'летающие острова' сей механизм пока не сможет показать?.. сейчас починил. |
Сообщ.
#38
,
|
|
|
Вообще-то там именно 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-перлином или чем-то подобным, но опять же по детализации есть ограничения, иначе генератор будет слишком тормозить. |
Сообщ.
#39
,
|
|
|
Вот я и как-раз хотел спросить про voxlap, я немного подумал над ним, а потом нашел нирвану в вэйвсерфинге и забыл, где сейчас и нахожусь. Очень классные демки Сильвермана с домиком, где копать можно и воксельштейн. Лучшее что мне ответили в сети: Присоединяйся к копающим Вокслап, а страшное типа того: Да там все просто, квадратизируешь пачками кубы и октодерево здесь не причем........ А между тем очень интересно как он работает..... Работает на древних компах, криомозг не нужен... От него походу пошел Автомонтаж кажется...
Предмет моей мечты - это true3d flight simulator на вокселях, а еще хочу сделать скроллшутер с космонавтом с воксельным фоном... |
Сообщ.
#40
,
|
|
|
А, что в dx ограничен fps 60? Непонятно почему упал фпс... Блок не имеющий отношения к gl/dx раньше по rdtsc был 26 мегатиков, стал 40.... И финальный вопрос: Как перебросить збуффер в текстуру? Впочем с фпс разобрался -o3 стало 23 вместо 26, плюс теряю 5 кадров наверное на цикл перебора текстуры....
|
Сообщ.
#41
,
|
|
|
Цитата Сильверман в конечном итоге пришёл именно к октодереву в последней демке.квадратизируешь пачками кубы и октодерево здесь не причем "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/ Цитата FPS может по умолчанию привязываться частоте монитора.А, что в dx ограничен fps 60? <...> И финальный вопрос: Как перебросить збуффер в текстуру? Если это DX9, задать при инициализации девайса D3DPresentParameters.PresentationInterval := D3DPRESENT_INTERVAL_IMMEDIATE; Z-буфер - CreateTexture c D3DUSAGE_DEPTHSTENCIL, потом Device.SetDepthStencilSurface, потом наверное использовать текстуру как обычно. Или через шейдер, в OGL, насколько помню, depth-текстура "как обычно" не работает. |
Сообщ.
#42
,
|
|
|
Ну, буду копать.......... ))
А я тут озадачился, что если использовать вместо доступа к массиву (readpixels)/(unlock/read/lock). Еще не успел сделать замеры, но дело в том, что при непоследовательном доступе к большим массивам время доступа меняется от 0.1-20 мс (как правило 20 ((). Тормозит ли чего unlock/lock? Это все если конечно без Куды (Как я понял там доступ к массивам в видеопамяти поставлен на конвейер) И можно-ли достать из текстуры интерполированное значение в точке, типа read(3.5454,5.34432........... Я, хоть и враг анизотропной белины, но для рельефа полезно... |
Сообщ.
#43
,
|
|
|
Каких-то чудес от unlock/read/lock ждать не стоит, на современных системах оно быстро не работает.
Вообще постоянные пересылки в видеокарту и обратно не могут работать очень быстро, я вроде бы с самого начала об этом писал. Даже в CUDA/OpenCL лучше ими не злоупотреблять. А кстати, зачем читать Z-буфер в софтверном воксельном движке? Можно же наоборот - генерировать Z-буфер при рендере ландшафта, загонять всё в видеокарту и потом выводить полигональные объекты. Опять же можно пересылать только небольшие фрагменты вокруг 3D-объектов. С lock/unlock для пересылки я бы не связывался, мне кажется, лучше загнать Z-буфер в текстуру, а потом в шейдере (простые шейдеры должна поддерживать любая карта) писать собственно в Z-буфер. В целом на 100% не поручусь, что это будет быстрее чтения Z-буфера (не всегда пересылка "туда" быстрее пересылки "обратно", иногда и почти одинаково), но попробовать можно. Интерполированное значение - разве что вручную посчитать билинейную интерполяцию. Можно нагуглить готовое по запросам "bilinear filter c++" и т.п. |
Сообщ.
#44
,
|
|
|
unlock приходится делать все равно, практика показала, что для заделки дыр лучше пройти массив после рендера (по ср. с gl не тормозит). А второй вариант с збуффером, постоянно где-то лежит у меня в мозге, правда, реализация выглядит для меня немного муторной. Текстуру с моим забором надо куда-то приделать, чтобы при рендере дх учитывал ее и складывал со своим забором? А как рендер будет рисовать мою плоскость с ландшафтом, тоже учитывая суммарный результат?
Именно софт-фильтрацией я сейчас и интерполирую кубы рельефа, отъедает порядком кусок фпс... Если не хард, может алгоритм, какой получше есть... И вообще, там впереди много графической ерунды предстоит, так, что повторюсь: если кому интересно и нечего делать присоединяйтесь, одному мне этого слона трудно будет передвинуть... |
Сообщ.
#45
,
|
|
|
Я полагал, что ландшафт софтверно рендерится c уже нужным положением камеры, и в 3D картинка просто растягивается на весь экран перпендикулярно камере (можно сказать, выводится как 2D-картинка).
С Z-буфером возможно придётся повозиться, чтобы он корректно рассчитывался по стандартам DX/OGL. Но и при чтении из него всё равно нужно эти стандарты учитывать. Цитата Вроде нет, билинейный фильтр по 4-м точкам - самое быстрое сглаживание, разве что SSE к нему прикрутить.Если не хард, может алгоритм, какой получше есть... http://fastcpp.blogspot.ru/2011/06/bilinea...-using-sse.html Цитата Ну, для меня воксели не любовь на всю жизнь, а скорее сиюминутное увлечение... попробую написать статью про воксели в шейдерах, выложу исходники и на этом наверное успокоюсь. если кому интересно и нечего делать присоединяйтесь |