- 1 .Google O3DAPI:开发WEB3D的API

-
本周最大的行业新闻,除了Sun被Oracle收购,就是Google发布O3DAPI了,下面就详细介绍下该项目的内容:
GoogleO3DAPI是Google发布的开源WEB3DAPI,与GoogleMapAPI和GoogleEarthAPI不同的是,O3DAPI不是为开发者提供了图形或者地理数据服务,而是提供了一个开发WEB3D应用的类库和浏览器插件(runtime),其最大的意义在于为业界提出了一个新的WEB3D的标准,开发者使用javascript就能开发性能良好、渲染效果出色的WEB3D应用,而且是跨浏览器跨操作系统的。
在这里可以下载安装程序O3DSetup.exe,IE7下载不下来,不能弹出保存窗口,Chrome、Firefox没问题;在技术概览O3D Technical Overview我们可以看到这项技术的架构图,O3D应用通过调用O3DAPI,继而实现插件与底层图形类库OpenGL或者DirectX3D的交互,这些类库能利用显卡(GPU)的资源,从而实现高效的WEB3D渲染。
这里是开发指南,介绍了O3D编程的核心概念和常见任务;想快速体验O3D的效果就到实例浏览中挨个查看,每种编程语言都有HelloWorld,O3D也有Hello world,可惜在IE7下运行出现错误:Got error 126 loading d3dx9 library(装了DirectX9后正常),而在FF和Chrome下正常,查看CPU占用,发现不到10%,窃喜,然后查看模型旋转渲染效果Rotating a model发现CPU占用竟然在20%以下,细致的渲染效果让人惊叹,同样带物理引擎渲染的Box2DJS实例运行时,CPU在40%以下;我最喜欢的3D鼠标旋转地球Google trends visualizer运行时的CPU也在30%以下,整个实例的性能测试都让人很满意,绝对能让大多数用户接受。
这篇文章:Google试图使用O3D进入WEB3D领域,是目前能找到的唯一一篇业界评论文章,文章提供了一些更为广泛的消息,比如Google希望最终能将这项插件技术直接嵌入到浏览器中(Chrome是极有可能了),文章简要的总结到:O3D提供了一个接口来让开发者基于Javascript的web程序并能直接跟图形芯片打交道,从而意味着可以开发更好的游戏和其他应用。
从O3D的邮件列表的活跃程度能反映出这项技术的轰动性,邮件列表的一个话题让我们更加认识到了这个技术的价值:Why another standard,有位开发者提到,我们已经有了诸多web标准,比如VRML, X3D, 3DMLW, Canvas 3D, Java 3D...,为什么还要O3D,一位开发者作了回答,现原文摘录:
RML2过时10年多了;X3D过时7年多了;Java3D过时5年多了,而且不被JRE浏览器插件支持;3DMLW从来都没听说过;Flash没有3DAPI,仅仅是软件方式的2D多边形栅格器,脚本执行速度慢;shockwave封闭源码,仅有一个昂贵的创作工具,浏览器插件从来都没有被安装过;Silverlight跟Flash情况一样,而且更糟,使用来自微软的.net;Canvas3D究竟有多少浏览器能支持?安装率有多少,我猜不到5%。
我希望Google能将O3D作的更好,但是如果Adobe足够聪明的话,他们就应该集成3DPDF和Shockwave的特色到Flash中并增强它,Flash仍然有最大的安装数量;当大多数人有很强劲的显卡时甚至3D桌面时,用AS3来进行正常的3D渲染确实太慢了,而且使用2D多边形(软件方式的栅格化)配合深度排序来模拟3D渲染的这种方式很愚蠢(例如Papervision3D)。我甚至认为15年前的3D应用Amiga 1200/060都能超过今天Papervision在高端PC上的表现(看看这个例子:http://breakpoint.untergrund.net/download.php?dir=2009/amiga_demo/Videos/&file=08_034-nature-traktor-jesuschristmotocross.mp4)。
英文原文内容:
(VRML(2): outdated since >10 years;
X3D: outdated since >7 years;
Java3D: outdated since >5 years, not supported by JRE browser plugin;
3DMLW: never heard of this one;
Flash: no 3D API, just software 2D polygon rasterizer, slow scripting;
Shockwave: closed source, just one expensive authoring tool, browser plug-in nowhere installed;
Silverlight: same as Flash, only worse, .net crap from M$;
Canvas 3D: supported by how many browsers? installation base - my guess: 5%;
I hope Google is doing better with O3D. But if Adobe is smart enough,they integrate the features from 3D PDF and Shockwave into Flash and enhance it. Flash still has the biggest installation base. It's just to slow to do descent 3D rendering in ActionScript3 and it's silly to use 2D (software rasterized) 2D polys with depth sorting (stuff like Papervision3D), when most people have powerful GPUs and even 3D desktops. I think even 3D on a 15 year old Amiga 1200/060 can outperform Papervision on todays high-end PCs (have a look at winning Amiga Demo 'Jesus Christ Motocross' just released at Breakpoint 2009! Link: http://breakpoint.untergrund.net/download.php?dir=2009/amiga_demo/Videos...)
前面保留的英文原文是想让大家更原汁原味的体会目前3D技术的状况,以及Flash3D的不足,从而认识到Google的WEB3D标准的意义。
编者注:O3DAPI的提出让大家对WEB3D以及WEBGame的前景顿时明朗起来,但是仔细查看过那些实例后你可能会有点绝望,这么复杂的3D编程,都通过js来实现,会累死的,O3D技术真正的推广,如果抛开浏览器安装普及度,很大程度要依赖于相关类库的丰富,没有更加简化的API和控件,没有社区的积累,是没法真正成为标准的;另外,作者对PV3D的贡献抹杀太严重了,PV3D已经在达到了Flash软件3D渲染的极限了,相信在FP10环境下PVX会有惊人的表现,该作者看过新版后会作出不同的评价。
- 2 .检测位图数据的边缘线

-
原文地址:http://www.sakri.net/blog/2009/04/13/extract-shape-outline-points-from-bitmapdata/
作者看来是一位资深的Flex开发者,他想要完成动态文本的3D渲染(不嵌入字体的情况下),这样他面临的一个问题就是需要获取文字的边缘线点阵集合,然后通过这个集合生成文字的形状。一个比较野蛮(或变态)的做法是遍历文字的BitmapData的每一个像素点,看它是不是透明,但这样仍然没有获取到一个有意义的边缘的点阵集合。作者提出了一个思路并付诸实践,就是:建立9个像素点的正方形,按照一定的算法沿着文字的路径走,根据遮挡关系判断路径,并将路径记录下来。如下图所示:

最终可实现下面的效果:

- 3 .Flex基础:ArrayCollection

-
原文地址:http://blog.flexdevelopers.com/2009/03/flex-basics-arraycollection.html
这是一篇讲述Flex基础知识的文章,向读者介绍了Flex中ArrayCollection的概念和用法。如果你是Flex的初学者,或对ArrayCollection不太了解,建议仔细阅读这篇文章。
在Flex中,开发者用的最多的数据集合类型应该是Array,它确实非常有用,特别是它提供的检索数据的方式,是非常有效的数据存储与索引的方式。这样说起来,Array应该也适合于作为列表基础组件的数据源。当然了,实际上不是这样的。在数据绑定方面,Array是个非常Poor的选择。幸亏Flex还提供了另外一种数据集合类型-ArrayCollection。ArrayCollection支持Array的所有特性,并且添加了很多自身独特的特性。 语法手册中对ArrayCollection的解释:
ArrayCollection 类是将 Array 公开为集合的封装类,可使用 ICollectionView 或 IList 接口的方法和属性进行访问和处理。对 ArrayCollection 实例进行操作会修改数据源;例如,如果对 ArrayCollection 使用 removeItemAt() 方法,就会删除基础 Array 中的项目。
使用方法示例:
<mx:ArrayCollection Properties source="null" />
- 4 .JigLibFlash 物理引擎和Away3D试验

-
大家可能知道Flash3D引擎PV3D以及Away3D,以及2D物理引擎Box2DFlash,但是说到Flash3D物理引擎,大家可能就不太清楚了,这篇文章用最新的Flash3D物理引擎JigLibFlash和Away3D作了个小小的例子,并对JiglibFlash简单作了介绍。
作者想作些真正的3D物理应用,但是没有合适的Actionscript3物理引擎,目前仅有两个选择,一个是WOW物理引擎,一个是JiglibFlash物理引擎; WOW物理引擎是一个基于粒子的引擎,意思是每个顶点都有它自己的物理属性;而JigLibFlash是一个基于刚性体的物理引擎,你是跟基础的类型例如盒子和球体打交道来生成一个粗糙的3D物体,基于刚性体的物理引擎要比基于例子的物理引擎快的多,因为对于同样一个物体,刚性体用一个表面作碰撞检测,而基于粒子引擎是要用点作碰撞检测(以立方体来说,刚性体是一个整体有物理属性,而粒子引擎有8个点有物理属性)。
目前JigLibFlash支持主流的两种3D引擎,Away3D和Papervision3D, Jiglibflash将物理引擎设计成适配不同3D引擎的物理引擎,只要是能实现它的jiglib.plugin.AbstractPhysics接口,就能作为一个Jiglibflash物理引擎实例来使用,详细情况见这里的说明;该博客发表时,Jiglibflash还没有API文档,博客作者认为目前的这个从C++迁移过来的物理引擎还不够好,bug多,文档少。
其实到目前来说,最新的官方API文档已经在24号发布了,或许是引擎的开发者认为该补充些缺少的东西了,笔者认为,该引擎还是很有发展潜力的,只不过要解决性能上的问题,还需要时间来完善并补充些文档和教程,毕竟是刚开始几个月的项目,PV3D作成现在的规模还用了2年多的时间呢。
- 5 .Autodesk在线室内设计软件Dragonfly(蜻蜓)项目

-
本周最值得推荐的Flex应用要属来自AutoDesk的在线室内装饰设计软件Dragonfly项目了,该项目目前还在测试阶段,正在接受广大用户的测试和反馈;进入网站的主页看到的是对产品的概要性介绍,点击主菜单的DESIGNER进入创作场景,有三种模式可供选择:从设计画廊中选择已有案例作为开始;从一个配有家具的房间开始;从一个空房间开始;这三种模式分别对应不同水准的设计人员,如果是专业的室内设计人员会从零开始,如果是不懂室内设计的当然是从设计画廊中选择了,这种向导模式充分考虑了不同基础的用户情况,都可以在这个系统中快速上手。
有意思的是整个网站除了创作区是Flash的外,其余界面均为HTML页面,与后端的通讯也是利用Ajax技术实现,而且画廊中的HTML模版选择窗口也跟创作区的Flash设计模式选择窗口风格一致,都是透明的标题窗口,从画廊到创作区的切换也没有任何刷新,从而使整个网站浑然一体,又大大降低了文件下载尺寸;像这样将Flash和HTML/AJAX结合的如此紧密而且不留痕迹,非常难得。
再讲讲创作区的设计,左边是类似photoshop的标准的工具栏,下面是可伸缩到底部的室内建筑格局的主工具面板,右侧是家具和电器选择面板,通过两级过滤器可以将具体的分类加载进来,因为分类比较多点击一级分类会载入下级分类,而且还有历史记录选择功能可以找回前面的选择项,这个功能点对于这么复杂的内容选择非常重要;创作区的2D和3D场景切换更是该软件的亮点之处,据称是使用了Away3D技术;从制图设计角度讲,提供了拖拽时的尺寸数据反馈和位置合适度反馈,这充分反映了作为业界顶级制图软件公司的专业水准。
整个应用除了有时拖拽操作稍显迟钝外,界面切换和数据载入均响应较快,内存占用也不算高在150M左右(Chrome),CPU占用率在用户操作时稍微偏高些,总体来讲操作反馈很直观,无右键菜单简化了操作而且回避了编程上的复杂度,唯一不足的是,右侧的家具和电器面板在伸缩时都会重复载入数据,从资源消耗的角度考虑有点浪费。
总体来说,这个应用非常成功,如此复杂而且结合3D的应用能做到这样的效果和优越的性能,属于目前Flex应用中的一流水准了。
- 6 .使用增强现实制作大脚野人电影

-
这个网站又是一个使用Flash增强现实技术的网站,只不过跟其他网站不同的是,这个网站可以将你选择的不同动作编辑成电影片段,然后共享给其他人,从而实现了你的3D电影创作的愿望;好下面就来体验一下吧:
登陆网站,需要几分钟的时间等待应用下载,黑暗中走来了大脚野人,是不是很有神秘感呢?下载快要完成时,大脚野人就会带你到电影工厂了。
然后观看视频演示,你就能马上明白该怎么作了!首先需要下载一个电子文档,这是摄像头识别的标记:一个野人的脚印。像这种不规则的识别符号还是很少见的,将它打印出来放在桌面上,让摄像头对准它,然后点击网站上的Get Started就可以进入创作界面了,主界面左侧有野人的不同表情和动作供选择,拖拽或者双击表情或动作可以将其应用到野人身上,点击Record按钮后,你可以旋转放在桌面上的野人脚印来让野人随着你动,这样就将野人的动作记录了下来,然后可以保存并通过邮件分享给你的电影给其他人了,是不是很有趣呢?
美中不足的是,电影片段只能记录6个镜头,不能无限制加下去,这可能也是为了节省资源和性能上的考虑吧,在Tips中有一些小窍门来改善操作效果和电影品质的不可不看!正如网站名称一样,活生生的大脚野人,通过技术上的进步可以将你的梦想实现,这不失为一个很好的创意,如果你有小孩子,那么给他作这样的游戏是不是会让他对电脑和原始人产生无尽的遐想呢?
- 7 .Google Chrome 实验站点(Javascript效率测试)

-
地址:http://www.chromeexperiments.com
测试Google浏览器JavaScript的效率,同样也可以用于对比不同浏览器到Javascript效率。
优秀测试实例,http://www.chromeexperiments.com/detail/monster/
充分展示了Google Chrome浏览器的javascript效率高过Firefox很多。
详细内容,分别用firefox以及Google Chrome打开这个测试
- 8 .3D图片浏览器最终版发布

-
地址:http://blog.arnomanders.nl/index.php/archives/imageviewer3d-final-release/
这是一个非常酷的3D图片浏览器(它的名称叫ImageViewer3D),作者将最终版的示例以及组件下载地址公布了出来,它可能还有一些小问题或Bug,但作者要投入精力去做其它的事情,所以不能做到尽善尽美,虽然如此,这其实已经是一个非常强大的应用了。
它的特性:
- 滑动显示
- Flickr搜索
- 从XML中载入图片数据
- 支持分页
查看示例
组件下载地址:http://www.arnomanders.nl/blog/upload/imageviewer3dfinal/component/imageviewer3d-final-component.zip
- 9 . Adobe Flex3:高级图例说明组件

-
原文地址:http://srirangan.net/?p=119
这是一款用于Adobe Flex3的高级组件,它用于给图表添加一个图例说明,并且它和普通的图例说明组件的区别是:
- 图例的原件以CheckBox为基础,可以选择
- 可以控制图表中相应数据项的样式
使用方法:
<visualization:AdvancedLegend dataProvider="{lineChart}"/>
这样的用处在于,你可以让用户通过点击图例说明中的对应项目来控制图表的显示,比如图表有A,B,C三个显示数据的折线,那么你就可以通过图例说明中的对应选择(a,b,c),让折线中的某一条高亮显示。这对用户来说是非常有用的,特别是在数据量很大的情况下,用户可以轻松从复杂的数据图表中筛选自己需要的数据。这实际上是一种非常有效的数据过滤机制。
- 10 .为Datagrid添加合并单元格

-
地址http://flexoop.com/2009/03/adding-colspan-to-a-datagrid/
熟悉网页上HTML的朋友可能知道,HTML中的表格是可以合并单元格的,即:若干个单元格合为一个进行显示和渲染数据。那么Flex中能不能实现这样的效果呢?作者为我们探索出了一种方法,分析如下:
- 将原有Datagrid拆为两个
- 第一个Datagrid作为表头,分为若干列,第二个Datagrid则只保留一列
- 给第二个Datagrid使用Itemrenderer
- Itemrenderer的内容为若干显示元素的合集,比如第一个元素为一个Datagrid,第二个元素为一个Text组件,Datagrid分为若干列,与parentDocument中的Datagrid表头相一致,第二个Text组件则宽度为100%,这里只是示例,实际上你可以再添加其他元素
综合这四个步骤,就可以实现Flex中可合并单元格的Datagrid,详细步骤可以看原文。
不过编者认为,这仍然不是一个好的解决方案,代码量和标签组织结构都变复杂了,增加了很多冗余的工作来处理自定义的显示,或许Flex中的高级表格组件(AdvancedDataGrid)是一个不错的方案。