Поиск объектов

[SashaRX]

Есть сцена, в ней 20-30 кубемап, каждый объект в сцене должен каждый кадр искать ближайшие 2 и передавать данные в шейдер, подскажите как сделать быстрый поиск, чтобы не пробегать по всему циклу.

[Neodrop]

Не ясна задача.
Для чего эти кубамапы?
Почему объекты должны их искать?
Почему нельзя запомнить для каждого свои параметры?

[Paul Siberdt]

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

[ffinder]

если поиск в массиве из 20 элементов - это совершенно не страшно.
можно не искать расстояния - ограничится их квадратами (избавляемся от вычисления квадратного корня), так как всё равно ищем минимумы.

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

[LunaticX]

еще можно побить территорию на квадратики-секторы , сейвить инфу о кубемапах в каждом и начинать проверять расстояние с ближайших к объекту секторов.

ffinder
а вот эти "вокруг точек назначить триггеры" от чего будут срабатывать?
в моем представлении для этого придется каждый фрейм надувать вокруг объекта сферу-коллайдер и регистрировать первые два столкновения... или как? я с физикой плохо знаком, но любопытно =)

[ffinder]

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

[SashaRX]

Кубемапы будут играть роль Ambient cubemap, я использую лайт мап, и мне нужно запеч освещение в кубемапы для динамических источников, например на лайт мап запечена синяя лампа, и есть динамический объект - бочка, вот мне нужно чтобы подойдя к запечённой на лайт мапе лампочке с этой бочкой, она окрасилась в зелёный, ну и т.д. но тут резкое переключение будит бросаться в глаза, а вот если б, скрипт вычислял ближайшие к объекту и передавал их в шейдер, + коэффициент в процентах, например если первая кубемапа находиться в 1 метре от объекта, а вторая в 3 метрах, то передаём коэффициент 30, ну и в шейдере мешаем кубемапы и получается освещение от статических лампочек любого количества за 1 проход в шейдере, что-то похожее делают в движке Source. Как оптимизацию, думаю можно использовать Sleep, то-есть когда объект неподвижен, никаких просчётов не делать.

[Paul Siberdt]

В Сорсе есть эдакий мехинизм для создания динамических лайтмапов. Но там максимальное число источников света - 3 штуки. Как раз - по числу каналов цвета лайтмапа.
Как только динамические источники переваливают эту величину, лайтмап начинает игнорировать включение/выключение/мигание и так далее лишних источников, или объединяет их в группы.

Как использовать кубумапу для этого - для меня не ясно.

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

[SashaRX]

Эх, нужно относительно объекта найти ближайшие к нему 2 максимально быстрым способом, это если кратко. Вот тут есть описание похожей технологии
http://www.gamedev.ru/pages/null_ptr/ar ... mbient_cub
http://www.gamedev.ru/code/terms/IrradianceVolume

[Neodrop]

Разбить объем на зоны дважды - на мелкие (рабочие) и крупные, содержащие мелкие. Сперва найти в какой из крупных зон находится объект, затем найти рабочую зону.

[ffinder]

то передаём коэффициент 30, ну и в шейдере мешаем кубемапы и получается освещение от статических лампочек любого количества за 1 проход в шейдере

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