И вот я вам ставлю бизнес-задачу – повысить прибыль. Ну, давайте свои предложения!
А ты, директор, тут затем чтобы сидеть на троне и вот такие вопросы задавать? Мне казалось что как раз задача директора знать что нужно для прибыли, и ставить подзадачи другим.
«вот-вот уже почти готово» на любую тему писали и будут писать. Не очень далекие журналисты уже что только не пророчили. А тупики и прорывы в любой предметной области наблюдаются.
Ну как вам сказать… Вы же тоже для людей имеющих отношение к коду делали эту вещь. Я, например, весьма избалован прелестями IDE. Вряд ли какой то sublime text сранивнится с IDE, я уже не говорю про плюшки от Jetbrains. Я бы хотел тул где буквально пишут модель. Отсюда следует что почти все фичи при написании кода применимы и к процессу написания модели. Рефакторинги те же — если имеете дело с кодом то неизбежны и рефаторинги. Мне не очень было интересно создать какую то независимую вещь. Интереснее обкатать воркфлоу, на максимальной комфортности. Вам же важнее сделать законченное что то. Это тоже правильно.
ну и что. OpenScad пошел по пути своего языка, своего редактора,… вы правильно пишите в статье — зачем это делать когда есть питон (сишарп в моем случае). Только я еще больше отсекаю лишнюю работу: зачем редакторы, IDE. Одному человеку написать этот функционал? сума сошли?.. Билдить сишарп на клиенте не проблема. Проблема создать максимально комфортное окружение.
мне всегда казалось что строгая типизация проще, потому что не дает совершать ошибок банальных. плюс лучшая работа интелисенса. вместо VS есть VS Code сейчас… в общем конечно вопрос вкуса
Отличная работа. Увидел аналог своих начинаний в прошлом. За язык я взял тогда c#, и считаю это лучше питона: строгая типизация, MS VS — отличная IDE со всеми мыслимыми плюшками. За геометрический движок я взял SolidWorks API. Кто-то скажет «там же итак есть api на сишарп». Есть, но волосы от него дыбом. Целью было сделать не просто тул для генерации геометрий из сишарпа, а хороший internal DSL в функциональном стиле. Поигравшись немного я понял что это тупик… В лучшем случае можно сделать хороший c# api поверх убогого api. Проблема в том, что теряется связь с визуальной частью, там где напрямую можно выбрать какой то элемент геометрии. В вашем случае те же проблемы. Питон обертку вы сделали. Она может даже сама по себе имеет ценность, для любителей питона. Дальше, линейные скрипты, до if ветвлений — по сути и есть декларативная разметка. Если есть двустороння связь с визуальной частью — отлично. Если нет — снова имеем только просто некий api на питоне.
В целом направление хорошее, надо работать. Хорошо что взяли готовое геометрическое ядро… Для сборок, кстати, есть solvespace.
zencad — это для программистов, которым понадобилось 3д.
Это хорошо сказано. Но я соглашусь с автором выше: нодовая структура проще скриптования, и потому доступнее. Мне нравится аналогия с html разметкой: есть декларативная нодная структура, понятная всем. Дальше поверх нее можно строить редакторы, в которых можно работать как визуально так и на уровне разметки. И вот это мне видится крутой фичей. Я сужу по себе, верстая xaml я могу буквально писать пространственные структуры. Это давно напрашивается в CAD.
Но если «на глаз» данные выглядят одинаково, а распознаватель (нейросеть в данном случае) ведет себя как то по разному — я скорее засомневаюсь в распознавателе, потому что он явно цепляется ни за те данные которые мы от него хотим. Это в общем то и проблема всех нейросетей, что мы не понимаем а что они в действительности там распознают. И как раз набор разных тестов, в том числе синтетических, дает хоть какую то гарантию что алгоритм решает нужную нам задачу, и делает это надежно.
Про замеры времени 0.1 мкс. Есть же еще один параметр которым можно жертвовать для увеличения точности — latency, или пинг по русски. Т.е. банально умножая оптический путь измеряем бОльшее расстояние, жертвуя запаздыванием измерения. Как это технически делать — отдельная тема.
Про toloka, и расстановку баунд боксов… Неужели так трудно сгенерить синтетические данные где заранее известны все эти боксы. В наше то время, если уж в риал тайме фотореализм рендерится то облако точек то точно можно. Вообще синтетические данные и тесты как то используются?
это самое современное окружение, которое моделирует все кости и связки в теле
Надо же… а мышцы моделирует? А что за параметры этих мышц? И что, вы там управляете каждой мышцей отдельно? Я просто понять не могу на чем акцент. Физический движок однозначно не самый лучший, к тому же полумертвый судя по датам на сайте. Карта скелета (кости, связки, мышцы) — тут вообще не физ движки надо смотреть а какие то медицинские ресурсы.
Эмпирически заданные правила, такие как «тупое передвижение ногами», лишают модели возможности обучаться
Введите всего лишь один параметр — длинна шага, и на этой задаче можно диссеры писать. Но скелеты и связки конечно наводят ореол крутости, вне сомнений.
ссылки на публикации: вот и вот
Посморел, на пару формул больше. Там даже есть интеграл ).
Плюсую. Сыро и популистично. Почему Simbody? Почему три формулки на такую математичную работу? Ни строчки кода ни боле менее серьезного уравнения. Но главное — причем тут картинки бегунов? За начальный алгоритм сгодилось бы и тупое передвижение ногами. А если еще и обратную связь добавить от «гироскопа» — то такая модель и 5 метров запросто бы прошла и даже похоже на пьяного робота.
JetBrains Research это спонсирует? Мне хочется думать что просто плохая статья и в работе все это есть.
Ни очень понимаю где тут специфика игровой разработки. Все эти проблемы можно получить в любом другом проекте на С++, где идет борьба за перфоманс. А она практически везде идет, где выбирают С++. За метапрограммирование, обобщенное программирование приходится чем то расплачиваться, это да. Но а где легко? Везде свои проблемы.
Копипаст везде. Кодревью нот пасед. Мой вам совет — не нужно пихать такие методы прямиком в оберточки. Делается чисто статик класс где ТОЛЬКО extern методы. Нужно отделять оберточки с вашим ООП от флат апи. Ну и копипаст тоже решается условной компиляцией.
А ты, директор, тут затем чтобы сидеть на троне и вот такие вопросы задавать? Мне казалось что как раз задача директора знать что нужно для прибыли, и ставить подзадачи другим.
В целом направление хорошее, надо работать. Хорошо что взяли готовое геометрическое ядро… Для сборок, кстати, есть solvespace.
Это хорошо сказано. Но я соглашусь с автором выше: нодовая структура проще скриптования, и потому доступнее. Мне нравится аналогия с html разметкой: есть декларативная нодная структура, понятная всем. Дальше поверх нее можно строить редакторы, в которых можно работать как визуально так и на уровне разметки. И вот это мне видится крутой фичей. Я сужу по себе, верстая xaml я могу буквально писать пространственные структуры. Это давно напрашивается в CAD.
Надо же… а мышцы моделирует? А что за параметры этих мышц? И что, вы там управляете каждой мышцей отдельно? Я просто понять не могу на чем акцент. Физический движок однозначно не самый лучший, к тому же полумертвый судя по датам на сайте. Карта скелета (кости, связки, мышцы) — тут вообще не физ движки надо смотреть а какие то медицинские ресурсы.
Введите всего лишь один параметр — длинна шага, и на этой задаче можно диссеры писать. Но скелеты и связки конечно наводят ореол крутости, вне сомнений.
Посморел, на пару формул больше. Там даже есть интеграл ).
JetBrains Research это спонсирует? Мне хочется думать что просто плохая статья и в работе все это есть.
Бред какой то. Тащить код всех платформ в dll? Условная компиляция ни о чем не говорит?
Абстрактный класс у которого только абстрактные методы? Ребята, на этот случай interface есть.
Копипаст везде. Кодревью нот пасед. Мой вам совет — не нужно пихать такие методы прямиком в оберточки. Делается чисто статик класс где ТОЛЬКО extern методы. Нужно отделять оберточки с вашим ООП от флат апи. Ну и копипаст тоже решается условной компиляцией.