Пержде чем поучать удосужтесь ответить хотя бы на один из вопросов. Я еще раз справшиваю, на каком основании Вы утверждаете что в моей версии OpenCPN отключена поддержка OpenGL? Я Вам дал развернутый ответ о том, где я взал эту версию, показал пункт меню, в котором отчетливо видно, что OpenGL включен. Его можно отключить и заметить разницу. А Вы почему-то продолжаете утверждать что это не так. Почему? В мануле, который Вы мне зачем-то даете, и который я в свое время прочитал вдоль и поперек, нет ответа ни на один из вопросов.
Что значит спам? Я оставил один единсвтенный комментарий под этой статьей, в котором рассказал своем опыте работы с OCPN и сборки под Android. Дальнейший диалог Вы развиваете сами. Сами же затронули вопрос о "быстром рендере" и производительности. И эта ветка диалога именно об этом.
Что касается грамотности, я уверен что это Вам нужно внимательно изучить хотя бы терминилогию, и понять что же из себя предсвляет CUDA и в каких отношениях она находится с графическими API. Я не уверен что вообще могу Вас понять. Намешали все вместе, карты, воксели, CUDA, OpenGL. Как это связано? Скажите честно, Вы имели опыт работы с OpenGL и в полной мере понимаете о чем идет речь?
Моя "поделка" (почему в таком унизительной тоне?) выполняет ровно те задачи, для которых создавалсь и обладает ровно тем функционалом, который от нее требуется. Почему одна должна повторять функционал OpenCPN? Это два разных софта, котоые я сравниваю лишь в части производительности рендера.
Не хотите продолжать диалог - не продолждайте более. Я лично не привык оставлять обвинения в мой адрес неотвечеными.
И кстати, я до сих пор не могу понять причем тут CUDA? Точно ли ту СUDA, Вы имеет в виде, что SDK от Nvidia? CUDA - во-первых работает только на картах Nvidia, во-вторых, предназначена для выполнения параллельных вычислений общего характера и не имеет вообще никакого отношения к рендеру. Это тоже самое что вычислительный шейдер. Или OpenCL. Вычислительный шейдеры давно есть в современном OpenGL/ES, как Вы предлагаете их использовать в данной задаче? Разве можно CUDA вообще противопоставлять графическим API, типа OpenGL?
С чего Вы взяли что в OpenCPN на видео отключего ускорение OpenGL? Оно включего по умолначни, в меню-> отображение -> дополнительно-> использовать ускорение OpenGL. Сравнение вполне коррентное. OpenCPN 5.2.4 из официального сайта, я его не собирал самостоятельно. Без ускорения было бы в районе 5 FPS (я сейчас попробовал отключить). На видео видно что в некорых сценах FPS падает ниже 60, судя по плавности, счетчик почему-то не работает, хотя включен в опциях (карта GTX 1060). В моем рендере FPS почти никогда не опускатеся ниже 180 даже в самых нагруженых сценах, в среднем больше 200. Настройки парамтеров отображения карты оналогичны. Сравнивал производительность на разных устойствах. Отошение примерно такое, как я сказал.
А как функционал влияет на fps? Он есть, где-то там. Но не включен же постоянно, т.е. не влияет ни на время формирование кадра ни на отрисовку. Я не думаю что дашборд вообще может как-то сущетвенно влияеть на производительность. По сравнению с картой, сотоящей из миллиона полигонов, сотен тысяч вершин, и тысячи спрайтов, одновременно находящихся на экране это несущественно. Ровно как и наличие диалогов с формами. Как факт их наличия может оказывать влияние на производительность, особенно в части отрисовки карты? При сравнении я стараюсь создавать одинаковые условия, ни там ни там не открыти ни диалоги, ни дашборды. И кстати, сайдбар сбоку: что значит отдельная область вывода? Он отрисовывется в том же контексте, что и вся карта. QML сначала передает контекст мне, я рисую все что нужно - а потом, сверху уже рисуется весь интерфейс. Но я не думаю что он "съедает" больше 1 FPS.
Разница в производительности обосновата как минимум тем, что OpenCPN не объединяет похожую геометрию в batch. Тысячи объектов на экране = равно тысячи вызовов отрисовки. Batching - это самый очевидный способ оптимизации рендера. Использует glBegin - glEnd вместо, того чтобы рисовать геометрию из вершинного буфура (VBO). Совершенно не задействуется многопоточность при подготовке кадра. Вот она и трехкратная разница в производительности . Я в коде OpenCPN где-то на протяжении года ковырялся и вполне себе разобрался. Изначально именно на его базе делался весь функционал, для нужд лаборатории. На видео 2018 года еще осталась та самая версия на базе OCPN.
Под GUI я имею в виду средство для создания кросплатформенного графического интерфейса. И в этом смылсе я противопостовляю wxWidgets - Qt. Понятно что Qt это больше чем просто GUI, но тем не менее это основная его задача - создание кросплатформенного софта с графическом интерфейсом.
Выбрал Qt в перую очредь из за большого количества поддерживаемых платформ и простоты сборки. Поменял таргет в среде(Qt Creator это все же просто среда разработки с точки зрения терминологии) c Windows на Android и вот ты уже собираешь проект под андроид или IOS. Без проблем. К тому же сам графический инфтефейс куда более кастомизируемый и визуально приятный. Особенно QML. wxWidgets в этом плане выглядит совсем уж аскетично.
CUDA же это про параллельные вычисления на картах NVIDIA а не про рендеринг, развне нет? Unity все-таки игровой движок, и скриптуется C# а не C++. Пришлось бы интегрировать С++ библиотеки (а большая часть библиотек из этой предметной области написана именно на C/C++ ). К тому же опыта работы с Unity и С# у мне не было и нет.
Меня в общем то в Qt устраивает все. Кроме лицензии пожалуй. LGPL с одной стороны позволяет использовать софт в коммерчеких целях, но там какие-то сложные моменты, типа того что нельзя линковать библиотеки статически, а IOS зарпещеат линковаться динамически, и еще много тонкостей и органичений.
По поводу быстрого рендеринга: я использую непосредственно OpenGL/ES, объединяю всю похожую геометрию в группы(batch). Все символы на карте также рисуются за 1 вызов. Линии тесселируются на CPU, а сглаживаются во фрагментном шейдере. В итоге производительность раза в 3 выше чем в OpenCPN при значительно более качественной графике. Навряд ли можно сделать быстрее, чем с помощью непосредственно графического API. https://www.youtube.com/watch?v=msDhjk1dndk
В свое время, будучи студентом очень сильно помучался в попытках собрать OpenCPN под андроид, и безуспешно. На одной из стадий была ошибка и я не знал как её решить. На, cruisersforum создал тему, и мне по этому поводу коротко ответили что мол версия для андроид более не бесплатная. Мне в общем то нужен был минимальный функционал (отображение карт s57, судна и ais целей) для научной лаборатории, где я тогда уже параллельно работал. При этом требовалась поддержка большого количества платформ, в том числе Android и желательно IOS. С этого момента началась моя эпопея с созданием собственного картографического движка. В качестве GUI выбор сразу пал на Qt. Сначала рендер карты осущетвлялся при помощи QPainter, затем полностью переделан под OpenGL (cовместимость с ES 2.0). Сейчас хочу и вовсе "оторвать" весь код от конкретного фреймворка (специфичные классы и методы) со всеми его лицензиями, чтобы для работы требовались лишь OpenGL контекст и ввод. Мне вообще кажется что OpenCPN довольно сильно устарел: wxWidgets с его лишь частичной кроссплатформенностью; первобытный fixed-pipeline OpenGL, чего только стоят glLineWidth и GL_LINE_STIPPLE.
Почему-то прочитав заголовок, подумал что речь пойдет об OpenGL.
Не знаю позволяет ли yandex api создавать пользовательские слои, но если бы я думал о решении данной задачи, то в первую очередь смотрел бы в сторону собственного слоя с OpenGL контекстом.
Для рендеринга сглаженного круга достаточно нарисовать прямоугольник, все остальное сделает специальный фрагментный шейдер. В том числе сразу с обводкой. Чтобы не было 100к вызовов отрисовки, батчим все прямоугольники в один буфер и рисуем всю сцену за 1 вызов.
Если же использовать современный OpenGL ES c (AEP) и поддержкой геометрических шейдеров, то для каждой метки достаточно добавить в буфер одну вершину, причем без проекции, а проекцию координат и создание прямоугольника доверить геометрическому шейдеру.
У родителей на даче такие пчелы завелись года два назад. Был удивлен, узнав что они занесены в Красную книгу. Гудят как вертолет, совершенно не агрессивные. Хорошо опыляют пассифлору. Там расположение пестиков и тычинок как раз под такие размеры опылителя рассчитаны.
Я на 100% не уверен, но разве время доступа к файлу зависит от общего количества файлов данной директории? Не слышал о таком. Вот допустим у нас есть функция QImage* getTile(const QString& filename). Внутри она пытается открыть файл по имени, и естественно обрабатывает случаи, в который указанного файла нет на диске. Опять же, на одной сцене всего около 30 тайлов. Если одного из тайлов не окажется на диске, то он как бы и не будет отрисован. Т.е. 30 обращений к файловой системе за кадр(и то, если мы полностью изменили текущую область видимости не экране). Я в свое время делал приложение для растрирования векторных морских навигационных карт и разбиения их на тайлы. Все тайлы лежали в одной папке. В картографическом приложении я просто их от туда брал. Каждый раз при изменении уровня зума или или центра, я рассчитывал т.н. Tile Coverage - квадратная область [minX,maxX,minY,maxY]. И тайлы из этой области брал с диска.
Я, честно говоря не совсем понимаю что значит "поиск файлов" и в чем суть оптимизации. Вот допустим у нас в локальной директории лежат готовые тайлы. Именование файлов соответствует их позиции на проекции веб-Меркатора, например {X}_{Y}_{Z}.png. Мы рендерим сцену, смотрим какие тайлы перекрывают текущую область видимости при текущем масштабе, и просто берем их с диска по имени. В одной сцене как правило всего 20-30 тайлов. По сути так и работает тайл-сервер, мы у него запрашиваем имя тайла, он нам его выдает. Только тут они все на диске.
Все ясно. Готовятся к блокировке ютюба и предлагают «аналог». Да вот только никому не нужен видеохостинг. Всем нужен контент. Контент, которого в рутюбе никогда не будет.
Мне кажется, проблема бюджетных электромобилей состоит в том, что они выглядят несолидно. Электромобиль все еще стоит дороже чем аналогичные собраться с ДВС, но покупать нечто, похожее на «Оку» по цене нормального автомобиля как то рука не поднимается. ИМХО успех теслы по много обеспечен тем, что их автомобили никогда не были похожи на собачью будку.
Насколько хорошо качество распознавания с Kaldi? Я использовал CMU Sphinx для локального распознавания в мобильном приложении, и при достаточно большом словаре результат распознавания — совершенно непредсказуем. Сделал вывод что Sphinx годится только для распознавания ограниченного набора отдельных фраз.
Сложный вопрос на самом деле. Я туда устроился когда еще учился в магистратуре. Учеба и работа в одном месте. Плюс тема диссертации аккуратно совпадала с текущей работой. Мне было удобно. Начальник лаборатории человек амбициозный и красноязычный. Основная часть ЗП должна была состоять не из оклада а из денег на заказы. Спустя пол года мы сделали два метеобуя для «росморпорта». Делали пол года. В этот период получал суммарно 50к. Не много, но я не считал себя таким уж хорошим специалистом чтобы требовать больше. А дальше затишье. Тендеры, коммерческие предложения (от нас), конференции. Кажется вот вот. Но время идет а денег нет.
Во вторых — моя инертность. Не люблю что-то менять, вот так просто. Но если увижу подходящую вакансию — долго думать не стану. Но вот что-то не вижу пока. В регионах с этим сложно. Здесь в основном 1С, и Web. При окладе не более 50к. Но я все-таки позиционирую себя как программист С++/Qt и мне нравится это.
В третьих — я не могу оценить свой профессиональный уровень, т.к. нет фидбэка. Кроме меня мой код не видел никто. Из за чего развился синдром самозванца. Я единственный IT-шник в команде. Из-за чего также нет опыта командной работы. Поэтому не рассматриваю удаленку, понимаю какая там конкуренция. А куда двигаться и с какого конца начать — не знаю.
А мне вот интересно чем Вас не устроила работа в море? Мне 28, работаю мл. научным сотрудником в морском университете. Но я IT-шник. Как раз таки использую стек С++/Qt в основном. В данный момент работа в области морской картографии (IHO S57, IHO S52 — вот это все). Плюс приходится заниматься web (Python/JS,HTML), микроконтроллерами и даже нативным IOS, так как больше некому это делать. ЗП 15к в месяц (рублей, да). В то время как выпускники судоводители на стартовых(!) должностях получают 3 — 4к$. К тому же такие бонусы как практика английского с носителями и мир посмотреть можно. Да еще и рост обеспечен. Выглядит как работа мечты. (Я под зп IT-шника, не подразумеваю свои 15к. Я думаю что в среднем 100к. В регионах возможно еще меньше).
А в свое время начал использовать формулы вместо запоминания паролей. Т.е. есть некая формула, зависящая от названия сервиса по которой строится пароль. Например: @первая_буква_сервиса/сайта + 123 + @последняя_буква + 45. Уже много лет мне не приходится ничего запоминать. (Сложность формулы может быть любой, это просто пример).
Любое увеличение степени защиты идет в минус удобству. Это всегда компромисс. И «Нечего скрывать» — скорее говорит о крайне низкой степени риска, чем о непонимании. Лично мне кажется гораздо более рациональным раз в несколько лет восстановить взломанный аккаунт, чем лишать себя огромного количества удобств. Степень защиты должна быть сопоставима со степенью риска в случае взлома. Можно не сохранять пароли в браузере, каждый раз тратить время на двойную аутентификацию, запоминать сложнейшие пароли, периодически их менять… Но зачем?
Пержде чем поучать удосужтесь ответить хотя бы на один из вопросов. Я еще раз справшиваю, на каком основании Вы утверждаете что в моей версии OpenCPN отключена поддержка OpenGL? Я Вам дал развернутый ответ о том, где я взал эту версию, показал пункт меню, в котором отчетливо видно, что OpenGL включен. Его можно отключить и заметить разницу. А Вы почему-то продолжаете утверждать что это не так. Почему? В мануле, который Вы мне зачем-то даете, и который я в свое время прочитал вдоль и поперек, нет ответа ни на один из вопросов.
Что значит спам? Я оставил один единсвтенный комментарий под этой статьей, в котором рассказал своем опыте работы с OCPN и сборки под Android. Дальнейший диалог Вы развиваете сами. Сами же затронули вопрос о "быстром рендере" и производительности. И эта ветка диалога именно об этом.
Что касается грамотности, я уверен что это Вам нужно внимательно изучить хотя бы терминилогию, и понять что же из себя предсвляет CUDA и в каких отношениях она находится с графическими API. Я не уверен что вообще могу Вас понять. Намешали все вместе, карты, воксели, CUDA, OpenGL. Как это связано? Скажите честно, Вы имели опыт работы с OpenGL и в полной мере понимаете о чем идет речь?
Моя "поделка" (почему в таком унизительной тоне?) выполняет ровно те задачи, для которых создавалсь и обладает ровно тем функционалом, который от нее требуется. Почему одна должна повторять функционал OpenCPN? Это два разных софта, котоые я сравниваю лишь в части производительности рендера.
Не хотите продолжать диалог - не продолждайте более. Я лично не привык оставлять обвинения в мой адрес неотвечеными.
И кстати, я до сих пор не могу понять причем тут CUDA? Точно ли ту СUDA, Вы имеет в виде, что SDK от Nvidia? CUDA - во-первых работает только на картах Nvidia, во-вторых, предназначена для выполнения параллельных вычислений общего характера и не имеет вообще никакого отношения к рендеру. Это тоже самое что вычислительный шейдер. Или OpenCL. Вычислительный шейдеры давно есть в современном OpenGL/ES, как Вы предлагаете их использовать в данной задаче? Разве можно CUDA вообще противопоставлять графическим API, типа OpenGL?
С чего Вы взяли что в OpenCPN на видео отключего ускорение OpenGL? Оно включего по умолначни, в меню-> отображение -> дополнительно-> использовать ускорение OpenGL. Сравнение вполне коррентное. OpenCPN 5.2.4 из официального сайта, я его не собирал самостоятельно. Без ускорения было бы в районе 5 FPS (я сейчас попробовал отключить). На видео видно что в некорых сценах FPS падает ниже 60, судя по плавности, счетчик почему-то не работает, хотя включен в опциях (карта GTX 1060). В моем рендере FPS почти никогда не опускатеся ниже 180 даже в самых нагруженых сценах, в среднем больше 200. Настройки парамтеров отображения карты оналогичны. Сравнивал производительность на разных устойствах. Отошение примерно такое, как я сказал.
А как функционал влияет на fps? Он есть, где-то там. Но не включен же постоянно, т.е. не влияет ни на время формирование кадра ни на отрисовку. Я не думаю что дашборд вообще может как-то сущетвенно влияеть на производительность. По сравнению с картой, сотоящей из миллиона полигонов, сотен тысяч вершин, и тысячи спрайтов, одновременно находящихся на экране это несущественно. Ровно как и наличие диалогов с формами. Как факт их наличия может оказывать влияние на производительность, особенно в части отрисовки карты? При сравнении я стараюсь создавать одинаковые условия, ни там ни там не открыти ни диалоги, ни дашборды. И кстати, сайдбар сбоку: что значит отдельная область вывода? Он отрисовывется в том же контексте, что и вся карта. QML сначала передает контекст мне, я рисую все что нужно - а потом, сверху уже рисуется весь интерфейс. Но я не думаю что он "съедает" больше 1 FPS.
Разница в производительности обосновата как минимум тем, что OpenCPN не объединяет похожую геометрию в batch. Тысячи объектов на экране = равно тысячи вызовов отрисовки. Batching - это самый очевидный способ оптимизации рендера. Использует glBegin - glEnd вместо, того чтобы рисовать геометрию из вершинного буфура (VBO). Совершенно не задействуется многопоточность при подготовке кадра. Вот она и трехкратная разница в производительности . Я в коде OpenCPN где-то на протяжении года ковырялся и вполне себе разобрался. Изначально именно на его базе делался весь функционал, для нужд лаборатории. На видео 2018 года еще осталась та самая версия на базе OCPN.
https://www.youtube.com/watch?v=SwgmZaP3HGU
Под GUI я имею в виду средство для создания кросплатформенного графического интерфейса. И в этом смылсе я противопостовляю wxWidgets - Qt. Понятно что Qt это больше чем просто GUI, но тем не менее это основная его задача - создание кросплатформенного софта с графическом интерфейсом.
Выбрал Qt в перую очредь из за большого количества поддерживаемых платформ и простоты сборки. Поменял таргет в среде(Qt Creator это все же просто среда разработки с точки зрения терминологии) c Windows на Android и вот ты уже собираешь проект под андроид или IOS. Без проблем. К тому же сам графический инфтефейс куда более кастомизируемый и визуально приятный. Особенно QML. wxWidgets в этом плане выглядит совсем уж аскетично.
CUDA же это про параллельные вычисления на картах NVIDIA а не про рендеринг, развне нет? Unity все-таки игровой движок, и скриптуется C# а не C++. Пришлось бы интегрировать С++ библиотеки (а большая часть библиотек из этой предметной области написана именно на C/C++ ). К тому же опыта работы с Unity и С# у мне не было и нет.
Меня в общем то в Qt устраивает все. Кроме лицензии пожалуй. LGPL с одной стороны позволяет использовать софт в коммерчеких целях, но там какие-то сложные моменты, типа того что нельзя линковать библиотеки статически, а IOS зарпещеат линковаться динамически, и еще много тонкостей и органичений.
По поводу быстрого рендеринга: я использую непосредственно OpenGL/ES, объединяю всю похожую геометрию в группы(batch). Все символы на карте также рисуются за 1 вызов. Линии тесселируются на CPU, а сглаживаются во фрагментном шейдере. В итоге производительность раза в 3 выше чем в OpenCPN при значительно более качественной графике. Навряд ли можно сделать быстрее, чем с помощью непосредственно графического API. https://www.youtube.com/watch?v=msDhjk1dndk
В свое время, будучи студентом очень сильно помучался в попытках собрать OpenCPN под андроид, и безуспешно. На одной из стадий была ошибка и я не знал как её решить. На, cruisersforum создал тему, и мне по этому поводу коротко ответили что мол версия для андроид более не бесплатная. Мне в общем то нужен был минимальный функционал (отображение карт s57, судна и ais целей) для научной лаборатории, где я тогда уже параллельно работал. При этом требовалась поддержка большого количества платформ, в том числе Android и желательно IOS. С этого момента началась моя эпопея с созданием собственного картографического движка. В качестве GUI выбор сразу пал на Qt. Сначала рендер карты осущетвлялся при помощи QPainter, затем полностью переделан под OpenGL (cовместимость с ES 2.0). Сейчас хочу и вовсе "оторвать" весь код от конкретного фреймворка (специфичные классы и методы) со всеми его лицензиями, чтобы для работы требовались лишь OpenGL контекст и ввод. Мне вообще кажется что OpenCPN довольно сильно устарел: wxWidgets с его лишь частичной кроссплатформенностью; первобытный fixed-pipeline OpenGL, чего только стоят glLineWidth и GL_LINE_STIPPLE.
Почему-то прочитав заголовок, подумал что речь пойдет об OpenGL.
Не знаю позволяет ли yandex api создавать пользовательские слои, но если бы я думал о решении данной задачи, то в первую очередь смотрел бы в сторону собственного слоя с OpenGL контекстом.
Для рендеринга сглаженного круга достаточно нарисовать прямоугольник, все остальное сделает специальный фрагментный шейдер. В том числе сразу с обводкой. Чтобы не было 100к вызовов отрисовки, батчим все прямоугольники в один буфер и рисуем всю сцену за 1 вызов.
Если же использовать современный OpenGL ES c (AEP) и поддержкой геометрических шейдеров, то для каждой метки достаточно добавить в буфер одну вершину, причем без проекции, а проекцию координат и создание прямоугольника доверить геометрическому шейдеру.
У родителей на даче такие пчелы завелись года два назад. Был удивлен, узнав что они занесены в Красную книгу. Гудят как вертолет, совершенно не агрессивные. Хорошо опыляют пассифлору. Там расположение пестиков и тычинок как раз под такие размеры опылителя рассчитаны.
Я на 100% не уверен, но разве время доступа к файлу зависит от общего количества файлов данной директории? Не слышал о таком. Вот допустим у нас есть функция QImage* getTile(const QString& filename). Внутри она пытается открыть файл по имени, и естественно обрабатывает случаи, в который указанного файла нет на диске. Опять же, на одной сцене всего около 30 тайлов. Если одного из тайлов не окажется на диске, то он как бы и не будет отрисован. Т.е. 30 обращений к файловой системе за кадр(и то, если мы полностью изменили текущую область видимости не экране). Я в свое время делал приложение для растрирования векторных морских навигационных карт и разбиения их на тайлы. Все тайлы лежали в одной папке. В картографическом приложении я просто их от туда брал. Каждый раз при изменении уровня зума или или центра, я рассчитывал т.н. Tile Coverage - квадратная область [minX,maxX,minY,maxY]. И тайлы из этой области брал с диска.
Я, честно говоря не совсем понимаю что значит "поиск файлов" и в чем суть оптимизации. Вот допустим у нас в локальной директории лежат готовые тайлы. Именование файлов соответствует их позиции на проекции веб-Меркатора, например {X}_{Y}_{Z}.png. Мы рендерим сцену, смотрим какие тайлы перекрывают текущую область видимости при текущем масштабе, и просто берем их с диска по имени. В одной сцене как правило всего 20-30 тайлов. По сути так и работает тайл-сервер, мы у него запрашиваем имя тайла, он нам его выдает. Только тут они все на диске.
Во вторых — моя инертность. Не люблю что-то менять, вот так просто. Но если увижу подходящую вакансию — долго думать не стану. Но вот что-то не вижу пока. В регионах с этим сложно. Здесь в основном 1С, и Web. При окладе не более 50к. Но я все-таки позиционирую себя как программист С++/Qt и мне нравится это.
В третьих — я не могу оценить свой профессиональный уровень, т.к. нет фидбэка. Кроме меня мой код не видел никто. Из за чего развился синдром самозванца. Я единственный IT-шник в команде. Из-за чего также нет опыта командной работы. Поэтому не рассматриваю удаленку, понимаю какая там конкуренция. А куда двигаться и с какого конца начать — не знаю.