Russian Qt Forum

Добрый день

Есть "облако" точек в пространстве. Каждая точка, кроме своих координат (x. y. z) имеет также набор дополнительных данных (нормаль к поверхности и.т.п). Задача посчитать значение освещенности в каждой точке. Расписывать все детали расчета нет никакого смысла - это глухая специфика. Дело в другом: ф-ция освещенности меняется медленно так что в 90% случаев нет никакой необходимости считать каждую точку (что весьма накладно) - лучше посчитать некоторые (базовые) точки и интерполировать остальные. Ведущие теоретики (Гриша Вард и др.) предложили это много лет назад. Lazy выглядит красиво:

Приступаем к расчету точки

- если кэш имеет достаточно много данных - интерполировать значение
- если нет - посчитать новую точку и вставить ее в кэш

Что Вы об этом думаете?

Спасибо

Igors, если не секрет, ты над каким ПО работаешь?  Для каких оно целей?

для повышения самооценки(в первую очередь). т.е. чел с его уровнем знаний в области с++, вряд ли что-то рациональное сможет написать ;D
к примеру: http://www.prog.org.ru/index.php?topic=14210.msg92996#msg92996  ;D

3D sofware render (т.е. без OpenGL  :))

Эта задача прекрасно ложится под темплейты, итераторы, паттерны и.т.п. - все то что Вы якобы знаете/владеете. Вот и покажите на деле силу богатырскую вместо того чтобы засорять форум детскими выпадами  :)

А книгу такую толстую, красную, типо "разработка 3д игр", автора не помню, не читал? Там такие штуки насколько мне память не изменяет детально были прописаны, я в 2004м этим же маялся помню.

Ну согласитесь: "толстая красная книга" уж слишком расплывчатый ориентир  :) И потом - задача совсем не для игры, ни о каких fps речи не идет. Такой расчет может длиться секунды и минуты, это нормально

книга там так называется, т.к. анимация еще рассмотрена )) остальные кучу страниц про освещение и визуализацию, имнно софтварную. Если "большая красная" ничего не сказала, значит не читали, счас поищу как называется (под рукой нет :( )

Пацаны, я никого не хочу подначить/обидеть и уважаю правило форума "запрещается провоцировать..". Но, блин, обидно


О как Вы смелы когда прочитали решение в Assistant  :) Куда же все девается когда есть задача которую Вы не видели? Почему общие прынцыпы ООП перестают работать? Я написал этот алгоритм 2 месяца назад - но я не удовлетворен ни квачеством ни скоростью. Задача весьма сложна - это типично для вещей которые "формулируются очень просто". Но первые несколько ходов очевидны и обязательны. Так "куда идем - в Москву или в Монголию?". Что есть программирование - творческий (не побоюсь этого слова) поиск решений или запоминание кучи дурацких правил (a la наша малышь),?

Может сегодня "не мой день" - не буду иметь претензий если модераторы удалят этот  пост

Ого)) Кажется я чего то пропустил)

У меня была похожая задача. Тоже имелось целое облако точек и нужно было посчитать амплитуду в каждой точке (комплексная величина). Более того, это облако точек должно было быть случайным, т.е. нужно было проиграть оч много случайных их распределений и затем усреднить полученную амплитуду. Короче, в итоге я забил на эту затею) Проще оказалось воспользоваться диаграммным методом)

То, что освещённость у Вас меняется плавно - как я понимаю, следствие гладкости поверхности, на которой эти точки лежат. А как вы, кстати, освещённость высчитываете? И чем плох тот алгоритм, который предложили Гриша Вард и др.?   

очевидно OpenGL RedBook http://www.opengl.org/documentation/red_book/

Совершенно верно, хотя этот критерий не единственный. Проще говоря есть ф-ция которая принимает 2 точки и возвращает значение от 0 до 1, так что можно судить насколько точки "совместимы" (можно ли интерполировать их)

Это долгая песня и было бы некорректно грузить спецификой. Скажем проще: точка имеет все данные необходимые для расчета освещенности и расчет одной точки независим от другой. 

Они предлагали идею/концепцию, а не конкретный алгоритм