Конечно, нужно сказать, что он платный. Во вторых, как я понимаю, он онлайн. В третьих он гугловский, а мы все знаем, как гугл любит закрывать различные проекты. Поэтому все наработки могут в один момент превратиться в тыкву. Но на самом деле, даже это все не очень важно.
Для меня важно, чтобы был режим скрипта (доступ ко всем возможностям через программный интерфейс). Еще хочется, чтобы было развитое геометрическое ядро, которое может решать различные геометрические проблемы. Например в OpenSCAD c этим не очень хорошо. Он хорош только в прямых построениях согласно известных размеров, поэтому для некоторых моих задумок он не подходит. Кроме того - он основан на полигонах и делать что-то красивое на основе поверхностей с ним не очень удобно. Здесь мне подсказали SolveSpace - он меня заинтересовал и я его обязательно посмотрю.
Важно понять характер построений, которые я пытаюсь делать и которые мне интересны. Я не пытаюсь проектировать космические корабли, или допустим 3D-гипопотамов, которые бегают из угла в угол. Мне больше интересны красивые эффекты и необычные формы, порождаемые математическими алгоритмами.
Я пробовал какие-то свои идеи реализовать в Blender. Споткнулся на том, что там ненадежно работает логическое сложение и вычитание объектов, а многие эффекты, которые мне интересны именно на этом и основаны. Причем в динамике. Когда я запустил анимацию в Blender - на каких-то кадрах логическая операция не сработала. Я отложил Blender в сторону. Наверное для кого-то это хороший инструмент, но для моих целей он не очень подходит.
Со ScetchUp я не очень знаком и не понимаю его возможностей в плане параметрических построений. Возможно в нем все хорошо и он вполне может сгодится.
Да, отличный пример. Что касается Fusion - то это уже продукт ИТ-мышления со всеми вытекающими последствиями:) Что касается бумажных чертежей - в том как заданы размеры, скрывается суть конструкции. Если Вы не против - я немного порассуждаю.
Многие думают, что размеры на чертеже нужны, чтобы знать размеры:) Это наивная позиция. Конструктор, читая чертеж, смотрит на числа на размерных линиях в последнюю очередь. Но вот как они нанесены, чего от чего меряется - это очень важная информация.
Проблема в том, что одна и та же геометрическая форма может возникнуть на чертеже вследствие совершенно разных конструкторских решений. Например, вы видите на чертеже равносторонний треугольник. Что в этой форме важно для того чтобы конструкция заработала. Возможно, то, что все стороны равны и с этих сторон к ним что-то примыкает. Тогда конструктор обозначит размеры сторон в явном виде (И вам придется решать некую геометрическую задачу, чтобы восстановить форму). Возможно решающим для конструкции является угол в 60 градусов. Тогда будет указан угол и для восстановления формы вам придется решать некую тригонометрическую проблему. (Если вы увидите равносторонний треугольник, на котором нанесены три осевые линии - значит это какая-то секретная разработка с треугольным сухарем - лучше с этим не связываться :)
Если погрузится еще больше в философский сумрак, то станет понятно следующее. Конструкторы на чертежах избегают избыточности, так же как программисты избегают избыточности в коде. Поэтому размеров как правило задается ровно столько, сколько нужно, чтобы восстановить форму. Необязательные размеры тоже есть, но они специально помечаются звездочкой, чтобы не путались под ногами и ими для восстановления формы пользоваться нельзя. (Это как комментарии в программном коде). Так как размеров - самый минимум, то процесс восстановления формы по чертежу практически всегда связан с решением тех или иных геометрических задач. (Естественно, когда у вас чертеж представляет несколько прямоугольников задача восстановления формы вырождается в простое складывание и вычитание размеров)
Извините, что был многословен, но проблема действительно интересная и затрагивает многие фундаментальные вещи.
Да, Вы правы. Здесь нужно сделать так (некий компромиссс), чтобы гнулось, например пассатижами, не очень легко, но в то же время точно по линии. Когда это будет на человеке, разогнуть это будет сложно.
Да, конечно. Это всего-лишь концепт, проясняющий идею. В производство этот чертеж не отправишь. Требуется, чтобы над этим поработал технолог.
Насчет пластика - я не уверен. Я вижу это изделие именно из металла. Более того - думаю, что было бы прикольно его предоставлять в несогнутом виде. Линии сгиба нужно обозначить, частично убрав с них материал (типа пунктирных прорезей). Это же прикольно самому согнуть такую штуку. Типа 3D-пазла.
Да, конечно, Вы правы. В OpenSCAD не хватает многих вещей, которые по идее должны быть при параметрическом моделировании - это конечно всякие решатели ограничений, нахождение пересечений. Solvespace, как я понимаю в этом плане более продвинутый.
Здравствуйте! Хотя финансами почти не интересуюсь - с интересом читаю Ваши обзоры. Больше всего мне нравится ваша ирония, а местами и сарказм, которые финансовые рынки в общем-то и заслуживают. Желаю вам не терять эту интонацию!
Да, спасибо! Дело в том, что я по образованию тоже не чистый программист. Я инженер-конструктор электронно-вычислительных систем. Мой отец - авиационный инженер. Я мог поступить без экзаменов на программирование (это был самый престижный курс), но я выбрал специальность ближе к конструированию. И я не пожалел. У программистов не было ни начертательной геометрии (я был чемпионом института), ни ТММ, ни сопромата, ни тепловых расчетов, ни многих других интересных вещей.
Но я все равно ушел потом в программирование. Отчасти потому, что было время, когда конструктором работать по специальности было вообще невозможно. Но основная причина - я видел, сколько рутинной работы ложится на конструктора. И как мало места для творчества. Сейчас стало лучше, в том числе благодаря и вашему продукту. Но все равно, как программист, я вижу что простора для автоматизации тут непочатый край. Если вы позволите, я немного порассуждаю на эту тему.
Если представить себе идеальное рабочее место конструктора - он должен как скульптор "лепить" конструкцию. Все расчеты на прочность, термодинамику, функциональные свойства, а также на возможность изготовления и унификацию должны пересчитываться автоматически в реальном времени. Понятное дело, что у любой конструкции есть ограничения - если изменяешь один параметр автоматически меняются остальные. Конструкция должна не только подстраиваться под желания конструктора, но и сопротивляться его желаниям, когда нужно - это такая УМНАЯ ГЛИНА.
То, что конструкторам непонятны макросы и программирование - проблема не конструкторов - а программирования:) Вы правильно заметили, что в моем примере много кода, - больше чем могло бы быть. Ведь сама модель не очень сложная. Кроме того он не интуитивно ясный - мне самому в нем спустя год разобраться будет сложно.
Должен появится, (а может уже и есть) язык понятный инженеру. Скорее всего он должен быть декларативный. Мне кажется наиболее перспективный - это язык описывающий ограничения. Я не очень хорошо знаю эту область - по-моему такое уже везде должно быть и вроде бы называется проектирование на основе ограничений. Но эти ограничения как правило разбросаны по модели и носят второстепенный характер. А нужно, чтобы они были собраны в один кусок кода и кроме них не было ничего, что бы влияло на конечный результат проектирования. Причем ограничения могут быть не только геометрические, а, например, и прочностные. Если для какого-то параметра возможен диапазон - нужно указывать функцию оптимизации - и он примет оптимальное значение.
Конечно, все это наивные мечты и идеи - я неисправимый романтик :)
Спасибо, за ваш комментарий. С большим уважением отношусь к профессиональным САПР. Очень внимательно слежу за развитием отечественных САПР и мне очень приятно, что Вы заглянули в этот пост. Вообще я все это дело очень люблю, и мне хочется со всем этим познакомится как можно ближе, в том числе и с командами, которые делают конструкторский софт.
Кроме OpenSCAD я еще экспериментирую с Open CASCADE. Была статья на Хабре. Очень хочется попробовать отечественное ядро С3D, но, как я понимаю, его так просто не раздают. Мой общий тезис - конструкторское ядро может делать такие вещи, которые не снились 3D инструментам, обычно используемым для гейм и рекламной индустрии.
Ваша ирония мне понятна :). Почему я предпочитаю писать код, а не работать в визуальных инструментах? Ответ простой - если вдруг в процессе построения возникнет какая-то новая идея или захочешь что-то подправить - все начинай с нуля. Поэтому на короткой дистанции визуальные инструменты выигрывают, а на длинной - вопрос остается открытым.
Сейчас модно стало движение AS CODE. Раньше были админы - теперь стали DevOps - оказалось, что код для развертывания писать гораздо продуктивнее, даже по сравнению с любимой админами командной строкой. Были раньше технические писатели - теперь стали DOCUMENTATION AS CODE. Раньше были тестировщики, тыкающие мышкой в браузере - теперь пишут тесты на SELENIUM. Раньше поддерживали инфраструктуру вручную, через визуальные интерфейсы. Потом кто-то изобрел Terraform и все опять превратилось в код.
Так что пока вы сокращаете пробег мышки в системах меню, может возникнуть какой-нибудь CONSTRUCTION AS CODE и в конструкторском деле все кардинально изменится :)
Это больше рекламный ролик, чем какой-то реальный проект. Думаю, что в реальных проектах непрямые углы возникают только вследствие необходимости, которая вызвана внешними факторами (допустим дом имеет два крыла, которые сходятся под непрямым углом). Да и то их в таком случае их стремятся изолировать (делают всякие кладовки, гардеробные, чуланы и т.д.)
Спасибо! Одна из лучших статей на тему технического долга. Прочитал с большим интересом. Буду показывать ее всем, как образец. Очень подробно и наглядно разобраны основные противоречия и возможные компромиссы при реальных процессах разработки и поддержки ИТ. Обязательна к прочтению всем бизнесменам желающим что-нибудь "замутить" на почве ИТ. Ровно как и наоборот - для романтически настроенных программистов, пытающихся окунуться в коммерческую разработку.
Различия между работником и предпринимателем стираются если считать работника предпринимателем, продающим свой труд. И тот и другой получают деньги - предприниматель за реализацию продукта, работник - за реализацию объема работ.
Проблема в том, что практически всегда предприниматель платит не за объем работ, а за время и здесь как раз возникает парадокс оптимизации. Если предпринимателю нужен объем работ - ему до фени как там это все происходит. Когда платится за время (что сейчас повсеместно) - возникают всякие извращения в виде программ слежения за работниками, трекинга, так называемых оценочных игр и прочие антигуманные технологии.
Лайфхаки работников возникают на пустом месте, и уж точно не благодаря предпринимателям. Это могут быть красные глаза, проведенные за чтением мануалов, могут быть ночи в гараже - проведенные за настройкой инжекторов. Может еще что-то - у каждого свой путь.
Поймите, я не против предпринимателей. Я их очень уважаю. И хочу, чтобы работники не стеснялись быть похожими на них. И потому дам возможно спорный, но все-таки совет. Если Вы нашли способ сделать свою жизнь немного легче, никому об этом не говорите. А тем более работодателю :)
Представьте ситуацию - некто собирает всех "работодателей", работающих в некоторой сфере и говорит: ну что же вы, товарищи, я знаю - у вас есть секреты, промышленные находки и изобретения - ведь если вы их расскажете друг - другу, наша отрасль совершит великий прорыв вперед, давайте - делитесь своими ноу-хау, патентами и прочими секретами производства.
Вам смешно?
Почему-то, когда предприниматели охраняют свое ноу-хау - это нормально. А когда это делают работники - возникают какие-то вопросы морали. Грустно...
Конечно, нужно сказать, что он платный. Во вторых, как я понимаю, он онлайн. В третьих он гугловский, а мы все знаем, как гугл любит закрывать различные проекты. Поэтому все наработки могут в один момент превратиться в тыкву. Но на самом деле, даже это все не очень важно.
Для меня важно, чтобы был режим скрипта (доступ ко всем возможностям через программный интерфейс). Еще хочется, чтобы было развитое геометрическое ядро, которое может решать различные геометрические проблемы. Например в OpenSCAD c этим не очень хорошо. Он хорош только в прямых построениях согласно известных размеров, поэтому для некоторых моих задумок он не подходит. Кроме того - он основан на полигонах и делать что-то красивое на основе поверхностей с ним не очень удобно. Здесь мне подсказали SolveSpace - он меня заинтересовал и я его обязательно посмотрю.
Важно понять характер построений, которые я пытаюсь делать и которые мне интересны. Я не пытаюсь проектировать космические корабли, или допустим 3D-гипопотамов, которые бегают из угла в угол. Мне больше интересны красивые эффекты и необычные формы, порождаемые математическими алгоритмами.
Я пробовал какие-то свои идеи реализовать в Blender. Споткнулся на том, что там ненадежно работает логическое сложение и вычитание объектов, а многие эффекты, которые мне интересны именно на этом и основаны. Причем в динамике. Когда я запустил анимацию в Blender - на каких-то кадрах логическая операция не сработала. Я отложил Blender в сторону. Наверное для кого-то это хороший инструмент, но для моих целей он не очень подходит.
Со ScetchUp я не очень знаком и не понимаю его возможностей в плане параметрических построений. Возможно в нем все хорошо и он вполне может сгодится.
Да, отличный пример. Что касается Fusion - то это уже продукт ИТ-мышления со всеми вытекающими последствиями:) Что касается бумажных чертежей - в том как заданы размеры, скрывается суть конструкции. Если Вы не против - я немного порассуждаю.
Многие думают, что размеры на чертеже нужны, чтобы знать размеры:) Это наивная позиция. Конструктор, читая чертеж, смотрит на числа на размерных линиях в последнюю очередь. Но вот как они нанесены, чего от чего меряется - это очень важная информация.
Проблема в том, что одна и та же геометрическая форма может возникнуть на чертеже вследствие совершенно разных конструкторских решений. Например, вы видите на чертеже равносторонний треугольник. Что в этой форме важно для того чтобы конструкция заработала. Возможно, то, что все стороны равны и с этих сторон к ним что-то примыкает. Тогда конструктор обозначит размеры сторон в явном виде (И вам придется решать некую геометрическую задачу, чтобы восстановить форму). Возможно решающим для конструкции является угол в 60 градусов. Тогда будет указан угол и для восстановления формы вам придется решать некую тригонометрическую проблему. (Если вы увидите равносторонний треугольник, на котором нанесены три осевые линии - значит это какая-то секретная разработка с треугольным сухарем - лучше с этим не связываться :)
Если погрузится еще больше в философский сумрак, то станет понятно следующее. Конструкторы на чертежах избегают избыточности, так же как программисты избегают избыточности в коде. Поэтому размеров как правило задается ровно столько, сколько нужно, чтобы восстановить форму. Необязательные размеры тоже есть, но они специально помечаются звездочкой, чтобы не путались под ногами и ими для восстановления формы пользоваться нельзя. (Это как комментарии в программном коде). Так как размеров - самый минимум, то процесс восстановления формы по чертежу практически всегда связан с решением тех или иных геометрических задач. (Естественно, когда у вас чертеж представляет несколько прямоугольников задача восстановления формы вырождается в простое складывание и вычитание размеров)
Извините, что был многословен, но проблема действительно интересная и затрагивает многие фундаментальные вещи.
Да, спасибо. Интересная идея!
Да, я знаю про ZenCAD. Хорошая штука. Но я когда работал с Open CASCADE хотел попробовать именно голое ядро, чтобы лучше разбираться, что к чему.
OpenSCAD же подкупает своим минимализмом.
Да, Вы правы. Здесь нужно сделать так (некий компромиссс), чтобы гнулось, например пассатижами, не очень легко, но в то же время точно по линии. Когда это будет на человеке, разогнуть это будет сложно.
Да, конечно. Это всего-лишь концепт, проясняющий идею. В производство этот чертеж не отправишь. Требуется, чтобы над этим поработал технолог.
Насчет пластика - я не уверен. Я вижу это изделие именно из металла. Более того - думаю, что было бы прикольно его предоставлять в несогнутом виде. Линии сгиба нужно обозначить, частично убрав с них материал (типа пунктирных прорезей). Это же прикольно самому согнуть такую штуку. Типа 3D-пазла.
Да, конечно, Вы правы. В OpenSCAD не хватает многих вещей, которые по идее должны быть при параметрическом моделировании - это конечно всякие решатели ограничений, нахождение пересечений. Solvespace, как я понимаю в этом плане более продвинутый.
Здравствуйте! Хотя финансами почти не интересуюсь - с интересом читаю Ваши обзоры. Больше всего мне нравится ваша ирония, а местами и сарказм, которые финансовые рынки в общем-то и заслуживают. Желаю вам не терять эту интонацию!
Да, спасибо! Дело в том, что я по образованию тоже не чистый программист. Я инженер-конструктор электронно-вычислительных систем. Мой отец - авиационный инженер. Я мог поступить без экзаменов на программирование (это был самый престижный курс), но я выбрал специальность ближе к конструированию. И я не пожалел. У программистов не было ни начертательной геометрии (я был чемпионом института), ни ТММ, ни сопромата, ни тепловых расчетов, ни многих других интересных вещей.
Но я все равно ушел потом в программирование. Отчасти потому, что было время, когда конструктором работать по специальности было вообще невозможно. Но основная причина - я видел, сколько рутинной работы ложится на конструктора. И как мало места для творчества. Сейчас стало лучше, в том числе благодаря и вашему продукту. Но все равно, как программист, я вижу что простора для автоматизации тут непочатый край. Если вы позволите, я немного порассуждаю на эту тему.
Если представить себе идеальное рабочее место конструктора - он должен как скульптор "лепить" конструкцию. Все расчеты на прочность, термодинамику, функциональные свойства, а также на возможность изготовления и унификацию должны пересчитываться автоматически в реальном времени. Понятное дело, что у любой конструкции есть ограничения - если изменяешь один параметр автоматически меняются остальные. Конструкция должна не только подстраиваться под желания конструктора, но и сопротивляться его желаниям, когда нужно - это такая УМНАЯ ГЛИНА.
То, что конструкторам непонятны макросы и программирование - проблема не конструкторов - а программирования:) Вы правильно заметили, что в моем примере много кода, - больше чем могло бы быть. Ведь сама модель не очень сложная. Кроме того он не интуитивно ясный - мне самому в нем спустя год разобраться будет сложно.
Должен появится, (а может уже и есть) язык понятный инженеру. Скорее всего он должен быть декларативный. Мне кажется наиболее перспективный - это язык описывающий ограничения. Я не очень хорошо знаю эту область - по-моему такое уже везде должно быть и вроде бы называется проектирование на основе ограничений. Но эти ограничения как правило разбросаны по модели и носят второстепенный характер. А нужно, чтобы они были собраны в один кусок кода и кроме них не было ничего, что бы влияло на конечный результат проектирования. Причем ограничения могут быть не только геометрические, а, например, и прочностные. Если для какого-то параметра возможен диапазон - нужно указывать функцию оптимизации - и он примет оптимальное значение.
Конечно, все это наивные мечты и идеи - я неисправимый романтик :)
Спасибо!!!
Спасибо, за ваш комментарий. С большим уважением отношусь к профессиональным САПР. Очень внимательно слежу за развитием отечественных САПР и мне очень приятно, что Вы заглянули в этот пост. Вообще я все это дело очень люблю, и мне хочется со всем этим познакомится как можно ближе, в том числе и с командами, которые делают конструкторский софт.
Кроме OpenSCAD я еще экспериментирую с Open CASCADE. Была статья на Хабре. Очень хочется попробовать отечественное ядро С3D, но, как я понимаю, его так просто не раздают. Мой общий тезис - конструкторское ядро может делать такие вещи, которые не снились 3D инструментам, обычно используемым для гейм и рекламной индустрии.
Ваша ирония мне понятна :). Почему я предпочитаю писать код, а не работать в визуальных инструментах? Ответ простой - если вдруг в процессе построения возникнет какая-то новая идея или захочешь что-то подправить - все начинай с нуля. Поэтому на короткой дистанции визуальные инструменты выигрывают, а на длинной - вопрос остается открытым.
Сейчас модно стало движение AS CODE. Раньше были админы - теперь стали DevOps - оказалось, что код для развертывания писать гораздо продуктивнее, даже по сравнению с любимой админами командной строкой. Были раньше технические писатели - теперь стали DOCUMENTATION AS CODE. Раньше были тестировщики, тыкающие мышкой в браузере - теперь пишут тесты на SELENIUM. Раньше поддерживали инфраструктуру вручную, через визуальные интерфейсы. Потом кто-то изобрел Terraform и все опять превратилось в код.
Так что пока вы сокращаете пробег мышки в системах меню, может возникнуть какой-нибудь CONSTRUCTION AS CODE и в конструкторском деле все кардинально изменится :)
Это больше рекламный ролик, чем какой-то реальный проект. Думаю, что в реальных проектах непрямые углы возникают только вследствие необходимости, которая вызвана внешними факторами (допустим дом имеет два крыла, которые сходятся под непрямым углом). Да и то их в таком случае их стремятся изолировать (делают всякие кладовки, гардеробные, чуланы и т.д.)
Теперь я понял, что не зря все это делал :)
При тестировании возникают те же проблемы технического долга, что и в процессе разработки
Спасибо! Одна из лучших статей на тему технического долга. Прочитал с большим интересом. Буду показывать ее всем, как образец. Очень подробно и наглядно разобраны основные противоречия и возможные компромиссы при реальных процессах разработки и поддержки ИТ. Обязательна к прочтению всем бизнесменам желающим что-нибудь "замутить" на почве ИТ. Ровно как и наоборот - для романтически настроенных программистов, пытающихся окунуться в коммерческую разработку.
Различия между работником и предпринимателем стираются если считать работника предпринимателем, продающим свой труд. И тот и другой получают деньги - предприниматель за реализацию продукта, работник - за реализацию объема работ.
Проблема в том, что практически всегда предприниматель платит не за объем работ, а за время и здесь как раз возникает парадокс оптимизации. Если предпринимателю нужен объем работ - ему до фени как там это все происходит. Когда платится за время (что сейчас повсеместно) - возникают всякие извращения в виде программ слежения за работниками, трекинга, так называемых оценочных игр и прочие антигуманные технологии.
Лайфхаки работников возникают на пустом месте, и уж точно не благодаря предпринимателям. Это могут быть красные глаза, проведенные за чтением мануалов, могут быть ночи в гараже - проведенные за настройкой инжекторов. Может еще что-то - у каждого свой путь.
Поймите, я не против предпринимателей. Я их очень уважаю. И хочу, чтобы работники не стеснялись быть похожими на них. И потому дам возможно спорный, но все-таки совет. Если Вы нашли способ сделать свою жизнь немного легче, никому об этом не говорите. А тем более работодателю :)
Представьте ситуацию - некто собирает всех "работодателей", работающих в некоторой сфере и говорит: ну что же вы, товарищи, я знаю - у вас есть секреты, промышленные находки и изобретения - ведь если вы их расскажете друг - другу, наша отрасль совершит великий прорыв вперед, давайте - делитесь своими ноу-хау, патентами и прочими секретами производства.
Вам смешно?
Почему-то, когда предприниматели охраняют свое ноу-хау - это нормально. А когда это делают работники - возникают какие-то вопросы морали. Грустно...
Спасибо!
Не знал про такое. Спасибо!
Да, конечно, Вы правы. В общем-то весь рассказ в том числе и про это.