Archive

Posts Tagged ‘3d’

Grandpa SDK 0.81 发布

May 11th, 2011 No comments

下载Grandpa SDK 0.81 for Windows

访问Grandpa主页

主要修改:

  • 添加通用样条曲线采样器,支持float, Vector2, Vector3, Vector4, Quaternion等数据类型的样条插值
  • 完善DemoCamera类,支持左手系或右手系坐标,支持z轴向上或y向上
  • 添加摄像机动画演示工程CameraDemo
  • 整理完善数学库

Categories: 程序/算法 Tags: , ,

Grandpa SDK 0.8发布

March 20th, 2011 No comments

下载Grandpa SDK 0.8 for Windows

访问Grandpa主页

主要修改:

  • 添加Viewer(模型查看器)工程
  • cpu蒙皮效率提升约35%
  • Vector4现在派生于Vector3,Vector3派生于Vector2
  • 支持动画随模型一起加载( 默认为第一次播放时加载)
  • 支持attachment模型和主体模型动画同步
  • 提高Xml加载效率
  • 加入DemoCamera类,替换原来的DXUTCamera
  • IModel接口分解为IPartFunctions,IAnimationFunctions和ILodFunctions

 

Categories: 程序/算法 Tags: , ,

D3D9的Pixel和Texel(续)

December 13th, 2010 No comments

前一篇只说了屏幕坐标和纹理坐标一一对应,也就是说没有缩放的情况。实际上有时候会需要把图素进行缩放后渲染,举个例子,把3×3像素的纹理(注意,不是整张纹理3×3,而是取一张纹理上3×3大小的一部分)渲染成屏幕上的4×4像素大小,如下图。和以前一样,红色的线框代表纹理像素的边界,灰色线框代表屏幕像素的边界,由于纹理被放大了,所以只有在图素边界处二者才是重合的。

这里有个不容易觉察到的问题,估计已经让很多程序员抓狂过,也就是放大后的图素的边界像素上会多出一些来历不明的颜色,放大倍数越大就越明显。实际上,这是采样到边界以外的纹理像素了。

Read more…

Categories: 程序/算法 Tags: ,

Grandpa Demo on iPhone

July 6th, 2010 2 comments

Grandpa从设计之初就定位于跨平台,渲染API无关的库。核心代码仅依赖c++标准库,理论上可以在任何平台,用任何(基本)符合c++标准的编译器编译。

但是这次还是碰到了一些问题,主要还是VC用的时间太长了,没有意识到某些特性实际上是非标准的,例如:

  • hash_map头文件的位置不同。大家都知道该容器是非标准的,在vc下该头文件和其他容器在一起,而gcc下在ext子目录中
  • gcc警告最后一行非空(也就是说源代码文件最后一个字符必须是回车,标准的确是这么规定的),vc不会警告
  • vc允许只声明enum,gcc不允许
  • gcc没有“安全版”(带_s)的字符串处理函数

另外,Mac OS X(以及Linux等其他Unix系的操作系统)是用utf-8表示unicode,而Windows则采用utf-16,这一点也引起了一些小麻烦。

还有一个很讨厌,gcc居然不认识utf-8的bom(ef,bb,bf)。导致我所有的源代码文件都要改为multibytes编码

好在这些都是小问题,花了不到一天时间就都解决了。

特别感谢张志鹏同学,帮我把原来基于d3d的Demo移植到了Opengl es上。

另外从今天开始,Grandpa SDK开放svn更新,地址为 Http://www.multi-crash.com/release

推荐使用TortoiseSVN

Categories: 程序/算法 Tags: , ,

骨骼动画的数据压缩(二)

June 13th, 2010 4 comments

上一篇遗留了一个问题没有说完,就是关于绝对变换和相对变换。我们的骨架一般是以树形结构存储的,一个骨骼会有一个父骨骼(根骨骼除外)和若干个子骨骼。所以对于骨骼的变换我们可以存储在模型空间中的绝对变换,也可以存储相对于其父骨骼的相对变换,二者是可以相互转换的。

用相对变换形式存储的好处主要是便于拆分成不同类型的变换从而使动画插值成为可能;而保存绝对变换的好处首先是效率较高,因为在蒙皮计算的时候我们真正需要的是骨骼的绝对变换,如果保存的是相对变换就需要根据骨骼的父子关系先计算出绝对变换矩阵,每块骨骼都多出一个矩阵乘法的开销。另外直接保存绝对变换还能避免因为逐层相对变换引起的累积误差。

言归正传,我们继续来看动画数据的压缩,前文已经把200k的数据压缩到60k左右,还有办法继续压缩吗?

用过Max(Maya和XSI不太熟悉,但想来也应该差不多,下文只讨论Max)的同学会发现,虽然我们的动画定的是30fps的标准,但是美术实际摆放的关键帧要远远低于这个密度,对于简单的动画,某些骨骼可能在两秒的时间内只有3~4个关键,其它时间的骨骼方位实际上是导出时Max自动插值得到的。于是小算盘就开始打了,既然我们保存的骨骼关键帧大部分都是Max自动生成的,那么我们能不能只保存真正由美术摆放的关键帧,剩下的也象Max所做的那样自动插值出来呢?如果可以的话,无疑将再次大幅减小动画文件的尺寸。

Read more…

Categories: 程序/算法 Tags: , ,

骨骼动画的数据压缩(一)

June 12th, 2010 No comments

这里说的骨骼动画数据,是指美术用Max,Maya或者XSI之类的3d工具制作的角色动画,通常要导出成引擎可以读取的特殊格式,为游戏所用。对于目前越来越强调动作感的网络游戏来说,动画资源占整个安装包尺寸的比例在不断上升,动画数据的压缩也在变得原来越重要,更不用说采用大量实时渲染过场动画的次世代Console游戏了。

每个引擎都有自己独特的动画文件格式,但里面的内容都大同小异。所谓动画,就是一系列关键帧的集合,每个关键帧可以描述了角色整个骨架的完整姿态信息,也就是每一块骨骼在3d空间中的位置和方向。

假设我们有一个包含50块骨骼的骨架,采用30fps的帧率,一个长度为两秒的动画需要占用多大的空间呢?我们来计算一下。我们知道空间的方位可以用一个矩阵来描述,一个矩阵包含4 x 4 = 16个浮点数,也就是64字节;我们有50块骨骼,那么每个关键帧就需要50 x 64 = 3200字节,另外关键帧还需要一个4字节的时间值,那么就是3204字节;两秒的30fps动画一共包含60个关键帧,于是可以算出最终的大小是3204 x 60 = 192240字节,不到200k的样子。这就是未经压缩的数据大小,当然这里忽略了一些诸如骨骼名字之类的信息,和我们要讨论的动画压缩关系不大,就不算在内了。

Read more…

Categories: 程序/算法 Tags: , ,

D3D9的Pixel和Texel

May 19th, 2010 2 comments

名词解释:Pixel–屏幕像素;Texel–纹理像素

在使用d3d来渲染GUI元素时,可能很多人都碰到过一些让人抓狂的灵异问题,例如整个界面变模糊,边缘偏差一个像素,甚至在不同显卡上的表现还不一样……

这一般都是Pixel和Texel的对应出了问题导致的,界面元素的渲染的主要特点是一般是要求屏幕像素和纹理像素严格一一对应,这个在2d绘图中看来很自然的事,到了3d环境下似乎变得不那么简单。

d3d的特点是确定投影范围(记住渲染UI要使用正交投影)以后,“整数位置坐标”对应的是屏幕像素中心,而“整数纹理坐标”对应的却是纹理像素的边缘,这就是一切罪恶的根源。怎么理解这句话呢?请继续往下看……

一般来说渲染GUI时我们会把视口大小设置为和背缓分辨率一致,这样3d坐标的单位“1”就和屏幕上1个像素对应;而纹理坐标则用待渲染图元的像素尺寸占整张纹理像素尺寸的比例来确定。这里面有什么问题呢?

Read more…

Categories: 程序/算法 Tags:

Grandpa SDK 0.7发布

February 25th, 2010 No comments

下载Grandpa SDK 0.7

Grandpa主页

主要修改:

  • Max插件能自动保存最后一次成功导出的设置
  • 添加IVertexStream接口,顶点数据分为静态和动态两个stream
  • 完善IEventHandler接口,支持任意用户自定义动画事件
  • 添加IProperty接口,用户可以在模型,部件和材质文件中添加自定义属性
  • 添加ISkin接口,支持GPU蒙皮

详情请见更新历史

Categories: 程序/算法 Tags: , ,