Microservices陷阱:概念篇

2011年5月,microservice一词由一次在威尼斯举行的软件架构工作坊中被提出,直到次年的同次会议中被正式命名为microservices(微服务)。 James Lewis, Martin Folwer

通常,微服务被用于描述一种架构风格。在这种风格下,单个应用软件被设计成一系列可独立部署的服务。尽管业界在微服务的具体定义上还有争议,但其基本上代表了自动化部署、智能终端、语言和数据的去中心化等特征。

1.基本概念

Martin是这样用一句话描述微服务的:

对于每一个小型服务,其拥有独立的进程、轻量化通信机制(通常是http请求)、这些服务围绕着业务上下文构建,并可以实现独立的自动化部署。而这种控制的去中心化允许不同服务可以采用不同的语言和数据库技术实现。

微服务的拥趸把与之相反的设计风格称为monolithic,也就是单一系统。在他们看来,凡是不符合微服务特征的架构,都属于单一系统。

企业web应用中的单一系统和微服务架构

基本的企业web应用架构包含三层,分别是用户界面层(页面)、数据层、以及服务端应用层。其中服务端应用层负责接收请求,处理领域逻辑,操作数据库,然后选择响应的视图。单一系统风格一般是指服务端应用层的设计,任何修改都需要对整个系统进行重新部署。

单一系统风格的缺点是:1.小的更新需要对整个系统进行重新构建和部署;2.单一系统内的模块化设计通常很难维持,事实上很难做到完全的修改隔离;3.扩展时需要考虑整个系统,而不是其中拥有真正需求的一小部分。

针对单一系统的上述问题,微服务提供了自己的解决方案:应用软件被设计为一系列服务,这些服务允许独立部署和扩展。每个服务需要提供一个稳固的模块边界,允许由不同语言和团队实现。

2.微服务的基本特征

利用服务实现组件化

在微服务中,组件化是目的,分割服务是方法。这里的组件是指实现替换和更新独立的软件单位。其中,在不同的场景中软件组件的定义可能不同。一种情况是采用库实现组件,这里的库是链接程序代码、并且直接在内存中调用的一种组件化形式。而对微服务而言,由于服务是进程隔离的,通常采用web service或者rpc实现相互通信的组件化。

基于服务的好处在于,1.允许独立部署,对整体变化更轻量,尽管有些改动不可避免地影响到接口层面,从而产生协同变化,但可以通过聚合服务边界和利用服务契约实现优化演进。2.更加明确的发布接口,对于语言层面来说,发布接口可能没有什么太好的办法,通常只能借助文档并且约束用户破坏组件的封装性,导致组件间的紧耦合。

当然服务也有缺点,首先rpc的效率远不及进程内调用,意味着远程api需要是粗粒度的,但使用起来并不方便。如果需要跨组件的职责变更,跨进程边界通常并不容易。再次,服务内的进程完全独立于外界,包括开发和部署,也就意味着应用服务器和数据库也应当是独立并仅为该服务使用的。

围绕业务能力构建组织

为了避免康威法则,应转变固有的以功能划分团队的方式,尽可能组建全功能团队。对于大型单一系统应用,几乎都可以围绕业务能力进行模块化,但这通常需要团队按照业务线划分,这里遇到的主要问题是,通常这些团队的组织都基于复杂的上下文。如果单一系统跨越了多个模块边界,那么对团队中的个体成员来说消化成本是非常高的。此外,模块线需要一个强有力的约定去保证实施。而服务组件能够提供更加明确的分割,从而使团队边界更清晰。

产品而非项目

绝大多数的应用开发采用项目模型的方式运作,即完成软件并交付给运维团队,然后开发团队解散。而微服务建议摈弃这种项目形式,而是让团队拥有产品的整个生命周期。这种做法的好处是令整个开发团队能够更进一步和用户接触,承担一定的用户支持任务,并理解用户的业务需求。而对于单一系统而言,该做法几乎很难实现。

智能终端和哑管道

当构建不同过程间的通信框架时,多数做法是将业务智能整合进通信机制中,例如Enterprise Service Bus,ESB。ESB产品通常包括了消息路由、编排、变换、乃至业务规则的制定等复杂功能。智能终端和哑管道则相反,由于解耦的需求,服务应当拥有其自身的逻辑,采用类似REST的通信协议,而非WS-Choreography,BPEL或其它采用集中式工具编写的复杂协议。两个好的例子分别是Http API(或protobuf)和轻量级消息总线。后者通常的特点也是“哑”的,如RabbitMQ或ZeroMQ,它们仅仅提供一套异步纤程,智能仍掌握在终端服务手中。

当你试图从单一系统转移至微服务时,最大的难点在于解决内部消息机制。而朴素的转移可能会导致不良通信行为,这里可能需要采用粗粒度方法解决细粒度通信的问题。

去中心化的控制

控制中心化的一个结果是使单一的系统平台成为标准,这么做的缺点在于,并非每个问题都是钉子,也并不是每个问题都是锤子,更恰当的方法是在具体情况下采用正确的工具。

微服务的理念是条条大路通罗马式的,也就是说强调服务的独立性。实际上,你会发现越来越多的开发人员开始从自己的实现中分离出实用工具,并分享至社区(工具之间可能拥有类似的功能,却存在不同的实现形式)。

然而这种自由并不意味着微服务并不遵守服务契约。恰恰相反,像是Tolerant Reader和Consumer-Driven Contracts这种契约模式经常被用于微服务实现,帮助服务能够独立发展。同时契约能够保证新服务开发的精简性,保证YAGNI原则,提高开发效率。

去中心化的数据管理

目前存在许多方法来解决数据管理中心化的问题。在最抽象级,就意味着划分出系统间不同的概念模型。例如,在大型企业级应用中,顾客的销售视图和支持视图之间存在差异,在销售视图中的顾客信息并不会存在于所有支持视图中,而这又会由于不同语义间的细微差别而存在不同或相同情况。

基于上述原因,如果试图把单一系统划分为多个分离的组件,采用领域驱动设计DDD会是一个不错的方法。DDD能够把复杂的领域分解成多个带边界的上下文,并建立其相互之间的映射关系。对于单一系统和微服务来说DDD都很有效,而后者在概念上更加符合DDD增加隔离的思想。

当基于概念模型进行去中心化时,微服务同样要求把数据存储去中心,而单一系统则采用单独的逻辑数据库进行持久化,企业甚至倾向于使用同一个数据库覆盖多种应用(这在很大程度上取决于供应商的许可证业务)。微服务则更加极端,既可以采用同一数据库技术的多个实例,或者采用完全不同的数据库技术实现(Polyglot Persistence,同样可适用于单一系统)。

这里最大的问题是变更管理,因为在许多应用场景中,单一系统采用事务处理的方式保证多个资源间的一致性。而在分布式系统中,事务无疑变得十分困难,这令微服务面临两难的问题:既要保持分割独立,又要保证一致性。而在实际上,微服务的设计思想倾向于强调服务间的弱事务性。这就使得一致性只可能是最终一致性,并采用弥补操作解决相关出现的问题。

这种非一致性管理的问题对多数团队都是一项挑战,但在实际业务中却时有发生。有时具体业务会要求将不一致性保持在一定程度以内,从而快速响应需求,同时拥有一些类似于回退的过程处理错误。一旦修复这些错误的耗费小于保证业务的强一致性,这种权衡就是值得的。

基础设施自动化

近年来,基础设施自动化技术取得了巨大的进步,特别是类似AWS这种公有云服务的兴起,降低了构建、部署、以及操作微服务的门槛。

一般来说,采用微服务的团队通常都能熟练应用持续集成CI、甚至持续交付CD技术,拥有丰富的基础设施自动化背景。CI/CD的目标是令构建和部署变得“无趣”,一旦目标达成,任何扩展就变得非常容易实现,而这在单一系统上已经得到了充分验证。对于微服务来说,该项技术与单一系统相比没有太大区别,但两者的操作域存在明显区别。

高融错设计

当采用服务作为应用组件以后,该应用就需要被设计成面向服务的高容错系统。而在实际情况中,任何服务都有可能发生错误而中止服务,客户端必须据此给出合理的响应。与单一系统相比,这是一个存在于微服务系统中的额外复杂度。

首先是测试,包括在生产环境中执行自动测试,以及当某些服务或者数据中心出错的意外情况恢复和监控。然而对习惯于单一系统的运维团队来说,这种方式可能是一时难以接受。 微服务特别强调服务的实时监控,无论是架构方面,还是业务方面,这种语义化监控能够提早给出出错警告并同时开发团队。对于单一系统,可以把单个应用视为一个微服务,区别是你需要在不同进程中的服务出错时得到警告。而由于单一系统通常采用库实现组件化,相同进程内的服务出错可能并不会得到明确的警告。

总而言之,微服务要求较为完善的监控和日志系统,同时拥有一个实时的dashboard随时通知开发团队,重要的测量单位有断路器状态、吞吐量、延迟等等。

演进化设计

微服务的实践者通常拥有演进化设计背景,他们把服务分解当作未来控制变更的工具之一。控制变更的目的并非是要降低变更频率,而是保证更好、更快地控制变更对软件的影响。 无论何时对现有系统进行组件化分解,你都需要遵守一个分解原则:组件的关键属性之一是独立可替换和升级。这就意味着我们需要寻找一个点,能够通过重写这部分的组件而不会影响其它组件。而实际上,很多团队选择直接将服务碎片化,而非进行长期演进。

在模块化设计中,一个通用的准则是强调可替换性,这样就可以保证接受变更。当你发现你需要重复的修改两个服务时,那就意味着它们应当被合并。

微服务的优势是降低变更发生时的构建和部署时间,缺点是你需要考虑服务变更对消费者带来的影响。一个传统的解决方式是采用服务版本管理策略,但对于微服务来说,应当尽量不要进行版本管理。在许多情况下,我们可以通过设计使得服务尽可能接受不同的消费者请求。

2. 总结

上文几乎列出了微服务架构到目前为止被发现的全部优点,这里列出其缺陷或尚未解决的问题:

组件边界的确定

由于微服务本质上是采用服务实现系统组件化,那么组件边界就成为衡量微服务设计优劣的重要参考价值。一旦设计完成,任何代码级重构、借口变更、向下兼容、以及测试架构的复杂度都会提升。

组件的组成

当组件的组成方式存在瑕疵,剩下来能做的就是把组件内的复杂性转移至组件连接部分。当你关注组件内部时,应当注意组件间的组成方式设计。

团队技能

任何新技术都倾向于更适合拥有中高级能力的团队,但并非对其它团队完全无用。即使是采用单一系统,某些团队依然做的一团糟,而微服务表现如何犹未可知。

最后给出Martin对何时向微服务架构迈进的评论: One reasonable argument we’ve heard is that you shouldn’t start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem. (Although this advice isn’t ideal, since a good in-process interface is usually not a good service interface.)

喜讯:热烈祝贺本站正式被OOXX!!

经向有关部门了解,本站已被GFW屏蔽,具体原因不明。大家今后VPN见!百度的朋友就对不住啦……

有关秋雨、毕业、软件测试、痛苦根源、《金刚经》和妄念的一切

须菩提白佛言:“世尊!佛得阿耨多罗三藐三菩提,为无所得耶?”佛言:“如是,如是。须菩提!我于阿耨多罗三藐三菩提乃至无有少法可得,是名阿耨多罗三藐三菩提。”

——《金刚般若波罗蜜经》,第二十二品 无法可得分

趁着雨天赶上了入夜前的最后一班校车,结果遇到喜闻乐见的大堵车,折腾回家天已全黑。待饭毕,终于不愿去碰什么C++、数据结构与算法的书——最近整天泡在图书馆里读各种经典,恨不能把本科和研究生几年来西大欠我的一座图书馆一下子搬走。结局是书读了不少,却毫无长进:恐怕是因为我这种随众的心态,毕竟眼见人人都揣着本面试宝典之类的畅销书,再淡定也终不能自持了。但这真称得上是所谓的奋斗么?却未必尽然。

现在回头看一眼前一篇文章的日期:写于大约一个半月之前。在那又之前的很长一段时间里,我始终以为未来将在那之后笃定,我甚至认为自己将与心仪的导师和朝气蓬勃的团队会面,大家相谈甚欢,以至于令我觉得能够在自己钟爱的领域大干十年,人生便没有遗憾了。然而当青岛会议结束后,却发现情况和当初预想的完全不同:首先,如果稍了解国内的科研现状,你会发现好的导师和团队真是凤毛菱角,即便遇到了,准入门槛也极高,甚至不完全取决于主观因素,有时真得称得上是可遇而不可求;其次,我发现自己现有的心智模式中可能缺少非常重要的一块,尽管多年来不时遇到好心人提醒,却很少真的思考这个问题。换言之,如果我选择并得以“再干十年”,难道就真能得到自己想要的东西么?

这是一个矛盾,而且以我仅有的经验而言根本无法解决之,也无法获得能够真正说服自己的第三方的帮助。再加上七八月份的火气:令我不得不选择逃离,去到一个能够给自己降温的圣地,也是为了给自己留一点时间:我明智地选择了一人出发,在青藏高原起伏的草场上,试图短暂忘却平均海拔4000米下的一切,而有时候,甚至真的已经感到有些“乐不思蜀”了。有意思的是,等我回到家,发现命运已经把自己落下了一截。

我不知道它是如何发生,实话说也不想知道。大概是因为我有一种固有的计算思维,在提前制定测试用例时,我会像是强迫症似地列举出每条分支和可能性,然后从自己的角度做出对结果的评估。也就是说,我已经意识到这会是结局之一,的确就不很讶异了。但这种所谓的“淡定”存在明显的缺陷,即如果我们只一味做黑盒测试,无法真正从编码的角度去解释问题的原因,那么作为此生唯一的程序员,怎么保证自己能谱下一首生命之歌呢?然而关于这个问题,我至今没有想太明白。

后来有机会和朋友讨论这件事,还是不到两周前的事。谁知道大家听了都很不屑:“这简直太显而易见了吧?”我很惊奇他们是如何熟练掌握这种技能的,更有可能是道听途说吧?但如今世界的规则不就是由道听途说演变而来的么?唯一能确定的,就这是一切都没有超出合理的范围之外,如果连这些都不合理,那人类恐怕早都灭亡了也说不定。

于是我觉得自己又面临着一次需求跟踪与评估,值变了,维度却没变,复杂度依然毫无降低。唯一能做的,就是像众人一样,去啃那些本不值得在此时去啃的书。也就是说,虽然自己的算法bug了,换成朴素的一样好用,当然前提是你不是一个追求完美的狂热份子。我显然在这又悲剧了一把。

所以好不容易回趟家,绵绵秋雨,好时节当然不能全浪费了,便去读大乘经典。本文开头的《金刚经》第二十二分,大意为“须菩提问佛说:世尊,佛所得至高无上、大彻大悟大智慧,也就是什么也没得到吗?佛回答道:正是这样,正是这样!须菩提,我于阿耨多罗三藐三菩提,是无所得,(须菩提)一点法都没得到,只是说我成就了至高无上、大彻大悟大智慧。”另文中的名词可参见关于心经的注,在此就不讨论佛学。南怀瑾亦有关于本品的偈颂:“多年行脚觅归途,入室知为道路愚。检点旧时新衣钵,了无一物可提扶。”或许可当做送给自己的安慰作?仔细想了下,自己恐怕永远也到不了那个境界……

尽管我崇尚绝对自由,甚至可以说如果没有自由,我就不再是我。但是另一方面,如果未来我选择妥协,用自己的自由去换取世界观,我就变成了另外一个我,一个背叛了原始的我的我,到那时,我该怎么看待自己?我只能确定,本文完成后还剩了一摞的书等着我去啃。至少通过这种方法,我就有机会去变成一个不一样的我,然后告诉原始的我:原来我是这样的我!

最后,如果读者您完全看懂了本文,那么也请尽量告诉我,让我能够佩服一下自己 ,谢谢。

Comments

网络里的隐形蝴蝶

取道天津回家的路上,回想起在研讨班上介绍的近期发表在《Science》上的一篇文章——《Network Interventions》,恰好随身u盘里存有该期的full text,为了打发时间,便试读了这篇Review(很少去碰《Science》上的Review,往往感觉高贵但又不知所云)。结合最近、特别是这几天会议期间的经历,觉得有所感触,于是就想写文章,无奈下了动车就找不到一个能接到电源的地方,于是只好回家后将其完善。事实上,南加州大学Thomas W. Valente博士通过这篇Review列举了一些针对社会网络的最新研究成果,并向我们展示了一个看待现实问题的新思路。

原文作者Thomas W. Valente是USC的传播学博士,现任该校预防医学系副教授,由于数学学士的背景,其研究兴趣主要集中于网络分析和基于社会网络与程序评估的社会影响研究。Network Interventions的字面意思是网络介入,指利用社会网络数据加速行为变更或改善组织效率的一种新方法。近年来,研究人员逐渐发现通过分析已有的社会网络数据,并采用合适的方法就能得到一种具体且有效的Network Intervention方案,而一旦应用该方案就有可能引发强烈的正面或负面效应(Interventions并不是本文的重点,但却是原文的核心主题)。应当注意的是,Network Interventions之所以可被看作一门科学,是因为前期已有大量有关社会网络分析的研究,并取得了不乏瞩目的成果,而Network Interventions实际上是建立在前述成果基础上的一系列应用。那么,随着时间的推移,社会网络的规模和复杂度不断更迭,其本质是否已发生了无数次巨变呢?

同一篇文章的原作者著有一本《Social Networks and Health: Models, Methods, and Applications》,别出心裁地将社会网络分析的理论和方法应用于公共卫生和其它社会科学领域,其基本观点是:不同人类分组之间相互交流和传播形成了个体的健康行为。这里的“分组”可以指一个族群,也可以指一个个体。通过对社会网络的数据、特别是近年出现的基于互联网的虚拟社会网络所带来的庞大数据进行网络分析,研究人员发现个体行为和精神状态不同程度地受到了网络中相邻节点的影响,影响力最大的节点被称为“变更代理”。目前已有许多判别网络中“变更代理”的方法,而采用Borgatti提出的最关键节点方法可以找到网络中的局部Key player,即所谓的Leader。通常情况下Leader影响了网络中大部分节点的行为属性,但对于类似存在桥节点(且Leader非该类型节点)的网络,传播效率就很大程度上受到非Leader因素的影响。具体到公共卫生领域,这种影响可能是饮食性超重在节点间的传染,其根源则是Key player对其它节点施加了影响,使节点的固有行为、如饮食习惯等发生变化,从而导致超重节点数量的增加。另一个典型案例就是某种抑郁症的网络传播,这里会另文介绍。进一步,研究人员为了度量个体行为在网络中的传播速度和冲量(动量的变化量),通常采用一种“低阈值变更代理”的方法,即通过分析邻接Key Player数量与所有相邻的节点数,从而得到节点的曝光度,其值实际上就是每个节点的阈值。低阈值携带节点有时也会成为变更代理,但确定这部分则需要获取行为学意义上的先验数据加以支持。

总的来说,社会网络可被看作是一个个体相互间施加行为影响的媒介,如同一只隐形的蝴蝶,有意无意将花粉传播到网络中的各个角落。而随着电子信息工业的发展,互联网上的社会网络逐渐崛起,非常丰富和高质量的社会网络数据直接被用于网络分析,从而为底层的基础理论研究提供数据保障,使这第一手资料变得弥足珍贵。但是,研究人员仍需要进一步明确传统社会网络和所谓SNS的本质区别,由于网络传播的即时性和爆炸性,行为影响传播在广度上会有极大的促进,但也未必完全意味着好消息。毕竟,从植物学的角度来说,错误的花粉被授予柱头,将导致花粉和胚珠的双重浪费,这显然不是进化论给予我们的答案。

即使是在传统社会网络里,这种情况发生的概率也非常之低。

Comments

整站迁移完成

最近一直在考虑是不是该升级到vps了?毕竟单纯的空间已经远远无法满足现在互联网DIY的需求。然而思考再三,vps需要花更多时间去照顾,恰好在未来一段时间内又不会很轻松,只好先忍一忍。于是决定趁早先拿下新域名hanyi.name。结果问题就来了,国内的空间商要求新绑定域名必须重新备案,否则按规定不予解析。还好我对这一套比较熟悉,屁颠儿跑去XX部网站办备案,结果被告知个人只允许备案1次,机构最多也只允许备案5次。而我前次备案是在08年,当时还是因为他们无故删除了我在06年就提交并审核通过的备案信息,悲剧的是他们这次居然成功保存了4年前的信息!回来找空间商商量,最简单的方法还是换别人的真实信息重新提交。顿时无语,原来早前CN域名开放是纯属坑人呢?进而有了将整站迁移至国外空间的想法。

域名问题很好解决,许多国外知名域名商支持通过支付宝进行国际支付,加上pending共花了一天时间完成。缺点是DNS初解析较慢,平时用的CN域名的解析在国内几乎是实时更新的。另一方面采用了原空间商在国外的主机业务,用电信线路看主机的ping不错,不过迁移后发现明显还是慢了一个级别,目前看来只好通过在今后优化页面内容来改善了。好处是空间容量是以前的三倍,不过现在看来用处似乎不大。

迁移工作还是颇费周折,现在看来wordpress迁移唯一必然的成功办法还是数据库内容链接的全文替换,否则只改几个字段可能会出现无法进入后台的情况。再加上周中实验室网络欠费,用了几天坑爹的“西大国内网”,很难顺利完成整站内容的迁移。于是只好把多余的时间用来进行一些反思:多年以来我做了许多自己感兴趣的工作,尽管无甚成果,但确实也学习了不少东西,总体上始终循着当初所谓“自由学习,自由思想”的理念,也从未遇过大的挫折。然而,出于一些忧虑和回避,自己有意无意忽视了平等交流:所谓平等交流,在我看来就是用自己的想法去换取别人的想法,并且所有人都认同且遵守唯一的道德准则。事实上,我对周围真实环境的了解程度非常低,某种程度上是基于以上原因。这也就导致了自己对身边事物的看法具有很强的不确定性,难以在自身问题上做出有效判断。另一方面也导致自己至今缺乏一些常识……有些事在别人看来是显而易见,自己却不容易想明白。

考虑到有些外链是指向原mp77.cn,本站仍会对继续支持这个域名,并持续至少1年时间。而hanyi.name会是我的永久性域名,今后也不会再向站外自动导出文章。

手嶌葵拯救世界

如果说,手嶌葵是六年前的《地海战记》迄今为止给人们留下的唯一记忆的话,同样的评价送给《虞美人盛开的山坡》恐怕也没多少人会提出异议。然而必须承认,宫崎吾朗的二次登场的确令人耳目一新,看似俗套的少女漫画情节,影片最终展现出的信息却远超出这个范畴。毫无疑问,我们都被影片和她的主题歌声完全治愈了。

仅从观影的角度来说,影片的主线情节可以说毫无新意,即使单是吉卜力在近二十年里也已拍了不少类似的主题,观者可能会感到比较乏味。不过如果换一个方向,会发现影片丝毫不含蓄地表达着一种积极向上的氛围,这一点却是同类型片中所少见的。正如《萤火虫之墓》展现给我们一个焦灼的日本一样,《虞美人盛开的山坡》所展现的是短短二十年后一个全新的社会。许多中国人都对五六十年代的日本感兴趣,以至于有关彼国六十年代经济腾飞的著述迄今都颇受欢迎,然而恐怕许多人(包括我)至今都为此感到困惑,如今幸好一部2011年本土票房冠军的影片能够给我们以管中窥豹的机会。

故事原设于公元1963年,恰好是东京第十八届夏季奥运会的前一年。阿海和阿俊几乎在同一时间内都遇到了“人生的重要挑战”,一是“拉丁楼事件”,二是关于自身的身世之谜。然而二人自始至终都未言放弃,一方面成功使得作为历史见证的活动大楼免遭校方为了“迎接奥运”而进行的拆毁重建;另一方面,同时也颇具戏剧性的是,历史真相的唯一见证人恰好在片末出现,吐露出了阿俊身世的秘密,并且终于卸下了重压在两人身上的历史包袱。如果仅仅从青春爱情故事的视角去鉴赏影片,有些情节可能经不起推敲,于是宁愿称之为一种朦胧的、尚未成熟的情感加以附会,但叙事手法上就显然比不上早年的《侧耳倾听》。事实上,从《地海战记》中我们就可以发现,宫崎吾朗的思想深度其实不亚于老爹,广度上则可能要更甚一些。然而他的劣势在讲故事的能力上,导演没能像上一辈的几部经典作品(当然宫老也并非只是传说)那样能够抓住观众,这种小遗憾现在看来恐怕仍然是不可避免的。

不过,导演真正希望传递的信息可能不止于此。其实,真正令人惊讶的是片中人物所共有的思维方式。例如,作为全剧线索的“拉丁楼事件”,即使在争辩双方矛盾非常尖锐的情况下,依然能够齐心协力维护大家得来不易的自由。学生们甚至喊出了“少数服从多数,即是多数人对少数人的暴力”这样颇具智慧的政治口号:这些桥段无一不体现着当时日本社会的整体风貌。另一方面,阿海和阿俊都是非常严肃地看待两人之间的微妙关系,哪怕是后来所谓的“兄妹疑云”,也没有发生任何情绪化事件,相反二人都在尽力追求真正的谜底:相比之下,在五十年后的现代社会,这样的“死理性派”是否太少了点呢?

如果对故事的所有事件追根溯源,则要归结于立花洋和泽村雄一郎两位长辈在战时的先后离世。阿俊每天驾着拖船驶过阿海家门前的一片水域,不经意间发现少女每天准时升起祈愿平安的U.W信号旗,于是撰下诗篇并发表在校园刊物上:

少女扬起了旗帜  何故  要将思念寄语晨风  呼唤著远方  伴著一时心血来潮的老鸦  少女啊  那藏青色围绕下红白相间的旗帜今日也在风中飞扬

命运就那样巧合。阿海偶然读到诗文,从此记住了松间俊这个名字,也为二人相识奠定了命运的基础。最后,唯一历史亲历者小野寺善雄的出现,使得尘封十余年的故事最终浮出水面,拖船缓缓驶向岸边,夕阳下的阿海和阿俊终于如释重负:对阿俊而言当然是得知了自己的真实身世;另一方面则包含了阿海对父亲的怀念;而当下乃至未来的意义则是不言自明了。片末,阿海完成了人生中迄今为止最为宁静的一次升旗,镜头回到姐姐的那副画作,正是不远处水域上航行的那艘拖船,船头也挂起了“答语U.W”。对导演来说,战后的日本社会长期受到历史遗留问题的困扰,而同样作为战争受害者的普通民众则受之更甚:人们需要通过某些方式得到彻底解脱,才能坦然面对未来并开始新的生活。实际上,六十年代的日本国民不仅做到了,而且还比其他亚洲国家要出色的多。或许这才是导演的真正意图:唤醒国民对美好时代的回忆与憧憬,而且不应仅仅是怀念而已。

手嶌葵的歌声在片尾响起,其实是翻唱自森山良子在七十年代的一首老歌《さよならの夏(告别之夏)》,宫氏招牌式的完美结局,在手MM的伴奏下逾显动人了(也彻底填补了影片末尾与《侧耳倾听》之间存在的思想差距)。

附歌词:

光る海に かすむ船は

さよならの汽笛 のこします

ゆるい坂を おりてゆけば

夏色の风に あえるかしら

わたしの爱 それはメロディー

たかく ひくく 歌うの

わたしの爱 それはカモメ

たかく ひくく 飞ぶの

夕阳のなか 呼んでみたら

やさしいあなたに 逢えるかしら

だれかが弾く ピアノの音

海鸣りみたいに きこえます

おそい午後を 往き交うひと

夏色の梦を はこぶかしら

わたしの爱 それはダイアリー

日々のページ つづるの

わたしの爱 それは小舟

空の海をゆくの

夕阳のなか 降り返れば

あなたはわたしを 探すかしら

散歩道に ゆれる木々は

さよならの影を おとします

古いチャペル 风见の鶏(とり)

夏色の街は みえるかしら

きのうの爱 それは涙

やがて かわき 消えるの

あしたの爱 それはルフラン

おわりのない言叶

夕阳のなか めぐり逢えば

あなたはわたしを 抱くかしら

(完)

Comments

Kinect的三维重建(1)

有关Kinect应用开发正日新月异,稍有懈怠就会被远远甩在身后。不过,Kinect目前带给我们的仍只是一个充满无限可能的远景,正如App store能吸引年仅11岁的开发者一样,Kinect未来将对“全民开发者”产生重要推动作用。另一方面,一些基于Kinect的应用研究仍颇复杂,主要是因为一些关键环节的滞后而导致的。2011年的siggraph talks上,KinectFusion首次展示了实时、廉价、轻便的室内场景三维重建,使得我们向着“无处不在的数字化”迈进了一大步。该项目主要由微软剑桥研究院的研究人员发起实施,研究小组目前公开发表了两篇文章:

Shahram Izadi, David Kim, Otmar Hilliges, David Molyneaux, Richard Newcombe, Pushmeet Kohli, Jamie Shotton, Steve Hodges, Dustin Freeman, Andrew Davison, and Andrew Fitzgibbon, KinectFusion: Real-time 3D Reconstruction and Interaction Using a Moving Depth Camera, ACM Symposium on User Interface Software and Technology, October 2011

Richard A. Newcombe, Shahram Izadi, Otmar Hilliges, David Molyneaux, David Kim, Andrew J. Davison, Pushmeet Kohli, Jamie Shotton, Steve Hodges, and Andrew Fitzgibbon, KinectFusion: Real-Time Dense Surface Mapping and Tracking, in IEEE ISMAR, IEEE, October 2011

除了Microsoft Research外,国内外大量机构都借助Kinect进行相关研究。仅就实时场景三维重建这项应用而言,由开源机器人研发公司Willow Garage在2011年发起的Point Cloud Libary (PCL)就吸引了全世界数十家著名科研机构参与、十余家公司提供经济支持。PCL是一项集点云获取与处理、滤波、特征提取、关键点标定、表面重建和点云配准以及点云融合等功能为一体的开源点云处理库,PCL使用OpenNI作为系统IO接口,实际成为KinectFusion的开源实现项目,该项目的相关论文发表在ICRA2011上。

上述文献可以说是迄今为止有关Kinect的三维重建应用的最佳切入点了。应注意的是这两篇文章讨论重点的区别,前者先是对KinectFusion整个项目进行了流水式说明,随后解释了文中采用的经典算法的GPU实现,开发者可能会比较感兴趣;而后一篇文章则重点讨论了新的并行算法的形式化描述和性能分析,这部分可能会更吸引一部分研究者。我们将采用一种自上而下的方法先对这两篇文章进行简要介绍。

 概述

有关Kinect的结构光技术读者可以参考这篇文章或直接去Google下PrimeSense的专利,这里不再赘述。不过,尽管Kinect在获取深度图方面几乎是达到了性能与质量的完美结合,但仍无法避免深度图中大量抖动的产生,如果我们直接对单张深度图进行bilateral filter双边滤波然后重建出网格模型,会发现重建出的模型表面质量较低,甚至出现孔洞的情况。更重要的是,单张深度图能够获得的只是模型在某个视角下所展现出的一部分,而非表示完整的模型。因此,如何改善基于Kinect深度图的模型重建质量,并实现物体的完整重建成为该项技术的关键。

KinectFusion的首要任务就是克服该难题,它允许用户手持Kinect设备在室内场景自由移动,并实现场景的高质量三维重建。同时,KinectFusion还提供了精彩的AR应用,包括前景、背景和人体的分割与重建、以及AR世界中的多点触摸识别技术。

场景重建

基于上述需求,KinectFusion允许用户手持Kinect设备自由探索室内环境,系统将自动跟踪Kinect摄像头的6DOF姿态,然后融合不同时序的深度图数据并重建出场景的全局模型。由于视角的不断变化,Kinect反馈的深度图也会发生改变,这里采用了类似图像超分辨率技术对深度图进行了细节优化,从而提高模型的重建质量。最后利用Kinect自带的RGB数据进行场景纹理映射。

首先如何利用单Kinect摄像头去跟踪它自己的6DOF姿态?这里采用点云模型的刚性配准对齐来计算摄像头在空间中的6DOF变换,点云配准首选经典的ICP[Besl92, RusinKiewicz01]。之前需要将深度图像数据变换至摄像机的空间坐标系中,并计算其对应点的法线信息;然后逐帧采用基于GPU的ICP实现进行模型配准和6DOF计算;在重建部分,KinectFusion并没有直接融合点云或生成网格模型,而是采用了[Curless96]的体集成算法,最终在全局坐标系中生成一个三维体素网格并进行不断更新,每个体素内最终保存了一段时间内从该体素到物理表面上某一点的平均距离。最后使用Raycast给出隐式表面的渲染结果,另一方面,以摄像机位置作为视点做Raycasting,同样能够得到一个具有真实细节的高质量的合成深度图,然后再对其进行下一轮ICP迭代。这就允许我们能够利用合成深度图与下一帧的深度图进行配准,使重建结果的精度不断提高。

具体算法实现采用了CUDA并行架构,算法基本流程如下:

1)深度坐标变换,对于每个像素启用一只CUDA线程,给定一个Kinect红外摄像头的内部校准矩阵K,使用如下公式

计算坐标变换;相应的顶点法线则直接取其右、下邻向量的外积,并进行归一化。时间i时的6DOF摄像机姿态使用一个刚性变换矩阵T表示,其中T包括了摄像机的旋转矩阵R和平移矩阵t。变换后的顶点和法线通过T即可再变换至全局坐标系中。

2)摄像机跟踪,该部分的主要目的就是计算6DOF姿态。核心的ICP即迭代最近点算法,首要是需要逐帧计算不同朝向的点集的相关度。这里采用了projective data association方法计算相关度。

3)体集成,针对已配准的点云数据,需要执行后续的融合处理,这里采用了经典的[Curless96]体集成方法融合这些点云数据。

4)光线投射渲染,采用光线投射渲染前步生成的隐式表面。

上述整个管线均采用了并行GPU实现,在下文中,我们将重点解析上述算法的CUDA实现细节。

Comments

TangleTracer(Basic edition/B) 1.0 Beta开源发布

TangleTracer是一个实验性光线跟踪渲染平台,目的在于为真实感绘制技术的初学者提供完备的学习例程和友好的实验接口。系统设计思路主要源于Kevin Suffern的《Ray tracing from the Ground Up》一书,同时部分参考了著名的真实感绘制圣经《PBRT 2nd》。从今年三月中旬起我们就开始了前期的技术储备工作,该项目由四月初正式开始,截至目前完成代码近9万行,系统框架基本完善,实现并调试通过了440个demo或Kevin书中的习题(这部分代码超过4万行)。与K书中提供的原型系统不同,项目开发平台选择了Microsoft Visual Studio 2010和Qt framework 4.7.3,为快速开发提供了良好基础。 由于系统和部分框架来源于K书,我们循例采用GPLv2开源发布。此次发布的主要内容是系统的代码部分,为便于大家测试,我们稍后会提供基于win32平台的二进制版本(目前正在进行兼容性测试),运行系统内置的全部例程需要同时满足以下条件: 1.下载例程所需的纹理包:http://www.raytracegroundup.com/downloads/TextureImages.zip%EF%BC%9B 2.下载例程所需的模型包:http://www.raytracegroundup.com/downloads/PLYFiles.zip%EF%BC%9B 3.确保纹理包的TextureFiles目录和模型包的PLYFiles目录与程序二进制文件位于同一目录下; 4.部分模型需要下载stanford的原始文件并进行替换(具体请阅读README及代码注释):http://www-graphics.stanford.edu/data/3Dscanrep/%EF%BC%9B 此次发布的是TangleTracer的Basic edition/B版本,其目的在于提供思路清晰的CPU渲染技术,但实际渲染性能较低。我们正在进行系统的并行迁移实现,并力求在下半年提供TangleTracer的GPU edition/G版本。详情请关注项目github主页:http://mp77.github.com%E3%80%82

Comments

《武训传》的现实意义

我对所谓的“国产禁片”并不感冒。其原因在于真正要被禁的影片根本不可能启动拍摄,而已经拍出来的所谓“禁片”注定是褪去了核心思想的阉货,顶多被允许在课堂上当教学片放,还需得是遮遮掩掩的那种。不过,当听到《武训传》要出数码修复版时又不禁小兴奋了一下,突然对这部筹划于上世纪四十年代初、成片于1950年并在中国当代史上扮演了重要角色的“第一禁片”十分好奇起来。尽管寻找片源时颇费了一番周折,好在终于在周末第一次看完时长197分钟的全片。

使我对该片产生好奇的第一个问题是,《武训传》在今天仍不失影响力,那么是因为传主事迹确实称得上“感天动地”、堪得流芳百年?还是由于该片后来“意外地”成为了首个思想文化批判与改造运动的漩涡中心,以致于迄今为止仍有许多人们念念不忘,难以释怀?我们知道,影片创作最初源于民国著名教育家陶行知先生对“武训精神”的推崇和力行,并随段承泽和漫画家孙之俊两位先生的《武训先生画传》而广为人知(1950年李士钊和孙之俊又重新出版了一套《武训画传》)。据《武训画传》载,武训(武七)幼年丧父,与母亲以讨饭为生,年少时先后在自己的姨夫家和李地主家做工,饱受欺辱。由于没上过学,被地主骗光了三年工钱。经过几番沉重打击后,武训意识到只有读书才能改变穷孩子们的命运,才能真正帮助穷人摆脱这种不公正。经过近四十年行乞的勤劳与节俭,武训先后创办“崇贤”、“杨二庄”以及“御使巷”三家义塾,免费供贫困子弟上学。武训事迹轰动山东,最终得到清廷嘉奖并授予“义学正”。总的来说,武训事迹是真其人、确其事的贫民教育典范,理应作传以传后世。不过,当漫画版传记到银幕则产生了原因复杂到令人难以理解的后果。

昆仑公司出品的《武训传》成片于1950年,实际上影片曾断断续续拍了几年时间,周恩来等领导人都曾经对拍摄中的剧本进行了修改和建议。不过,影片的编导对原《画传》的核心思想进行了改编,我认为这恐怕是为创作团队带来日后横祸的重要原因,但也不得不佩服孙瑜导演及其他主创对待文艺创作的理性态度和勇气。影片新引入的一条主要线索是前太平军周大的经历,北伐失利的周大与武训一同在张举人家里做工,最终与武训共同逃离,不过他的选择和武训大相径庭,后者选择兴办“义学”,而周大则去做了响马,其理想是将地主“抢光”、“杀光”,有意影射清末数量庞大的农民起义运动。影片中武训的态度很清楚:“读书改变命运”,一味烧杀并不能解决问题。但在片末,农民运动达到了高潮,响马们履行诺言回来复仇,武训看着一切只能又标志性地挠了挠头,但影片没有给出事件的最后结局。批判者指责影片推崇“改良”,在某种程度上说并不完全错误,同时这也是至今影片仍存争议的原因。不过,关于所谓的“路线”争执是自百年前至今都确实存在的,只是取决于我们怎样对待这种应当仅存于学术层面的争论。

然而影片中武训的担心也未必没有道理,当狂热到丧失理性之时,原本就缺乏思考的人们会变成怎样可怕的怪兽?君不见,当代中国又横遭了多少磨难?我对影片与《画传》的一处细节差别印象深刻,首先片中强调“张举人”的读书人身份,后来又编出什么“没收武训所积造文昌帝庙,以明读书人之修身齐家的志愿”?读书人是不完美,但人始终无完人,影片着重渲染了一干“读书轻义”的当权者,与武训到处跪求贫困家庭送子入学形成了明显矛盾,尽管片中也给出了几个开明乡绅的形象。而当武训听到对“学而优则仕”的解释时又大为困惑起来,是顺带批评了当时的知识分子么?可见,影片所带给人的思考余地是非常广阔的。

现在回去看《武训传》所遭遇的不公正待遇,我认为这正是影片创作者们的担心终成现实的结果,甚至可能丝毫不出他们所预料。当然恐怕有更多的人宁愿相信这些卓越的文艺创作者们是犯了某些错误,至少是某一“特定历史时期”下的错误。但我始终觉得这些说辞只会是无力面对历史的辩解之词,看似轻描淡写,实则是一个讳疾忌医的病人罢了。

最后,针对《武训传》的当代史研究在最近30多年里已经著述颇丰,我认为要了解一段历史,必须行史学家的态度去阅读文献,在此之前不应轻下结论,否则必然是一叶障目。本文不提非官方的野史故事,理由一是资料真假难辨,有失严谨;二是希望现今的人们能继续从本质上对武训及这部影片展开讨论,当然这种讨论必须是完全理性的、有意义的观点和看法。尽管我们长久以来避而不谈,但历史终究会使我们不得不去思考,今后的路朝哪里走。

Comments

参数化设计/建模及其在艺术创作领域的应用前景

一、概述

迄今为止,参数化设计/建模仍代表一种理念,尽管这种理念已经经历了CAD/CAM近五十年的发展历程。系统化的CAD/CAM技术包含两种基本思路,一是使用二维几何原语如点、线或样条表示三维物体,如Bezier、De Casteljau以及Sutherland这些先驱们的工作;明暗处理的需求接着被提出,从而出现了早期着色模型的研究(本文将不涉及这部分内容);即使是目前最广泛使用的Nurbs,也是A.R. Forrest早在1980年就已经完成了。

另一种思路是使用体素构造表示(CSG)进行实体建模(该技术实际上也诞生于60年代初期),其基本方法是使用一组基本几何体,如球、柱体、椎体等,对其执行交、并、补等布尔运算序列,从而构建复杂三维物体,通常再使用B-Reps表示最终生成的三维模型。这种方法由于能够保持模型拓扑的欧拉示性数V-F+E,有助于满足三维物体的基本几何特征,因而得到了广泛应用。

现在看来,CAD/CAM的关键技术似乎早在30年前就已经比较完整了,那么继续该领域的研究还存在哪些意义?事实上,CAD/CAM目前仍面临许多瓶颈,这些瓶颈已经影响了目前广泛采用此类技术的汽车制造、电子和建筑等行业的进一步发展。例如面向三维模型的可编辑性,模型编辑的目的通常有两类:一是用户设计意图发生变化,需要变更现有设计;二是模型的适用条件发生变化,不得不做出调整以适应新变化:如某些工业组件所面临的不同规格需求。在参数化设计提出之前,针对三维模型的编辑主要采用直观交互式的方法进行,其复杂程度甚至超过最初的建模过程。一些行业专家分析,模型编辑的主要难点在于该过程既要保持原组件的局部特征,还要适应新的条件,同时还要确保这种编辑不会影响组件之间的相互关系;特别重要的是,在整个设计、建模、编辑的过程中要保证一定的数据精度。提高可编辑性一度成为现有CAD/CAM技术的重要研究方向。

二、参数化设计的发展和现状

参数化设计的最初目标就是解决CAD/CAM的上述问题,并取得了一定成果,特别是在建筑业。参数化设计的本质就是使用一系列参数定义三维模型的基本特征,包括基本尺寸、各组件间关系等。在一些文献中,参数化设计也被称为关系型建模或是变量化设计。在参数化设计中,建模原语通过一组参数表示,如使用位置、长度和方向参数表示空间线段,而如果仅涉及到这部分,那么参数化设计似乎与传统的交互式设计并无不同。更进一步,为了保证模型在一定条件下的可编辑性,参数化设计要求用户建立建模规则的参数化表示。如AutoDesk推出的AutoLisp语言,实际上是通过编写脚本制定规则,而把输入参数转化成三维模型的应用在目前已经十分流行了。然而对于绝大多数设计师而言,学习编程语言其实没有太多必要,同样对于一些复杂模型的构造,编程实现会真正意味着缘木求鱼。因此参数化设计需要进一步的形式化、领域化和直观化,才有可能被大多数设计师所接受。

“约束”是参数化设计的一个重要概念,不过其提出要比“参数化设计”本身还早。约束表示针对一个或一组实体的行为关系限定。实体可看作是三维模型的一个组件,实体行为则代表该组件在不同参数下表现出的状态。例如”一组线段相互平行、垂直或共线”就是一种约束描述,每条线段受相应参数控制其行为,而各线段的参数却受到“平行、垂直或共线”的关系限定。在带约束的设计和建模过程中,无论是施约束端还是受约束端,都需要得到完整的参数列表才能进行,由于约束的存在,某些参数实际上需要通过“推理”进行估计和计算,这种推理估算参数的过程在很大程度上影响了建模效率。当前应用中普遍存在两类约束:几何约束和物理或称工程约束。平行、垂直、共线、相邻、尺寸等都属于几何约束,此外包括一些物理方程、条件关系等则属于后者。这类方法需要用户在建模初期提供实体类型、空间位置和尺寸参数,然后通过一些具体方法描述实体关系,如前面所述的编程脚本。

1982年,Gossard和Light首次提出了“变量化设计”的概念。此后十年间,由于几何造型、自由曲面和实体建模技术的迅速发展,出现了愈多针对交互性及可编辑性的改进需求。大量工作开始致力于该领域中,如前面介绍的变量化编程的提出,通过编写一段程序脚本控制建模过程,这种方法实际上并不能有效解决存在的问题。而为了保证用户设计意图的准确实现,直观交互通常是必须的,因此提供领域化的参数化设计工具是较为合理的选择。

1、基于时序的约束建模,即记录用户交互式建模时产生的参数集时序变化,在修正设计时,通过随机选取并更改时序中的参数变化内容,实现参数化设计。这种方法要求模型的构建过程保证良好的层次性;

2、变量几何和变量化设计,即通过构建基于参变量的建模公式进行参数化设计,例如利用简单解析式创建二次曲面。对于复杂模型而言,其构建公式的有效性就成为实现参数化设计的基础;

3、基于规则的变量化设计,前面两种方法在实际应用中很难真正实现,出于实用的考虑,人们首先建立基本规则库,利用人工智能方法进行推理并最终得出约束条件。例如,对于两个实体而言,系统内置了有关实体位置参数的规则,通过推理即可得出实体间的相对位置关系(对于直线段可能就是平行、垂直、共线、相交或其它情况)。实际上,该方法目前仍是参数化设计的研究热点之一;

4、基于特征的参数化设计,从视觉上看,特征指模型在某些观察角度下所呈现出的特殊现象。而在参数化设计中,特征包括了与其相关的实体、参数和关系式,特征是相对于变量或规则的更高级别的语义描述,例如描述物体表面有一处“凹陷”,这就是一种特征。但是,良好的基于特征的设计需要精心设计特征库。

三、参数化设计的应用现状

尽管参数化设计目前已经深入工业设计和制造业,但最令人瞩目的则是其在建筑设计领域中的应用。应注意的是,由于建筑设计本身带有艺术气质和时代特征,引领前端的通常都是著名研究机构或设计公司,而更多的从业人员仅仅是采用稍成熟方法满足需求即可,因此参数化设计在该领域存在着两种截然不同的应用思路。

毫无疑问,最早提出的变量化编程已经为大多数CAD建筑设计师所知了,如AutoLisp。另一方面,参数化设计在这一阶段的主要工作是实现2D和3D的协同设计,具体方法可以是时序法或变量几何。在这期间许多计算机科学家努力向领域专家们推荐各种工具和应用,如William Mitchell于1987年推出的《The Art of Computer Graphics Programming. A structured introduction for Architects and Designers》,书中使用了流行的Pascal语言描述建模脚本。

在许多人看来,上述编程建立三维模型的应用过于抽象,可行性极低。事实亦如此,变量化编程目前已经成为参数化设计领域的非主流技术,而对我们来说更加常见的可能就是诸如ArchiCad或3DStudio Max:直观的交互式界面,以及大量参数输入对话框,该模式至今仍占据绝对优势。后者的缺点是,用户很难针对复杂模型整体进行参数化考虑,除非建模阶段存在非常精妙的参数设计,而这往往是不现实的。一种解决方法是确保层次化建模,例如K. Martini试图采用面向对象程序设计中的层次化类结构模拟建模过程。由此我们可以联想到一系列层次化方法,如集合、树等;另一方面,考虑到层次化建模的可行性尚未得到证明,我们还可以考虑使用图表示参数化设计中实体之间的约束关系。针对这方面的讨论目前仍是非常开放的问题。

四、艺术创作中的参数化设计思想和实践

首先,这里所说的艺术创作实际上包括前文提到的工业设计;另一方面,我们希望能在更多的艺术设计领域引入参数化的元素,其目的在于:1、大部分现有的艺术创作实际上与商业应用相关,原创效率和大规模应用能力将成为关键的风险因素;2、参数化设计为创作前所未有的艺术形式提供了新途径,而并非字面上的对艺术创作施加“约束”的意思。

达芬奇的《维特鲁威人》堪称把建筑学和人体解剖学相结合的传世名著,而这种艺术上的联系同样也反映到现代CAD/CAM技术中。香港中文大学的王昌凌(Charlie C. L. Wang)就在现代服装设计中引入参数化设计技术,并提出了一种新的基于人体特征的参数化设计方法。该方法从人体点云中提取相关特征,并在参数化模型(注意这里的参数化与“参数化设计”的区别)的基础上使用参数化设计创建新的模型。其中人体模型的参数化包含两个主要阶段,首先使用激光扫描仪获取人体点云,根据语义特征提取并重构人体的特征线框;其次,对人体网格曲面的对称信息进行建模,在特征线框上通过曲线插值生成Gregory曲面片。然后利用一种体素算法在G1连续的曲面上添加细节点云;最后再调整网格曲面的对称性。在完成人体模型参数化后,根据用户输入参数采用参数化设计方法把样例模型映射至参数化模型中,同时对样例模型的选用需依据相关策略进行。与普通的数值插值函数相比,该方法具有较低的出错率,能够保证参数化模型的正确性。基于正确的参数化模型,即可在人体上自动导入使用参数化设计方法在样例模型上设计的服装模型。

事实上,关于服装的参数化设计在最近十年已成为CAD的热点之一,并取得了一些研究成果,但仍鲜见规模化应用。而对于参数化设计技术本身而言,能否继续扩展其应用范围、并在此过程中完善自身的方法论,将成为CAD发展的一个未知数。不过,进一步扩展出有效的杀手级应用则是当务之急。

Comments