Сообщение от pax
Собственно перед расчетами все координаты поделить на размер клетки, а после домножить. (Привести в единичную систему)
В коде есть -.001 и +.001, т.е. с каждой итерацией будет расти ошибка?
|
Собственно да. Есть немного говнокода. Это можно немного подумать и исправить, но оч сильно хотелось использовать функцию в деле, поэтому пришлось поторопится. Как я и писал, еще немного позднее попробую подправить код и этот недостаток попробую учесть.
п.с. При дальности пика куба в 10 клеток(это уже неиграбельный параметр) погрешность становится в 0.01. Имхо заметно только нам с вами
Сообщение от Nuprahtor
Это хорошая статья.
Когда можно будет погонять .exe пример?
|
Я хочу эту функцию применить при перерасчете передвижения игрока. (копать он уже может). Редактор тоже есть. Короче пара мелочей и буду выкладывать. (надеюсь в пределах этой недели будет.)
Сообщение от Igor
А может, искать пересечения луча не с кубиками, а с плоскостями? Потом их округлять и получать кубик.
(Берём много плоскостей - параллельных XOY, XOZ, YOZ и отличающихся на целое число третьей координатой. Ищем точки пересечений. Потом у этих точек округляем координаты и получаем положение кубика)
|
Идей и теорий куча, вопрос в том кто возьмется за их реализацию? А потом еще и сумеет качественно поделится этим с народом. Была еще одна идея похожа на эту. Вектор проходящий через грань представляется как вектор принадлежащий прямой. Точка Dest(x2,y2,z2) - просто как точка (в нашем случае это был конец вектора). Должно было высчитывается смещение точки относительно прямой и по переменной смещения находилась проткнутая сторона куба и т.д. Но мне с косинусом угла чот больше понравилось.
Ну а за полурусский язык простите, с чем словарь в мозилле справляется так и выкладываю
Ошибки вроде подправил.
Нашел главный баг. Не предусмотрено деление на ноль практически везде. Омг
