查看完整版本: [-- [CG]软件渲染器演示一枚 [更新v0.7] --]

-> 同人游戏创作/Doujin Games Workshop -> [CG]软件渲染器演示一枚 [更新v0.7] [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

glkasumi 2010-03-02 21:49

[CG]软件渲染器演示一枚 [更新v0.7]

=====================
[Update 03/07/2010] Version 0.7


renderer_0_7.rar


花了一个周末对软件渲染器主流程的每个函数都做了精简和优化,
主渲染流程的代码被压缩到了500行以下,
纯色渲染模式的FPS由40+上升到了90+(默认位置)
(光照模式基本没什么变化,基本上我只是将pow函数用查表代替了...)

将color buffer的数据类型由 FLOAT 回归到 UNSIGNED BYTE 效果提升明显...
另外开与不开编译器的优化选项渲染的图像会有差异......

程序的稳定性不可知...
所以增加了两种操作,保存的文件名为 “rot.txt”
<F5>       : 保存当前镜头位置以及物体朝向
<F7>       : 加载当前镜头位置以及物体朝向


可以和原先的程序比较一下...
=====================
 
 

嘛,计算机图形学的作业,软件模拟渲染流水线,周末修正了关键的光栅化bug后,暂时性地整理成一个DEMO玩玩好了...
虽说运行速度和GPU没有什么关系了,结果就是大家一起把速度降下来吧...
其实最方便的特性是把顶点着色和片元着色模拟出来了...

默认的渲染模式是双光源的逐像素Phong光照,附带线性的纹理过滤,FPS 一般在15左右,
按‘2’的话就是纯色模式,速度就比较流畅了,即使是离得很近的时候(而且因为包含了裁剪,所以不会出现意外的状况)


-----------------------------------
简单的操作说明
<1>        : Phong逐像素光照模型
<2>        : 逐面随机纯色
<3>        : 正常渲染 ( 启用深度测试和背面剔除 )
<4>        : 混合叠加

<J/L>      : 物体向左/右旋转
<K/I>      : 物体向外/里旋转
<U/O>      : 物体逆时针/顺时针旋转
<A/D>      : 镜头向左/右移动
<S/W>      : 镜头向后/前移动
<Q/E>      : 镜头向下/上移动


-----------------------------------

我自己所总结和应用的流水线大致是这个样子:



ryuka 2010-03-03 19:11
厚脸求code看

littlewater 2010-03-03 19:13
你这个时候钻出来- -??

话说我这里FPS稳定在 20 (默认位置)

做得不错- -+++

Advance 2010-03-03 21:00
牛逼
图形学什么的实在太难

littlewater 2010-03-03 21:08
引用第3楼Advance于2010-03-03 21:00发表的  :
牛逼
图形学什么的实在太难


这一点我也是- -0F 1F 的二位都是牛人啊- -

GL与BL之争 2010-03-03 21:31
于是用适合四核CPU+垃圾集成显卡的本本开发图形程序了啊!
能像1楼一样厚个脸皮么?

GL与BL之争 2010-03-03 21:48
根据链接的opengl32.dll与glu32.dll,以及程序执行就会冒出个dos控制台窗口的情况来YY,这是基于开放百合(OpenGL)的吧,激动地握手!
看来大家对于日趋臃肿、标准又漂浮不定的直接X(看看微软取的名,真是一点都不内涵)的怨念值都已经达到一定境界了啊!
话说LZ是将一帧图像用CPU渲染好以后,直接传送到framebuffer上的吧,直接涂鸦(DDraw)应该很容易,不知开放百合是如何操作的,别扁我,最后这个问题我是真的不知道,特求真相.....

Advance 2010-03-03 21:56
纯软件渲染就算你用GDI也不会跟DX和GL出来的有啥区别

GL与BL之争 2010-03-03 22:20
这个问题要去问微软了,从图上看gdi确实是像d3d一样直接与设备驱动接口打交道,不过猥琐的微软是不是从中搞了什么不可告人的鬼把戏就不得而知了。反正,纯软件渲染一直处理到帧缓冲的形成,至于帧缓冲如何送到显卡,理论上gdi、d3d都差不多,但潜意识似乎在说还是d3d效率高些,也更拉风些......

glkasumi 2010-03-03 22:22
引用第1楼ryuka于2010-03-03 19:11发表的 :
厚脸求code看 [表情]

嘛,我先把我的流水线设计框图放上来吧,基本和函数接口是一一对应的,
个人感觉目前为止矩阵变换(包括裁剪)和栅格化部分最难,主要是细节必须处理得当,不然结果肯定有偏差和瑕疵...
而接下来的光照渲染基本就是顺理成章的事情了(一个晚上就搞定了),需要处理的基本就只有插值了...

引用第4楼littlewater于2010-03-03 21:08发表的 :
这一点我也是- -0F 1F 的二位都是牛人啊- -

呃,其实感觉现在才刚入门...

glkasumi 2010-03-03 22:27
引用第6楼GL与BL之争于2010-03-03 21:48发表的 :
根据链接的opengl32.dll与glu32.dll,以及程序执行就会冒出个dos控制台窗口的情况来YY,这是基于开放百合(OpenGL)的吧,激动地握手!
看来大家对于日趋臃肿、标准又漂浮不定的直接X(看看微软取的名,真是一点都不内涵)的怨念值都已经达到一定境界了啊!
话说LZ是将一帧图像用CPU渲染好以后,直接传送到framebuffer上的吧,直接涂鸦(DDraw)应该很容易,不知开放百合是如何操作的,别扁我,最后这个问题我是真的不知道,特求真相.....


嗯对,没错,我在内存中开辟一段buffer用于模拟framebuffer,
最后再使用 glDrawPixels 将coloe buffer 里的内容填充到幀缓存中去...
使用GDI应该更直接一些,因为OpenGL最终调用的也是GDI,所以这种做法迂回了,
但是鉴于可能需要比较软件硬件渲染的结果以及熟悉程度等等原因,最后还是以OpenGL为最基本的渲染API了

Advance 2010-03-03 23:13
引用第8楼GL与BL之争于2010-03-03 22:20发表的  :
这个问题要去问微软了,从图上看gdi确实是像d3d一样直接与设备驱动接口打交道,不过猥琐的微软是不是从中搞了什么不可告人的鬼把戏就不得而知了。反正,纯软件渲染一直处理到帧缓冲的形成,至于帧缓冲如何送到显卡,理论上gdi、d3d都差不多,但潜意识似乎在说还是d3d效率高些,也更拉风些......


我来科普一下好了

GDI是一种大量使用了矢量描述的图形接口(Linux上的X11也是),它的抽象层需要尽可能兼容所有的显示设备。由于管理设备上下文和转换数据格式需要多层次的封装和大量的运算,在效率上自然没法跟独占显示设备和固定数据格式的DX相提并论了。GDI从结构上分为两部分,一部分是GDI32用户层接口,从WIN3.X开始就规范了GDI的绘图方式,这个接口沿用至今;另一部分是WIN32K内核层接口,通过显卡驱动提供的DDI接口将GDI请求提交给驱动,这些请求由描述绘图行为的矢量数据和色彩的点阵数据组成。GDI从来不会直接操作FB,实际上显卡驱动也可能将大部分绘图的指令(例如Bitblt、DrawPolygon)通过它与Miniport驱动的接口直接传送给GPU处理,只有在确实无法实现硬件加速的时候,才会利用WIN32K提供的绘图帮助类API进行软件渲染。这样做的好处是能够为显卡厂商提供灵活的硬件加速解决方案,而对于终端用户来说,他们可能希望将待渲染阶段的画面重定向到任何他们想要送达的地方,GDI抽象层为此提供了实现。因此这解释了RDP下不能运行D3D游戏的原因——与真实设备无关的GDI相反,DX是设备相关、基于硬件抽象层、内存控制级的图形接口,它是无法实现远程重定向的。
对于现在的显卡来说,由于多数提供了Bitblt硬件拷贝加速,从效率损失的情况来看,与DX相比主要是多走了一些GDI上层的处理。这种情况与D3D+窗口模式渲染2D非常相似。

zavayev 2010-03-03 23:45
居然在东镇也看到整渲染器的同好了~~~~握手握手~~~~
顺便赞一个先,我还没做过这么一个完整的软件渲染器……


ps: 刚才跟踪了一下发现GL还调用了ddraw.dll……233……

Wiksy 2010-03-04 05:09
软件渲染我只会写Ray tracer...(因为简单)

果然有完全流程的软件渲染很少见啊

GL与BL之争 2010-03-04 11:17
引用第12楼zavayev于2010-03-03 23:45发表的 :
居然在东镇也看到整渲染器的同好了~~~~握手握手~~~~ [表情]
顺便赞一个先,我还没做过这么一个完整的软件渲染器…… [表情]
ps: 刚才跟踪了一下发现GL还调用了ddraw.dll……233……


微软对待OpenGL也费了不少脑细胞啊,一方面要退散反垄断的怨念,一方面又要坚持D3D在Windows平台一统天下的目的,怎么办好呢?每次公布新版操作系统时吹得唾沫四溅地要为OpenGL提供更好的支持,然后暗地里在操作系统层面作一些不可告人的小动作,所以GL调用ddraw.dll也不是什么奇怪的事。最后就等着程序员自己得出结论:Windows平台下原来OpenGL效率这么低啊,而微软就可以说:Windows平台下,顺我者昌,逆我者亡了

ryuka 2010-03-04 19:08
看看图大概了解了.管线模拟硬件很全面呢 难点应该在扫描线算法下次有光线跟踪/辐射度/光子跟踪的程序也拿来晒吧

littlewater 2010-03-04 21:15
另一台机器跑了- -结果这样了:

那台机器配置很低…… P4 2G 256M 的…… 1.XX FPS

OPENGL 支持到 1.3,1.4只有 66%了……

glkasumi 2010-03-05 12:16
引用第16楼littlewater于2010-03-04 21:15发表的  :
另一台机器跑了- -结果这样了:
那台机器配置很低…… P4 2G 256M 的…… 1.XX FPS
OPENGL 支持到 1.3,1.4只有 66%了……


水水GJ~
我是使用浮点数储存色彩的(方便以后实现HDR什么的...),所以没有处理过饱和的情况,
但按理说OpenGL处理最终色彩时,会将颜色截取(Clamp)到 ( 0.0, 1.0 )之间,
所以我猜想那台机器处理过饱和的方式不一样,所以就实验了一下,不是截取而是只取小数部分,也即
color = color - floor( color );
结果截图就是 : 嘛,这就算是驱动实现的问题吧...我还是手动Clamp一下吧...

littlewater 2010-03-05 23:25
这台机器,忘记吧- -DX 7.0的显卡- -

glkasumi 2010-03-08 12:50
引用第18楼littlewater于2010-03-05 23:25发表的 :
这台机器,忘记吧- -DX 7.0的显卡- -

更新一个版本,纯色模式的效能提升比较明显;

PS : 将framebuffer的数据类型更换成unsigned char型之后,我把浮点数直接赋给了字符型,
结果又犯了和那台机器一样的错误,直接截取小数部分了...

ryuka 2010-03-08 18:34
如果G大真的要提升软渲染器的速度的话.除了对float要进行int化处理(要么用fix-point的float,要么对float到整型的转换使用IEEE格式的tricks).还要想想为什么显卡做这个步骤那么快.最大的原因是,显卡是并行执行的.那么做一个线程池或者用现成的线程池例如intel的TBB,把屏幕分成几块,每块做一个task扔里面,简而言之,就是改造扫描线算法,使其可并行化.

Advance 2010-03-08 19:19
嗯可以用CUDA
但是作为作业应该不要求速度上的优化和考虑特定硬件实现

littlewater 2010-03-08 19:20
其实FPS比较合理的使用方法是附上显卡型号= =+

那台机器以修正,而且性能达到你那FPS5-6了 ^-^

CPU型号 Intel P4 2.20G

littlewater 2010-03-08 19:23
引用第21楼Advance于2010-03-08 19:19发表的  :
嗯可以用CUDA
但是作为作业应该不要求速度上的优化和考虑特定硬件实现


AVC连CUDA都玩拉

可惜最近没有看到你发的有趣DEMO- -真可惜~

Advance 2010-03-08 19:35
最近在搞一个掌上终端产品比较忙所以没啥空玩儿,至于个人的project,除了为NTLER增加WIN7 x86/x64支持外应该暂时不会有其它动作

glkasumi 2010-03-08 20:09
引用第20楼ryuka于2010-03-08 18:34发表的 :
如果G大真的要提升软渲染器的速度的话.除了对float要进行int化处理(要么用fix-point的float,要么对float到整型的转换使用IEEE格式的tricks).还要想想为什么显卡做这个步骤那么快.最大的原因是,显卡是并行执行的.那么做一个线程池或者用现成的线程池例如intel的TBB,把屏幕分成几块,每块做一个task扔里面,简而言之,就是改造扫描线算法,使其可并行化. 


当前主要是单从算法上进行精简和优化,并行和多线程都是待去研究的领域,暂时不是短期能够展开的工程,不过YUKI的建议收纳了,应该会用上的说,其实说到并行我优先想到的是SIMD...
引用第21楼Advance于2010-03-08 19:19发表的 :
嗯可以用CUDA
但是作为作业应该不要求速度上的优化和考虑特定硬件实现 


什么时候 OpenCL 成主流了就好了  虽然现在手头的N卡CUDA和OpenCL都支持...

引用第22楼littlewater于2010-03-08 19:20发表的 :
其实FPS比较合理的使用方法是附上显卡型号= =+ [表情]

那台机器以修正,而且性能达到你那FPS5-6了 ^-^

CPU型号 Intel P4 2.20G

呃,对,应该配上型号,我只是想表达性能是有了一定提升的意思之类的

我的是Intel Core2 Duo 2.66GHz

littlewater 2010-03-10 09:04
AVC大依然很忙,那姑且有空常来这里交流吧^-^,还有如果有时间期望看到你的TUT,很有用,
虽然一般在4-5年之后才看得懂- -++

--------------------------

GL大,水水以为算法优先高于指令优化=x=

--------------------------

GL大难道要抛弃ATI了吗^-^?

--------------------------

Intel Core2 Duo 2.66GHz  的CPU也很多吧- -

譬如水水 E8200跟你就一样主频= =(搞不好一样XD?)

E7X00 大概也有这样的一款,老核心E6X00也有……


查看完整版本: [-- [CG]软件渲染器演示一枚 [更新v0.7] --] [-- top --]


Powered by phpwind v8.7 Code ©2003-2011 phpwind
Time 0.030669 second(s),query:2 Gzip enabled