Comments 14
UFO just landed and posted this here
Если автор данного материала с ним знаком, то возможно, поскольку в нашем случае это перевод. :)
Я такой трассировщик писал еще в инстуте в 90 годы на делфи, переписывая его с сей из замечательной бумажной книжки по 3д графике )))
Дайте угадаю, книга за авторством Шикина и Борескова? (:
да, вот такая www.ozon.ru/context/detail/id/32018525
Когда-то давно писал аналогичное на чистом JS без каких либо зависимостей с 1 переотражением: http://heap.nologin.ru/ray.html
Ухты, как медленно работает =))
Прикольно.
Прикольно.
Там оптимизаций практически нет. Причём сейчас заметил, что в хроме работает значительно быстрее, чем в ФФ. А на момент написания (лет эдак 6 — 8 назад) было наоборот. Причём за это время скорость в ФФ упала, а в Хроме — выросла. Интересный поворот.
Думаю, если сейчас написать с использованием современных возможностей движков, например, используя, SIMD или хотя бы WebAssembly, то было бы значительно быстрее.
когда то, лет 25 назад, когда я только начинал заниматься графикой — как раз так и считали всё. с тех пор такой подход через фэйковые составляющие уже не используется в рендерах. да, для обучения может и сгодиться из за своей простоты, но надо понимать что это обман самого себя. попытки сделать мягкие тени, преломления с дисперсией и тп. приведут к еще большим надстрокам фэйковых составляющих. в какой то момент ваш код станет очень большим и будет включать 200 слоёв разных составляющих. я помню те времена когда я для рендермана писал свои шейдеры которые как раз и включали в себя все эти слои и позволяли играть с коэффициентами. более того мы еще вы водили каждый такой слой в отдельный файл и на композе можно было поиграться с ними давя тени и делая эффекты которые не предусмотрены были математикой шейдера.
когда компьютеры были медленные — это еще имело смысл. сегодня же уже не используется на практике почти нигде. да, на JS можно такое сделать, но если вы ходите получить хороший результат — то надо использовать уже современные подходы в том числе и к трассировке лучей. возможно данный подход вполне реален на всяких армах и прочих мелких и медленных девайсах, но не на современном компьютере уж точно
это как сегодня учить считать на счётах. да, оно конечно показывает устройство математики и процесс вычисления. но на практике куда проще взять калькулятор
когда компьютеры были медленные — это еще имело смысл. сегодня же уже не используется на практике почти нигде. да, на JS можно такое сделать, но если вы ходите получить хороший результат — то надо использовать уже современные подходы в том числе и к трассировке лучей. возможно данный подход вполне реален на всяких армах и прочих мелких и медленных девайсах, но не на современном компьютере уж точно
это как сегодня учить считать на счётах. да, оно конечно показывает устройство математики и процесс вычисления. но на практике куда проще взять калькулятор
В целом, здесь действительно смысл как раз в том, как пишется элементарный трассировщик, отталкиваясь от математики. В самом конце даже приводится код на Kotlin, который выигрывает как минимум по быстродействию.
А что именно вы называется фейковыми составляющими — модель отражения? И чем это заменено сейчас, хотя бы термины для гугления.
«Точечное произведение» по-русски обычно называется скалярным.
Sign up to leave a comment.
Трассировщик лучей с нуля за 100 строчек Python