opengl z buffer

[Serg2016_1]

Когда я делаю рендер в текстуру, где у меня окажется буффер глубины? Как его достать в массив и как достать кстати в массив текстуру?

[Sapersky]

Нужно создать depth-текстуру (glTexImage2D с параметрами GL_DEPTH_COMPONENT, GL_FLOAT) и прицепить её к FBO (glFrameBufferTexture2D с параметром GL_DEPTH_ATTACHMENT).
Получить содержимое - забиндить FBO, потом glReadPixels, GL_DEPTH_COMPONENT/GL_FLOAT для Z-буфера или GL_BGRA/GL_UNSIGNED_BYTE для цвета. Но это медленно, фактически имеет смысл только для отладки.

[Serg2016_1]

Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру?
А насколько медленно?
Я каждый кадр скидываю софтвейрно рендереный массив в текстуру, посредством glTexImage2D. Насколько утормозит процесс добавления чтения забора и текстуры в массивы?
И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д.

[Славян]

Цитата Serg2016_1 @ 18.03.16, 10:17

Насколько утормозит процесс добавления чтения забора и текстуры в массивы?

Самый мегатормоз - это функция glReadPixels, а glTexImage2D неоднократно оптимизировалась (даже ввели glTexSubImage), так что за неё не беспокойтесь.

[Sapersky]

Цитата

Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру?
А насколько медленно?

Скорее, текстура используется в качестве Z-буфера. Даже если что-то там копируется, внутри видеокарты это должно быть быстро.

Цитата

Насколько утормозит процесс добавления чтения забора и текстуры в массивы?

Зависит от качества конкретного драйвера, у меня, например, максимум 1 Гб/с получалось на ReadPixels. Если пересчитать на кадр 1920*1080, это 126 кадров/c, или 8 мс. При 60 FPS у тебя 16 мс на кадр, т.е. половину времени рендера ты потратишь на банальную пересылку картинки.
Даже если с драйвером повезёт и пересылка будет быстрее, добавляется ещё лишняя синхронизация CPU и GPU, это тоже не прибавляет скорости.

Цитата

И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д.

А что рисуется софтверно, неужели нельзя это аппаратно нарисовать? Сейчас в шейдерах чего только не делают - рей-трейсинг, воксели и т.п.

Сообщение отредактировано: Sapersky - 18.03.16, 15:51

[Serg2016_1]

Пишу натуральный софтвейрный мохеровый воксель, без туды, куды, сюды (из принципа)... https://yadi.sk/d/_-_3Zjl4qAvoB

[Serg2016_1]

А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс....

Сообщение отредактировано: Serg2016_1 - 19.03.16, 14:44

[Sapersky]

Цитата

Пишу натуральный софтвейрный мохеровый воксель

Это ландшафт что ли? В шейдерах (на видеокарте) и более сложное делают:
https://www.shadertoy.com/view/XsX3RB
Обычный 2D-ландшафт (в котором не может быть произвольных пещер) тоже наверное можно сделать.
Другое дело, что сейчас воксели для этого применять нет особого смысла, проще загнать миллион-другой треугольников в регулярную полигональную сетку - будет лучше выглядеть и тоже деформируется в направлении вверх-вниз.

Цитата

А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс....

Не в процессоре суть, а в видеокарте, точнее в конкретном драйвере видеокарты (Radeon 7750). AMD не особенно любит OpenGL и плохо оптимизирует драйвера. Через OpenCL на той же карте я получал 5 Гб/c. Ну, понятно - OpenCL им нужен для продвижения APU, поэтому они его активно "вылизывают".
Пару мс на 2 небольшие текстуры - верю, это те же 1 Гб/c, но в направлении "туда", это практически любая карта может.

[Serg2016_1]

А пишу в софте, потому, что ТАМ целый нереализованный мир и все прямо перед глазами, только взять. Автомонтаж появляться не спешит, а "Вангеров", вспоминают в народных эпосных поэмах...

[Sapersky]

Мне кажется, пытаться копировать старую игру 1 в 1 скучно. Хоть что-то своё привнести, хотя бы рендер сделать по-другому. А если хочется давить на ностальгические чувства игроков корявыми "софтверными" пикселями, то это можно через GL_POINTS имитировать.
Прикреплённый файлSurfVoxGL.zip (83,8 Кбайт, скачиваний: 207)
R - переключение псевдовоксели/полигоны, 1,2,3 - разное разрешение карты.

[Serg2016_1]

Ну, насчет корявых я бы поспорил, но шерсть, конечно есть....
Нет, не копировать, даже наоборот, очень много вариантов: хочешь rts/tbs, гонки на кувыркающихся багги, rpg фаллаут тот же, я например хочу очень tbs... На Андроне по-моему, при определенном подходе должно все крышки снять, и воксели они, все таки мозг зацепляют...
Пробовал GL_LINES, был послан в космическую пустоту скоростью отрисовки ))
А в surfvox у меня чето фпс хромает, 30/12/5...

[Sapersky]

Цитата

А в surfvox у меня чето фпс хромает, 30/12/5...

У меня не хромает, 2000 / 1400 / 600 в зависимости от разрешения карты.
Может быть, это конкретно точки тормозят, переключи на полигоны. Или видеокарта совсем слабая.

[Serg2016_1]

Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8...

Добавлено 20.03.16, 13:55
А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли?

[Sapersky]

Цитата

Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8...

Сомнительное это занятие, оптимизация под древнее железо. Тем более оптимизация игры - у основной массы игроков с мощностями всё в порядке.
Разве что действительно на Андроид рассчитывать, но там всё относительно слабое, и видеокарта, и процессор. Надо тестировать, что быстрее - софтвер или OpenGL-точки.

Цитата

А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли?

GL_POINTS через VBO (хотя на встроенной карте VBO не поможет). Размер точек задаю через glPointSize в зависимости от размера окна и карты, чтобы не было дырок.

[Serg2016_1]

Вот если-бы еще и GL_lines работало...
У меня с фпс все хорошо, на средних настройках 50 и еще запас по оптимизации, но единственное конечно трудновероятно сделать true perspective, приходится довольствоваться орто(чему я очень и рад), либо искаженной перспективой. Можно правда написать алгоритм диагональной штриховки, для заделки дыр, и причем вполне. С полигональной отрисовкой, по большому счету будет тот-же эффект, как от вокселей, если делать без белины(рушится параллакс, цветность выпадает, контрастность там..... Белиной надо рисовать тени, а чтобы nearest не топорщился надо использовать мипмап и малую контрастность(все равно цветом завалит по сравнению с фильтрованным)), но у воксов все равно своя прелесть ))(там обитают грифоны)

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

[Sapersky]

С точками-линиями это опять вопрос качества драйверов.
Где-то драйверописателей можно понять, если в играх почти исключительно треугольники, то зачем сверхбыстрое рисование точек. Можно сделать по принципу "лишь бы работало".

Если возвращаться к гибридному рендеру - насколько я помню, в Вангерах машинки были довольно мелкие. Имеет смысл вытаскивать из видеокарты не весь экран/z-буфер, а только маленькие фрагменты вокруг нужных объектов.

[Serg2016_1]

Чего-то я все писал коды, а тут утих, застой творческий(пишите/не пишите). Подведу пока итог: туда применяем быстрый glTexImage2D, а обратно медленный glreadpixels, что по прогнозу тоже неплохо должно выйти...

[Serg2016_1]

А где описана переменная GL_FRAMEBUFFER? Дело в том что пишу на мингве(не потому, что модно, а потому, что без памяти влюбился в codeblocks с первого взгляда ))) И вот он мне пишет not declared...

[Славян]

Цитата Serg2016_1 @ 26.03.16, 10:56

А где описана переменная GL_FRAMEBUFFER?

glew.h

#define GL_FRAMEBUFFER 0x8D40
#define GL_RENDERBUFFER 0x8D41

[Serg2016_1]

Все, изв. туплю...

[Serg2016_1]

Как я понял, чтобы забиндить framebuffer его надо создать типа: glGenFramebuffers(1, &fb1), а могут ли быть объективные причины того, что программа колбасит в этом месте доской с надписью 0x00000 не read?

[Славян]

Конечно. Если так сделаете, то и будет расколбас:

int MyGen(unsigned int &fb)
{
    glGenFramebuffers(1, &fb);
    return 0;
}
 
main()
{
  GLuint framebuffers=NULL;
  MyGen( framebuffers );
  ...
}

Добавлено 26.03.16, 16:24
Ай, тьфу, вру. Учитывая:

#define glGenFramebuffers GLEW_GET_FUN(__glewGenFramebuffers)

ошибка будет оттого, что функция такая не нашлась.

[Serg2016_1]

Вишу на glGenFramebuffers. glewInit() работает, не знаю чего делать. glfw.

[Славян]

У меня получалось выбраться из такой ямы, вручную делая:

wglGetProcAddress("glGenFramebuffers");

Но потом я как-то автоматизировал сей процесс.

Цитата Serg2016_1 @ 28.03.16, 10:47

Вишу на glGenFramebuffers

Правильно ли я подразумеваю, что у вас сия функция системой не нашлась, и при отладке показывается, что glGenFramebuffers = NULL ?

[Serg2016_1]

Вроде оно.Еще не проверял, но уже огр. спсб. Даже Билл Гейтс не додумался до такой дружелюбности пользовательского интерфейса.... Может еще с glfw openwindow чего-нибудь не контачит...

[Serg2016_1]

:-EEEEEEEEEEEEEEEE
В злодейском glGenFramebuffers по прежнему 0. У меня появилась здравая мысль, а что если моя карта не поддерживает fb. Тогда, понесу нот помощнее в ремонт, оставлю gl для androna, а к населению ВОПРОС: куда примерно надо в dx глядеть, чтобы сделать rendertotexture,чтение текстуры и збуффера в массив???

[B.V.]

Цитата Serg2016_1 @ 29.03.16, 09:31

куда примерно надо в dx глядеть, чтобы сделать rendertotexture

CreateTexture2D -> CreateRenderTargetView

[Sapersky]

Цитата

В злодейском glGenFramebuffers по прежнему 0. У меня появилась здравая мысль, а что если моя карта не поддерживает fb

Попробуй glGenFramebuffersEXT, т.е. через расширение. В основную функциональность оно перенесено начиная с OpenGL 3, которого у тебя видимо нет.

Можно и через DX, но лично мне после OGL возвращаться к DX (я довольно много работал с DX7-9) не хочется, там почти всё сложнее и муторнее, в DX10+ тем более.
DX9: рендер в текстуру - Device.SetRenderTarget (+ нужно создать текстуру со спец. флагом), получение картинки - Device.GetRenderTargetData. Z-буфер - нужно указать спец. флаг при создании девайса, что-то там с LOCKABLE, залочить (Surface.Lock), скопировать, разлочить.

И кстати, я тут ради развлечения упихал классический воксельный рендер (с циклом по столбцам) в GPU. Используются compute shaders, нужна видеокарта с поддержкой OpenGL 4.3. Картинки получаются примерно такие:

Прикреплённая картинка

т.е. почти не отличимые от полигонального рендера, хотя при желании можно сделать и чтобы квадраты торчали. Без квадратов-то ведь не true? Чтоб как в 92-м:
http://simulationcorner.net/index.php?page=comanche

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

[Sapersky]

Хотя, есть у вокселей одно достоинство - позволяют относительно легко наращивать детализацию, FPS снижается, но не очень сильно (у меня 190 при стартовом положении камеры и размере окна).

Прикреплённая картинка

Прикреплённая картинка

Полигонами такое уже не так просто изобразить, во всяком случае брут-форс точно не потянет.
Прикреплённый файлVoxGL.zip (98,96 Кбайт, скачиваний: 166)
Управление - стрелки, правые Shift/Ctrl, пробел - движение, W - wireframe, L - освещение, V - большая дальность отрисовки, но может глючить вблизи.

[Славян]

Цитата Sapersky @ 29.03.16, 22:08

VoxGL.zip

Не пошло́:

Прикреплённая картинка

[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 Кбайт, скачиваний: 179)

Цитата

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

Там всё рисование в шейдере.
Сейчас в шейдерах можно писать на почти полноценном 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

Цитата

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

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

[Serg2016_1]

Картинка, на плоскости перпендикулярной камере, растянутой на экран... По стандартам посчитать тоже дефакто... Но очень смутно представляю как впарить свой буффер рендеру, а интересно...

[Sapersky]

Формулы для расчёта Z-координаты можно найти в документации по DX/OGL, хотя и не факт, что они так сразу заработают. Вот например:
zw = s * [ (we / ze) * f*n/(f-n) + 0.5 * (f+n)/(f-n) + 0.5 ]
https://www.opengl.org/archives/resources/f...depthbuffer.htm
(we наверное = 1, остальное см. по ссылке п.12.050)

[Serg2016_1]

Как изобразить большие ОКРУГЛЕННЫЕ глаза. Это куда?
Или это просто, учитывая расстояние от передней до задней стенки забора?

Сообщение отредактировано: Serg2016_1 - 05.04.16, 08:17

[Sapersky]

Хе, ну если говорить об округлённых глазах, то мог бы и сам выражаться более внятно. Что такое "забор"? (Я уж не спрашиваю про "белину").
Но в целом похоже направление мысли верное, f и n - задняя и передняя отсекающие плоскости.

[Serg2016_1]

Вариант, что такое без белины здесь:
Обсуждение компьютерной графики
А забор он и есть забор ))))))))))))))))))

Сообщение отредактировано: Serg2016_1 - 07.04.16, 10:30

[Serg2016_1]

А кстати все-таки есть у кого соображения как voxlap устроен?

[Serg2016_1]

Я тут только сейчас подумал про вокслап и пр...
Когда я начал копать воксели я написал сразу прямой рэйкастер (где выпускается из камеры xres x yres лучей) и по причине тормозов его сразу забросил. Я тут подумал, а что если он тормозил только из-за тормозов неупорядоченного доступа к большим массивам. Тогда все понятно как устроен вокслап... И еще в моем посте про эти самые тормоза один товарищ привел видео где другой товарищ четко сказал по английски "мелкие суксь" показывая два графика тормозов при неупорядоченном доступе к большим массивам у мелких и уникса, где мелкие раз в ....20 может медленнее... Хотел проверить как оно под линуксом, но какой-то из линуксов раньше поджарил мой ноут. Сейчас жалко времени нет все это проверить...



P.S. Через некоторое время размышлений пришел к выводу: все, что я хотел сделать - это воксельный ландшафт в изометрии (даже без масштабирования)с вращением только вокруг оси z, при этом максимально быстрый и доступный на любой платформе. Все казуальные гггг...эймы сразу бы поднялись с такой графикой на несколько пунктов. Это сразу бы засияли TBS, RTS и RPG...

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