“Ты исправь - нам надо!”, “Ты добавь - нам будет полезно!”, “Ты напиши побольше примеров - станет больше пользователей!”, “Подумаешь, объяснил в сотый раз то, что написано в README, не буду я свое время тратить на чтение - не будь таким токсичным!” - типичный набор “заходов” юзверов моего опенсорса за последние 10 лет :)
Конкретно OmniVoice просто игнорирует плюсы и буквы в верхнем регистре как маркеры ударения - немного помогает ручная разбивка по слогам, что резко снижает ценность OmniVoice как инструмента в автоматическом режиме из-за непредсказуемости:
Неоригинал брать не рискнул, и наверное не рискну. Если сравнить со сменными соплами эндера, которые при засоре даже выкинуть не жалко, то разница в цене ощутима.
У неоригиналов заявлены сменные сопла (в комплекте идут) - это как раз то, что в эндере выкинуть не жалко. Например, вот
особенно в свете того как быстро словил засор
Я так убил комплектный закаленный 0.6-хотенд за пару дней на филаменте, который родной 0.4-хотенд прекрасно переваривал несколько месяцев :)
На алике сейчас есть уже 3 поколение кастомных хотендов:
"проводки на соплях" - ужасное подключение, особенно на adv5pro, где корпус закрыт и фиг подлезешь сбоку. Работают 50 на 50 - один экземпляр показал отрицательную температуру сопла, второй нормально отработал месяц, пока ехали оригиналы. На распродаже можно было найти по 700-800 руб (цены упали после появления новых поколений сопел).
"красные" хотенды - провода разъема уже не соплями висят, а упакованы в пластик красного цвета по аналогии с корпусом оригинального хотенда. На распродаже стоили порядка 1100 руб.
"xxx Phaetus Conch Hotend", где xxx - обычно имя магазина. Обещают объемный поток больше оригинального, закаленные сопла. Цена - больше оригинальных, на распродаже можно найти в районе 2000 руб. Пару месяцев назад самого ходового варианта с 0.4-соплом было просто нереально купить - все выбрали подчистую.
Сейчас оригинальные хотенды подешевели и стоят в районе 1500-1600 руб (в начале года были больше 2к руб), поэтому сторонние стали не такими интересными, только если смотреть варианты с закаленными соплами на убой абразивами.
Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/ Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Вы не правы в том, что производительность не ассоциирована с ECS
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Практически все ее упоминания или реализации на этом сосредоточены и так было с момента ее создания.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Безусловно важным фактором является и разделение логики и данных - и, на самом деле, я критикую это не в последнюю очередь как способ создать реально сложные и плохо обслуживаемые решения
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
ООП буквально придуман для того, чтобы собрать это вместе по хорошей причине - локальность данных и кода
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Я бы не сказал, что сложные задачи, где нужны гибкие отношения многих ко многим сильно упрощаются в ecs
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня. Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов. Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места. Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
первый же абзац оттуда:
“Ты исправь - нам надо!”, “Ты добавь - нам будет полезно!”, “Ты напиши побольше примеров - станет больше пользователей!”, “Подумаешь, объяснил в сотый раз то, что написано в README, не буду я свое время тратить на чтение - не будь таким токсичным!” - типичный набор “заходов” юзверов моего опенсорса за последние 10 лет :)
Конкретно OmniVoice просто игнорирует плюсы и буквы в верхнем регистре как маркеры ударения - немного помогает ручная разбивка по слогам, что резко снижает ценность OmniVoice как инструмента в автоматическом режиме из-за непредсказуемости:
так не работает
так тоже не работает
а так срабатывает
в .vscode еще есть launch.json с настроенной конфигурацией, например, дебага + settings.json для унификации настроек по команде.
Так ничего делать не нужно,
llama-serverзапускается в режимеOpenAIпо умолчанию.вот только стоимость далеко не та же :)
он на текущей распродаже стоит дороже - 27к руб, без распродаж - 23к в среднем: https://aliexpress.ru/item/1005008094126761.html
да, 256х256 против 220х220 у FF 5x. правда цена у FF в 2-3 раза ниже, в зависимости от маркетплейса.
Надо сравнивать не с bambu p1s, а с flashforge 5x с теми же 4 цветами, и теми же схожими ттх, который к тому же продается уже полгода как.
Вот оригинал за 1700
Вот оригинал за 1800
У неоригиналов заявлены сменные сопла (в комплекте идут) - это как раз то, что в эндере выкинуть не жалко. Например, вот
Я так убил комплектный закаленный 0.6-хотенд за пару дней на филаменте, который родной 0.4-хотенд прекрасно переваривал несколько месяцев :)
На алике сейчас есть уже 3 поколение кастомных хотендов:
"проводки на соплях" - ужасное подключение, особенно на adv5pro, где корпус закрыт и фиг подлезешь сбоку. Работают 50 на 50 - один экземпляр показал отрицательную температуру сопла, второй нормально отработал месяц, пока ехали оригиналы. На распродаже можно было найти по 700-800 руб (цены упали после появления новых поколений сопел).
"красные" хотенды - провода разъема уже не соплями висят, а упакованы в пластик красного цвета по аналогии с корпусом оригинального хотенда. На распродаже стоили порядка 1100 руб.
"xxx Phaetus Conch Hotend", где xxx - обычно имя магазина. Обещают объемный поток больше оригинального, закаленные сопла. Цена - больше оригинальных, на распродаже можно найти в районе 2000 руб. Пару месяцев назад самого ходового варианта с 0.4-соплом было просто нереально купить - все выбрали подчистую.
Сейчас оригинальные хотенды подешевели и стоят в районе 1500-1600 руб (в начале года были больше 2к руб), поэтому сторонние стали не такими интересными, только если смотреть варианты с закаленными соплами на убой абразивами.
https://github.com/mattermost
Так опенсорс же, форкаешь и дописываешь то, что тебе нужно, а потом тебя форкают дальше и перепиливают под себя. Ограниченный кодоген в виде патча на ядро был в классике и то только для тех, кому 6 компонентов в фильтре было мало. Т.е кодоген по сути для исправлений в ядре, а не для пользовательского кода. Такое количество компонентов не совсем нормально и должно быть поводом задуматься о пересмотре компоновки данных, но механизм расширения был дан. В лайте уже не надо было патчить ядро и можно было собирать фильтры любой сложности на стороне клиента без изменений в ядре.
В LeoECS нет кодогенерации, ответственно заявляю как автор.
Про идеи организации можно почитать вот тут https://habr.com/ru/articles/742376/
Какие-то административные договоренности по взаимодействию нужны, да. Еще не стоит мельчить с компонентами, иначе это на самом деле может превратиться в неуправляемое месиво, когда никто не будет знать как и что должно работать. Функционал стоит делить на "фичи", когда есть блок компонентов, управляемых блоком систем, а снаружи к ним идет обращение через создание сущностей-событий или навешивание маркеров-событий, а дальше они сами работают. Когда логика разбивается на подобные логические блоки - управлять ей становится проще. Это все решается административными мерами - какими-то правилами, которыми должны руководствоваться все со-командники, т.к строгих правил не существует из-за гибкости самого ECS-подхода (одни правила подходят на одном проекте, другие на другом).
Абсолютно нет, Entitas построен исключительно на классах, про структуры автор начал заговаривать в рамках разработки нового фреймворка с атомарными компонентами, где все разбивалось вплоть до отдельных значений, но это было в 2020 году и все благополучно умерло.
Я свои самописные поделия начал делать как раз в конце 2017 как альтернативу платному кодогену Entitas, который проблемно ставился на macos. В начале 2018 была написана реализация на классах, которая обогнала или показала такую же производительность как Entitias, но без кодогена - задача была выполнена и появился LeoECS Classic, про Entitas больше не вспоминал. В 2019 эта реализация переехала на структуры и скорость работы еще возросла - Entitas все это время был в коме и не развивался.
Так я про то и написал, что одни понесли, а другие охотно поверили. Производительность абсолютно никак не связана с ECS, а связана с логикой обработки данных - скорость в итоге может быть как лучше, так и хуже.
Абсолютно ничем не подтвержденное высказывание. ECS впервые как архитектурный паттерн появился в dungeon siege, а это 2002 год. Ни про какую скорость разговора не было, была попытка управлять взрывным ростом механик и поддерживать их в рабочем состоянии.
Следующая известная веха - это GDC 2015, когда авторы entitas начали активно продвигать этот паттерн и конкретно свою реализацию в рамках юнити. Ни слова про производительность не было ни тогда, ни на следующем GDC2016, где опять же было выступление про удобство декомпозиции, добавления и удаления игромеханик без ломания остального кода.
Юнитехи со своим "performance by default" заявились на ECS-сцене только в 2017 году и то не смогли ничего работающего показать раньше середины 2018, причем этим пользоваться было нельзя, а производительность была ужасна.
Плохо обслуживаемые решения можно создать на чем-угодно и ECS тут никак не помогает и не мешает.
Внезапно, от локальности и когерентности данных в памяти/кеше и производительности по этой причине перешли к локальности данных по отношению к логике. В чем тогда был смысл рассказывать про производительность? Экземпляры ООП классов в общем случае всегда размазаны по памяти случайным образом и никогда не смогут догнать на тех же линейных переборах DOD-подход, когда данные лежат плотно и подряд (и нет, это опять сравнение не ECS с ООП, а DOD с ООП).
Тут какая штука - с ецс ты просто садишься и пишешь код как получится, на ходу подправляя неудобные места, тебе просто не нужно иметь в голове какую-то стройную архитектуру, а только набор идей/правил по взаимодействию различных подсистем. ООП-шники этому не верят и скорее всего именно отсутствие строгой архитектуры их и пугает в ECS, что все настолько гибко, что может быть изменено в произвольном направлении и относительно без боли.
Херня написана - хорошую работу по промыванию мозгов проделали маркетологи юнитехов, которые рассказали, что ECS это про скорость и приравняли его к DOD (https://en.wikipedia.org/wiki/Data-oriented_design). Нет, ECS - это не про скорость, про скорость - это DOD. ECS не накладывает никаких требований и ограничений на то, как будут реализованы кишки, удобно ли для кеша разложены данные и будет ли оно максимально быстро обрабатываться - следование DOD является особенностью конкретной реализации. ECS - это архитектура, причем скорее архитектурный паттерн, не имеющей фиксированной реализации. Если бы оно было про скорость, то Entitas (https://github.com/sschmid/Entitas) никогда бы не появился на свет и не был бы до сих пор самым быстро растущим по популярности ECS-фреймворком (сейчас уже по 1к звезд в год) с 2015 года, ведь он весь на классах, через интерфейсы, на реактивных системах и местами постоянно аллоцирует память, про производительность вообще не стоит заводить разговор - это самая медленная реализация из всех существующих на сегодня.
Смысл ECS не в скорости, а в гибкости и простоте рефакторинга. Если системы распилены на независимые части (features, "фичи"), то их можно наращивать и выпиливать почти безболезненно, пользуясь понятием "composition over inheritance". Берут его именно по этой причине, когда ТЗ или не готово, или меняется каждую неделю - с ECS рефакторинг проходит менее болезненно, чем в красиво выстроенной абстракции ООП-типов.
Да, в ECS неприятно делать обработку любых иерархических данных типа графов, работы с UI и т.п, но не нужно все тащить в ECS, оно прекрасно живет рядом с ООП-сервисами, реализующими проблемные места.
Непонятно, почему после миллиона статей про ECS продолжают приравнивать ECS к DOD или, что еще хуже, к UECS/DOTS, хотя это всего лишь частный случай реализации.
"Работа с референсами с обводкой" - тут имелась ввиду работа в фотошопе. Krita - это опенсорсная замена фотошопу в задачах, перечисленных в статье. Так же она может являться заменой Aseprite после настройки.
Почему не krita - и для работы с референсами с обводкой и для пиксельарта?