Извините, ничего не найдено.

Platon · 26.01.2013, 17:46

Сообщение от burovalex

Но твоё утверждение 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| }

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

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

HolyDel · 26.01.2013, 17:49

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

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

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

Platon · 26.01.2013, 18:11

Сообщение от HolyDel

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

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

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

Сообщение от HolyDel

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

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

burovalex · 26.01.2013, 22:07

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

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

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

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

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

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

tormoz · 26.01.2013, 23:56

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

LLI.T.A.L.K.E.R. · 27.01.2013, 00:57

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

burovalex · 27.01.2013, 08:43

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

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

Platon · 27.01.2013, 08:53

Сообщение от tormoz

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

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

Сообщение от tormoz

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

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

Сообщение от tormoz

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

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

Сообщение от tormoz

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

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

Сообщение от tormoz

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

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

tormoz · 27.01.2013, 22:12

Сообщение от Platon

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

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

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

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

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

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

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

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

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

burovalex · 27.01.2013, 22:40

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

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

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

HolyDel · 27.01.2013, 23:19

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

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

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

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

burovalex · 28.01.2013, 07:15

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

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

tormoz · 28.01.2013, 19:32

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

burovalex · 29.01.2013, 07:44

Сообщение от tormoz

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

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

tormoz · 29.01.2013, 19:02

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