Сортировка перед отрисовкой

Качественный метод сортировки объектов перед отрисовкой. Качественный, потому что был использован в God Of War 3 и еще некоторых известных тайтлах. Основная идея: хранить информацию, необходимую для отрисовки, и указатель на объет в массиве в виде пары (key, value). key содержит в себе информацию в виде беззнакового числа и по нему происходит сортировка.

О ядре

В качестве основы для ядра хочу использовать вот это (один двиг - описание в 4х частях): один, два, три, четыре. Точнее начиная со второй половины второй статьи (The Kernel).
То есть основная идея - это использовать ядро (kernel) в качестве организатора цикла обработки всего и вся, а все и вся организовать в виде задач для ядра (tasks). В качестве задач может выступать все, что угодно: таймер, рендер, триггер, физика и тд.
Если кратко об устройстве, то внутри kernel содержится список задач, а у каждой задачи есть 3 метода: start, stop и update. При добавлении задачи, выполняется метод start, при ее удалении из списка - stop. У kernel есть метод execute, внутри которого крутиться цикл, в котором поочередно выполняется метод update у всех задач. Чем меньше приоритет, тем раньше будет вызван метод update у этой задачи в текущей итерации цикла.
На текущий момент все просто - за одну итерацию цикла у каждой задачи выполняется метод update один раз. Мне хочется большего: чтобы была возможность за одну итерацию, для некоторых задач выполнять метод update несколько раз. Объясню для чего это нужно: например, у нас есть задача "физика" (соответственно для обсчёта физики), она должна делать update несколько раз на один раз рендера (например, 10 аптдейтов физики на 1 апдейт рендера). Есть идеи, как это сделать? Прошу помочь ссылками на соответствующую литературу.

Опять о плагинах

Сидел читал разные статьи и комментарии к ним, в частности попались каменты к статье "Применение многопоточности в играх" на геймдеве.
И тут мне в голову пришла аццкая мысль : а что если вынести выполнение работы плагинов в отдельный поток?
То есть в одном потоке у нас крутиться рендер, а в другом выполняются плагины. Такая штука очень хороша будет на современных многоядерных (хотя тут скорее 2х ядерных) системах. Я, конечно, понимаю, что такие штуки довольно сложно отлаживать, но как-то плохо это осознаю =) Хотелось бы услышать (почитать) мнения по этому поводу.

Доп ссылки по теме:

1. про файберы
2. про microthreads в EVE
3. protothreads
   

О плагин-системе

До этого (в концепт-документе, который лежит пока у мну на винте и нигде в инете не светился) рассматривалась только функциональность рендера. Вот решил подумать что должна представлять из себя система плагинов.
Плагины из себя представляют внешние библиотеки (.dll для windows, .so для linux), которые ищутся при старте приложения в заранее заданной директории (например ./plugins), затем конфигурируются (выбираются те, которые следует загружать и выполнять), затем выбранные загружаются и выполняются. Так же должна быть возможностью последующего выключения и выгрузки плагинов (в специальном пункте меню). Плагины, как раз, и занимаются добавлением объектов в рендер для последующего их отображения.
Данные, которые должен содержать в себе плагин:

1. Имя (может не совпадать с именем библиотеки)
   
2. Тип (не обязательно; возможно для последующего разделения плагинов по функциональности)
3. Автор (имя автора + контактная информация)
   
4. Описание (чтобы знать, чего плагин делает)
   
5. Версия плагина
6. Требуемая версия рендера (не ниже)

Примерно вот.

Немного нового (кросспост с блога l1feh4ck3r'а)

Так же я сегодня, для своей дипломной работы, зарегистрировал проект в google code и в gitorious (git-репозиторий). Называться это дело будет microbe. С наполнением там пока туго, а точнее вообще никак - чистота и порядок %) Так же, в перспективе, завести блог по этому поводу (от автора - который вы созерцаете здесь), чтобы туда сваливать все свои мысли, а не хранить их в xpad'е =) Так же эти ссылки можно найти в моем публичном блокноте вот тут.

Lets get the party started

Старт!
Ну вообще-то первые обсуждения начались ещё где-то в начале лета, но там было самое начало и ещё ничего не было решено.
Итак, чего же мы будем делать? А делать мы будем визуализатор для системы МИКРОБ. А если проще, то двиг с системой плагинов.
Выглядеть это будет примерно следующим образом.
Есть графический API (OpenGL) и есть данные. Между ними находится рендер и система плагинов к нему. То есть вот:

OpenGL<->Render<->Plugins<->Data

OpenGL уже есть, данные уже тоже есть(их "производством" занимается "какая-то другая лаборатория в ДВО РАН"), поэтому они зелененькие. Разработкой плагинов будет заниматься опять же "какая-то другая лаборатория ДВО РАН", поэтому они обозначены синим цветом. Плагины будут заниматься переводом данных из того формата в котором они находятся у "какой-то другой лаборатории ДВО РАН" в формат, понятный рендеру. А вот разработка рендера ложиться на наши плечи, именно поэтому он красный. Вот, собственно, процесс создания рендера и системы плагинов и будет рассматриваться и обсуждаться в этом блоге.