Доходит игрок до некого триггера, чем инициализирует процесс подгрузки уровня(в целом он может подгрузиться и не сразу, я допускаю что этот процесс займёт какой-то время). После чего создаётся второй поток, внутри которого создаются буферы, в них и будем выгружать данные с харда. После окончания загрузки ждём когда первый поток доложит об окончании итерации, после чего просто скидываем буферы из второго потока в первый(так как у меня используется список, то процесс этот займёт константное время. После подвязки данных убиваем второй поток и продолжаем дальше.
Dmitrii, Больше похоже на костыль, чем на адеквтное решение. Тем более что игровая сцена целиком легко может весить несколько гигабайтов или даже больше. Хранить её мёртвым грузом такое себе решение. В играх как раз и используются подгрузки кусков сцены по необходимости
Здравствуйте, словарик у меня уже и так есть, пользуюсь lingvo, самый удобный из тех, что встречал. Но всё-таки это словарь и переводить предложения он не может.
На счёт жанра литературы то да, это именно техническая
На счёт читать текст, который хорошо знаком на русском. Проблема в том, что нужные мне книги есть только в англоязычной версии и полны научных терминов, понимание которых и на русском языке даётся с большим трудом
Разрешение коллизий не совсем то, что мне нужно. К тому же я уже раз 100 перечитал статью винтера о GJK + EPA алгоритме :)
Wataru уже написал именно то, что я и хотел. Правда объекты ведут себя немного не так, как ожидается, но это из-за того, что алгоритм EPA в принципе возвращает не реальную нормаль проникновения, а ближайшую. Но у меня уже есть несколько идей как можно решить эту проблему.
я так понимаю вы предлагаете заменить фи на нормаль плоскости контакта соприкосновения, а вместо углов движения использовать вектор движения. Но ведь в формуле есть косинус из фи. Я ведь не могу скалярно умножить 1 вектор
я пиши свой 3д игровой движок и в данный момент пишу для него физику. Задача реализовать физику этих столкновений. Для разрешения коллизий я уже использую GJK + EPA алгоритмы.
Просто мне сказали, что эти формулы слишком сложны для игровых симуляций и лучше придумать что-то попроще.
задача умножения матриц реализована в сонме готовых библиотек, начать поиск можно с них.
Все необходимые операции с матрицами у меня уже есть. Писал я их сам, хоть и знаю о существовании всяких там glm библиотек. Задача перенести эти перемножения на видеокарту, так как умножать приходиться очень много.
А на счёт поиска, я находил презентации, по типу этой, но предпочел бы уроки в текстовом формате.
Dmitrii, на самом деле в моём случае однозначно лучше обычный статический массив. Просто ранее я использовал вектор, но после перехода заметил значительное снижение расхода памяти.
Просто стало интересно, а есть ли ускорение в плане производительности. Ведь вектор я использовал для хранения вершин моей 3д геометрии, соответственно обращался к нему постоянно и не выборочно, а ко всем элементам.
Но если он основан на динамическом массиве, то как тогда выполняется вставка элементов?
Массив, хранящийся в оперативной памяти, я представляю себе так:
[какие-то даннные]-[наш массив]-[какие-то данные]
Благодаря этому доступ к элементам постоянный.
std::vector я представляю себе так:
[какие-то даннные]-[наш вектор]-[какие-то данные]-[ещё данные с вектора]-[какие-то данные]-[и ещё данные с того же вектора]
В таком случае чтобы найти данные по определённому индексу нужно сначала понять где они хранятся физически