GameDev.ru
/ GameDev.ru / Пользователи / Andrey / Сообщения на форуме пользователя Andrey (15 стр.)

Сообщения на форуме пользователя Andrey (15 стр.)

Render Ops6 июля 201211:42#55
Executor
>Для каждого ропа?
> То есть каждый кадр аллокация параметров для каждого ропа со своим количеством
> параметров или как?
Ты шейдера загрузил, с ними же для параметров шейдера сделал аллокацию, зачем что-то аллоцировать повторно? При инициализации ROP ему ссылку на шейдер сохраняют шейдер про свои параметры знает,памятью уже аллоцирована и скольно нужно не больше не меньше. на размер ROP это не влияет, число uniform не ограничено.
>Каждому объекту надо задать свой рандомный цвет, который передаётся через юниформ. Как это реализовано в ропах?
Ага вот тут уже сложнее! Значит расширяем шейдерную систему таким образом, что есть параметры обновляемые Render'ом - матрицы и т.д.(автоматические) И те параметры, которые обновляются, допустим игровой логикой(User Parameters). В таком случае при отрисовке ROP нужно по ссылке на эти User Parametr'ы нужно обновить их для шейдера.
Хранить  User параметры можно прямо в материале, т.к. ROP знает про материал, то при отрисовке ROP значение рандомного цвета запишется в параметры шейдера напрямую, и два наших объекта будут рисоваться с разными цветами. В двух подходах размер ROP неизменен.
Память под все шейдерные параметры опять таки выделяется при загрузке.

Правка: 6 июля 2012 11:44

Render Ops6 июля 201211:03#51
innuendo
> Кстати, может анизотропку включать\выключать по ориентации в пространстве или
> там признаку (пол\потолок) ?
Наверное не стоит, уже перебор.
Render Ops6 июля 201211:02#50
innuendo
> Какие RasterOps в материале ?
CullFace, Blend,DepthFunc(хотя это лишнее возможно), DepthWrite/DepthTest
>А если, например, материал многослойный ?
приведи пример, вообще я бы разбил его, возможно и не нужно так усложнять, на уровне экспорта данных нужно это упрощать. Не нужно движку так сложно с материалом работать.
Render Ops6 июля 201210:58#48
Executor
>   float4 vs_uniforms[256];
>   float4 ps_uniforms[256];
Ну это конечно неверно в корне.
>И всё равно не особо и универсально, а если захочется 1024 регистра в VS послать? Обломс?
Я же говорил храни ссылки, может храни индексы на Lokup Table, пересмотри серьезно структуры данных. innuendo предложил хорошее решение в 45 посту.
У меня в шейдере есть класс ShaderParameters - там все константы для шейдера, их обновляет Render перед отрисовкой ROP. И не важно сколько там констант, причем на размер ROP это не влияет.
Render Ops6 июля 201210:53#46
innuendo
>А что есть материал ?
Textures(с параметрами фильтрации, параметры адресации, параметры отключение анизотропной по расстоянию),shaders(вместе с их лодами), RasterOps, некоторые параметры, например изменения альфа теста по дистанции(для травы деревьев), параметры считается перед отрисовкой ROP, передается в шейдер.
Конечно не претендует на универсальность и правильность.
Render Ops6 июля 201210:35#41
Executor
> У тебя универсально? Как сделал?
Универсально. На самом деле пока в процессе полного перевода на универсальную, пока проблем нету.
Структура содержит примерно следующее:
VB, IB, StartIndex, StartVertex, numPrimitive, Material (указатель), WorldMatrix(указатель) далее нужен набор параметров упакованных в 64 бита. Ну не совсем пока толстый ROP.
Идти нужно примерно от такой структуры.
>Просто получается, что чем универсальнее, тем толше роп.
Ну смотря как ты оформил эту структуру, лучше оставить ссылки на данные если они тяжелые для копирования и т.д.
Можно объединить VB,IB, в единую структуру - будет ссылка(StartIndex, StartVertex может быть разным вдруг со смещением идет отрисовка)
Если не паковать другие параметры, то конечно sizeof будет большим.
про упаковку можно тут  посмотреть
http://www.gamedev.ru/pages/totem4_engine/articles/totem4_article2
Z еще говорил про флаги в рендер операциях.
>Например для шадоумаппинга вообще нафиг не нужно 99% того, что есть в материалах,
а для постпроцесса или для объемного тумана, света и т.д. возможно другие параметры нужны, будешь еще списки другие делать?
Имея универсальную структуру ты можешь спокойно расширять и наворачивать рендер, добавляя проходы и современные техники. Все равно конечный итого DIP + материал.

Render Ops6 июля 20129:57#36
innuendo
> Понятие примитива ещё не появилось в твоей вселенной ? :)
Опустим это понятие, предположив что все Rop содержат это список треугольников. Точки в игрой графики рисуют редко, а линии в режиме отладки движка или в редакторах.
>Это же для группы ROP ?
Почему для группы? Нашел ты кусок геометрии на сцене(кусок сложной модели кусок ландшафта и т.д.) в каждом куске могут быть свои RasterOps. Ну а потом сортировка по приоритемат
Z,Blending,texture,shaders и т.д. тут уже будет по группам.
Render Ops6 июля 20129:30#34
Sergio
> Да, кстати. Объясните про них подробнее. Действительно, ведь они могут быть
> слишком разные, чтобы их объединять в одну сущность.
Нужны примеры. Я так понимаю что при усложнении рендера как раз и возникает сложность в объединении. Можно начать с простого - прозрачный объект и непрозрачный.
В чем разница ? разная функция прозрачности, т.е. в составе RenderOps будет разные RasterOps. Ну и при сортировке это нужно учесть.
Render Ops6 июля 20129:27#33
SNVampyre
Это не совсем RenderOp, или линковку и присоединение шейдеров ты делаешь во время рендеринга? То что ты описал скорей всего часть RenderOps + создание ресурсов.
То что относится к это SH_RENDER_BIND, SH_RENDER_DRAW, причем они должны быть в составе одной  операции.
По идее подход тоже верный, ты накидаешь кучу SH_RENDER_BIND + SH_RENDER_DRAW  и будет почти тоже самое. Только сложнее, слишком сильно разделил то, что не нужно разделять.
Хотя не известно как будет это выглядеть. Пробовать нужно.
Mr F
>пакеты raw данных для рендера, которые откуллились
>это и есть рендерОп?
Совершенно верно.
Есть вопросы и замечания по твоему классу.
>GVertexDeclaration* decl;
>U32 GVDeclSize, GVDeclSize1;
а зачем это тут ? лишняя память, ты подумай какой swap будет тяжелый при сортировке. По идее по вершинному буферу можно узнать его формат, по крайней мере у меня так, а по формату  берется VertexDeclaration все это линейный операции по константным массивам.
>U8 primsize;
А это что ?
Кстати а мировая матрица трансформации где? Достаточно указателя естественно, сама она хранится в объекте/модели и т.д.
Подумать можно еще про упаковку параметров в виде битов.
Где еще набор текстур, Raster Ops ? (Blending, Depth Func и т.д.)
>Объясните идиоту, зачем нужны renderOps, они же не универсальны, чтоб их во что-то объединять.
Почему не универсален?
Для DIP нужно:
VB,Ib, число примитивов, стартовая вершина стартовый индекс.
Материал(текстуры шейдеры Raster Ops)
мировая матрица
+ расширения например для инстансинга как у Mr F
Executor
> У меня они не универсальны. Это плохо?
Да, не очень хорошо, после обхода сцены, рендеру нужно давать список готовых максимально правильно отсортированных примитивных структур данных, хранящих очередную операцию отрисовки с установкой соответствующих настроек. Объекты и графические техники бывают сложными, поэтому некий менеджер, должен собирать с них одинаковые данные,
приводящие в конечном счете к DIP + настройки. Конечно, не так просто это сделать, но стараться все приводить к универсальному виду.
Убогость OpenGL API4 июля 201223:29#318
Blew_zc
>Драйвер вообще может потенциально дать указатель на видеопамять, и никаких выделений и дополнительных копирований не будет.
Ну вот еще дополнительный плюс.
Убогость OpenGL API4 июля 201223:04#316
SNVampyre
> Да, второй вариант намного быстрее, так как не вызывает локов.
значит ты дополнительную память выделяешь, грузишь сначала из файла потом вызываешь glBufferData. У тебя за камерой могут не успевать грузится объекты. Зато да, асинхронно будет грузится в потоке рендера, и быстрее возможно будет копирование, хотя я не уверен что быстро как раз на glBufferData будет просадка.
Теперь все понятно. Дополнительные затраты памяти на загрузку файла, двойное копирование, все та-же остановка в потоке отрисовки. Хотя Lock/Unlock тоже память выделяет, но драйвер может это сделает возможно оптимальнее, чем ты ручным выделением.
Убогость OpenGL API4 июля 201222:01#311
SNVampyre
>Так у тебя два объекта грузились 150мс что ли? Ты определись.
объекты грузились с временем достаточным для простоя и дергания камеры.
> Ты вообще хоть читаешь посты собеседника? Я же писал, что у меня стриминг текстур даёт 2000 текстур 2048х2048 DXT3 в секунду. Тебе такой скорости мало что >ли?
Ну пробуй грузить десяток объектов по 150 метров файлы. Что ты на текстурах зациклился? Как раз текстуры грузились быстрее всего.
Я видел твою сцену. Это кубик с освещение и построцессом. Не надо этим тыкать. Нужно тестировать на десятке гигабайт моделей и на карте 50 км на 50 км. И при полете камеры нужно загружать/выгружать десятки объектов за полсекунды.
Кстати я забыл сказать я грузится с файла сразу в указатель выданный VB/IB/Texture аналог того что выдает к примеру функция glMapBuffer, а ты я так понял грузишь файл в память, а потом копирование в потоке рендера.
Убогость OpenGL API4 июля 201221:22#309
SNVampyre
>10мс - это уже 100FPS.
А если 5 объектов уже 50 FPS ? :) и твой продвинутый рендер на 10000 DIP + все остальное даст слайд шоу?
Еще раз для твоей сцены с машинкой и ландшафтом на 2 полика этого хватит, хороший запас.
> Это копирование практически ничего не занимает по времени. Копирование больших массивов нынешние процессоры делают очень быстро. Я тебе точно могу
> гарантировать, что ты не сможешь так загрузить подгрузку ресурсов в видеокарту, чтобы это было заметно, банально жёсткий диск не будет успевать.
Ну загрузил же, лаги были. Я спорить не буду. Все равно копировать в другом потоке будет быстрее. Пока что У тебя нету опыт стриминга данных Так что давай каждый останется при своем мнении. Заканчиваем бессмысленую дискуссию на эту тему.

Убогость OpenGL API4 июля 201220:52#307
SNVampyre
> Это время включая загрузку с диска или только копирование данных в буферы?
Да это все время, но без учета, Create/Lock/Unlock. Тут по любому в потоке рендера. Ну ты  сократи допустим 10 мс на копирование всех данных для объекта думаю вполне адекватное время и это в кадре очень много, конечно для таких задач как были у меня. И учти что грузится часто, и много буферов и текстур.
Вот и выйдет на все 10 объектов 150 мс. Не думаю что это мало. Тут смысл не в том что-бы взять и грузить в отдельном потоке а в том что-бы не было лагов. Я поставил профайл и понял где лагает. Городить создание много поточного устройства в Direct3D это аналог расшаривания контекстов. Вынеся копирования в другой поток лаги исчезли.
>Ну так в Direct3D9 нет PBO, поэтому там этому нет альтернатив.
ну опять таки копирование в потоке рендеринга. Это нужно выносить, если много данных как по числу запросjв на копирование так и на объемы копирования.
Убогость OpenGL API4 июля 201219:32#304
SNVampyre
>А в чём усложнение-то? У тебя в другом потоке грузятся твои текстуры.
не будем про это, в той ситуации я не хотел ничего делать лучше тут другие факторы.
>> Ты думаешь, с загрузкой в другом потоке это будет быстрее?
>> Я пока не загружу ресурсы для объекта он не попадет в список отрисовки
>А это разве не простой? То есть ты увеличиваешь время ожидания на время синхронизации потоков...
Только он на порядок ниже чем твой рендер будет копировать данные.
>> Он не давал рендеру ресурсы залоченные и заполняемые в другом потоке.
>В общем, куча задержек и неудобств, ясно.
Давай я объясню как было сделано может поймешь что там задержки минимальны.
имеем список объектов array objects;
array
objectsList;
Object :
VB,
IB
textures[n];

Не будем рассматривать машику с сотней кустиков и плоский ландшафт как пример того что это все можно грузить в потоке рендера.
Возьмем примерные времена Для больших реальных сложных сцен. К примеры размер VB 100 метров, а IB 30.
Время загрузки VB - 100 мс, IB - 30 мс, текстура 20 мс. Ну времена примерные.
Если это будет в потоке рендера как у тебя, то сложи эти времена. Согласен синхронизации той что у меня нет. Загрузил и тут-же отправил на отрисовку. Итого 150 мс рендер стоит, тут другая синхронизация - копирование данных.
Как сделал я:
Поток рендера:

UpdateQuaerysLoadingResourceData(); // Creating,Locking,Unlocking VB,IB,Texture
Lock(); // минимальная синхронизация
UpdateObjectList(); // создать список видимых и готовых к загрузке объектов, проходим по objects создаем новый список objectsList.
Unlock(); // минимальная синхронизация
Draw(objectsList);

Поток загрузки:

CreateAndLockVB(); // в потоке рендера создается буфер и лочится, сюда получаем готовый указатель
loadVB(); // разлачиваем буфер - он готов, но рендер его пока не использует
// аналогично для Ib, texture
Lock();
objects.AddNewObject(); // добавляем в objects, теперь про новые готовые ресурсы узнает рендер.
Unlock();
Итак имеем одну CriticalSection на проход по массиву. Это явно не 150 МС, а сотые доли MC. Не знаю понял ты или нет.
И никаких неудобств и кучи задержек с копированием каких-то рендер команд временных массивов STL, кучи левого ненужного кода и т.д.
Если делать такой подход как у меня в случае с OpenGL нужно расшаривать контексты ну как известно там проблемы с синхронизацией, быстродействием. Вот тут OpenGL сливает даже Direct3D9.

Следующие темы >>

2001—2012 © GameDev.ru — Разработка игр