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