Pull to refresh
121
0

Пользователь

Send message

Такой подход является стандартным для .NET мира. С таким же успехом можно критиковать в целом подход к работе с async\await в .NET и тасками.

Для .Net мира может и является стандартным, а для Unity мира - нет. В стандартном .Net не было корутин, вместо них появилось решение async/await. Но в юнити такое решение как корутина было всегда. И оно более удобно в этом плане.

А вообще, я вам про то что это не удобно, а вы мне "это стандартное решение".

При работе с файлами точно также нужно вручную освобождать ресурсы или вы и от этого инструмента отказались?

При работе с файлами я использую using. Это удобно. А вот с CancellationTokenSource так не получится.
К тому же, чтение файлов, так скажем, не самая частая операция в игровом движке.

По моим наблюдениям в районе половины компаний используют UniRx\UniTask вместо того, что бы изобретать свои велосипеды. К слову, а всякие WhenAll\Any \ContinueWith и тп вы тоже будете велосипедить? 

Ну хорошо, что используют.

Еще раз: стандартную корутину можно запустить без привязки к объекту. А так-то, да, я люблю велосипеды :)

Самая большая проблема async/await это остановка корутины. Использование CancellationToken громоздко и неудобно. Этот токен нужно протаскивать во все корутины, и во все вложенные корутины тоже. А еще его нужно генерировать. Вы в примерах показываете только передачу токена в корутину. А ведь если посмотреть внешнюю обвязку, то там кода для CancellationToken еще на добрый экран наберется.

Токен генерируется через CancellationTokenSource. А оно в свою очередь должно быть объявлено полем в MonoBehaviour. И еще оно IDisposable, а значит его нужно корректно диспозить. А что бы его диспозить нужно вызвать его Dispose в событии OnDestroy. А вот это событие вызывается не всегда (и при краше приложения и в редакторе). В результате чего асинхронная операция продолжает себе спокойно выполняться дальше после того как основной поток уже умер или вышел из плей-мода.

В общем, CancellationToken это боль. А вот с классической корутиной таких проблем нет. Вызвал StopCoroutine и все.

К тому же, зависимость корутины от MonoBehaviour вы почему-то записываете в минусы. Но на самом деле, привязка жизни корутины к жизни объекта сцены вполне логична и удобна.

Если же нужно сделать непривязанную ни к чему корутину, то это делается легко через какой нибудь самописный Dispatcher который у всех давно уже есть.

В целом async/await это хорошо и правильно. Но вот проблема остановки таких корутин к сожалению останавливает от их использования.

Для генерации деревьев лучше использовать случайные последовательности с низкой дисперсией. Например Halton sequence или Plastic sequence. Это намного быстрее, чем генерить случайные точки а потом их "расслаблять".

Основной недостаток подобных систем в том, что в глобальном масштабе они бессмысленны.

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

Максимум - для генерации отдельного здания.

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

В целом с мясными изделиями в турции плохо. Среди турков колбасы не популярны, они их почти не едят. Соответственно и ассортимент в магазинах малый.

Но мы уже привыкли. Из турецких колбас едим только Hindi (куриная колбаса, не похожа ни на какую их наших колбас, но зато имеющая какой никакой мясной вкус). Также в Seç бывает колбаса Ukrainska (на самом деле она похожа на Дрогобыцкую или на Шинкову) - ее можно есть, она вкусная, но бывает редко.

Также есть "русские магазины" где можно найти более привычные продукты, но и цены там соответствующие. Мы туда не ходим.

Есть еще пельмени. Но нужно покупать именно те, где написано "пельмени". Потому что традиционные манты на вкус - такие же как сосиски, то есть никакие.

А как же турецкий суджук?

Это есть невозможно. Как и большинство турецких колбас/сосисок.

Только сейчас заметил, что картинки имеют гораздо большее разрешение. На первой действительно нашел два лося (по крайней мере я думаю что это лоси:). А вторая картинка в полном разрешении у вас не открывается.
Про лосей. Удалось найти решение этой задачи? Как на мой взгляд это из разряда impossible.
А каков FPS и на каких разрешениях?
У меня несколько вопросов:
1) Удается ли распознавать смазанные номера, когда камера тряслась при съемке, типа такого:
Скрытый текст


2)Удается ли распознать расфокусированные номера:
Скрытый текст


3) Аналогичный вопрос — для непрямых, изогнутых номеров:
Скрытый текст


4) Что вы делаете с афинными искажениями (skew):
Скрытый текст


5) Ну и наконец номера типа таких удается распознать?
Скрытый текст

Скрытый текст

Скрытый текст


Спасибо.
Участвовал в прошлом турнире, в финале занял место где-то в районе первой двадцатки. Тогда было интересно. Хотел поучаствовать и в этом турнире, но почитал усливия игры… и передумал.
Проблема в том, что в этом турнире я так и не понял за счет чего вообще можно победить. В танчиках поворот корпуса и башни занимал приличное время, и там можно было подъехать сзади или сбоку и иметь профит. Это было основой всех стратегий. Здесь же если солдаты находятся в видимости друг друга то оба могут убить друг друга. Поэтому подкрадываться сзади — смысла нет. Выглядывать из-за угла — тоже проблематично из-за особенностей движка.
Поэтому стратегия сводится к кропотливому подсчету очков действия и т.п. странным вещам. Получается какая-то бухгалтерия сплошная. А экшена нет.
У автарки буква b сильно подпортила контур и оно посчитало что это уже не квадрат )

Это в OpenCV, верно?
Да, контуры ищутся с помощью OpenCV
Контурный анализ


Думаю использование пула имеет очень ограниченную область применения.
Во-первых, он усложняет приложение.
Во-вторых, он требует очень аккуратного использования. Как уже писали, если вы не очистите ссылки в CleanUp — будет утечка памяти (и это еще в лучшем случае), а сделать такю ошибку — очень легко.
И в-третьих — он бесполезен для больших объектов (те, которые в LOH). И вот почему: откуда может взяться объект размером 85к и больше? Очевидно, что это массив(список, строка). Но есть ли смысл хранить массив в пуле? Ведь массив обычно нужен переменной длины. И как пул может нам помочь здесь? Менять длину массива он не умеет. А если бы даже и умел, то только путем создания нового массива, что сводит на нет преимущество пула. А кроме того, метод CleanUp должен будет чистить весь массив, а это может занять значительное время, если массив действительно большой.
Если же объект не является сам массивом, а содержит поле с массивом, то пул тоже бесполезен, потому что метод CleanUp обязан будет уничтожить ссылку на этот массив. В общем как ни крути, но для больших объектов — пул не подходит в общем случае.
Ага, понятно. А когда идет сравнение вот этих Iris Code, то сравниваются только те области, которые не прикрыты веком в обоих развертках?
А еще такой вопрос. Ведь при сжатии зрачка — радужка расширяется. Вы просто нормируете все развертки к одинаковой высоте, что бы компенсировать это растяжение?
А как вы обрабатываете ситуацию, когда радужка прикрыта веком? Веко как то распознается?
И еще, сравнение инвариантно к наклону головы? То есть если наклонить немного голову набок — система уже забракует?
Не участвовал в этом конкурсе потому что заметка на хабре была больше похожа на рекламу Шри-Ланки, чем на конкурс по CV. Прочитав название «Увлекаешься компьютерным зрением? Ivideon зовет тебя на Шри-Ланку!» сразу закрыл :)
Во-первых, мне совсем не хочется ехать на Шри-Ланку. А во-вторых, я CV не увлекаюсь, я в нем работаю. Я конечно понимаю, что компания себе ищет молодых разработчиков, но тогда и не стоит удивляться что профи не откликнулись на этот конкурс.
Хотя тема конкурса была вполне себе интересная…
Автор, тема интересная, но не раскрытая. Нужны примеры гистограмм, картинки, примеры классификации. Ведь этот метод на самом деле очень мощный (особенно вместе с HOG). Например, было бы интересно увидеть программу для автоматической классификации изображений. Это как раз та задача, с которой LBP хорошо справляется.
Для инвариантности к вращению используются uniform patterns. При этом, к рассмотрению берутся только паттерны вида:
10000000
11000000
11100000
11110000
11111000
11111100
11111110
11111111
И все их циклические сдвиги (всего 58 кодов).
Поскольку каждый uniform patterns является сдвигом одной из перечисленных комбинаций, то каждому из этих паттернов можно присвоить номер комбинации (8 штук). И этот номер уже будет инвариантным к вращению.
Я понимаю ход ваших мыслей. Однако метод который вы предлагаете даст заведомо худший результат, чем метод динамического программирования.
Это легко доказать: метод динмического программирования гарантированно дает решение, при котором невязка между левым и правым изображением — минимальна. У вас же алгоритм ничего не гарантирует, а значит дает худший результат. Более того, результат вашего алгоритма не детерминирован. Ведь если вы будете сканировать строки слева направо и справа налево, то вы получите разные результаты.
По сути вы применяете самую простую инутитивную эвристику: если точка сдвинута на dx, то и соседняя точка тоже сдвинута на dx. К сожалению, это простое и неправильное решение. Оно дает посредственные результаты.
Кроме того, для этой эвристики можно применить более простую схему с предсказывающим фильтром (типа фильтра габора) и без всяких партиклов и роев.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity