Войти
ПрограммированиеФорумГрафика

Рендеринг. Кто как делает? (9 стр)

Страницы: 18 9 10 11 12 Следующая »
#120
16:53, 11 апр. 2016

innuendo
>2) Отсекай объекты на большом расстоянии через Clip Distance.
> Он же сказал про DX9
вот это в перлы.
Причем тут АПИ мне непонятно. Может объяснишь?
>Зачем ты работаешь с GL ?
>Мыши жаловались, но продолжали грызть кактус ?
Верно подмечано, ну типа того. Пока он есть пригодиться опыт работы с ним.
Mr. Rabbit
> надо алгоритм кокой нить для быстрого отсекания лишнего.
т.е. тормозит отсечение по Frustum ? на 2000 объектах? сколько объектов в кадре? я так понял 1 объект 1 DIP ?
>да не в этом проблема,
А ты попробуй БЛИЗКО расположенные объекты слить в 1 DIP, число DIP уменьшиться, Если конечно материалы одинаковые. Ну а тка изначально уровень спроектирован не оптимально. Но для теста CPU/GPU bound как раз подходит.


#121
17:01, 11 апр. 2016

Andrey
> > ) Отсекай объекты на большом расстоянии через Clip Distance.
> > Он же сказал про DX9
> вот это в перлы.
> Причем тут АПИ мне непонятно. Может объяснишь?

ClipDistance и ClipPlane это не совсем одно и тоже

> т.е. тормозит отсечение по Frustum ? на 2000 объектах? сколько объектов в
> кадре?

А как же Octree ?

#122
17:09, 11 апр. 2016

Mr. Rabbit
> ЗЫ: насрать, попробую по сфере динамически всё отсекать.
Clip Distance чуть быстрее. Но в целом особо толку не будет. Но я не верю что 1900 объектов тормозят на отсечении. профилировал?
innuendo
> ClipPlane
Где я говорил про ClipPlane? И как его использование(IDirect3DDevice9*::SetClipPlane) оно уменьшит числоDIP ??? вот ты жжешь. Я так и подумал, тут отсечение по кварту расстояния для мелких и дальних объектов.
>А как же Octree ?
тут ему не поможет.

#123
17:12, 11 апр. 2016

Andrey
> Clip Distance чуть быстрее. Но в целом особо толку не будет. Но я не верю что
> 1900 объектов тормозят на отсечении. профилировал?

Не, не профилировал. А чё за Clip Distance ? отсечение по фрустуму не тоже самое?

#124
17:22, 11 апр. 2016

Mr. Rabbit
> А чё за Clip Distance ? отсечение по фрустуму не тоже самое?

Сейчас мы услышим правду :)

#125
17:28, 11 апр. 2016

Mr. Rabbit
>Не, не профилировал.
Сделай это. Я уверен что тупой перебор с проверкой по Frusutm 1900 объектов не будет тормозить.
> А чё за Clip Distance ? отсечение по фрустуму не тоже самое?
Нет. Frustum может сказать что объект виден, к примеру на большом расстоянии, но не выходящим за пределы Far ClipPlane Камеры, но по факту он на экране занимает пару пикселей, Но шейдеры, буферы, материалы, выставлены и DIP вызван, но результат бесполезный.
При растеризации, есть некие правила, если треугольник не занимает какое-то число пикселей, то он не рисуется, но зачастую это правило выполняется но на тяжелых загруженных сценах можно выкинуть значительно число объектов занимающих несколько пикселей на экране, ощутимо не влияющих на результат.
Проверяй квадрат расстояния до камеры и выкидывай объекты из списка. Это уменьшит число DIP.
Расстояние можно подобрать экспериментально. Но можно и посчитать по хитрой формуле, учитывающей площадь проекции объекта на экран что по сути примерное число видимых пикселей, допустимых для правильного визуального результата.

#126
17:40, 11 апр. 2016

Andrey
> Я уверен что тупой перебор с проверкой по Frusutm 1900 объектов не будет
> тормозить.

7 лет назад, когда вместе работали  ты не был так уверен ! :)

> Но можно и посчитать по хитрой формуле

количество пукселей зависит от  разрешения :)

#127
17:41, 11 апр. 2016

Andrey
Дельно говориш, попробую, отпишусь.

#128
17:47, 11 апр. 2016

Mr. Rabbit
> Дельно говориш, попробую, отпишусь.

Ох, это уровень школьника-студента

#129
18:33, 11 апр. 2016

К слову в самом сталкере, в формате уровней был зарезервировано место для неких порталов, предполагаю, вот как раз эффективного отсечения геометрии на CPU. Но по факту они их так и не заюзали. Видимо и видеокарта неплохо справилсь с отсечением.

#130
18:39, 11 апр. 2016

g-cont
> Но по факту они их так и не заюзали.

Юзали. Поставь в шейдере portals_ps красный цвет и увидишь. Это окна в зданиях и тд

#131
18:40, 11 апр. 2016

Стоит ли использовать единый формат вершин на весь движок, или для каждой цели использовать свой? Ну например для мешей один формат, для системы частиц другой. Я все большое склоняюсь к тому, чтобы использовать один формат на всё.

Например такой:

struct Vertex {
  Vector3 mPosition;
  Vector3 mNormal;
  Vector2 mTexCoord;
  Vector3 mTangent;
  Vector4 mBoneIndices;
  Vector4 mBoneWeights;
};

Он подойдет и для мешей (в том числе со скелеткой), и для систем частиц - в mBoneIndices, mBoneWeights можно положить дополнительную инфу для частиц. Что думаете?

#132
19:33, 11 апр. 2016

>Что думаете?
необоснованый перерасход памяти

#133
19:41, 11 апр. 2016

А типа дрочерство с разными форматами лучше? Кстати у меня максимум 1,5kk вершин на уровень игры. При таком формате это всего лишь 108 Мб.

#134
19:56, 11 апр. 2016

mr.DIMAS
> Я все большое склоняюсь к тому, чтобы использовать один формат на всё.
Фу. Это перерасход памяти, нагрузка на пропускную способность памяти и кеш.
Надо делать много форматов и выбирать наиболее оптимальный из них для каждой задачи.

А частицы вообще должны допускать наиболее гибкий формат частиц: от 0 байт на вершину, до сколько угодно, в зависимости от того, что не используется конкретным эффектом или считается\интерполируется шейдером, а что считается и передаётся с CPU. Прокачка на шине кучи лишнего мусора каждый кадр очень сильно ударит по производительности.
И ещё есть смысл не делать всё interleaved в одном куске, а поделить на потоки. Например для shadow map не нужны тангенты и нормали, и текстурные координаты не нужны, если не используется альфа-тест. Так что позиции лучше в отдельном буфере или части буфера держать.

Сделай формат отдельным ресурсом, как текстура, меш и т.п. и пусть меши хранят в себе его или ссылку на него. Добавление поддержки нового формата вершин будет лишь заключаться в том, что ты создашь новый экземпляр этого ресурса и может быть создашь структуру для удобного заполнения и заливки данных. При желании ещё можно написать функцию-конвертер в\из массива структур, которую ты написал в посте #131, но лишь для того, чтобы можно было изредка генерировать и модифицировать геометрию.

Страницы: 18 9 10 11 12 Следующая »
ПрограммированиеФорумГрафика

Тема в архиве.