Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.139.97.157] |
|
Сообщ.
#1
,
|
|
|
Когда я делаю рендер в текстуру, где у меня окажется буффер глубины? Как его достать в массив и как достать кстати в массив текстуру?
|
Сообщ.
#2
,
|
|
|
Нужно создать 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 для цвета. Но это медленно, фактически имеет смысл только для отладки. |
Сообщ.
#3
,
|
|
|
Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру?
А насколько медленно? Я каждый кадр скидываю софтвейрно рендереный массив в текстуру, посредством glTexImage2D. Насколько утормозит процесс добавления чтения забора и текстуры в массивы? И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д. |
Сообщ.
#4
,
|
|
|
Цитата Serg2016_1 @ Самый мегатормоз - это функция glReadPixels, а glTexImage2D неоднократно оптимизировалась (даже ввели glTexSubImage), так что за неё не беспокойтесь. Насколько утормозит процесс добавления чтения забора и текстуры в массивы? |
Сообщ.
#5
,
|
|
|
Цитата Т.е. Zbuffer будет каждый раз скидываться в эту depth текстуру? А насколько медленно? Скорее, текстура используется в качестве Z-буфера. Даже если что-то там копируется, внутри видеокарты это должно быть быстро. Цитата Насколько утормозит процесс добавления чтения забора и текстуры в массивы? Зависит от качества конкретного драйвера, у меня, например, максимум 1 Гб/с получалось на ReadPixels. Если пересчитать на кадр 1920*1080, это 126 кадров/c, или 8 мс. При 60 FPS у тебя 16 мс на кадр, т.е. половину времени рендера ты потратишь на банальную пересылку картинки. Даже если с драйвером повезёт и пересылка будет быстрее, добавляется ещё лишняя синхронизация CPU и GPU, это тоже не прибавляет скорости. Цитата И вообще как посоветуете поступить? Я рисую свой софтвейр на плоскости, хочу сочетать его с хардвейром, который хочу отрендерить на текстуру, после чего вручную сопоставить софт и хард с буффером и перегнать полученный общий массив в тестуру и.т.д. А что рисуется софтверно, неужели нельзя это аппаратно нарисовать? Сейчас в шейдерах чего только не делают - рей-трейсинг, воксели и т.п. |
Сообщ.
#6
,
|
|
|
Пишу натуральный софтвейрный мохеровый воксель, без туды, куды, сюды (из принципа)... https://yadi.sk/d/_-_3Zjl4qAvoB
|
Сообщ.
#7
,
|
|
|
А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс....
|
Сообщ.
#8
,
|
|
|
Цитата Пишу натуральный софтвейрный мохеровый воксель Это ландшафт что ли? В шейдерах (на видеокарте) и более сложное делают: https://www.shadertoy.com/view/XsX3RB Обычный 2D-ландшафт (в котором не может быть произвольных пещер) тоже наверное можно сделать. Другое дело, что сейчас воксели для этого применять нет особого смысла, проще загнать миллион-другой треугольников в регулярную полигональную сетку - будет лучше выглядеть и тоже деформируется в направлении вверх-вниз. Цитата А на каком процессоре получалось 1Гб? Это у меня при 512x512 на 2 шт. текстур будет пару мс.... Не в процессоре суть, а в видеокарте, точнее в конкретном драйвере видеокарты (Radeon 7750). AMD не особенно любит OpenGL и плохо оптимизирует драйвера. Через OpenCL на той же карте я получал 5 Гб/c. Ну, понятно - OpenCL им нужен для продвижения APU, поэтому они его активно "вылизывают". Пару мс на 2 небольшие текстуры - верю, это те же 1 Гб/c, но в направлении "туда", это практически любая карта может. |
Сообщ.
#9
,
|
|
|
А пишу в софте, потому, что ТАМ целый нереализованный мир и все прямо перед глазами, только взять. Автомонтаж появляться не спешит, а "Вангеров", вспоминают в народных эпосных поэмах...
|
Сообщ.
#10
,
|
|
|
Мне кажется, пытаться копировать старую игру 1 в 1 скучно. Хоть что-то своё привнести, хотя бы рендер сделать по-другому. А если хочется давить на ностальгические чувства игроков корявыми "софтверными" пикселями, то это можно через GL_POINTS имитировать.
Прикреплённый файлSurfVoxGL.zip (83,8 Кбайт, скачиваний: 207) R - переключение псевдовоксели/полигоны, 1,2,3 - разное разрешение карты. |
Сообщ.
#11
,
|
|
|
Ну, насчет корявых я бы поспорил, но шерсть, конечно есть....
Нет, не копировать, даже наоборот, очень много вариантов: хочешь rts/tbs, гонки на кувыркающихся багги, rpg фаллаут тот же, я например хочу очень tbs... На Андроне по-моему, при определенном подходе должно все крышки снять, и воксели они, все таки мозг зацепляют... Пробовал GL_LINES, был послан в космическую пустоту скоростью отрисовки )) А в surfvox у меня чето фпс хромает, 30/12/5... |
Сообщ.
#12
,
|
|
|
Цитата А в surfvox у меня чето фпс хромает, 30/12/5... У меня не хромает, 2000 / 1400 / 600 в зависимости от разрешения карты. Может быть, это конкретно точки тормозят, переключи на полигоны. Или видеокарта совсем слабая. |
Сообщ.
#13
,
|
|
|
Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8...
Добавлено А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли? |
Сообщ.
#14
,
|
|
|
Цитата Карта встр., нот, 1.86x1 у меня это критерий ))) Рассчитываю на старые компьютеры, фпс приподнялся 70/20/8... Сомнительное это занятие, оптимизация под древнее железо. Тем более оптимизация игры - у основной массы игроков с мощностями всё в порядке. Разве что действительно на Андроид рассчитывать, но там всё относительно слабое, и видеокарта, и процессор. Надо тестировать, что быстрее - софтвер или OpenGL-точки. Цитата А это кстати GL_POINTS? А как они отрисовываются, Они разного рамера что-ли? GL_POINTS через VBO (хотя на встроенной карте VBO не поможет). Размер точек задаю через glPointSize в зависимости от размера окна и карты, чтобы не было дырок. |
Сообщ.
#15
,
|
|
|
Вот если-бы еще и GL_lines работало...
У меня с фпс все хорошо, на средних настройках 50 и еще запас по оптимизации, но единственное конечно трудновероятно сделать true perspective, приходится довольствоваться орто(чему я очень и рад), либо искаженной перспективой. Можно правда написать алгоритм диагональной штриховки, для заделки дыр, и причем вполне. С полигональной отрисовкой, по большому счету будет тот-же эффект, как от вокселей, если делать без белины(рушится параллакс, цветность выпадает, контрастность там..... Белиной надо рисовать тени, а чтобы nearest не топорщился надо использовать мипмап и малую контрастность(все равно цветом завалит по сравнению с фильтрованным)), но у воксов все равно своя прелесть ))(там обитают грифоны) |
Сообщ.
#16
,
|
|
|
С точками-линиями это опять вопрос качества драйверов.
Где-то драйверописателей можно понять, если в играх почти исключительно треугольники, то зачем сверхбыстрое рисование точек. Можно сделать по принципу "лишь бы работало". Если возвращаться к гибридному рендеру - насколько я помню, в Вангерах машинки были довольно мелкие. Имеет смысл вытаскивать из видеокарты не весь экран/z-буфер, а только маленькие фрагменты вокруг нужных объектов. |
Сообщ.
#17
,
|
|
|
Чего-то я все писал коды, а тут утих, застой творческий(пишите/не пишите). Подведу пока итог: туда применяем быстрый glTexImage2D, а обратно медленный glreadpixels, что по прогнозу тоже неплохо должно выйти...
|
Сообщ.
#18
,
|
|
|
А где описана переменная GL_FRAMEBUFFER? Дело в том что пишу на мингве(не потому, что модно, а потому, что без памяти влюбился в codeblocks с первого взгляда ))) И вот он мне пишет not declared...
|
Сообщ.
#19
,
|
|
|
Цитата Serg2016_1 @ glew.hА где описана переменная GL_FRAMEBUFFER? #define GL_FRAMEBUFFER 0x8D40 #define GL_RENDERBUFFER 0x8D41 |
Сообщ.
#20
,
|
|
|
Все, изв. туплю...
|
Сообщ.
#21
,
|
|
|
Как я понял, чтобы забиндить framebuffer его надо создать типа: glGenFramebuffers(1, &fb1), а могут ли быть объективные причины того, что программа колбасит в этом месте доской с надписью 0x00000 не read?
|
Сообщ.
#22
,
|
|
|
Конечно. Если так сделаете, то и будет расколбас:
int MyGen(unsigned int &fb) { glGenFramebuffers(1, &fb); return 0; } main() { GLuint framebuffers=NULL; MyGen( framebuffers ); ... } Добавлено Ай, тьфу, вру. Учитывая: #define glGenFramebuffers GLEW_GET_FUN(__glewGenFramebuffers) |
Сообщ.
#23
,
|
|
|
Вишу на glGenFramebuffers. glewInit() работает, не знаю чего делать. glfw.
|
Сообщ.
#24
,
|
|
|
У меня получалось выбраться из такой ямы, вручную делая:
wglGetProcAddress("glGenFramebuffers"); Цитата Serg2016_1 @ Правильно ли я подразумеваю, что у вас сия функция системой не нашлась, и при отладке показывается, что glGenFramebuffers = NULL ? Вишу на glGenFramebuffers |
Сообщ.
#25
,
|
|
|
Вроде оно.Еще не проверял, но уже огр. спсб. Даже Билл Гейтс не додумался до такой дружелюбности пользовательского интерфейса.... Может еще с glfw openwindow чего-нибудь не контачит...
|
Сообщ.
#26
,
|
|
|
:-EEEEEEEEEEEEEEEE
В злодейском glGenFramebuffers по прежнему 0. У меня появилась здравая мысль, а что если моя карта не поддерживает fb. Тогда, понесу нот помощнее в ремонт, оставлю gl для androna, а к населению ВОПРОС: куда примерно надо в dx глядеть, чтобы сделать rendertotexture,чтение текстуры и збуффера в массив??? |
Сообщ.
#27
,
|
|
|
Цитата Serg2016_1 @ куда примерно надо в dx глядеть, чтобы сделать rendertotexture CreateTexture2D -> CreateRenderTargetView |
Сообщ.
#28
,
|
|
|
Цитата В злодейском 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 |
Сообщ.
#29
,
|
|
|
Хотя, есть у вокселей одно достоинство - позволяют относительно легко наращивать детализацию, FPS снижается, но не очень сильно (у меня 190 при стартовом положении камеры и размере окна).
Прикреплённая картинка
Прикреплённая картинка
Полигонами такое уже не так просто изобразить, во всяком случае брут-форс точно не потянет. Прикреплённый файлVoxGL.zip (98,96 Кбайт, скачиваний: 166) Управление - стрелки, правые Shift/Ctrl, пробел - движение, W - wireframe, L - освещение, V - большая дальность отрисовки, но может глючить вблизи. |
Сообщ.
#30
,
|
|
|
Сообщ.
#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 Цитата Ну, для меня воксели не любовь на всю жизнь, а скорее сиюминутное увлечение... попробую написать статью про воксели в шейдерах, выложу исходники и на этом наверное успокоюсь. если кому интересно и нечего делать присоединяйтесь |
Сообщ.
#46
,
|
|
|
Картинка, на плоскости перпендикулярной камере, растянутой на экран... По стандартам посчитать тоже дефакто... Но очень смутно представляю как впарить свой буффер рендеру, а интересно...
|
Сообщ.
#47
,
|
|
|
Формулы для расчёта 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) |
Сообщ.
#48
,
|
|
|
Как изобразить большие ОКРУГЛЕННЫЕ глаза. Это куда?
Или это просто, учитывая расстояние от передней до задней стенки забора? |
Сообщ.
#49
,
|
|
|
Хе, ну если говорить об округлённых глазах, то мог бы и сам выражаться более внятно. Что такое "забор"? (Я уж не спрашиваю про "белину").
Но в целом похоже направление мысли верное, f и n - задняя и передняя отсекающие плоскости. |
Сообщ.
#50
,
|
|
|
Вариант, что такое без белины здесь:
Обсуждение компьютерной графики А забор он и есть забор )))))))))))))))))) |
Сообщ.
#51
,
|
|
|
А кстати все-таки есть у кого соображения как voxlap устроен?
|
Сообщ.
#52
,
|
|
|
Я тут только сейчас подумал про вокслап и пр...
Когда я начал копать воксели я написал сразу прямой рэйкастер (где выпускается из камеры xres x yres лучей) и по причине тормозов его сразу забросил. Я тут подумал, а что если он тормозил только из-за тормозов неупорядоченного доступа к большим массивам. Тогда все понятно как устроен вокслап... И еще в моем посте про эти самые тормоза один товарищ привел видео где другой товарищ четко сказал по английски "мелкие суксь" показывая два графика тормозов при неупорядоченном доступе к большим массивам у мелких и уникса, где мелкие раз в ....20 может медленнее... Хотел проверить как оно под линуксом, но какой-то из линуксов раньше поджарил мой ноут. Сейчас жалко времени нет все это проверить... P.S. Через некоторое время размышлений пришел к выводу: все, что я хотел сделать - это воксельный ландшафт в изометрии (даже без масштабирования)с вращением только вокруг оси z, при этом максимально быстрый и доступный на любой платформе. Все казуальные гггг...эймы сразу бы поднялись с такой графикой на несколько пунктов. Это сразу бы засияли TBS, RTS и RPG... |