forum.boolean.name - Советы по оптимизации

forum.boolean.name (http://forum.boolean.name/index.php)

- 3D-программирование (http://forum.boolean.name/forumdisplay.php?f=12)

- - Советы по оптимизации (http://forum.boolean.name/showthread.php?t=17056)

Ответ: Советы по оптимизации

Цитата:

Сообщение от burovalex (Сообщение 250776)

Но твоё утверждение SDK с твоих слов по поводу перебора ентити по боксу, А уже далее по геометрии - чушь!

Наркоман штоле??
Если ентити - меш, и стоит режим пика по треугольникам - происходит проверка по боксу ( точнее по дереву боксов ) и потом уже по треугольникам ( в листьях дерева )
Вот тебе пруф, развертка CameraPick ( некоторые неважные места я пропустил ):

файл blitz3dsdk/dev/source/bbsdk/bbblitz3d.cpp

функция bbCameraPick

Код:

943| Entity *  bbCameraPick( Camera *c,float x,float y ){

...|         ...

956|         Line l;

...|         ...

964|         return doPick( l,0 );

965| }

функция doPick

Код:

938| static Object *doPick( const Line &l,float radius ){

...|         ...

940|         return world->traceRay( l,radius,&picked );

941| }

файл blitz3dsdk/dev/source/blitz3d/world.cpp

метод World::traceRay

Код:

127| Object *World::traceRay( const Line &line,float radius,ObjCollision *curr_coll ){

...|         ...

139|         if( hitTest( line,radius,obj,obj->getWorldTform(),obj->getPickGeometry(),&curr_coll->collision ) ){

...|         ...

147| }

метод World::hitTest

Код:

 87| bool World::hitTest( const Line &line,float radius,Object *obj,const Transform &tf,int method,Collision *curr_coll  ){

 88|         switch( method ){

 89|         case COLLISION_METHOD_SPHERE:

 90|                 return curr_coll->sphereCollide( line,radius,tf.v,obj->getCollisionRadii().x );

 91|         case COLLISION_METHOD_POLYGON:

 92|                 return obj->collide( line,radius,curr_coll,tf );

 93|         case COLLISION_METHOD_BOX:

 94|                 Transform t=tf;

 95|                 t.m.i.normalize();t.m.j.normalize();t.m.k.normalize();

 96|                 if( curr_coll->boxCollide( ~t*line,radius,obj->getCollisionBox() ) ){

 97|                         curr_coll->normal=t.m*curr_coll->normal;

 98|                         return true;

 99|                 }

100|         }

101|         return false;

102| }

файл blitz3dsdk/dev/source/blitz3d/object.h

метод Object::collide

Код:

48| virtual bool collide( const Line &line,float radius,::Collision *curr_coll,const Transform &t ){ return false; }

метод виртуальный, перегружается наследниками, поэтому в случае с мешем имеем Object => Model => MeshModel

файл blitz3dsdk/dev/source/blitz3d/meshmodel.cpp

этот самый перегруженный метод MeshModel::collide, берет коллайдер и проводит коллизию с сегментом

Код:

290| bool MeshModel::collide( const Line &line,float radius,Collision *curr_coll,const Transform &t ){

291|         return getCollider()->collide( line,radius,curr_coll,t );

292| }

метод MeshModel::getCollider, возвращает коллайдер ( как для коллизий, так и для пика, т.к. это одно и тоже )

Код:

282| MeshCollider *MeshModel::getCollider()const{

283|         return rep->getCollider();

284| }

собственно метод MeshModel::Rep::getCollider, возвращает коллайдер ( и пересчитывает его, если меш изменился )

Код:

133| MeshCollider *getCollider()const{

...|         ...

160|         return collider;

161| }

метод MeshCollider::collide, из сегмента вычисляет бокс и трассирует им дерево
непонятно конечно почему сразу лучом не трассирует, но не суть

Код:

 54| bool MeshCollider::collide( const Line &line,float radius,Collision *curr_coll,const Transform &t ){

 55| 

 56|         if( !tree ) return false;

 57| 

 58|         //create local box

 59|         Box box( line );

 60|         box.expand( radius );

 61|         Box local_box=-t * box;

 62| 

 63|         return collide( local_box,line,radius,t,curr_coll,tree );

 64| }

перегруженный метод MeshCollider::collide, собственно сама трассировка бинарного дерева

Код:

 66| bool MeshCollider::collide( const Box &line_box,const Line &line,float radius,const Transform &tform,Collision *curr_coll,MeshCollider::Node *node ){

 67|         if( !line_box.overlaps( node->box ) ){

 68|                 return false;

 69|         }

...|         ...

100|         return hit;

101| }

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

ЗЫ
Есь чо возразить?:)

Ответ: Советы по оптимизации

Цитата:

Есь чо возразить?

ты смотрел экзешник?
там даже при остуствии пика по бокусу (курсор уведен в сторону) проверка пика по геометрии работает в 15 раз медленне проверки по боксам. хотя должна быть одинаковой.

видимо blitz3D и blitz3D SDK не одно и то же.

Ответ: Советы по оптимизации

Цитата:

Сообщение от HolyDel (Сообщение 250783)

Вся соль в том, что происходит не рейкаст, а коллизия лучевого бокса ( см метод MeshCollider::collide ) с боксами дерева. Поэтому уводи или не уводи курсор, бокс все равно будет частично задевать другие ( только если совсем в сторону увести ). Что-ж поделаешь если блиц говно :-D
Кстати счетчик Stats3D ( 0 ) показывает ( странно что обнуление не сделали ) как раз кол-во треугольников "собранных" по время трассировки дерева, и по нему видно что даже когда уводишь курсор, трассировка доходит до листьев дерева.

Цитата:

Сообщение от HolyDel (Сообщение 250783)

видимо blitz3D и blitz3D SDK не одно и то же.

Да не, я как-то исследовал некоторые части ( структуры в основном ), совпадения были. Понятно конечно что сдк был лишь основан на части сырцов которыми Марк поделился со своими корешами, но похоже они не так уж и много там поменяли, какие-то баги замазали соплями, какие-то внесли, в целом многое совпадает :)

Ответ: Советы по оптимизации

Цитата:

Наркоман штоле??

Я то нет,и согласен с Холиделом

Цитата:

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

А вот что разработчики блитца, возможно и нарки грёбанные ))

Покрутил побольше тест с pick mode mesh, если в рендер попадают меши фпс сразу падает. Пробовал наводится на пустое место на небольшом расстоянии - фпс в норме. Далее начиная отдаляться,не двигая камеру, фпс начинает падать. Т.е. берутся пик-меши в опеределенном диапазоне от центра экрана.

А с другой стороны, если расположить шары в линию, т.е. чтоб выглядело как линия горизонта, и расположить центр чучуть выше -всё норм. Что противоречит предыдущему выводу. Короче - говнокод!

Ответ: Советы по оптимизации

Сами вы нарики, с кривыми руками на любом ЯП будет все тормозить.
Ну вот НАХЕРА пикать в цикле 100500 высокополигональных мешей?
Блеать, это на асме тоже будет тормозить !
Мозг включить надо и все "проблемы" уйдут.
Варианты всегда есть, как минимум сделать малополигональный невидимый "пик-меш" с отсечением по секторам, или расстоянию (иф двигался - выключить всем пикмод, включить тем кто близко и тд).
И да, используйте ентитипик, он быстрее на многих машинах и удобнее. Используйте ресурсоемкие функции ТОЛЬКО ПО НЕОБХОДИМОСТИ ПО УСЛОВИЮ, а не в цикле от балды (непременный атрибут говнокода всех начинающих). И хватит уже списывать свою убогость на прекрасный инструмент.

Ответ: Советы по оптимизации

http://www.youtube.com/watch?v=K0_eh...ilpage#t=66 s
блин надо не полениться и смастерить игрулю, показывающую "широкий мир" в B3d

Ответ: Советы по оптимизации

Слушай, тормоз, давай без оскарблений. Каждый может сказать, включи мозг, руки не от туда..
Ты сам мозг включи!
Во-первых там всего 1000 мешей, это вполне реальная цифра для сценографа.
Во-вторых. Я не собираюсь 1к мешей пикать. Это тест, меня просто заинтересовала производительность пика.

З.Ы. Для тебя может это глупым кажеся. Но кто-то для себя какие-то выводы сделает.

Ответ: Советы по оптимизации

Цитата:

Сообщение от tormoz (Сообщение 250809)

Сами вы нарики, с кривыми руками на любом ЯП будет все тормозить.

Разве кто-то про ЯП говорил? Речь-то про движок.

Цитата:

Сообщение от tormoz (Сообщение 250809)

Ну вот НАХЕРА пикать в цикле 100500 высокополигональных мешей?

1000 ентитей в сцене помоему вполне нормально. И с каких пор 360 треугольников это высокополигональный меш?

Цитата:

Сообщение от tormoz (Сообщение 250809)

с отсечением по секторам, или расстоянию

А вот это надо делать в самом движке, нормальную систему менджмента сцены, а не тупой перебор с копированием туда-сюда по массивам.

Цитата:

Сообщение от tormoz (Сообщение 250809)

И да, используйте ентитипик, он быстрее на многих машинах и удобнее.

С чего он быстрее будет когда EntityPick, LinePick, CameraPick и т.п. - это все это одна система коллизий, различия лишь в инициализации формы для проверки коллизии.

Цитата:

Сообщение от tormoz (Сообщение 250809)

И хватит уже списывать свою убогость на прекрасный инструмент.

Блиц прекрасен снаружи ( и то, только для нубов которые ничего другого и не видели и\или не могут юзать ), но внутри он убог и больше похож на студенческую "тяп-ляп" поделку.

Ответ: Советы по оптимизации

Цитата:

Сообщение от Platon (Сообщение 250841)

1000 ентитей в сцене помоему вполне нормально. И с каких пор 360 треугольников это высокополигональный меш?

Ну епрст, еще раз: зачем пикать В ЦИКЛЕ ?
Я не могу представить ситуацию где бы это было нужно

Цитата:

Еще раз епрст. При чем тут движок? Это задача программиста - создать логичную схему, не перегружающую впустую систему.

Цитата:

Это из опыта. На некоторых машинах лайнпик выполняется очень медленно. Может в новых версиях пофиксили, не знаю

Цитата:

Плохому танцору - хорошего хирурга!:-D

зы. я как-то вытащил свой древний нубский мега-проЭкт 2002 года и прооптимизировал. Цикл выполнялся 30 мс, после оптимизации 4-5 мс. Это без ускоряющих длл, только правильная логика игры и взаимодействий. А в игре объектов 7-11 тыс одномоментно.

Ответ: Советы по оптимизации

Да ладно, хватит писькой мериться. )
Без обид, тормоз, но ты реально иногда тормозишь. НИКТО НЕ СОБИРАЕТСЯ ПИКАТЬ 1000 мешей в цикле!!!

Цитата:

Во-первых там всего 1000 мешей, это вполне реальная цифра для сценографа.
Во-вторых. Я не собираюсь 1к мешей пикать. Это тест, меня просто заинтересовала производительность пика.

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

Ответ: Советы по оптимизации

burovalex, без обид, но мал ты еще на тормоза наезжать :)

tormoz, вся фишка в тестах - узнать цену метода. ни больше - ни меньше. если методы быстрые - то можно меньше думать - больше прыгать. если методы медленные надо извращаться.

Цитата:

А в игре объектов 7-11 тыс одномоментно.

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

Ответ: Советы по оптимизации

holydel, ты как плагиат - тоже самое, только своими словами, без обид :-D

А на тормоза я и не наезжаю, просто пытаюсь объяснить, что смысл теста - это не кривые руки )

Ответ: Советы по оптимизации

Эти тесты 100500 раз уже сделаны и пережеваны. У меня батхерт, когда впустую на блитц наезжают.
К слову, еще в 2005 на офсайте проскакивала "грамотная система коллизий и пиков" на длл. И быстрее она была аж на 13% в коллизиях и 5% в пиках.
Так что кривизна движка сильно преувеличена.

Ответ: Советы по оптимизации

Цитата:

Сообщение от tormoz (Сообщение 250972)

Я не так давно блитцом занимаюсь, чтобы говорить что для меня всё разжовано.
И скажи, разве плохо что в теме "Советы оптимизации" появился пример с производительностью EntityPickMode???

Ответ: Советы по оптимизации

Мерить производительность ФПС - мягко говоря неправильно. Сделай нормальный тест с замером времени и правильной интерпретацией - похвалим. ;)