HDR格式的编码与解码
[ 2007-07-24 16:39:53 | 作者: Admin ]
原文出处:
http://www.graphixer.com.cn/ShowWorks.asp?Type=3&From=HomePage&ID=20
RGBE格式的图象是浮点数据的一种压缩形式。其中RGB指定该像素的颜色,E指定像素的暴光度。不同的暴光度决定了像素不同的亮度。RGBE的编码和解码方式如下。 ...
阅读全文...
http://www.graphixer.com.cn/ShowWorks.asp?Type=3&From=HomePage&ID=20
RGBE格式的图象是浮点数据的一种压缩形式。其中RGB指定该像素的颜色,E指定像素的暴光度。不同的暴光度决定了像素不同的亮度。RGBE的编码和解码方式如下。
编码:
maxComponent = max(FloatSource.R,
FloatSource.G,
FloatSource.B );
fExp = ceil( ln(maxComponent)/ln(2) );
Encoded.R = (unsigned byte) (FloatSource.R / Power(2,fExp)*255);
Encoded.G
maxComponent = max(FloatSource.R,
FloatSource.G,
FloatSource.B );
fExp = ceil( ln(maxComponent)/ln(2) );
Encoded.R = (unsigned byte) (FloatSource.R / Power(2,fExp)*255);
Encoded.G
阅读全文...
廉价的水也要做出最好的效果
[ 2007-07-16 17:04:15 | 作者: Admin ]
这是一种低成本的水, 适合比较低端的显卡.
由于水面是一个平面, 会与地形穿插相交, 必然会在相交的地形边缘形成一片很锋利的边界, 很难看
通过一些技巧, 我实现的对水岸线边缘的弱化. 为这种低成本的水增加了更好的效果.
通过动态生成纹理, 然后通过水的深度决定当前水面的alpha值, 最后将此alpha图导出, 形成edge map.
留图纪念:
www.azure.com.cn
由于水面是一个平面, 会与地形穿插相交, 必然会在相交的地形边缘形成一片很锋利的边界, 很难看
通过一些技巧, 我实现的对水岸线边缘的弱化. 为这种低成本的水增加了更好的效果.
通过动态生成纹理, 然后通过水的深度决定当前水面的alpha值, 最后将此alpha图导出, 形成edge map.
留图纪念:
www.azure.com.cn
静态阴影烘培 + 地形高光, 留图和视频纪念
[ 2007-07-12 20:10:03 | 作者: Admin ]
这段时间的工作还是颇有成效的, 在一个本不可能加入阴影层的地形结构上成功的添加入了阴影层,
并实现了程序上的离线渲染过程.
渲染阴影的过程无非是光线跟踪, 没有什么难度, 最烦人的是纹理的像素坐标转世界坐标, 由于根本就不知道前作者是怎么画的, 必须不段的摸索和尝试才能确定其正确的绘制顺序. 十分费脑筋.
下面发张图两图留念:
还有两段演示高光和decal系统的视频.
[swf]http://tv.mofile.com/cn/xplayer.swf?v=LM2AEDYQ&p=http://cache.mofile.com/tv/static/picture/u13/Disk1/ctc/20...
阅读全文...
并实现了程序上的离线渲染过程.
渲染阴影的过程无非是光线跟踪, 没有什么难度, 最烦人的是纹理的像素坐标转世界坐标, 由于根本就不知道前作者是怎么画的, 必须不段的摸索和尝试才能确定其正确的绘制顺序. 十分费脑筋.
下面发张图两图留念:
还有两段演示高光和decal系统的视频.
[swf]http://tv.mofile.com/cn/xplayer.swf?v=LM2AEDYQ&p=http://cache.mofile.com/tv/static/picture/u13/Disk1/ctc/20...
阅读全文...
今天为一个简单的问题折腾了一天
[ 2007-07-05 22:08:59 | 作者: Admin ]
今天准备将地形块的顶点数据复制一份, 做一个PASS来渲染阴影层, 可以最后画出来的地形和原地形有很严重的z-fighting 问题, 这个都不是什么问题, 我本以为通过调整 depth bias 就可以解决, 却发现怎么设置都解决不了z-fighting, 总是以为是渲染队列的问题, 一直从早上折腾到下午, 简直是头一个大. 晚上大家都要去小肥羊吃东西. 快到下班了, 看着那个问题一筹莫展, 大家都准备出发了, 我于是我最后用 NVPerfHUD 把 d3d hook 了一下, 看看有没有什么头绪, 下班的最后一分钟我终于发现了,我新写 绘制顺序与原地形不一样, 即
有四个顶点
P1 P2
P4 P3
组成的一个Quad, 原场景是( P1, P2, P3 ) (P1, P3, P4) 来构建这个QUAD的,
而我呢, 是 (P1, P2, P4), (P2, ...
阅读全文...
有四个顶点
P1 P2
P4 P3
组成的一个Quad, 原场景是( P1, P2, P3 ) (P1, P3, P4) 来构建这个QUAD的,
而我呢, 是 (P1, P2, P4), (P2, ...
阅读全文...
水体裁减体的生成与水体的裁减(原创)
[ 2007-07-01 00:02:01 | 作者: Admin ]
如有转载, 请注明出处:
http://www.azure.com.cn/
声明: 这种方法对于RTT方式实现的水面最适用,其他水面(纹理动画)并没有多大意义,请读者们注意。
我们当前游戏的水体其实就是一个大平面, 横插在整个地形上。
也许你会笑我,这样不是摄像机裁减不掉了吗?你不知道把水面分块吗?这样不是可以被摄像机裁减掉吗?你这样说其实没有错,但它针对那种纹理动画的水面是有效果的,对于那种RTT的水面的性能提升几乎为0,为什么?让我来解释给你听。
RTT水面的主要性能消耗,主要集中在两个方面。
如果你明白了这一点以后,我告诉你,如果你看到了你所谓的一块水,其实多渲染一遍...
阅读全文...
http://www.azure.com.cn/
声明: 这种方法对于RTT方式实现的水面最适用,其他水面(纹理动画)并没有多大意义,请读者们注意。
我们当前游戏的水体其实就是一个大平面, 横插在整个地形上。
也许你会笑我,这样不是摄像机裁减不掉了吗?你不知道把水面分块吗?这样不是可以被摄像机裁减掉吗?你这样说其实没有错,但它针对那种纹理动画的水面是有效果的,对于那种RTT的水面的性能提升几乎为0,为什么?让我来解释给你听。
RTT水面的主要性能消耗,主要集中在两个方面。
- 1. 多渲染一遍场景(渲染到纹理过程)
- 2. Pixel shader
如果你明白了这一点以后,我告诉你,如果你看到了你所谓的一块水,其实多渲染一遍...
阅读全文...
Decal (贴花) 系统完美实现, 留图纪念.
[ 2007-06-29 17:12:16 | 作者: Admin ]
其实 用 ManualObject 实现 Decal , 比传统的 Projective Decal 要好用,
其放大缩小都要比Projective Decal方便很多, Projective Decal还需要多PASS,
白白把地形渲染多遍, 而且decal大小还得通过复杂的计算.
通过对mesh适应地形的大网格, 在纹理内部偏移纹理坐标实现小网格内的适应,
就实现了mesh到地形的精确吻合, 不会发生一点的地形穿插情况.
使用ManualObject只会带来很少的性能损失, 当然你需要优化你decal的构造过程, 下面我留图纪念下:
贴了个商标
贴了个圣诞老人
...
阅读全文...
其放大缩小都要比Projective Decal方便很多, Projective Decal还需要多PASS,
白白把地形渲染多遍, 而且decal大小还得通过复杂的计算.
通过对mesh适应地形的大网格, 在纹理内部偏移纹理坐标实现小网格内的适应,
就实现了mesh到地形的精确吻合, 不会发生一点的地形穿插情况.
使用ManualObject只会带来很少的性能损失, 当然你需要优化你decal的构造过程, 下面我留图纪念下:
贴了个商标
贴了个圣诞老人
...
阅读全文...
总结今天使用 Ogre 遇到的几个Bug
[ 2007-06-27 20:03:46 | 作者: Admin ]
如有转载, 请注明:
http://www.azure.com.cn/
今天使用Ogre, 居然接连遇到了Ogre的几个Bug, 首先我声明我使用的Ogre1.2版本, 也许这些我所谓的Bug在1.4版本中已经修正了.
1. Entity::setVisible() 无效
平常使用setVisible() 总是屡试不爽, 感觉没有什么问题, 今天突然发现 setVisible() 居然无效了, 后来又发现对于有的Entity是有效的, 有的又无效了, 郁闷了半天. 后来发现只要Entity使用了非固定管线的材质(Shader), 其setVisible就没有作用了, 汗一个, 典型是那个Fresnel反射的水面, 无法通过setVisible()隐藏掉, 后来我使用SceneNode::detachObject()代替了. 再汗一个.
...
阅读全文...
http://www.azure.com.cn/
今天使用Ogre, 居然接连遇到了Ogre的几个Bug, 首先我声明我使用的Ogre1.2版本, 也许这些我所谓的Bug在1.4版本中已经修正了.
1. Entity::setVisible() 无效
平常使用setVisible() 总是屡试不爽, 感觉没有什么问题, 今天突然发现 setVisible() 居然无效了, 后来又发现对于有的Entity是有效的, 有的又无效了, 郁闷了半天. 后来发现只要Entity使用了非固定管线的材质(Shader), 其setVisible就没有作用了, 汗一个, 典型是那个Fresnel反射的水面, 无法通过setVisible()隐藏掉, 后来我使用SceneNode::detachObject()代替了. 再汗一个.
...
阅读全文...
如有转载, 请注明:
http://www.azure.com.cn/
通过一段时间对当前项目代码的阅读, 已经基本掌握其设计思想了.
之前场景渲染的效率一直是个大问题, 而且久拖不决.
这今天来潜心下来, 把场景渲染部分的代码集中修改了一遍,
下面总结下, 一些影响效率最大的问题.
1. 游戏中场景加载过程与编辑器场景加载过程未分离开.
编辑器和游戏是共用一套场景模块的, 在修改前, 我发现游戏中场景加载是使用的编辑器的那套过程, 由于编辑器将没有加载进来的对象都包装在一个CLASS中,这样是为了方便编辑(移动,旋转,缩放), 这样游戏中场景对象是成千上万, 如果游戏中每个对象也被CLASS封装了, 可想而知效率是多低下, ...
阅读全文...
http://www.azure.com.cn/
通过一段时间对当前项目代码的阅读, 已经基本掌握其设计思想了.
之前场景渲染的效率一直是个大问题, 而且久拖不决.
这今天来潜心下来, 把场景渲染部分的代码集中修改了一遍,
下面总结下, 一些影响效率最大的问题.
1. 游戏中场景加载过程与编辑器场景加载过程未分离开.
编辑器和游戏是共用一套场景模块的, 在修改前, 我发现游戏中场景加载是使用的编辑器的那套过程, 由于编辑器将没有加载进来的对象都包装在一个CLASS中,这样是为了方便编辑(移动,旋转,缩放), 这样游戏中场景对象是成千上万, 如果游戏中每个对象也被CLASS封装了, 可想而知效率是多低下, ...
阅读全文...
想到了一种对小植物渲染的终极优化方案
[ 2007-06-23 17:14:42 | 作者: Admin ]
如有转载, 请注明:
http://www.azure.com.cn/
也许这种方法有人使用过, 只是我孤陋寡闻了, 没有听说过.
希望大家不要见笑哦!!
今天午睡, 一直想着现在游戏的效率不高, 半睡半醒间, 突然想到了一种小植物的制作方案, 可以将大量小植物的材质都统一起来, 这样的话就算是不同样式的草都可以打包成一个 StaticGeometry , StaticGeometry 的作用就是将相同材质的物体打成一组, 用一个DP渲染出来.
众所周知, 现在图形显示卡, 对于多边形数已经不是瓶颈了, 一次渲染100W个顶点的模型, 和分10W次渲染10W个10个顶点的模型, 前者的效率要远远高于后者, 前者的DP = 1, 而后者的DP = 100000 (DP就是D3D一个API, DrawPrimitives() 的缩写) , 可是对于小植物的渲染来说, ...
阅读全文...
http://www.azure.com.cn/
也许这种方法有人使用过, 只是我孤陋寡闻了, 没有听说过.
希望大家不要见笑哦!!
今天午睡, 一直想着现在游戏的效率不高, 半睡半醒间, 突然想到了一种小植物的制作方案, 可以将大量小植物的材质都统一起来, 这样的话就算是不同样式的草都可以打包成一个 StaticGeometry , StaticGeometry 的作用就是将相同材质的物体打成一组, 用一个DP渲染出来.
众所周知, 现在图形显示卡, 对于多边形数已经不是瓶颈了, 一次渲染100W个顶点的模型, 和分10W次渲染10W个10个顶点的模型, 前者的效率要远远高于后者, 前者的DP = 1, 而后者的DP = 100000 (DP就是D3D一个API, DrawPrimitives() 的缩写) , 可是对于小植物的渲染来说, ...
阅读全文...

















