Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

Здравствуйте, Аноним, Вы писали:

А>Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

Вы все 35 мегапикселей честно отрисовываете? Что ж это за дисплей такой....

Обрабатывать надо, при проецировании этих 7000 лучей на растр, скажем 1024x768 пикселей, большая часть точек будет занимать одно и то же место. Отсюда, собственно, алгоритм: нарисовать в битмапку в памяти, размером с экран, а потом перебросить ее. Как обрабатывать совпадающие пиксели зависит от задачи, может быть нужно брать среднее, может максимум, может еще как-то.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Здравствуйте, Аноним, Вы писали:

А>>Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

EK>Вы все 35 мегапикселей честно отрисовываете? Что ж это за дисплей такой....

Конечно нет.

EK>Обрабатывать надо, при проецировании этих 7000 лучей на растр, скажем 1024x768 пикселей, большая часть точек будет занимать одно и то же место. Отсюда, собственно, алгоритм: нарисовать в битмапку в памяти, размером с экран, а потом перебросить ее. Как обрабатывать совпадающие пиксели зависит от задачи, может быть нужно брать среднее, может максимум, может еще как-то.

То что вы пишите примерно и делается, но это долго, вопрос был про 3Д, шейдеры какие-нибудь использовать или что-нибудь еще, т.е. воспользоваться математикой DX-а или OGL-я.

Здравствуйте, Аноним, Вы писали:

EK>>Обрабатывать надо, при проецировании этих 7000 лучей на растр, скажем 1024x768 пикселей, большая часть точек будет занимать одно и то же место. Отсюда, собственно, алгоритм: нарисовать в битмапку в памяти, размером с экран, а потом перебросить ее. Как обрабатывать совпадающие пиксели зависит от задачи, может быть нужно брать среднее, может максимум, может еще как-то.

А>То что вы пишите примерно и делается, но это долго, вопрос был про 3Д, шейдеры какие-нибудь использовать или что-нибудь еще, т.е. воспользоваться математикой DX-а или OGL-я.

Так что тормозит-то? Обработка или вывод битмапки на экран? Последнее тормозить не может, если только не попиксельно делается.

Если обработка, то какого ответа вы хотите? Да, какие-нибудь шейдеры можно использовать, тем более "что-нибудь еще" тоже можно. Как именно делать -- зависит от метода отображения, если нужно рисовать веер лучей с радаром в центре -- я бы загнал приходящие данные в текстуру и аппроксимировал этот веер треугольниками. Надо учитывать, что текстуры с размерами не кратными двойке поддерживаются плохо, размеры больше 1024x1024 тоже не стоит делать.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Так что тормозит-то? Обработка или вывод битмапки на экран? Последнее тормозить не может, если только не попиксельно делается.

конечно подготовка картинки тормозит

EK>Если обработка, то какого ответа вы хотите? Да, какие-нибудь шейдеры можно использовать, тем более "что-нибудь еще" тоже можно. Как именно делать -- зависит от метода отображения, если нужно рисовать веер лучей с радаром в центре -- я бы загнал приходящие данные в текстуру и аппроксимировал этот веер треугольниками. Надо учитывать, что текстуры с размерами не кратными двойке поддерживаются плохо, размеры больше 1024x1024 тоже не стоит делать.

вопрос в обработке, т.е. результат это битмап, пусть он будет 1024х1024, это пока не очень важно.

вот вы там написали про аппроксимацию треугольниками, я просто подумал, что если это делать в лоб, то будет 70 млн. треугольников и это скорее всего будет долго.

Здравствуйте, Аноним, Вы писали:

А>вопрос в обработке, т.е. результат это битмап, пусть он будет 1024х1024, это пока не очень важно.

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


А>вот вы там написали про аппроксимацию треугольниками, я просто подумал, что если это делать в лоб, то будет 70 млн. треугольников и это скорее всего будет долго.

Нет, смысл в том, чтобы побить на вот такие куски , каждый кусок отображает соответствующую часть текстуры, не больше чем максимум, поддерживаемый видеокартой, скажем, 512x512.

Здравствуйте, Eugene Kilachkoff, Вы писали:

А>>вот вы там написали про аппроксимацию треугольниками, я просто подумал, что если это делать в лоб, то будет 70 млн. треугольников и это скорее всего будет долго.

EK>Нет, смысл в том, чтобы побить на вот такие куски , каждый кусок отображает соответствующую часть текстуры, не больше чем максимум, поддерживаемый видеокартой, скажем, 512x512.

ммм, я правильно понимаю, что пример на картинке, это 4 луча по 3 пикселя в каждом?
тогда я так себе и представлял, но тогда будет 70 млн. треугольников, видеокарта замучается все это пережевывать.

Здравствуйте, Аноним, Вы писали:



А>ммм, я правильно понимаю, что пример на картинке, это 4 луча по 3 пикселя в каждом?
А>тогда я так себе и представлял, но тогда будет 70 млн. треугольников, видеокарта замучается все это пережевывать.

Нет, это веер, аппроксимированый 4x3 четырехугольниками, каждый четырехугольник -- 7000/4 лучей и 5000/3 пикселов.

Здравствуйте, Eugene Kilachkoff, Вы писали:

EK>Здравствуйте, Аноним, Вы писали:

EK>

А>>ммм, я правильно понимаю, что пример на картинке, это 4 луча по 3 пикселя в каждом?
А>>тогда я так себе и представлял, но тогда будет 70 млн. треугольников, видеокарта замучается все это пережевывать.

EK>Нет, это веер, аппроксимированый 4x3 четырехугольниками, каждый четырехугольник -- 7000/4 лучей и 5000/3 пикселов.

ну и как туда 35 Мб данных запихать

Здравствуйте, Аноним, Вы писали:

А>Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

Дело не в GDI, и другой API для вывода картинки тоже не спасет. Надо оптимизировать свою часть, где происходит рисование в битмап (текстуру). И конечно (на всякий случай пишу, вдруг?) не пользуйтесь GDI SetPixel для заполнения картинки, ф-я очень медленная.

35 млн сэмплов — это объективно очень много. Подозреваю, что в случае радара можно просто прогнорировать большую часть информации, она избыточна (для визуализации). Например, залейте всю картинку нейтральным (нулевым) фоном, анализируйте только каждый N-й луч и в луче только каждую M-й сампл, отрисовывайте только если значение отличается от нейтрального (возможно в этом случае просматривайте более подробно и отрисовывайте окрестность такой ненулевой точки). При приближении к центру, откуда лучи расходятся и где их плотность больше, число N увеличивайте, там реально надо совсем мало точек. Примерно так, в 1-м приближении.

Возможно стоит придумать scanline алгоритм, его можно по-своему оптимизировать.

Возможно стоит учитывать, что не вся область меняется, перерисовывать только часть.

Примерно упоминал, но может быть самому отслеживать "ненулевые" точки и их окрестности + параллельно и независимо просматривать массив данных на предмет появления/исчезновения таких точек. Процедура отслеживания может делаться с огрублением в 1-м приближении (пропускать лучи & точки) и, что более важно, с меньшей частой кадров, чем отрисовка. Допустим, для такого поиска хватит точности раз в полсекунды.

Здравствуйте, Аноним, Вы писали:

EK>>

А>>>ммм, я правильно понимаю, что пример на картинке, это 4 луча по 3 пикселя в каждом?
А>>>тогда я так себе и представлял, но тогда будет 70 млн. треугольников, видеокарта замучается все это пережевывать.

EK>>Нет, это веер, аппроксимированый 4x3 четырехугольниками, каждый четырехугольник -- 7000/4 лучей и 5000/3 пикселов.

А>ну и как туда 35 Мб данных запихать

Запихать 12 раз по 35/12 Мбайт.

Здравствуйте, <Аноним>, Вы писали:

А>Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

Данные чохом приходят, или как в радаре — последовательно, по лучам?

Если второй вариант, то идёте шагом в 1/30 с, вертите луч, на каждом шаге отмеряете сектор, проходите по точкам сектора, выбирая для каждой проекцию в поступивших данных, получаете растр, из которого делаете текстуру, и закидываете в массив секторов — это будет четыре вершины (достаточно два угла, а то и один хранить) и текстура. При отрисовке кадра отображаете все сектора — четырёхугольник (две вершины в центре, две — на радиусе, по сторонам сектора) с текстурой. Когда луч обгоняет сектор на круг, сектор выкидывается и текстура удаляется. Таким образом, просчёт на каждом кадре будет вестись для одного сектора, а это, при пяти оборотах в минуту, всего-то два градуса или 40 лучей. Размер текстуры — 256 на 16. Ну от силы 512 на 32. Так что вычислительная нагрузка будет мальенькая, а с включенной фильтрацией текстур ещё и картинка достаточно гладенькая получится.

Здравствуйте, Аноним, Вы писали:

А>Надо быстро нарисовать радарную картинку. Данные приходят в виде 7000 лучей по 5000 точек в каждом, каждая точка может иметь значение от 0-255 (это цвет точки). Сейчас используется GDI и на отровку картинки 1000-1000 точек уходит 1.3 секунды, а надо быстрее. Есть мысль использовать 3Д как-нибудь, но как конкретно не знаю, опыта мало. Может у кого идея появится?

Если я правильно понял, то задача распадается на:
1) Задать размер прямоугольной области
2) Спроецировать лучи на прямоугольную область
3) Уменьшить размер области до размера выводимого на экран изображения, т.е. обычное масштабирование
4) Непосредственно вывод на экран

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

А почему не сделать так, как это делается в ЭЛТ.
1. Рисуем круг темно зеленого цвета
2. Рисуем линию из центра с углом 0 градусов
3. Сохраняем текстуру получившегося
3. Задаем смещение в 1 градус для следующей линии
4. Используем прозрачность (0, 0.1), рисуем зеленый фон и полученную текстуру.

т.е. получаем только отрисовку линни, а историю берем из буфера...

Здравствуйте, usa, Вы писали:

usa>А почему не сделать так, как это делается в ЭЛТ.
usa>1. Рисуем круг темно зеленого цвета
usa>2. Рисуем линию из центра с углом 0 градусов
usa>3. Сохраняем текстуру получившегося
usa>3. Задаем смещение в 1 градус для следующей линии
usa>4. Используем прозрачность (0, 0.1), рисуем зеленый фон и полученную текстуру.

usa>т.е. получаем только отрисовку линни, а историю берем из буфера...

При таком алгоритме будет наблюдаться муар.