3D.ru

Доброго времени суток, Господа. В методе обработчика триггера мне нужно узнать какой именно объект столкнулся со мной, и продолжить выполнение при определенном. Если я напишу вот так:

не долго проверять так Тег?

Что-то вы заморочились совсем. Знаете сколько во всём коде вашего проекта происходит подобных ваших и внутренних проверок? Думаю очень много и ничего, работает ведь. Так что никакая проверка на тег не притормозит вашу игру.

Что-то вы заморочились совсем

Возможно.

Знаете сколько во всём коде вашего проекта происходит подобных ваших и внутренних проверок?

Я имел ввиду не проверку на тег, а проверку на Строку, тег имеет я так понимаю string тип? И сверять строки это довольно дорого. И я сомневаюсь, что разработчики Unity3D внутри своего движка используют проверки Строк.

bretbas писал(а):

Что-то вы заморочились совсем

Возможно.

Знаете сколько во всём коде вашего проекта происходит подобных ваших и внутренних проверок?

Я имел ввиду не проверку на тег, а проверку на Строку, тег имеет я так понимаю string тип? И сверять строки это довольно дорого. И я сомневаюсь, что разработчики Unity3D внутри своего движка используют проверки Строк.

Используйте collider.CompareTag(yourTag), он вроде как быстрее чутка.

Rando_OM, collider.CompareTag тоже в параметре принимает строку...возможно внутри происходит сравнение строк по какому-нибудь другому принципу, но не думаю...
Вообщем стандартными средствами Unity3D никак не сделать обозначения объектов, чтобы это были не строки? В C++ я писал свою собственную систему тегов, которая добавляла тег через макрос, который генерировал enum. Очень удобно было и быстро. Сделать придется тоже, я так понимаю, ручками все писать...

bretbas писал(а):Rando_OM, collider.CompareTag тоже в параметре принимает строку...возможно внутри происходит сравнение строк по какому-нибудь другому принципу, но не думаю...
Вообщем стандартными средствами Unity3D никак не сделать обозначения объектов, чтобы это были не строки? В C++ я писал свою собственную систему тегов, которая добавляла тег через макрос, который генерировал enum. Очень удобно было и быстро. Сделать придется тоже, я так понимаю, ручками все писать...

Мне кажется, что строка, что число не так сильно повлияет на быстродействие. Но если вдруг, то можно на ассет сторе посмотреть

Rando_OM,

Мне кажется, что строка, что число не так сильно повлияет на быстродействие

Там внутри идет сравнение. Что быстрее сравнить, int или string? В последнем будет посимвольное сравнение, а это достаточно долго...

bretbas писал(а):Rando_OM,

Мне кажется, что строка, что число не так сильно повлияет на быстродействие

Там внутри идет сравнение. Что быстрее сравнить, int или string? В последнем будет посимвольное сравнение, а это достаточно долго...

Это само собой понятно, но в реальной жизни мне кажется не заметно.

Rando_OM,

Это само собой понятно, но в реальной жизни мне кажется не заметно.

Еще как заметно. Представьте, что у нас больше 1000 объектов на сцене, есть 100 тегов, по 10 объектов на тег. Тег имеет тип string, где количество символов >10. И еще мы разрабатываем приложение для мобильных платформ.
С какой скоростью мы найдем все объекты того или иного тега? Это будет ужас и провисание в fps...

Оптимизаторы оптимизировали оптимизировали да не выоптимизировали.

bretbas писал(а):Rando_OM,
Еще как заметно. Представьте, что у нас больше 1000 объектов на сцене, есть 100 тегов, по 10 объектов на тег. Тег имеет тип string, где количество символов >10. И еще мы разрабатываем приложение для мобильных платформ.
С какой скоростью мы найдем все объекты того или иного тега? Это будет ужас и провисание в fps...

Только что проверил. За 0мс Юнити решает подобную задачу, что как бе намекает.
Поиск уходит под капот, но в упрощенной форме там должно быть что-то вроде

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

bretbas писал(а):Тег имеет тип string, где количество символов >10

А нафига в тег пихать столько символов, вы что делаете теги типа : "GreenGrassGrowsOnTheGround" ?

Поиск будет практически мгновенным

Ну с Dictionary то все ясно. Dictionary реализован на хэш-таблице. Следовательно в нем нет никаких переборов строк. Берется строка-ключ, считается ее хэш и уже по нему ищется. Более того не просматриваются все записи словаря, т.е. поиск O(0)!
Интересно - поищите. Можно начать с этого https://habrahabr.ru/post/198104/

Dewa1s, seaman, возможно Вы правы. Я не знаю, что там у Unity3d под капотом, поэтому при первом виде, что поиск "как-будто" происходит по строкам, у меня сразу включилась параноя. Спасибо за ответы

IDoNotExist,

А нафига в тег пихать столько символов, вы что делаете теги типа : "GreenGrassGrowsOnTheGround" ?

Нет, я не делаю. Я вообще пока что ничего не делаю, просто сижу и щупаю unity3d с разных сторон:)

возможно Вы правы

Я не утверждал, что поиск по тегу идет так как написал Dewa1s. Я не проверял, так что утверждать не могу. Я сказал как будет происходить поиск в словаре, а вот есть ли такой словарь в Юнити?- я сомневаюсь. Во всяком случае Юнитеки в один голос говорят, что Find(любой) - медленная операция. И медленная не из-за строк.
Лучше всего, конечно проверить утверждение Dewa1s, но если оно не подтвердится можно использовать кеш как написано ниже. (Не советую! Лучше просто не привязываться к тегам!)
Если у Вас частый поиск (не однократный в начале игры, в Start как советуют делать),- можно закешировать поиск в том же словаре. Типа (использовать на свой страх и риск, т.к. я не вижу причин частого поиска, при котором такой вариант будет хорош):

Ну и дальше уже ищете в cache свой объект.
Еще раз. Вышеописанный Start будет долгим! Чем больше объектов на сцене, тем дольше. Но потом поиск будет достаточно быстрым.

есть большое подозрение что Юнити использует внутри себя тот же словарь , хеш-таблицу.

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

поэтому предлагаемый кардебалет никоим образом не повысит производительность.