Добрый день

Вот обдумываю (типа "с карандашом и блокнотом") предстоящую задачу, и, правду сказать, боюсь начинать По сути все сводится с графу, есть "вершины" и есть дуги/ребра. Физически вершины - точки на поверхности объектов 3D сцены. Каждая имеет по меньшей мере позицию (x, y. z) в пространстве, плюс нормаль, материал и др. Дуги образуются выбросом лучей из каждой точки, рабочее число дуг от 200 до 1000

Проблем море. Для начала такие квешнзы

1) Как эффективно хранить данные? Прямолинейное юзание контейнеров для дуг забивает всю память практически сразу, и дальше печальное лазание по свопам, 64-бита не спасают. Пока наметил хранить в RAM только точки, дуги как-то подкачивать (а как ?)

2) Как считать дуги? Не, ну выброс лучей конечно thread-safe, но дугу "из A в B" надо считать один раз, а не два. Т.е. просто так "выбрасываться" нехорошо

3) Как создавать новые точки? Начальные получаются из того "что видно на экране". Но лучи могут стрелять куда угодно, т.е. просто так дело никогда не кончится. И опять больное место multi-threading

[off]
Шансы на интересный/продуктивный разговор здесь невелики, но почему бы не попробовать ? Без нормальных тем становится скучно  
[/off]

Спасибо

Ну ладно, расскажу известные/популярные вещи.

Первый способ brute force, типа "а мне похер". Есть точка, выбросили из нее 200 лучей.  В замкнутой сцене (комната) получили 200 новых точек. Из них опять по 200. И.т.д Надо что-то делать, как-то гасить эту "цепную реакцию". Выбора тут особо нет, ну ограничить число рекурсий и уменьшать число лучей для второй и последующих. Последние GPU SDK с поддержкой raytrace вдохнули в этот совершенно тупой способ новую жизнь (ну это ненадолго)

Второй способ - популярный "path tracing". Выбросили луч, нашли новую точку. Из нее в случайном направдении с какой-то вероятностью (называется "pdf") опять выбросили луч. И просто повторяем этот процесс осредняя/накапливая рез-т для исходной точки. Привлекает простота реализации и ноль расхода памяти (ничего не храним). Также доказано что "сходится", если pdf грамотная и вот так долбить, долбить и долбить - получается рез-т высокого квачесnва.

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

Нет, неделю я бы не выдержал) Хотя бесконечности "под ковёр" приходится ножкой прятать)

Я не говорю о полном пересчёте.. Кадр за кадром берём случайные N вершин и для них только пересчитываем рёбра. Конечно (N << N_total)
Если всё более-менее непрерывно происходит, то такой фйинт может сработать..(Но это так, наивный взгляд на проблему..)

Но проблема остаётся. Всё равно нужно запоминапь рёбра на каждом кадре..

 Не важно..
Если Вы вот так вопрос ставите, то как Вы вообще подразумеваете, хотя бы в принципе, эту проблему решить? С либой ли левой, али нет..и Всё равно придётся на каждом кадре пересчитовать..

Ох, как Вы вот так просто с недель на минуты перескочили.. Узкое место в Вашем подходе - это пересчёт рёбер? Тогда не понимаю как кэширование здесь сможет спасти.. Мне самому приходится числодробилками заниматься, и какого то универсального подхода точно не существует. Да, приходится идти на компромисы (скорость/точность) А то и вообще от теории отказываться

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

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

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