SHVV

В этом случае 3D-шники докупают памяти и ставят 64-х битные проги.
Вообще, 7.5м полигонов - это не так уж и много, я на 4-х ГБ открывал и большие файлы (3D Max, ZBrush).
Может файл какой битый?

PS: А программисты пишут утилиту, разбивающую файл несколько более мелких, благо .obj - простой текстовый формат.

Не скажу в ценах, но попробую оценить в человеко-часах.

Poser предельно прост, любую позу на встроенных человеках вы можете выставить сами за несколько минут. Плюс несколько минут на рендеринг, если в большом разрешении.

С остальными редакторами и кастомизацией всё сильно варьируется и зависит от требуемой детализации и выбранной основы. Но не думаю, что займёт больше недели на модель + также несколько минут на каждую позу (если модель со скиннингом), либо + несколько десятков минут и до часа на позу (если модель будет трансформироваться под каждую позу без скиннинга с компенсацией искажений суставов).

Если кратко, полный цикл такой: моделирование -> текстурирование -> скиннинг -> риггинг -> получение нужных поз -> рендеринг.
По затратам, каждый следующий этап проще предыдущего. В ZBrush можно обойтись без скиннинга и риггинга, но постановка поз будет чуть дольше. Тут всё зависит от количества поз, если их реально много, то лучше потратить время на скиннинг, но зато потом клепать их пачками, если их можно перечислить по пальцам одной руки, то время на нормальный скиннинг себя может и не оправдать.

Короче, диапазон очень большой и сильно зависит от ваших требований и бюджета.

P.S.: Может лучше просто разместить заказ на фрилансе и не гадать тут?

На сколько я помню Позер, там реально могут бть дырки, так как вся модель состоит из отдельных кусочков, состыкованных между собой. Я даже в некоторых случаях переносил модель в МАКС и сшивал всё в один меш,, чтобы таких косяков на рендере не было видно.
Но это было давно и сейчас может отказаться не актуальным.

SketchUP

Не надо так делать, используйте углы Эйлера.

Не работал с OSG, но судя по всему вы создаёте планарную проекцию текстуры на объект. Так что не удивительно, что они накладываются не очень хорошо.

Не пробовали использовать текстурные координаты, загруженные из файла? Есть ли они там?

Я голосую за морфинг между несколькими заранее заготовленными модельками. UV координаты при этом должны быть у всех одинаковыми.

Думаю, вам стоит взять готовый опенсорсный движок и посмотреть, как опытные люди это делают.

За основу всех более-менее сложных алгоритмов поиска пересечения выпуклых многогранников берётся "Теорема о разделяющей оси". Суть проста: если проекции многогранников на какую-нибудь прямую не пересекаются, то они не пересекаются в пространстве. Если такой оси нет, то пересекаются. Как таковых конечных точек пересечения у них при этом не будет, будет целый многогранник этих пересечений. Но для физического движка нужно выделить некоторое количество характерных точек и этот выбор будет зависеть от той оси, которую вы сами выберете. В большинстве случаев такой осью выбирают прямую, на которой пересечение проекций минимально.

Какие оси надо проверять? Ведь их бесконечное количество.
Это зависит от топологии. В общем случае достаточно проверять оси коллениарные нормалям всех граней многогранников (в этом случае мы ищем пересечение с гранью), и оси полученные векторным произведением каждого ребра одного многогранника с каждым ребром другого (пересечение ребро - ребро). Но, так как у Бокса очень много параллельниых граней и рёбер, то все их проверять нет смысла. Так как получится куча одинаковых осей.
Итого получается, что нужно проверить 3 + 3 (грани) + 3 * 3 (пары рёбер) = 15 потенциальных разделяющих осей. В первом случае, необходимо потом будет найти пересечение грани с вершинами, и из тех вершин, что пересекают плоскость построить многоугольник и пересечь его уже в 2Д, получив от 1-й до 6-ти точек пересечения. Во втором случае ещё проще - ищем точку пересечения двух векторов.

ПС: Лучше начинать собственный движок с более простых фигур - сфер и касюлей. У них функция пересечения на пару порядков проще.

Как вы написали, матрица преобразования — это матрица перехода от одного базиса к другому. Она может содержать как поворот, так и масштабирование и прочие линейные искажения.

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

Итак, строки матрицы у нас — вектора нового базиса в координатах исходного базиса. Надо их найти.
Один из векторов у нас известен — это направление взгляда, нормализуем его и записываем сразу в матрицу (для OpenGL ось взгляда — ось Z, потому записываем наш вектор в третью строку матрицы). Второй вектор ортогонален первому и некоторой примерной линии, направленной вверх. получаем его векторным произведением вектора взгляда и этого вспомогательного вектора. Получаем вектор, направленный вправо (или влево, в зависимости от порядка умножения). После нормализации записываем его в первую строку матрицы (в OpenGL ось X совпадает с осью X экрана и направлена вправо). Оставшийся вектор получаем векторным произведением уже полученных векторов и записываем во вторую строку матрицы (в OpenGL ось Y направлена вверх). Он должен получаться уже нормализованным.

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