заточка кода под быстродействие.

[ieroglif]

1) На 600 единицах (объектах) проходит все что угодно и много на контейнерах не сэкономить. Все же я бы делал попроще

struct CDistObj {
 OGLObject * mObj;
 float  mDist;

 bool operator < ( const CDistObj & sec ) const { return mDist < sec.mDist; }
};

QSet <CDistObj> theDistObj;
// очевидные операции вставки и.т.п

спасибо, понял пока не очень, но думать буду.

2) Рендер "по расстоянию от камеры" дает ограниченные возможности, но если уж Вы так решили - то почему Вы каждый раз выводите ВСЕ объекты "задом наперед"? Делаете по расстоянию - так крутите оптимизацию с буфером (и при удалении тоже)

т.е. задом наперёд? и можно чуть по-подробнее - какую именно оптимизацию и с каким буффером курить? просто поподробнее, что бы точно стало ясно куда копать?

3)

хочется сделать красивую сцену, но стоит докинуть текстурку - получаю минус в скорости. докидываю источник света - та же хрень и так далее...

Хммм... а на что Вы рассчитывали? Если при добавлении текстуры/света скорость падает - то при чем здесь контейнеры?   Откуда убежденность что все должно быть real-time на любом железе?  Для начала отключите туманы и прочие красоты.

да блин.. я понимаю что железо у меня не привлекает к программированию 3д вообще, не говоря уж о программировании красивого 3д.. тот же код на других машинах (с нормальным железом) уже даёт 90-120 фпс вместо 24 моих, но всё же ощущать себя таким убогим совсем не хочется - тогда полностью пропадает интерес к программингу - вот и спрашиваю - где же ещё можно выдрать фпсы? на чём ещё можно выдрать чуть-чуть и сделать по симпатичнее?

[Igors]

спасибо, понял пока не очень, но думать буду.

Вам нужно держать массив сортированным и вставлять в него, правильно? Ну так QSet для этого и предназначен. Это имеет смысл если анимация сводится к добавлению/удалению. А если нет - то все еще проще QVector<QDistObj> и qSort

т.е. задом наперёд? и можно чуть по-подробнее - какую именно оптимизацию и с каким буффером курить? просто поподробнее, что бы точно стало ясно куда копать?

Полагаем что "очередность" меняется часто, от кадра к кадру (иначе нет смысла возиться). Были объекты [0..10], новый объект вставляем на место 5 (например). Значит можно перерисовать от 5-го нового до начала, хвост не трогать. При удалении - наоборот. Как содрать буфера в OGL - (depth и.т.п) - разберетесь.

да блин.. я понимаю что железо у меня не привлекает к программированию 3д вообще, не говоря уж о программировании красивого 3д.. тот же код на других машинах (с нормальным железом) уже даёт 90-120 фпс вместо 24 моих, но всё же ощущать себя таким убогим совсем не хочется - тогда полностью пропадает интерес к программингу - вот и спрашиваю - где же ещё можно выдрать фпсы? на чём ещё можно выдрать чуть-чуть и сделать по симпатичнее?

Почему Вы думаете что 3D = fps и OGL?   У меня кадр может считаться минуты а иногда и часы (на приличном железе) - и я совсем не страдаю от отсутствия фпс'ов, не в них счастье. Все зависит от того что и как рендерится и с каким качеством. Не говоря уже о том что рендер - это довольно малая часть от всего 3D вообще. Смотрите на вещи "ширше"

[ilot]

На мой взгляд контейнер QMap здесь не подходит (не для таких задач он нужен). Тем более, что не стоит использовать указатели в качестве ключей. Предлагаю следующий вариант:

В классе QGLRenderer заменить QMap на:

Код:

typedef QPair<QGLObject*, bool> RegistRecord;
QVector<RegistRecord> objects;

тогда метод render() можно записать так:

Код:

for(int i = objects.size() - 1; i >= 0; i--)
{
	objects[i].first->Render();
	objects[i].second = false;
}

Это не нужно (контейнер итак пустым создается):

Код:

QGLRenderer::QGLRenderer()
{
	objects.clear();
}

niXman: при вставки элементов в вектор перераспределение памяти выполняется не каждый раз, а только тогда, когда исчерпывается выделенная емкость. При желании можно заранее зарезервировать нужное место (см. методы capacity(), reserve()) поскольку автор примерно знает, сколько у него будет объектов. Но в данном случае это вовсе не узкое место - в приведенных примерах контейнеры содержат не сами объекты, а указатели на них. А это значит, что объем данных, которыми оперируют контейнеры нижточно мал! Поэтому метод render() даже в варианте автора должен работать очень быстро (из контейнера в контейнер перекидываются только указатели).

Другое дело, что "скрывается" за указателями QGLObject* ? К сожалению из приведенного кода не ясно как создаются объекты типа QGLObject, как потом в дальнейшем используются (реализация метода QGLObject::Render() тоже осталась за кадром). Вообщем, пока складывается такое мнение, что вся проблема в используемых методах отрисовки. Возможно они просто неправильно/неоптимально используются.

[ieroglif]

после долгого перерыва возвращаюсь к проекту. установил под венду последний Qt, собрал в нём свой проект - тот же самый код работает в два раза быстрее чем в линухе, выдавая под 60 фпс. начинаю задумываться, что узкое место не только в моём коде..

ilot, QGLObject-ы создаются заранее, модельки загружаются тоже заранее, в общем, там всё подготовлено к отрисовке и относительно оптимизированно и хоть возможности оптимизации даже мне видны, но не думаю что это даст сильный прирост... циклов там нет.. просто загружаются массивы координат и текстур в    glNormalPointer, glVertexPointer и вызывается glDrawArrays. массивы тоже подготавливаются при запуске программы.

в общем, на данный момент (после первого запуска в венде и офигения от результата) считаю это проблемой своей карточки (intel 945 чипсет) и начинаю думать над сетевой частью проекта.