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