Здравствуйте! Делаю отрисовку модели, определенной растром(картой высот) W x H типа float(Z-координата в данной точке). Ширина(W) и высота(H) растра, в точках, <=10001. Размер - около 100М точек. Шаг между точками растра - (Sx , Sy) Рисовать хочу текстурированные полики или просто интерполировать цвет вершин + flat shading. Растр будет обновлятся каждый кадр, возможно, частично.
Объем пересылаемых каждый кадр данных немал, как минимум это:
1. Карта высот (100М * sizeof(float) = 400Мб)
2. Карта цветов вершин(100М * sizeof(byte?) = 100Мб)
При реализации "в лоб", через IBO и прекалькулированные координаты каждой точки, объем необходимой видеопамяти увеличивается примерно в 4 раза. Это никуда не годится. Если рендерить triangle fan, придется под эту структуру перекодировать исходную карту высот, что тоже не канает, ибо CPU и так есть чем заняться.
Подозреваю, что геометрический шейдер можно как-то задействовать, но неясно, как получить из него произвольный доступ ко всему растру для формирования на выходе треугольников и расчета нормалей и UV.
Подскажите, пожалуйста, как эффективно рендерить подобное?
Точечные спрайты посмотри...
а вообще не понятна задача, как то не ясно описано
А как ты на экрн выведешь 100м точек да еще и каждый кадр менять там что-то, оно вообще зачем, не видно же будет. Даже если попиксельно, это два ляма пикселей всего ))
Смысл проги - симуляция и визуализация фрезерной обработки материала режущим инструментом по сложным траекториям. Точность 0.1мм - 0.01мм, отсюда и немалый размер растра.
Растр здесь нужен для экономии времени и памяти. У растра постоянное расстояние между точками, следовательно, не надо хранить для каждой точки поверхности XY-координаты, а только высоту(и, хотелось бы, цвет).
Рендерить растр я собираюсь в триангулированном виде.
Вот так выглядит растровая картинка и модель в блендере на ее основе:
Условно, физическая симуляция обработки на СPU дает на выходе гигантский битмап, содержащий вместо цвета точки ее высоту(Z в координатах модели). Эту карту высот я и собираюсь рендерить. Уменьшить количество точек при физических расчетах нельзя, можно только упростить визуализацию прореживанием и клиппингом. Но это работа CPU, что крайне нежелательно. В первую очередь я хочу загрузить GPU, даже если на пиксель экрана приходится по 100 поликов, а потом, по мере необходимости, упрощать визуализацию отсечением\прореживанием.
Еще надо шейдером face-нормали считать, вроде как геометрическим можно.
fecaloid666
посчитай сам 500mb * 60 = 30Gb/s, у топ видюх пропускная способность шины на порядок выше.
fecaloid666
Всякие солидворксы не помогут?
Aroch
Я не понял. О чем ты?
innuendo
Нет.
fecaloid666
> Я не понял. О чем ты?
то что делай в лоб как есть, будут проблемы тогда и начнешь решать. Если у тебя там ничего кроме этой задачи нет, то gpu справится.
> через IBO и прекалькулированные координаты каждой точки, объем необходимой
> видеопамяти увеличивается примерно в 4 раза. Это никуда не годится.
у тебя карта высот, что ты там собрался "перекалькулировать" в ibo? И с чего вдруг потребность памяти в 4 раза увеличится, как ты считал?
Aroch
Не хочу решать заведомо неэффективным способом.
В случае растра - один float на точку(Z-координата).
В случае IBO - три float(X,Y,Z) плюс примерно шесть int(индексы)
Ошибся. Примерно в 7 раз больше. Я насчитал 3.7 Gb видеопамяти.
fecaloid666
> В случае IBO - три float(X,Y,Z) плюс примерно шесть int(индексы)
не верно, ibo это только индексы, а на что они ссылаются дело десятое, на ту же z координату или что-то еще не важно. Далее ты можешь организовать их в виде strip'a что уже 4 индекса на квад. При этом сколько оно займет памяти не имеет значения пока этой памяти хватает, ибо ты можешь построить и заполнить буфер под индексы всего один раз, его не нужно менять каждый кадр. Меняй только свои z координаты и цвет.
Aroch
Огранизовать в виде стрипа не могу, писал выше.
Суть в том, чтобы найти более эффективное решение, чем рендер через IBO.
fecaloid666
> Суть в том, чтобы найти более эффективное решение, чем рендер через IBO.
находи, не забудь потом тут рассказать к чему пришел.
fecaloid666
Вершины нельзя как халф?
fecaloid666
> Смысл проги - симуляция и визуализация фрезерной обработки материала режущим
> инструментом по сложным траекториям. Точность 0.1мм - 0.01мм, отсюда и немалый
> размер растра.
Экран то имеет ограниченную точность, свою карту высот и рисуй как одну текстуру на весь экран. Тоже и с 3д моделью, бери точки высоты через несколько штук... А свои данные держи в максимальной точности. Ты не увидишь разнице на экране, передав в видеокарту 100м вершин, или 4млн вершин.
Тема закрыта.