Восприятие освещения

[Garu]

Итак, есть Н объектов, обладающие изрядно-хитрой геометрией, на них НЕТУ никаких коллизий. Так же есть несколько источников света. Нужно получить или через источник света - набор того, что он освещает, или же наоборот - от объекта получить те источники, которые освещают его.
*аналог - свет это огромная сфера, объекты - ригидбоди, которые в нее попали, скриптом выводим в массив те самые ригидбоди*, но все это надобно БЕЗ коллизий.
Из мыслей остановился на сравнивании налепленной текстуры с итоговым ее отображением, но сравнивать 1024х1024 попиксельно - жирновато, да и не даст конкретной инфы о том, что именно тот-то источник света ее задел, а нужна точная конкретика вывода объект-светильник, или светильник-объект.
Варианты в духе - щупать по имени и ловить вертексы объектов по дистанции - все же крайне НЕ желательны, ибо основной упор хотелось бы словить именно через свет, да и погрешностей многовато при таком варианте (пробовал).
И крайне желательно, что бы подход был актуален и для статиков и для скин\скелет-меша.
Вопрос - в куда копать?
П.С. Ссылки под скрипт референс и\или примеры кода - приветствуются =)

[Receptor]

Варианты в духе - щупать по имени и ловить вертексы объектов по дистанции

Тоже об этом подумал. Можно вместо вертексов искать крайнюю точку Bounds. Но это, имхо, еще хуже будет. А почему с вертексами не срабатывает? Просто по циклу перебирать все, у каждого сравнивать дистанцию между центром света и вертексом, если хотя бы у одного из них дистанция меньше половины от радиуса света, то объект освещаемый.

[AndreyMust19]

но все это надобно БЕЗ коллизий.

Шейдером не получится - вынести данные из шейдера в скрипт нельзя.
Для Pointlight - измеряйте расстояние между объектами, равное радиусу света. Если меньше - значит центр объекта попадает в свет. Для большей точности учитывайте AABB-границы коллайдера (но это физика).
Для Spotlight - то же, что с Pointlight, плюс добавляется ограничение по углам между ориентацией ИС и объекта (параметр spotAngle). Для оптимизации проверяйте только объекты, к-е сместились за посл. секунду более чем на 10-25 см. Если объектов много, то стоит делить пространство сцены на ячейки и сначала искать попадание в свет только тех объектов, к-е находятся в ячейках, попадающих в свет.

Вообще мне немного не понятно - зачем без использования физики создавать свою физику? Я бы советовал все-таки не заморачиваться и использовать готовое решение.

[KBEP]

Одним замером расстояния не обойтись - объект может быть закрыт другим объектом от источника света и, соответственно, не освещён. Можно попробовать вручную создать меш-коллайдер, описывающий целевой меш, так, чтобы каждая вершина коллайдера была, что-то вроде представителя нескольких вершин целевого меша. Будем считать, что если свет попадает на вершину-представителя, то он попадает и на вершины меша, которые он представляет. Затем, делать каст от источника света до вершин меша-коллайдера с игнорированием прозрачных объектов и замерять расстояние.

[AndreyMust19]

объект может быть закрыт другим объектом от источника света и, соответственно, не освещён.

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

[Garu]

Варианты в духе - щупать по имени и ловить вертексы объектов по дистанции

Тоже об этом подумал. Можно вместо вертексов искать крайнюю точку Bounds. Но это, имхо, еще хуже будет. А почему с вертексами не срабатывает? Просто по циклу перебирать все, у каждого сравнивать дистанцию между центром света и вертексом, если хотя бы у одного из них дистанция меньше половины от радиуса света, то объект освещаемый.

Это хорошо если в сцене например 3 лампы и 3 кегли, ну и больше ничего, а у меня малясь жирнее выходит. Да и опять же - есть помехи, например в виде стен - тогда источник света должен кидать проверочный рей до набора вертексов, которые попали в нужный радиус. А если стена с прозрачностью? Все эти нюансы учитывать, да и в не шибко малых масштабах - кажется это нехило подвесит машинку =(

но все это надобно БЕЗ коллизий.

Шейдером не получится - вынести данные из шейдера в скрипт нельзя.
Для Pointlight - измеряйте расстояние между объектами, равное радиусу света. Если меньше - значит центр объекта попадает в свет. Для большей точности учитывайте AABB-границы коллайдера (но это физика).
Для Spotlight - то же, что с Pointlight, плюс добавляется ограничение по углам между ориентацией ИС и объекта (параметр spotAngle). Для оптимизации проверяйте только объекты, к-е сместились за посл. секунду более чем на 10-25 см. Если объектов много, то стоит делить пространство сцены на ячейки и сначала искать попадание в свет только тех объектов, к-е находятся в ячейках, попадающих в свет.

Вообще мне немного не понятно - зачем без использования физики создавать свою физику? Я бы советовал все-таки не заморачиваться и использовать готовое решение.

В этом методе очень будет хромать точность, да и это - половина беды. Выше писал про "универсальность" даже под скин\скелет меш, да и он явно не "5 полигонов - орк", а собрать фулку скелета (убогие но триггер-коллайдеры) на каждом пальце, на каждой части руки\ноги\щупальце - боюсь это слишком жирно будет. По этой причине и отказался от такого метода - переизбыток коллизий на душу населения, да и опять же - стены = проверочные касты, как бороться с трансперентом - хрен разберет, а если разберет - то в такой радости ФПС скушается как горячие пирожки...
Вот и ломаю голову именно над точным "попаданием света" на объекты. Может разрабам пингануть на тему дополнительного взаимодействия-считывания света, или с таким запросом думаете лесом пошлют?

[AndreyMust19]

Тогда выбирайте - либо точно и дорого, либо неточно, но дешево.
Либо ищите специфический движок, в котором это можно сделать достаточно точно и относительно дешево.
Garu

Может разрабам пингануть на тему дополнительного взаимодействия-считывания света, или с таким запросом думаете лесом пошлют?

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

[Garu]

Тогда выбирайте - либо точно и дорого, либо неточно, но дешево.
Garu

Может разрабам пингануть на тему дополнительного взаимодействия-считывания света, или с таким запросом думаете лесом пошлют?

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

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

**Или же кто-то знает\может пингануть их с этим вопросом? А то как-то не шибко получается к ним обратиться =(