Sigel::EntityShaders

[HolyDel]

хочу поговорить о "объектных шейдерах".
на досуге мне подумалось что неплохо было бы сделать возможность задания "программы обработки" для отдельных объектов.

такая программка вызывается каждый раз перед отрисовкой объекта, в ней могут использоваться все методы объекта (Entity).
пример программки которая крутит объект

void *Turner(Entity* ent)
{
ent->Turn(0,5,0);
}

назначение:

Entity *MyEnt = new Entity(sSomeSurface);
MyEnt->PreProcess(Turner); //назначение программы обработки

далее, при каждом вызове Render() при обработки объекта будет выполненна назначенная програмка. В данном случае она будет поворачивать объект на 5 граджусов по оси Y.

внимание, вопросы:

1) Как вам идея, бредовая или имеет право жить?
2) Что делать с невидимыми объектами (отрезанными по фрустум, или еще каким методом)
//лично я считаю что ничего с ними делать ненадо, в на крайняк проврека на видимость может быть осуществленна в програмке:

void *Turner(Entity* ent)
{
if(ent->isVisible())
ent->Turn(0,5,0);
}

3) Управляющие данные. Вот в Delphi (храние его аллах) у многих компонентов есть такое поле - tag, в нем можно хранить всякую служеную информацию. есть идеи относительно заведения такого поля.
смысл - например можно организвать "затухание" объекта.

void *Fader(Entity* ent)
{
ent->tag--;
ent->Alpha((float)ent->tag/100.0f);
if(ent->tag<=0)
ent->Free();
}

4) Удалить сам себя объект не может в принципе (структура <list> не позволяет удалять элемент во время перебора, хоть явного, хоть через ForEach). что делать? остается одна идея - признак удалленности проставлять. или может иметь какой то локальный список удаленных объектов, который обрабатывается после ренедра, и объекты удаляются из основного списка на рендер)

5) (не по теме).
Скрытие объектов.
сейчас у меня идет примерно такая строчка перед отрисовкой
if(ent->isVisible)
{
//тут рендер
}

собсно идея фикс (уже давно появившеяся, но так и не утвержденная по целесообразности).
скрытый объект переностися в другой список. все просто - объект не будет обрабатываться при рендере вообще. хоть 1000000 скрытых объектов - они не обрабатываются. минус метода - почти бесплатная операция по скрытию/появлению объекта становится недешевой.
внимание вопрос:
как часто вы скрываете/показываете объект. что важнее - скорость скрытия/показывания или скорость обработки?

это банальное назначение функции Update ( или PreRender) для обьекта
лутче сделать список таких функций, даже классов (типов)
и назвать его еффектами

но это всё имхо

[dimanche13]

А я вообще ничего не понял, ну пробуй, ну тестируй, ну заводи списки объектов в фрустуме и вне его, ширяй из одного в другой, ну скорость тестируй, ну выкинь <list> или <vector> или что там у тебя? Критерий - скорость рендера, важен на финишном этапе. Красота кода и вензеля функуий тоже не самый важный параметр на стадии тестирования движка. Дружественность к пользователю, гибкость, предсказуемость и расширяемые возможности - вот главные цели, к которым надо стремиться на данном этапе.

[moka]

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

Вообще не совсем понимаю надобность такого, приведи пример, когда бы юзал подобное?

[HolyDel]

Вообще не совсем понимаю надобность такого, приведи пример, когда бы юзал подобное?

я привел абстрактные примеры. до реальных пока еще не дошло.
up: таки сделал ети объектные процедурки. все работает как надо (кроме удаления)

Хм, вызов выполнения заданий объекта, будет перед рендером, либо при вызове назначеной на эту должность функции?

сама вызывается. если разберусь с удалением, то будет достаточно удобный механихм для создания, например временных объектов (обломки, вспышки), или для контроля параметра шейдера, например передевать в шейдер такю то переменную при таком то условии. Как пример в реале ето может пригодиться для раскраски юнитов.

Я например уже скрываю часто, точнее не очень часто, но если скрываю\показываю, то большими объёмами.

спасибо. это мне полезно.
скрываеш/показываеш кучи объектов в геймтайме?
можно было бы ввести конструкцию типа:

LockEntites();
for(i=0;i<1000000;i++)
{
ents[i]->Show();
}
UnLockEntites();

чтобы ускорить процесс скрытия/появления. (т.е. создать новый временный список в него заносить изминения, и уже при UnLockEntites(); их обрабатывать одинм махом. должно быть быстрее, чем многократное изминение исходного списка, но все равно будет медленние чем просто изминение стейта)

[moka]

Ну выбор твой.
Главное чтобы это не замедляло LoD'ы (не программные, а методом замены на другие версии модели), и на систему Порталов.

[HolyDel]

про систему порталов знать ничего не знаю, а вот лоды будут обрабатоваться на уровне движка (что то типа

Entity *ent = new Entity(sSomeSurface);
ent->AddLoD(sSomeSurfaceLod,100.0f);
ent->AddLoD(sSomeSurfaceLod2,200.0f);
ent->AddLoD(sSomeSurfaceLod3,400.0f);

[moka]

Система Порталов? Представь, у тебя есть indoor сцена, много комнат, в каждой много объектов, так вот, когда ты находишся в другой комнате, то остальные не рендерятся (только если через дверь не видно ту комнату), и всё что в комнате, не обрабатывается, это Очень хорошая оптимизация для indoor FPS или RPG (third/first person). Но требуется разумеется редактор участков и корректная реализация переборов.

[HolyDel]

да ну нафиг. мой движог будет для outdoor сцен приемущественно. и с видом сверху желательно. вообще, он делается с рассчетом на стратегию.