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

Это давно реализовано, но увы, устарело  (техника середины 90-x) и сдано в архив

А она "непрерывна"? Т.е. можно ли спокойно брать/заниматься любой точкой внутри куба? Заметим что напр в моей задаче это не так (точка должна существовать в сцене)

Тут однозначно нужен псевдо (или квази) рандом. Предполагаем что есть "латиска" (3D сетка с достаточно малым шагом, хранить ее не надо).- Проходим 3 циклами по точкам латиски. Смотрим находится ли данная точка внутри радиусов уже имеющихся. Только если нет - добавляем эту точку в octree.

Инструмент - радиус захвата. Если есть доп инфа - она учитывается в радиусе. Т.е. он больше для "спокойных" областей и наоборот.

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

Да, серьезно. Напр
И "случайно" никто не пуляет, конечно нужно организовать адаптивную сетку и.т.п.

Не нравится - могу и помолчать  

Грубо говоря "разница в цвете", о чем вверху сказано дважды. Если соседи (вычисленные значения) отличаются более чем на заданную величину - считать еще. Это можно делать как на уровне точек, так и на уровне лучей одной точки.

Что у Вас плохо - не определены "точки". Вот человек создал сцену - прицепил стандартные чайник и пол (плоскость). Отрендерил картинку. Теперь он хочет чтобы чайник отсвечивал на пол и наоборот. Для всех точек на картинке. Ну или "в общем" - вот комната, в ней светит лампочка или свет проникает сквозь окно. Но не все места освещены напрямую. Однако и в этих местах все хорошо видно, "темноты" нигде нет. На заре компутерной графики это решалось абы-как (доливался амбиент, ставились лампочки подсветки и.т.п.). Но сейчас др времена - вынь да положь "физически корректный" расчет (пусть и далеко не быстрый).

В своем изложении Вы опускаете такую "стартовую позицию", и все сразу "повисает в воздухе". Откуда берутся Ваши 3D точки (на худой конец 2D)? Они "все заранее известны" или есть объем в котором они заключены или как? Какой-то начальный просчет с (псевдо) равномерным шагом видимо неизбежен, можно начать и с этой позиции.

Ах как болезненно критикующий реагирует на (справедливую) критику 

Много занимался (и занимаюсь) расчетами пере-отражений света. Поскольку никакой конкретной постановки в стартовом посте нет, постараюсь кратко изложить свою

Вот есть 3D точка (x, y, z) и надо посчитать как она освещена окружающей сценой (вторичное освещение). Из точки выбрасывается заданное кол-во лучей, в точках их пересечения со сценой считается цвет, рез-т осредняется. Чистый монте-карлик. По сути это все. Но за этой "простой" постановкой масса сложнейших задач, о каждой написаны тысячи статей, но лишь немногие имеют проверенные решения. Обозначу некоторые, а Вы выберете что желаете обсуждать, иначе тема слишком обширна

1) Какие точки выбирать для расчета? Может все имеющиеся (в моем случае все видимые напрямую в сцене), но может и нет. Обычно/часто есть "моря", т.е. большие но неинтересные области где ровным счетом ничего не происходит, и было бы замечательно просчитать 5% точек и интерполировать остальные

2) Считать адаптивно. Минимальное число лучей 200. Давайте выбросим сначала напр 13 и посмотрим: если все они принесли один и тот же цвет - ну значит принимаем его и остальные не считаем (это соответствует областям 100% и 0% света). Так-то оно так, но всегда есть риск "пропустить". Один профессор (умер, хороший был мужик) высказал интересную мысль типа: если одна точка "пропустила", то соседние не пропустят. К сожалению, ни одной практической реализации этой задумки мне найти не удалось

Адаптивность можно понимать/трактовать и по-другому. Напр для соседних лучей разница в цвете оказалась достаточно велика - ну значит пытаемся "уточнить" это место добрасывая туда еще лучей. То же самое на уровне точек (пункт 1)

3) И самое страшное: эта хрень рекурсивна. Это я так сказал "считаем цвет в точках пересечения", на деле расчет цвета требует той же освещенности. Ну это так, для общего развития, такие задачи могут повредить std::голову

Что из этого (или что-то еще) Вы хотите обсуждать ?

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

Возможно стоит покопаться в GStreamer (на уровне командной строки). Удовольствие ниже среднего, но шансы есть. Если получится из командной строки - остальное уже "дело техники". Привлекает что можно назначить "источник" в виде URL (там как-то чуть иначе называется, уже забыл), а он разберется с драйверами и.т.п.

[off]Классный язык, в свое время года полтора писал на AutoLISP. Вначале долго "лупал глазками", напр "..присваивает выражение не вычисляя его" - это как Но потом в кайф [/off]

Сколько чего займет - то Вам виднее, но по-любому здесь надо проявить принципиальность. Проект жив? Если да, то надо его апдейтить. Если нет - не дергаться с новыми фичами. А так больше времени уйдет на связки/затычки. И даже в случае их успеха вывод будет типа "нужно делать нормально,, по-человечески"

Решение: портировать это приложение на Qt5. Конечно найдется 100 причин "почему не хочется", но попытки что-то пристегнуть к старой обречены, разница только когда придет понимание этого (может с этим постом чуть быстрее  )

Ну придется рисовать "с оглядкой на него", и полученная альфа 1 бит (bool). Оно может "сегодня больше и не надо", но будет и завтра

Indexed8 - это "байт на точку", альфу негде хранить. Назначить один из 256 прозрачным можно, но это коряво

Indexed8  - вроде бы заманчиво (в 4 раза меньше данных), но не оправдывает себя, проще и лучше юзать ARGB_32 (и выше если нужно). Тогда можно спокойно зачистить с Qt::transparent и рисовать с альфой (uint на точку). Заметим что создание альфа-маски "из черных пикселей" не обеспечивает тот же рез-т всегда

Она там есть, наверно Вы хотите "альфа-маску", надо ее откуда-то взять/создать, здесь не видно др источника/данных кроме черных пыкселей. Значит в ARGB32 и по буферу

C++ (Qt)
if (p == 0xff000000)  // или 0x000000ff, могу путать
  p = 0;

Ну или "готовые проверенные" типа createAlphaMask и др

Ваш аттач имеет альфа-канал, он "весь белый". Format_Indexed8 - по-моему у него альфы и нет, при сохранении ARGB32 будет что в аттаче

Вроде "все так", и это место одно из самых понятных и безобидных. Но тут "бросили кость" - слово "viewing", ну и соответственно перевод "матрица вида" (повбивав би). В рез-те стойкая ассоциация "lookAt - это матрица вида". Многочисленные пережевывания посвящены "глазу", "цели" и где это "вверх".

Однако это всего лишь "частный случай", сама по себе lookAt просто создает матрицу новой СК из подручных средств (аргументов). Умножение на эту матрицу переводит точку из исходной СК (в которой были заданы eye и др) в созданную. В данном конкретном случае (OpenGL render) "из мира в камеру", но это может быть связано с др смыслом.

Да, вопрос чисто академический, где научные работники? Гуляют с собачкой или boost/std пьянствуют 

Плюсы ничего не навязывают, можно просто использовать глобальную переменную
и установить этот указатель при создании MainWindow
Тогда из др окна
Если же делать "в духе плюсов/OOП", то так

C++ (Qt)
// MainWindow.h
class MainWindow {
..
public
  static MainWindow * Instance( void ) { return m_instance; }
private:
 static MainWindow * m_instance;
};

И обеспечить корректность m_instance в конструкторе/деструкторе

C++ (Qt)
// MainWindow.cpp
MainWindow * MainWindow::m_instance = nullptr;
 
MainWindow::MainWindow(.. )
{
  Q_ASSERT(m_instance == nullptr);
  m_instance = this;
  ...
}
 
MainWindow::~MainWindow( void )
{
  Q_ASSERT(m_instance == this);
  m_instance = nullptr;
  ...
}

Тогда использование

C++ (Qt)
// win1.cpp
#include "MainWindow.h"
...
auto * inst = MainWindow::Instance();
if (inst)
 inst->DoSomething();
 

Да, увидел Ваш последний пост, но не стал ничего менять, так даже лучше