Пару недель назад Томас Крийнен (Thomas Krijnen), архитектор и программист из Нидерландов, опубликовал обращение к сообществу с просьбой помочь недавно начатому им проекту IfcOpenShell.
Томас уже был ранее известен как автор и соавтор проектов Blender Behavioral Simulation и архитектурной энциклопедии archikey.com. Его новый проект, призванный создать базовый инструментарий для рабочих процессов на основе формата IFC, показался нам достаточно интересным, и мы решили задать Томасу несколько вопросов.
Расскажи немного о себе.
Меня зовут Томас Крийнен. Помимо проекта IfcOpenShell я работаю над степенью магистра в техническом университете города Эйндховен, Нидерланды. Мой основной учебный курс объединяет архитектуру и IT.
В этом году ты начал новый проект IfcOpenShell. В Blender уже есть поддержка формата gbXML. Откуда интерс к IFC? Это как-то связано с твоими коммерческими проектами?
В индустрии AEC (Architecture Engineering and Construction) долгое время были распространены закрытые форматы файлов, а способность к взаимодействию между ПО была так себе. Так что у свободного ПО было крайне мало шансов стать инструментарием архитекторов и строителей.
Насколько я могу судить, в какой-то момент индустрия сделала шаг навстречу открытым стандартам, таким как IFC и gbXML (или только собирается сделать, а может быть всё же сделала, но ещё передумает). Эти стандарты, как и методология BIM (Building Information Modeling, информационное моделирование зданий), делают возможным модульное использование ПО, что для UNIX-систем является нормой вот уже несколько десятков лет.
Я представляю себе экосистему взаимодействующего модульного софта, где каждое приложение выполняет чётко определённую задачу. Например, в ней может быть инновационное приложение X для генеративного дизайна, создающее контуры, которые затем рассматриваются в программе для структурного анализа Y, на основе чего в программе Z рисуется остальная часть здания, которая затем рендерится в программе W, чертится в программе V, хранится и анализируется на предмет ошибок в U, просматривается клиентами в T, ну и т.д. Каждое из них передаёт данные без потери информации, и пользователь сам выбирает, какое приложение использовать в каждом случае — закрытое или свободное. А ещё я думаю, что вот-вот рак на горе свистнет :)
Как формат данных, IFC наряду с другими свободными проектами вроде Building Information Modelserver мог бы стать ключевой технологией в достижении этого высокого уровня взаимодействия.
Уже существуют некоторые открытые решения для работы с IFC. Автор блога cad-3d.blogspot.com недавно их кратко расcмотрел. Какое место среди них занимает твой IfcOpenShell, и каким ты видишь его будущее?
Наиболее важным для описанной выше экосистемы я считаю полную поддержку геометрии в IFC, поскольку нам, архитекторам, нравится работать с формами, а в AEC мы имеем дело с весьма реальными объектами. Мне показалось наиболее разумным задействовать для поддержки IFC платформу Open CASCADE, предназначенную для твердотельного параметрического моделирования. Ну а поскольку в Open CASCADE уже есть поддержка STEP, на базе которого построен IFC, реализация большинства геометрических операций IFC не составляет особых сложностей.
Писать собственный код разбора файлов с нуля было, вероятно, не самой удачной идеей, но я надеюсь в конечном счёте обеспечить прозрачную поддержку всех форматов IFC (кроме основанного на STEP есть ещё и формат на базе XML). Существующие открытые библиотеки для работы с IFC этого пока не могут. IfcOpenShell, правда, пока что тоже — как говорится, оцените иронию. Надеюсь, что IfcOpenShell станет полнофункциональной библиотекой для чтения и записи файлов IFC с акцентом на геометрию и метаданные (вроде свойств материалов).
Судя по журналу SVN, ты сейчас единственный разработчик в проекте. Полагаю, отсюда и обращение к сообществу :) У тебя есть что-нибудь вроде плана развития проекта, на который любой потенциальный участник мог бы опереться?
Ты прав насчёт количества участников. Тем не менее, я чувствую поддержку как со стороны проекта osBIM, который более официально запустится в октябре этого года, так и со стороны коллег в университете. Плана работы пока нет, но когда я писал этот призыв, то в том числе надеялся промотивировать потенциальных участников к размышлению, как именно можно использовать подобную свободную реализацию IFC.
Некоторые интересные идеи перечислены в трекере на SourceForge, но желающие поучаствовать могут их спокойно проигнорировать и предложить что-то своё, вне зависимости от того, хотят ли они использовать IfcOpenShell в закрытом или открытом ПО.
Blender и свободные визуализаторы вроде LuxRender и YafaRay понемногу становятся совершенно полноправными инструментами в профессиональной архитектурной визуализации. Какие преимущества у них ты видишь как архитектор?
Преимуществ немало. Мне нравится честность, с которой разработчики сообщают пользователям не только о сильных сторонах, но и об ограничениях своего ПО. По моему личному опыту, количество ошибок в закрытом и свободном ПО примерно одинаково.
Разница же состоит в том, что разработчики СПО склонны открыто сообщать о них пользователям и предлагать обходные пути. Если же вы натыкаетесь на ошибку в закрытом приложении, это всё равно что биться головой об стену, поскольку вы предоставлены самому себе. Найти список известных ошибок в коробке с закрытой программой — большая редкость.
Есть и чисто технические преимущества, такие как ранняя реализация новых наработок из академической среды (посмотрим, к примеру, на разные недавние новшества в LuxRender). Подобный функционал даёт вам конкурентное преимущество. Ну и кроме того, вы сохраняете полный контроль над своей работой, поскольку формат хранения данных открыт и задокументирован. И конечно же, свободное ПО работает на любых платформах.
Наконец, мне как человеку, который никак не решит, архитектором ему стать или программистом, весьма импонирует то, что разработчики относятся к пользователям как к потенциальным участникам проекта и поощряют их активное участие в улучшении софта.
Ты всё ещё используешь закрытое ПО в своей работе? Если да, то почему?
Иногда я использую 3DS Max и Revit, что объясняется, главным образом, необходимостью открывать присылаемые коллегами .dwg и .rvt. Кроме того, чего уж скрывать, в области AEC свободное ПО не всегда оказывается на одном качественном уровне с коммерческим.
Что на твой взгляд необходимо улучшить в Blender, чтобы сделать его более конкурентоспособным в качестве инструмента для архитектурного проектирования?
На мой лично взгляд, Blender нужно продолжать делать то, что он умеет делать лучше всего. Я не вижу особой необходимости в каких-то глобальных изменениях. Переработанный в 2.5х интерфейс, как мне кажется, сделал неактуальной основную критику в адрес проекта. С другой стороны, не помешало бы больше внимания уделять совместимости: обеспечить максимальную поддержку COLLADA, ну и да — может быть даже IFC.
Насколько пристально ты следишь за развитием 2.5х, а теперь уже и 2.6х? А за совершенствованием GPU-версии LuxRender? Какие новшества для тебя наиболее актуальны?
На самом деле, хотелось бы следить повнимательнее. Просто сейчас у меня есть только быстро перегревающийся лэптоп и 16-ядерный сервер без монитора и GPU. Иными словами, часть новинок оказывается как бы не в тему. А вот развитие нового Python API в Blender 2.5 меня как раз очень интересует. Собственно, главным образом за возможность писать сценарии на Python я и полюбил Blender, ведь с ним мне не приходится выбирать между искусством и программированием.
В одном из своих проектов ты использовал метасферы (metaballs) для создания естественных, органических форм. Насколько я могу судить, для архитектуры это несколько нетипичное решение. Они ведь появились когда? В 80-х примерно? У Роджера Дина, нарисовавшего добрую половину обложек Yes, была схожая концепция под названием «Home for life», которая до сих пор не реализована. И когда я смотрю на твой проект, то думаю: «О, метасферы! Идеальное решение!». Собственно, к чему эта предыстория: что из недавних изобретений, может быть, совершенно безумных и экспериментальных, кажется тебе потенциально интересным для архитектуры и точно так же способным «выстрелить» пусть даже через пару-тройку десятков лет?
В таком контексте единственная сравнительно новая технология, которую я могу сейчас назвать, достаточно очевидна и вовсе не экстремальна. Мне очень интересно, как скажется на архитектуре быстро растущий тренд CAM (Computer Aided Manufacturing) и личных трёхмерных принтеров, особенно в масштабе целых зданий. Т.е. я говорю не о печати отдельных блоков на фабрике, а об управляемых компьютером устройствах, слой за слоем печатающих бетоном целые здания.
Всё это может привести к смене представлений о том, как личная самоидентификация выражается через жилище, поскольку исчезнет сама причина строить одинаковые дома. На мой взгляд, в этом и заключается интерес морфологических концепций, порождаемых новой технологией: как они меняют наше представление о теории архитектуры.
Проект «Home for life», я думаю, рассматривает здание как сеть связанных фрейдовских материнских утроб, в которые мы возвращаемся в поиске чувства безопасности и защиты от внешнего мира. Другие же могут рассматривать архитектуру как инструмент создания личного взгляда на окружающий мир изнутри здания.
2 ответов to “Интервью с автором проекта IfcOpenShell”
03.05.2013
Выпущен FreeCAD 0.13[…] библиотеку IfcOpenShell Томаса Крийнена (см. наше интервью с Томасом о его проекте). Йорик считает поддержку IFC критически […]
07.09.2013
Autodesk сделали экспортировщик в IFC для Revit открытым проектом | Мультимедиа в Linux[…] нечаянно подгадали публикацию интервью с Томасом Крийненом из проекта IfcOpenShell под интересную […]