Frozen_Light писал(а):
К тому же, может ли она быть динамической?
Уж она так точно динамической может быть безо всяких осложнений. Гарантирую, ибо сам испытывал.
Frozen_Light писал(а):
Я, повторюсь, считаю, что сначала нужно создать минималистичную локацию для теста физики.
Ну так нужно понять, что создать. Локация - это абстрактно. Я конкретизирую - локация=карта высот, матрица чисел, символизирующих высоты соответствующих точек на ландшафте. Какой размер карты высот (к примеру, 1024х1024 вершин), какой формат (char/int/float/double), что насчёт карты нормалей, текстурных координат? И т.д.
У нас нет дэдлайнов. У нас есть время подумать и обсудить, чтобы сделать не на скорую руку, а обдуманно. Я умирать завтра не собираюсь, а возвращаться к старым проектам для переделки очень не люблю.
Мои мысли: в файле хранить только матрицу высот. Нормали вычислять после загрузки, но не динамически во время отрисовки; текстурные координаты вычисляются динамически (прямо в шейдере). Т.е. в файле на диске хранится лишь массив высот, затем при подгрузке этот массив грузится в память, создаётся дополнительный массив нормалей и рассчитывается. Всё это делается отдельным потоком - когда Игрок подлетает на определённое расстояние к требуемому куску карты (но ещё не захватывает его в зону видимости), менеджер графических данных (МГД) метит в карте мира требуемый кусок карты загружаемым, затем запускает поток-загрузчик, который выполняет вышеописанные действия, и по оканчании процесса этот кусок карты помечается готовым к использованию, а сам поток-загрузчик захлопывается. Когда МГД определяет, что кусок карты вошёл в зону видимости, он ссылается на соответствующую ячейку в мировой карте на предмет готовности требуемого куска карты. Если кусок ещё не готов, МГД останавливает все процессы на х миллисекунд в ожидании завершения процесса подгрузки карты, затем проверяет статус снова, и т.д.
Вышедшие из зоны использования куски карты сохраняются обратно на диск.
Насчёт динамического изменения карты. Каждый кусок карты может изменяться лишь одним потоком - если два и более потока будут менять одни и те же данные, в лучшем случае, результат будет не определён. Это значит, что куски ландшафта, возможно, стоит делать меньше по размеру, а воронкоштамповательным свойством наделять не всё оружие (или только терраформинговую технику). В добавок, изменения ландшафта на уровне карты высот не получится сделать анимированными - если занять единственный процесс постепенным изменением формы одной воронки, то вторая воронка может появиться лишь после оканчания анимации первой. Посему изменения ландшафта должны быть дискретными: взрыв - воронка, пук терраформера - яма на (санти)метр глубже. После изменения карты высот карта нормалей тоже должна быть пересчитана.
Посему размер куска карты ландшафта подлежит обсуждению. Возможно, 256х256 вершин будет оптимальным решением?