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

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

Организация Streaming data loading в 3D движке7 окт. 200918:04#11
innuendo
> у меня спросить :)
итак
>плавующие блоки в памяти ( через handle адрессуешь, а не через прямой указатель )
что за Win32 функция?
>что бы работать делаешь им lock(), пишешь, потом unlock() -
HeapLock/HeapUnlock ?
>через некую дельту времени если нет локов активных внутри критсекции делаешь уплотнение
HeapCompact ?
Организация Streaming data loading в 3D движке7 окт. 200917:56#8
Прибой94
> а есть способ дефрагментации оперативки
не знаю таких, рекомендуется не делать фрагментацию.
innuendo
ContentStream - хорошая реализация. Буду опираться на нее.
>плавующие блоки в памяти ( через handle адрессуешь, а не через прямой указатель )
>что бы работать делаешь им lock(), пишешь, потом unlock() -
>через некую дельту времени если нет локов активных внутри критсекции делаешь уплотнение
где поподробнее почитать?
Организация Streaming data loading в 3D движке7 окт. 200916:37#5
flaber
Ну какая тут критика. Это быстро? не падает? просадки FPS при подгрузке есть? Память не фрагментируется? значит хорошо.
кстати какое API ?
Организация Streaming data loading в 3D движке7 окт. 200915:48#2
innuendo
>ContentStream пример видел из DXSDK ?
нет. спасибо сейчас гляну.
Организация Streaming data loading в 3D движке7 окт. 200915:41#0
Привет всем!
Суть задачи в следующем. Есть сцена с условно бесконечным размером, т.е. большой протяженности. На ней большой кол-во объектов. Требуется при передвижении камеры динамически подгружать их и выгружать старые. Все грузить сразу нельзя, просто не хватит памяти. при каком Условии выгружать старые еще не подумал, но варианты выгрузки есть
такие:
- Если объект не виден, удалить через некоторое время, тут может быть тонкость, можно и не удалять, если есть свободный лимит памяти и т.д;
- удалять если он на большом расстоянии, тут тоже можно учесть время и свободное место в памяти.
Теперь вопросы:

1)Как делать выгрузку старых? на уровне объектов или на уровне ресурсов? на уровне объектов - удалили сам объект, вместе с ним все  графические ресурсы - материалы(текстуры, шейдеры), вершинные, индексные буферы. Тут можно объект пометить как пустой и использовать для загрузки другого, просто записав новые данные.
На уровне ресурсов тут все понятно - просто удаляем графические ресурсы
2) Как корректно и быстро выгружать старые данные? сохранять временно на диск? или просто освобождать память? или хранить в памяти? Либо самые старые сохранять диск? могут быть проблемы с фрагментацией?
надумал простую идею. Создаем большой файл средствами проецирования файлов в память. Каждому ресурсу выделяется позиция + смещение равное размеру данных.
При очередной выгрузке/подгрузке данные скидываются/загружаются оттуда. Какие тут могут быть проблемы?
3) Как организовать распределение задач по потокам?
На данный момент реализовано так:
1 Поток - рендер. 2 Поток - загрузка. Сейчас это работает. При полете камеры грузятся появляются объекты. Выгрузку еще не реализовывал.
В каком потоке делать задания на загрузку новой группы объектов? Сколько объектов лучше грузить, и в отдельных потоках ли это делать или все в одном?
4) Главный вопрос каким образом сделать эту реализацию что-бы производительность не падала.

Если еще что-то не понятно, задавайте вопросы я допишу.

Поиск по форуму ничего не дал.
Буду рад любым ссылкам, рекомендациям.

Спасибо всем заранее.
С Уважением, Андрей.

STL. Использовать или нет?7 окт. 200914:51#1060
Outlaw
итак по порядку.
>>часто std::fill для зануления массивов, можно и memset но небезопасно,
>чем не безопасно? если размер массива известен, какие ошибки тут можно сделать???
std::fill действительно не нужен. Везде можно memset.
>>ты в циклах не пишешь std::for_each ? мне удобно, коротко, тут уже на любителя,
>так нада функцию писать, мало мест где такое удобно.
ну в паре мест это есть, и это не часто.
>>std::copy удобен, конечно на memcpy можно заменить, но если объекты не сложные, часто std::find использую 1 строчка и все.
>копировать массивами сложные объекты??? зачем??? мы про геймдев же а не про биздев и т.д. теболее в движке.
std::copy в одном месте не получится заменить на memcpy, идет копирование int32 массива в массив int16 тут можно исправить ситуацию, возможно пересмотреть структуры данных и т.д. В других можно заменить на memcpy.
>>у тебя нету поиска массивах?
>зачем что то искать в массивах? ресурсы по имени?? ну догда хэшмап.
>что ещё искать???
std::find есть несколько, в режиме рендеринга есть одно место где есть std::find_if - поиск шейдера по квадрату дистанции(при большом расстоянии упрощенный шейдер ставится)
просто есть ли тут смысл для массива из 3,4 шейдеров  делать hash ?
>...а то вон один уже спекся, кризис кризис кричит везде.
да я адекватно отношусь к критике, анализирую просвещаюсь. делаю тесты, смотрю профайлером, смотрю asm код и т.д.
ну вот к примеру недавно действительно проверил что std::binary_search быстрее std::map хотя сложность у них одинакова...
vladislav
> В C++ такого нет - это приравнивается к велосипеду - тут нет неясностей.
ну в любом случае во всех реализациях STL это есть. Тут неясность писать ли свой Hash Map со статической таблицей, либо пользоваться этим.
Нужно детально исследовать проблему сколько элементов будет и т.д.
STL. Использовать или нет?7 окт. 200913:03#1044
Outlaw
часто std::fill для зануления массивов, можно и memset но небезопасно, ты в циклах не пишешь std::for_each ? мне удобно, коротко, тут уже на любителя, std::copy удобен, конечно на memcpy можно заменить, но если объекты не сложные, часто std::find использую 1 строчка и все.
я не спорю не все идеально у меня но эти алгоритмы полезны. У тебя всего это нету?
у тебя нету поиска массивах? и ничего не копируешь? std::max_element/min_element при построении вершинных буферов использую - наверняка не нужен можно пересмотреть алгоритм.
STL. Использовать или нет?7 окт. 200912:37#1039
Outlaw
> конкретно вот тебе что нужно из алгоритмов?
ну я думаю вот что можно использовать:
std::sort, std::find, std::find_if, std::binary_search, std::max_element, std::min_element, std::fill, std::fill_n, std::copy, std::for_each,
std::nth_element, std::replace, std::lower_bound, std::upper_bound, std::transform(хотя это для std::string а без него обойтись можно),
std::swap, std::reverse, std::count

правка добавил еще

Правка: 7 окт. 2009 12:44

STL. Использовать или нет?7 окт. 200911:58#1034
Outlaw
>ну так вроде пришли к выводу что кроме std::vector вроде в гемдеве больше нифига и не нада
наверное еще наверняка пойдут все алгоритмы STL кроме тех что выделяют временно память для своих нужд.
неясности еще с stdext::hash_map.
Передача данных от вершинного шейдера в пиксельный6 окт. 200917:38#48
innuendo
еще не пробовал. не знаю как.
STL. Использовать или нет?6 окт. 200917:37#1023
innuendo
а... блин точно по привычки не глянул внимательней, std::count имеет право жить.
STL. Использовать или нет?6 окт. 200917:33#1020
innuendo
>и почему count тормознее чем transform ?
std::find, transform они как раз нужны и удобны.
а вот потоки ввода вывода это вообще убожество.
http://www.ipolyakov.com/old/ru/stdioVSiostreams/comparison.html
Передача данных от вершинного шейдера в пиксельный6 окт. 200917:25#46
innuendo
>А как ты сделаешь в GL больше 8 ?
не возникало пока такой задачи. хватало 4 вроде...
в общем согласно доке по Cg:
The Cg profiles for GLSL provide access to all the uniform constants and variables documented in Section
7.4 (Built-in Constants) and 7.5 (Built-in Uniform State) respectively of the OpenGL Shading Language
specification found at:
http://www.opengl.org/documentation/glsl/
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.20.8.pdf

ну а там всего 8.
в общем ждать новой версии, вроде должен GLSL 1.5 поддерживать.
STL. Использовать или нет?6 окт. 200917:22#1015
innuendo
все кроме cout, это тормоз.
Передача данных от вершинного шейдера в пиксельный6 окт. 200914:19#39
Neptune
пиксельный скомпилился(glslf). Вершинный не хочет(glslv):
C:\Program Files\NVIDIA Corporation\Cg\bin>cgc.exe planet_land_diff_water_bump_atm_rings_light4_ecl0.cgv -profile main -profile glslv
planet_land_diff_water_bump_atm_rings_light4_ecl0.cgv(35) : error C5102: output semantic attribute "TEXCOORD" has too big of a numeric index (8)
planet_land_diff_water_bump_atm_rings_light4_ecl0.cgv(36) : error C5102: output semantic attribute "TEXCOORD" has too big of a numeric index (9)
187 lines, 2 errors.

Cg компилит успешно в профиль vs_3_0(Direct3D).
А вот Cg в профиль vs_2_0 выдает ту-же ошибку.
Может Cg еще не держит наверное больше 8 текстурных координат для OpenGL ? в новой версии может что измениться.

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

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