Спасибо

Обычная. Немного накосячил — делал свертку засунув по доброте душевной ее в ких фильтр, в котором на каждый семпл выполнялся сдвиг внутреннего буфера. Заменил на прямое семплирование входного массива со сдвигом — теперь свертка для 1 сек (с дискретизацией 64к) занимает 2 секунды машинного времени. Но все равно еще целая вечность, если попытаться засунуть это в микроконтроллер.
Хотя, возможно мне и ненужно делать свертку всей импульсной характеристики. Можно же посчитать только зоны интересов?

День добрый. Пытаюсь имплементировать и возможно я что-то упускаю. Импульсную характеристику со степенными гармониками получил, но даже для секундного свипа вычислительная сложность получается чересчур велика. При частоте дискретизации в 48кГц даже секундное окно требует миллиардов арифметических операций на свертку что выливается в минуты работы обычного ПК. Так и должно быть?

«Сложна»
Для CUBEIDE использую такое

//STM32F411
#define GPIO_OUT_REGISTER_OFFSET 0x14UL
#define GPIO_IN_REGISTER_OFFSET 0x10UL

#define PRT_WR(x, y) *((uint32_t *)((GPIO##x##_BASE - PERIPH_BASE + GPIO_OUT_REGISTER_OFFSET)*32 + PERIPH_BB_BASE + y * 4))
#define PRT_RD(x, y) *((uint32_t *)((GPIO##x##_BASE - PERIPH_BASE + GPIO_IN_REGISTER_OFFSET)*32 + PERIPH_BB_BASE + y * 4))

PRT_WR(C, 13) = 1;

Отличные статьи. А есть фото панелей на балконе?

Эту бы статью да года на три раньше :)
Для полноты картины сюда можно добавить про спекание энвайроментной BRDF в LUT текстуру (UE4)

Сначала гуглить, потом спрашивать :)
http://twvideo01.ubm-us.net/o1/vault/GDC2014/Presentations/Gareth_Thomas_Compute-based_GPU_Particle.pdf

Решил делать аналогичную партикловую систему и сразу же уперся в проблему — как убивать и добавлять частицы? Вроде ясно, что нужно неактивные частицы просто загонять в конец буфера, меняя их с живыми, но как это мапить на многопоточность не понятно… Может у вас уже есть готовый способ?

Из MSDN:
Floating-point scalar that indicates a back-facing primitive. A negative value faces backwards, while a positive value faces the camera.
Он рассчитывается аппаратно для всего треугольника.

Чаще всего нормаль, записанная в вертексы треугольника, не будет перпендикулярна плоскости треугольника (из-за софт эджей, настроенных художником). SV_IsFrontFace же не зависит от нормали и оперирует порядком объявления вершин и работает для всего треугольника.

До растерезации не известно, на какую сторону треугольника смотрим.

Не понимаю — зачем снижать частоту камеры, если аппаратная часть реализации без проблем обеспечивает 80 кадров в секунду? С такой частотой у меня без сбоев регистрируются импульсы порядка 5мс.
Дребезг контактов иногда случается, но совершенно не мешает — так как после детектирования выстрела идет 500мс игнорирования импульсов.
А круги засветки легко отфильтровываются программно, так как значительно тусклее основного пятна.

С длинным импульсом появляется проблема шлейфов в место точек, когда ствол ведет в руках.

Камера снимает 320х240, при этом на 100% загружается одно ядро. Можно распаралелить обработку на все четыре ядра, но такой необходимости не возникло. В текущем режиме тир работает не выключаясь — маленького радиатора хватает что бы держать температуру на уровне 50'C.
Этот нексус работает на Tegra?

Вот это наиболее реалистично. Пятно лазера будет хорошо видно.

Оптимальным вариантом развития сейчас вижу замену экрана TV на проектор. Тогда действительно можно будет без проблем стрелять в экран.

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

http://www.scatt.ru/

Ну это уже если понадобится сделать профессиональное решение. А моего для офиса хватает с избытком и усложнять смысла пока нет.

Тогда уж фильтры с круговой поляризацию для камеры и лазера :)