|
|
回复 92# zfBIM
好吧，我承认我发的每一个帖子都需要二次解释~大概是我脑子比较乱~
您也说了呀，BIM不是设计师干的活，BIM过程是制作不是设计！
我没什么别的意思，就是讨论一下，请问这个“过程是制作”该怎么理解呀，我始终不明白的是su的模型如何携带那么多信息并且保证信息绝对正确，不会被误操作？个人对su的理解就是一个纯粹的表现和推敲软件，也许su真的有一些深层次的功能是我没有理解的，但是我还是很难理解su如何完成bim的重任？
我认为除非su有一天有了像天正这样专业的系统的插件，才有可能实现bim，但是就目前的情形来看，以天正为例，在autocad R14版本以前，autocad的开发工具提供的应用编程接口（API）与autocad图形核心之间是缺乏直接联系的，无论开发者的编程水平多高，最终获得的程序指示起到加快专业图形生成速度的目的，所生成的无非也是autocad的基本图形对象。例如墙这个构件，用普通开发手段只能做到以一对line拼凑而成，无法在其中同时表现真实的三维高度、开洞、保温层、墙体材料等固有属性，我们现在su的各种插件，和autocad这个时期的插件非常类似。
从autocad R14版本开始，autocad公司推出了一种崭新的开发手段，称为 object ARX 技术，从此开发者可以运用面向对象的编程技术，自己创造带有专业特性的图形对象（不再是autocad基本图形对象），自定义对象在autocad里的几何表示完全由开发者按照自己的意图指定，自定义对象可以具有完整的几何和物理特性，自定义对象不但可以按专业特性独立定义，而且各种自定义对象之间可按预先定义的相关关系智能联动。由此autocad的扩展能力就被提高到一个新的高度，只要拥护对专业有足够的理解，通过编程二次开发，就会拥有一个专门为自己量身定制的cad系统。
而我们目前面临的现状是：su目前所处的境地，就像是autocad R14版本之前的处境，众多的su插件可以便捷的制作出各种物件，比如拉线成面，线转墙体等，但是他们无一例外的不是“su基本对象的集合”，它们不可能包含上述的三维高度、开洞、保温层、墙体材料等固有属性，因此，我说目前的su，其携带的信息量少的可怜，完全不具备发展为bim软件的基础。
所以，su能否发展为bim软件，并不在于我们是否能开发出更强大的插件，而是取决于google是否愿意像autocad R14一样公开su底层的图形类型库和软件接口API，只有他公开了这些底层基础，su才有可能发展出像天正一样的专业化的插件，而如果google不愿公开，那么这一天将永远不可能来到。
然而，更深层的问题在于，su的插件全部基于ruby语言开发，而su再怎么说也应该是visual studio的产物，这样问题就在于google即使公开了底层接口，ruby语言也未必能调用，到时候也许ruby语言的插件将难以完成创建“自定义对象类型”的重任，那么我们的插件开发者就必须放弃ruby，转向c或者其他什么语言，以c语言为例，ruby作为一个开放的编程语言，在业余领域热爱它和钻研它的人自然比c语言要多（这话也许不对，但我想不出更好的表示），众所周知目前的su插件都是业余爱好者开发的，当我们不得不使用c语言开发插件时，我们的插件种类必然会大幅度萎缩，功能也必然趋于单一化，甚至由于c语言的开发成本限制，我们可能很难再见到免费的插件了。
请注意，以上这些都是建立在如下假设上的：“假设一：有人愿意业余为su开发c语言插件，假设二：su的插件可以调用google公开的底层接口，假设三：google愿意开发新版本公开接口。”倘若这三个假设任何一个是不成立的，那么su走向bim的道路，一定是漫长而无望的。 |
|
/2 
