Честно сказать, вышеозначенные примеры примерно бесполезны, как по мне, но в любом случае спасибо, ваш ответ натолкнул на мысль покопаться в репозитории проекта и там я нашёл решение моей задачи
GavriKos, да я идею прекрасно понимаю и, в итоге, решил так и сделать, в ситауциях, когда не смогу повлиять на пивот модели. А если смогу, то лучше повлиять и не выдумывать лишнего. Но для изначальной идеи решение решил всё же добить. Просто для собственного опыта (вдруг случится так, что пригодиться :) )
#, физически могу, но через костыли и я это уже сделал, определяя в направлении нормали к поверхности случайную точку, а потом запрашивая у коллайдера (контура) ближайшую точку к заданной. Но это даже на словах звучит как дикий костыль. Я надеялся, что есть метод более адекватный
GavriKos, пока что я тоже пришёл к выводу, что нужно создать отдельную точку и просто опираться на неё, но хотелось понять, реально ли решить задачу именно так, как её обрисовал изначально.
GavriKos, #, спасибо вам за ответы, но, честное слово, возможно ваше кураторство вам слегка туманит глаза...
Школьная геометрия, функциональный анализ и даже векторная математика не имеют никакого отношения к заданному вопросу, так как я пытаюсь понять как это сделать именно используя апи, предоставляемое юнити.
Здесь вопрос не чистого кода, а того, что ни гугл, ни документация юнити не предоставляют нам информации о то, как координата в мировом пространстве пивот поинта связаны с размерами фигуры, или размерами её отображения, или точками на коллайдере. у меня есть данные: координаты пивота; 3, 5, 7, размер боундса: "два на три". И всё, никакой информации о смещении одного относительно другого, ни мировых координам вершин этого самого боундса, и координат вершин коллайдера в мировом пространстве, ни локальных координат пивот поинта в пространстве самой фигуры.
JhaoDa, да, это мне понятно, но в том-то и проблема, что
а) внутри include почему-тио тупо путь до папки с проектом
б) всё это безобразие крутиться на винде, а у неё вообще с правами нет вопросов(
Ну я, видимо, не понимаю как. Либо вы меня не понимаете. Пересчитать координаты совершенно бесполезно в данном случае, так как их нужно не просто передвинуть. Нужно увеличить их количество, а потом уже новые передвинуть
Григорий Васильков, Дмитрий
Господа, кто-то должен быть умнее. Зачем превращать всё это в фарс и ругань? Если вы вчитаетесь в ответы друг друга, то поймёте, что не так уж далеки ваши мнения. А более или менее опытный разработчик прочитает все ответы и поймёт что именно ему нужно и кто прав, а кто нет.
Тем более, что панацеи и идеально правильного решения на все случаи жизни всё равно не существует.
В рамках моего вопроса я понял, в чём была моя ошибка и почему не работало то, что я хотел.
В ином случае и при иной проблеме и решение может быть иным.
В конце концов вы же не знаете всей сути моей задачи :) А вам оно и не надо. Это дискуссия уже для других мест и другой ситуации
В том-то и прикол, что переключаться на работу с другой базой должно всё приложение на лету. То есть все модели, запросы, методы остаются теми же и продолжают работать как работали, просто в течении жизни запроса ,выполнившего определённые условия, они должны будут смотреть на другую базу. Задачка, малость, специфична, от того и решение не совсем по документации
Александр Ананьев, да, к сожалению, библиотека отказалась работать с некоторыми из наших камер из-за кодеков. Я связывался с её автором и он мне вполне закономерно ответил, что если я выдам ему ту камеру, которая не работает, он, может быть, когда будет время, допишет работу и под неё. К нему претензий тут нет, но увы, вариант так себе...
