的意见
以下是我从Bernard Cache在2023年3月16日举行的架构师开源大会上关于“自由软件伦理”的演讲中摘录的笔记。他是瑞士洛桑École理工学院建筑项目数字文化实验室的教授。
- - -
架构师们仍然梦想着一个有创造力的人在一个创作平台上完成自己的项目,然而我们知道,建筑项目变得越来越复杂,需要许多参与者之间不断的互动和协商,每个参与者都使用不同的软件,具有特定的优点和缺点。
实际上,不存在单一的、通用的软件。互操作性不是一种选择,而是我们当前日常混乱的情况。谁能想到设计过程中创造性更少的方面呢(比互操作性),它只是以不同的文件格式重复完全相同的内容。因为它带来了附加价值,所以互操作性根本就不是问题。
目前有一个解决方案:国际金融公司,行业基础课程,它利用了25年的交流、讨论和谈判,但它非常缓慢。它非常缓慢,因为有许多不同的参与者,他们每个人都在考虑任何可能的用途。IFC提供了诸如“是否有可能在建筑建成20年后的数字模型中找到防火等级属性?”它提供了描述建筑BIM组件的最佳框架。
因此,IFC主要用于转换具有数据丢失和参数智能的整个文件。请考虑一下:您认为有效的IFC转换对软件供应商的商业利益来说是一个好主意吗?因此,他们尽一切可能阻止其发展,并减缓国际金融公司智能化的进展。
因此,我们想探讨以下两种选择:
动态互操作性工具
本地IFC设计工具
动态互操作性工具
两种可能的动态互操作性工具是散斑(一个3D数据平台https://speckle.systems),犀牛。内部(在其他程序中运行的开源Rhinohttps://www.rhino3d.com/features/rhino-inside),而不直接依赖于国际金融公司的格式。
- - -
散斑可以在多个参与者之间提供全面的互操作性,每个参与者在连接到服务器的自己的计算机上使用他们选择的软件。它不处理文件转换,但使用GitDif版本控制处理数据流,仅通信文件中的更改内容。如果你有一个一千列的建筑,你改变了其中的一列,为什么你要重新发送整个文件呢?只发送修改过的那一列。
多亏了GitDif, Speckle在使用不同软件的人之间提供了近乎实时和有针对性的交流。但是Speckel的默认对象模型与IFC不同,所以这意味着它独立于缓慢的标准化过程,不受主流供应商的阻碍。
由于是开源的,它允许任何贡献者按照他想要的方向尽可能快地开发它。Speckle是开放的,因此任何贡献者都可以提出和使用替代对象模型。为什么不考虑一个可分割的开源IFC模式呢?
- - -
犀牛。内部是用于泡沫互操作性,因为它是为单个用户制作的,该用户愿意在他最喜欢的软件中启动Rhino和/或Grasshopper。它和他的电脑共享相同的内存空间。
作为一个泡沫,它们是非常强大的工具,但不能解决互操作性问题。最受欢迎的版本是用于Revit的Rhine,它只会增加Autodesk的主导地位,这对建筑师来说意味着高昂的价格和专有陷阱。
将BIM扩展到一般
我们应该将BIM行业的互操作性扩展到一般工业,因为建筑行业将永远依赖于一般工业,无论是制造还是再利用现有的组件。因此,互操作性必须在设计、建造和制造之间架起桥梁。
我们的实验室开发了两个开源工具,专门将建筑软件与CAD/CAM软件连接起来TopSolid(法国的)https://www.topsolid.com/en/products):
斑点- TopSolid连接器
莱茵河。Inside for TopSolid
IFC本地工作工具
这涉及将IFC从数据翻译格式更改为可操作的数据格式。已经有两个代码库允许我们直接处理ITC数据:
IFC.jsBIM工具包是否适用于Web通信https://ifcjs.io
ifcOpenShell直接处理IFC数据,因此可以摆脱所有专有格式http://ifcopenshell.org。它已经嵌入到开放软件中,比如BlenderBIM,并在计划中FreeCAD和Xeokit(3D API网址:http://xeokit.io).
开源开发
开放源码开发(没有公司对编程代码保密)不是魔法,也不是自发的开发,尤其是当我们期望使用专业工具时。我们不能指望年轻的极客们免费加班到很晚。即使是专有软件行业,由于其高薪,也存在劳动力短缺问题。
我们不应该重复Linux的失败,它仍然是一个边缘操作系统,超出了服务器的角色。
然后是文化问题:建筑社区在多大程度上愿意合作制作自己的工具?架构师通常不愿意参与技术事务。
开放源码软件的开发必须受到公共行为者(如日内瓦州)、私人倡议以及公共研究和教育机构的保护。
来源:https://mediaspace.epfl.ch/media/01+Bernard+Cache+%26+Nicola+Braghieri/0_awczzbxt/33141
评论