Raycasting note
Статья Shiru Otaku про рейкастинг была
изъята из неопубликованного материала
Adventurer #14. В соответствии с традиция-
ми нашего издания (а точнее,его Guide-час-
ти ;), она также снабжена моими ремарками.
Разумеется, моё мнение не является истиной
в последней инстанции. Кстати,данный мате-
риал, достаточно сдобренный личным непони-
манием со стороны лекторов, преподаётся
на курсе "Компьютерной графики" в районе
третьего курса специальности "Программное
обеспечение чего-то чего-то и чего-то че-
го-то". Спектрумистам учиться в ВУЗе по
данной специальности не советую.
Изначально в статье содержалось мнение,
что персонаж нельзя вращать по оси, перпе-
ндикулярной экрану. Вот так:
Однако я со своей стороны полагаю, что
это возможно. Для этого нужно строить кар-
тинку, будто герой не вращался около этой
оси, а потом переносить картинку на экран
в повёрнутом виде.
Конечно, это редко может потребоваться,
но вдруг? В demo, например...
Стены под 45° (т.е. с СВ на ЮЗ или с СЗ
на ЮВ ) можно реализовать и в стандартном
рейкастинге,и в моём варианте,где сканиро-
вание сплошное. Во втором случае это отни-
ет не так много процессорного времени, но
это число теоретически.Поскольку цикл ска-
нирования станет очень сложным. При входе
в каждый кубик нужно проверить,есть ли там
диагональная стенка, и если да, то какая -
в соответствии с её типом должен произойти
переход на нужный вариант внутреннего цик-
ла. При обработке диагональных вариантов
одна из координат должна быть искажена:
X=X+Y, или X=X-Y, или Y=X+Y, или Y=X-Y, в
зависимости от типа стенки и направления
входа в кубик. То же нужно сделать с пере-
менными, содержащими шаг. Тогда цикл будет
работать как обычный, т.е.сложение с выхо-
дом по переполнению.
Собственно,и в стандартном рейкастинге,
если тип кубика со стенкой знать заранее,
скорость упадёт вовсе не в 2 раза. Но ал-
горитм, видимо, ещё мудрёнее.
Alone Coder
