LINUX.ORG.RU

Непростой вопрос о структурах данных


0

2

Занимаюсь преждевременной оптимизацией (сейчас или никогда) 2д физики. Хочется разбить пространство на квадраты (клетки) и с помощью этого быстро находить соседние объекты, для детекции коллизий. Особенность в том, что будет очень много мелких объектов, одна итерации физики (обсчет за время dt) это несколько проходов (возможно >10) по всем объектам и определение коллизий. Из-за этого нужны эффективные структуры данных.

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

Задачи,

1. Быстрый список, не отъедающий много памяти на указатели.
Решение: Unrolled linked list

2. Быстрый пересчет списков клеток и объектов после их перемещения.
Решение: Объект хранит список пар (клетка, ссылка на ссылку на себя в этой клетке), по ссылке объект удаляется за постоянное время. При пересчете определяется новый список клеток для каждого объекта, сравнивается со старым, исчезнувшие клетки удаляются из списка и одновременно удаляются ссылки на объект из этих клеток, ну а появившиеся клетки добавляются в список вместе с соответствующей ссылкой на элемент списка клетки. И вот здесь уже есть проблема, при удалении из unrolled linked list меняется порядок элементов и ссылки будут указывать не туда куда должны. Не менять порядок элементов значит допускать пустоту в списке, нехорошо.

Иное описание проблемы, два списка, первый содержит элементы, второй ссылки на элементы первого. Как при проходе по второму списку правильно и быстро удалить соответствующие элементы первого. Вторых списков может быть много. Первых тоже. Ссылки могут быть на элементы разных первых. Использовать не unrolled списки тоже есть нехорошо.

★★

И вот здесь уже есть проблема, при удалении из unrolled linked list меняется порядок элементов и ссылки будут указывать не туда куда должны. Не менять порядок элементов значит допускать пустоту в списке, нехорошо.

Почему нехорошо?

mikki
()
Ответ на: комментарий от mikki

>Почему нехорошо? Обход такого списка не эффективен, добавлять новые элементы в эти пустоты, тоже, и надо еще подумать как.

amaora ★★
() автор топика
Ответ на: комментарий от dmsh

Адаптивное разбиение пока не планируется, с регулярным сложности. Ну и проблем бы не было ели бы не надо было перестраивать это разбиений по >10 раз за итерацию. Большинство объектов подвижны. И причем перестраивать не полностью, зная что во многих случаях изменения не велики.

amaora ★★
() автор топика
Ответ на: комментарий от amaora

Обход такого списка не эффективен, добавлять новые элементы в эти пустоты, тоже, и надо еще подумать как.

Упростить операции можно просто: каждый узел листа должен содержать кол-во свободных элементов, +индекс в виде пирамидки из сумм свободных узлов (элемент высшего уровня считается как сумма 2-4... 2^k элементов нижнего уровня) на случай большого кол-ва узлов.

Поддерживать достаточный уровень заполнения можно временными «ребалансировками» узлов. Такой метод имеет хороший потенциал оптимизации.

mikki
()

А почему бы при изменении положения элемента в списке не обновить ссылки?

creepnee
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.