2008年11月22日 星期六
SU Animate 2.0的组装动画功能
SU Animate 2.0的组装动画功能
SU Animate是Cadalog公司的产品,从1.0版上市迄今尚不到两年,目前的版本是1.1.1版。SU Animate是应用Ruby程式语言写成的,编译成.RBS格式,以插件方式内挂在SketchUP 6 Pro里面执行。1.0版只支持SketchUp Pro版,从1.1.1版以后则可以支持SU的免费版。
藉由SU Animate 2.0可以产生所谓“组装动画”,对于工业设计的产品发布特别有利。在组装动画的演示下,设计产品的零组件安装顺序和安装位置都能清晰的表达,避免冗长的文字说明或词不达意的问题。当然组装动画也可以应用在建筑设计和室内设计以及其他的设计领域里,必然或不必然都在使用者的方寸之间。
其实做组装动画只是SU Animate 2.0的新功能之一,运用的是这一版新加入的一个“Delay”(迟延起动)设置项。何谓迟延起动?动画的本质是,我们为动画设置路径,把路径指派给特定物件,让物件沿着路径移动。当场景里只有一条路径的时候,没有物件迟延起动的需要。可是应用在组装零组件的动画上,各个零组件在组装过程中有先后的顺序性,也有组装过程中的时间差。因此我们需要各个组件开始移动的时间不一样,这个“Delay”就是用于对各个零组件按照需要的顺序设置不同的起动时间。
(Rendered by Podium)
现在我开始测试SU Animate 2.0的Delay(迟延起动)的新功能,我的目标是一台桌上型电扇的安装过程。在SketchUpBBS论坛上模型交换区花了点U币借用一个电扇模型。在这里特别要向这个电扇模型的原作者致谢,他很好心的已经把电扇的组装元件,包括①后罩、②轴箍、③扇叶、④前罩、⑤螺丝、⑥马达以及⑦底座都设置好Group(群组),为我节省了不少构建群组的时间。
(1)由于SUAnimate移动的物件必须是已经命名的Group,所以我把上述组装元件这些群组物件分别给它们命名为:①Rear,②Screw,③Fan,④Front,⑤Pin,⑥Motor,⑦Base。我把这7个群组物件分别放在不同的图层上,这并不是必要的步骤,只是在测试软体时能开关图层显示比较方便而已。
(2)接下来我着手新建了6个给Path(移动路径)用的Layer(图层)分别给它们命名为Path0~Path5,准备每个图层上放置一个群组物件的移动路径。这也不是必要的作法,其实只要一个专门放置路径的图层就行了,在写成Scene之前把这个路径图层关闭,免得以后在动画里看到路径那几条线。
(3)第三个步骤开始做整理电扇模型的工作,既然要演示电扇的组装过程,当然要先把电扇拆解开来,把各部份零组件排列好,别人才看得清楚安装的顺序,对吧?我动手把上述电扇的各块组件按照⑤④③②①的顺序沿着座标绿轴向前方移出来,“⑤Pin”外移1000mm最远,“①Rear”外移200mm最近。各个组件之间间隔200mm,如此可以清楚的看到每块组件还没有组合成电扇的样子。又把“⑥Motor”也向上方移动200mm,这就完成了把这部电扇大卸八块的手续。
(4)正式开始工作是建立移动路径,好让这些被移出来的电扇组件能沿着路径回到原位。我从最远的螺丝开始,切换到Path5图层,从螺丝的一个角落沿着绿轴画一条长度1000mm的线,运用Divide命令把这条线分割为50个Segments(段落),全选线段以后在右键功能表上选取一个“CreateCurvefromEdges”命令,这是第一个出现的SU Animate操作命令。这条线就被结合成所谓Curve(“曲线”)的Path,为什麽叫做Curve?因为路径不一定是条直线,也可以是条七扭八拐的曲线。把滑鼠游标放在这条路径上按右键,这时右键功能表上的命令变成了三个,“ReveseCurveDirection”,“Assign Attribuates”,“Delete Attributes”。
第一个“ReveseCurveDirection”的意思是“倒转曲线的方向”,什麽时候会要倒转曲线方向?刚才我画这条路径的时候是从外面的螺丝位置画向电扇的位置,不错,曲线的起始方向是从画线的起始点决定的,同时也决定的物件沿着路径移动的方向。如果画反了,可以运用这个命令把沿路径的方向反过来。
我要使用的是第二个命令“AssignAttribuates”(赋予属性),把路径指派给某个已经命名的Group物件,要它沿着这条路径移动。在此同时我可以给它设置Delay(迟延起动)和Repeat(重复动作)属性。选择“Assign Attribuates”,马上出现了SU Animate的属性设置视窗,在面板上列示着6个已经命名的Group,我把这条路径指派给Pin,这次我做的是组装动画,Repeat就保持它的内定值。我要设定的是Delay,Delay的单位是Frame(影格数),我让这个螺丝迟延50个Frame才开始动作,所以给它“50”的数目。设置好Pin的动作,点击“Update”关闭这个属性设置视窗。
重复上面的步骤,分别画出各个电扇组件的移动路径,以及设置它们的移动属性参数,设定的结果如下:
Group: Pin, Path layer: Path5, Path length: 1000mm, Delay:50,
Group: Front, Path layer: Path4, Path length: 800mm, Delay: 40,
Group: Fan, Path layer: Path3, Path length: 600mm, Delay: 30,
Group: Screw, Path layer: Path2, Path length: 400mm, Delay: 20,
Group: Rear, Path layer: Path1, Path length: 200mm, Delay: 10,
Group: Motor, Path Layer: Path0, Path length: 200mm, Delay: 0,
电扇底座是不动的,所以没有给它设置路径和属性。
(5)现在我已经给这6条移动路径都指派了物件,也设置了移动的属性参数,接下来的工作就是要让它们动起来。在叫它们移动之前,我没忘记先把那些放置路径的layer(图层)关起来(Invisible),免得动画场景里面出现那几条路径的线条杀风景。
要从SU Animate建立动画,在下拉功能表Plugins > SU Animate!的里面有两个命令我可以选择,一个是“Make Scenes”(制成场景页面),另一个是“Make Batch Files”(输出循序文件)。先说说第一个,“Make Scenes”是从1.0版延续下来的老东西,它先在各组路径和Delay组合中挑出最长的,算出Frame(影格)数目,建立相同数目的Layer,把要移动的物件沿着路径循序复制在路径节点位置上,若设定了Delay格数,它就越过设定的格数再开始复制。跟着建立跟影格数相同的Scenes(场景页面),每个Scene对应一个Frame,并且只有一个相关的Layer是开启的,其他一大票Layer都关着。因此只要这些Frame的间隔时间在1/15秒视觉占留以内,在这些Layer开开关关之间,就能得到动画的视觉效果。
当然,在路径上物件每次移动的距离多长以及节点数多少比较适当,这是得靠经验和试验磨出来的,每次移动的距离设得太大,动画中物件好像兔爷一样蹦着走。每次移动距离设得太小,写出的Scene又太多,几百个页面对SU也不是好玩的。要是依循着插件开发者的思路,直接写出Frame(影格)的话,我们以25 fps(每秒25影格)的速度数出动画,100个Frame只能撑4秒钟,播放动画时,如果看的人不小心打个喷嚏,动画已经播了一半。要是哪个人低头点支香烟,再抬头时动画已经播完了。怎麽去玩转SU Animate,请看我在论坛上的相关帖子。无论如何,这次我还是跟着软体开发者的思路做这段组装动画。
这一次我不使用上述“Make Scenes”方式制作。我要使用的是第二个方法“Make Batch Files”,直接输出循序的SKP文件,虽然过程比较麻烦,可是可以得到最大的使用弹性。点选功能表上的“Make Batch Files”以后,首先弹出一个交谈框,SU Animate告诉我已经算出要建立76个Frame,我没改这个数字,因为即使增加数目,也只会在把最后那个Frame复制增加,改少了我不知道会发生什麽事。就按“OK”同意它的内定值吧。接着出现的是一个文件储存选择视窗,在上面建立一个新的文件夹,给个文件名字“FAN.skp”,要注意的是一定得加上.skp的延伸文件名,否则SU Animate会存成没有尾巴的文件名字。当我按下“OK”以后,SU Animate开始根据每个Frame输出skp文件。弄好了我后我检查一下,那个文件夹里从FAN.001.skp到FAN.076.skp总共有76个连号的skp模型文件,一个也不少。
(6)继续的工作是比较繁复的,把这些skp文件逐个载入SU,逐个输出解析度800X600的JPG影像文件,按照编号给它文件名称。使用直接输出skp模型文件有个好处,据说我有个机会可以把它们逐个进行渲染(例如Podium),使用渲染后的影像合成动画。不过今天我的精神还算正常,要连续渲染76个影像,哇靠。我还是老实点直接从SU输出影像就好,所以不一会儿我就拥有了76个连号的JPG影像文件。
我还得注意一件事,通常我们制作动画,习惯上会复制动画头尾的影格,长度差不多1/2秒左右,换算成Frame大约是10 Frame。作用是让看动画的人在一开始播放时能看清楚起始的场景,以及动画结束时的场景,不会让人看了感觉没头没尾的。因此我从SU写出一张张影像时就得从FAN0011.jpg开始编号,由于此时模型文件的流水号跟输出影像流水号不一致,这得仔细的做以免弄错了那就会特“郁闷”。
(7)手头上终于有了一串连号的JPG影像文件,不觉胆气一壮。心想如果把这个组装动画弄成先组合再分解,给人看了视觉效果可能更好些。于是开始把这些影像文件复制一份,按照相反的顺序更名,接续着原来的流水号码,把它们接在原来那些文件后面。别说这种事情好像很烦,可是由于不花什麽脑筋,一边看电视连续剧一边做,演不到一集居然也弄好了。现在我手头上有了220个JPG影像文件,以25 fps计算,可以撑到8秒钟,够用了。
⑻启动Premiere Pro,开一个新的Proproj文件,设定好25 fps速率、Cinepak压缩码。从那个文件夹里点选FAN0001.jpg,勾选了“Numbered Stills”(连号静态影像),按下“打开(O)”。一下子220个影像都被载入并且自动合成了Clip,把它拖拉到Timeline(工作列)上,从预览视窗Play一次没问题,就不再恋战直接输出AVI影片。看看解析度800X600的影片8秒钟有12Mb,还好。最后一步则是把它载入Camtasia Studio转换成能在网路上播放的Flash文件,虽然640X480的Flash文件还是那麽大,不过总算是解决了播放的问题,所以我现在可以把刚刚做出来的组装动画贴在后面,给大家看看SU Animate 2.0的新功能。
再灌一点水,写完了回头看一遍,发现一个问题。明明我要写的是关于SU Animate 2.0组装动画功能的测试报告,现在看看好像写成了教程。没关系,报告也好教程也罢,重要的是能够帮助各位朋友清楚明瞭SU Animate 2.0的功能,知道它能在我们的工作中扮演的积极角色。最后,我要感谢这个软件的开发者们辛苦的劳动成果。
2008年11月15日 星期六
BIM的迫切需求性
建築生命周期管理(Building Lifecycle Management,BLM)的完整概念是从国外引进来的,在此之前我们不能说国内没有人曾经体认到这种需求。但是长久以来我们的营建制度是一种松散的结合体,从设计到施工到营运管理都处在不同机构各自为政的状态,並没有一种能贯穿整个建筑生命周期的管理体系让建筑行为经常保持它的最佳能量。在建筑物至少长达数十年的结构生命中,为期最长的使用运营阶段,迄今仍然处于管理能力薄弱的状态中。
即使我们今天能够建立一个运营管理单位进行使用管理,在现今的体制下,这个管理单位面临的是建筑讯息分散缺漏,并且得承继来自于前面设计和施工全部的缺失。这种缺失多半是隐蔽不可见的,例如说水管爆裂、屋顶漏水等等,没有完整的建筑讯息就只能以打补钉的方式修补。又如进行室内装修的住户擅自打掉承重墙,无论是基于无知或自私,对于这种已经造成建筑物无法复原的损害行为,管理单位甚至于没法阻止和预防。所以我们常说一栋管理不健全的住宅大楼,可能在交屋数年的时间里内部就已经面目全非,竖向承重墙变得断断续续,竖向排水管线变得东弯西绕,防火门窗被不具防火性能的门窗任意取代等等。
我们不能把这些问题全都归责于建筑的管理单位不作为,『以不教民战,谓之杀』,在建筑的管理权责从施工单位(或业主)转移到使用管理单位的时候,有没有把完整的建筑讯息随同管理权移转。管理单位有没有能力从一大叠厚厚的图纸里找到需要的部份,有没有能力直接判读图上的专业标注,图纸间发现相互矛盾的地方怎麽解决? 我们急需的是把关乎一座建筑物原本分散的全部建筑讯息集中在单一位置,最好的位置是一个单一的三维建筑模型。这个模型具有能够直接经由视觉查阅的使用者介面,使得不具备建筑专业的建筑管理单位可以很方便的操作及更新这个建筑模型,在建筑全生命周期中的运营管理阶段才能发挥最大的运营效益。
这种把全部建筑讯息嵌附在单一模型上,我们称为应用"建築资訊模型化(Building Informatiom Modeling, BIM)"技术的模型。 BIM可以说是概念可以说是技术,虽然到目前为止BIM的重要性逐渐被人重视,可是要把BIM完整的应用在建筑项目全生命周期管理的各个阶段上还有一段很长的路要走。除了建筑项目体制的改革以外,BIM的载体尚未能落实是最主要的原因。我个人的感觉现今被软件开发商极力鼓吹所谓具备操控BIM的软件,即使创建模型的设计者这一端能顺利搭载BIM,可是在终端使用者(建筑运营管理单位)那一端能否顺利具备专业软件操控能力,另外得花上一笔高价购买这个应用软件,好像有点儿不切实际。
我看好的是操作简单价格低廉的SketchUp,当然截至目前为止的SketchUp版本并不具备BIM介面,也许Google会在未来的版本中加入BIM介面。可是经由二次开发插件把BIM操作介面外挂在SketchUp上,我们绝对有机会在SketchUp软件环境里实现操控BIM的目标。这一条路可能很长,可是如果没有先行者,我们永远达不成这个目标。
我写这篇文章的目的是在呼吁对BIM有认知和需求的朋友们,我们该去除拿来就用的速食心态,踊跃在论坛上提供自己对BIM的看法和建议,让有志开发SU+BIM的先行者得到足够的支持和动力,早日让我们身受其惠。
即使我们今天能够建立一个运营管理单位进行使用管理,在现今的体制下,这个管理单位面临的是建筑讯息分散缺漏,并且得承继来自于前面设计和施工全部的缺失。这种缺失多半是隐蔽不可见的,例如说水管爆裂、屋顶漏水等等,没有完整的建筑讯息就只能以打补钉的方式修补。又如进行室内装修的住户擅自打掉承重墙,无论是基于无知或自私,对于这种已经造成建筑物无法复原的损害行为,管理单位甚至于没法阻止和预防。所以我们常说一栋管理不健全的住宅大楼,可能在交屋数年的时间里内部就已经面目全非,竖向承重墙变得断断续续,竖向排水管线变得东弯西绕,防火门窗被不具防火性能的门窗任意取代等等。
我们不能把这些问题全都归责于建筑的管理单位不作为,『以不教民战,谓之杀』,在建筑的管理权责从施工单位(或业主)转移到使用管理单位的时候,有没有把完整的建筑讯息随同管理权移转。管理单位有没有能力从一大叠厚厚的图纸里找到需要的部份,有没有能力直接判读图上的专业标注,图纸间发现相互矛盾的地方怎麽解决? 我们急需的是把关乎一座建筑物原本分散的全部建筑讯息集中在单一位置,最好的位置是一个单一的三维建筑模型。这个模型具有能够直接经由视觉查阅的使用者介面,使得不具备建筑专业的建筑管理单位可以很方便的操作及更新这个建筑模型,在建筑全生命周期中的运营管理阶段才能发挥最大的运营效益。
这种把全部建筑讯息嵌附在单一模型上,我们称为应用"建築资訊模型化(Building Informatiom Modeling, BIM)"技术的模型。 BIM可以说是概念可以说是技术,虽然到目前为止BIM的重要性逐渐被人重视,可是要把BIM完整的应用在建筑项目全生命周期管理的各个阶段上还有一段很长的路要走。除了建筑项目体制的改革以外,BIM的载体尚未能落实是最主要的原因。我个人的感觉现今被软件开发商极力鼓吹所谓具备操控BIM的软件,即使创建模型的设计者这一端能顺利搭载BIM,可是在终端使用者(建筑运营管理单位)那一端能否顺利具备专业软件操控能力,另外得花上一笔高价购买这个应用软件,好像有点儿不切实际。
我看好的是操作简单价格低廉的SketchUp,当然截至目前为止的SketchUp版本并不具备BIM介面,也许Google会在未来的版本中加入BIM介面。可是经由二次开发插件把BIM操作介面外挂在SketchUp上,我们绝对有机会在SketchUp软件环境里实现操控BIM的目标。这一条路可能很长,可是如果没有先行者,我们永远达不成这个目标。
我写这篇文章的目的是在呼吁对BIM有认知和需求的朋友们,我们该去除拿来就用的速食心态,踊跃在论坛上提供自己对BIM的看法和建议,让有志开发SU+BIM的先行者得到足够的支持和动力,早日让我们身受其惠。
標籤:
BIM
訂閱:
文章 (Atom)