H3D TECH LOG

    Long time not to update. H3D studio now is developing the whole new project .

    After seven months development, we can show it now (dev code:Project H)...I don't like this code very much...hm,mm....whatever.  Now. It include a game prototype(single mode and multiplayer mode), a new 3d engine, and a whole new editor.

    The Engine support per-pixel lighting and other next-gen graphic functions. not much to say...You got 3d gurus in your team, find those rendering technologies  from ShaderX ,Game Programming Gems, and GPU Gems series. Also u can get the papers from GDC conference and sigraph conf pdf...something like that...then put some rendering trick with artists' help.

    Here 's some screenshot from the Editor. I adjusted some post process parameters in my taste.. hehe. maybe it's too heavy ...

*One of our character without animation. I can turn on the realtime shadow in the editor. so I put the actor model under the shadow of leaves.

*

We use different HDR parameters to make the different style in the same terrain.

the following pic it's blur....I just show our camera system here. there's a build-in depth of field modular in it.

    We use motion blur ,the tech is  same as NFS13 ,and the result is very ok .

    About the future, hmm..SSAO is very easy to implement. i doubt if it can improve the scene much.
    The next step is about multithread rendering (for speed)and some global illumination(....for my own interesting...and for more detailed in-door rendering), i will keep improving the nature rendering effect like water,all kinds of trees,better static shadow(maybe use distance field alpha test texture like ue3).and also, deferred rendering with massive lights is attractive..but in our game propotype, there's no need for complex in-door scene with multiple lights.
    We also developed a lightmap generator .it can generates the normal lightmap like half-life2 . but i doubt maybe the lispsm+csm with phong shading is very ok for outdoor rendering(like the lost planet). UE3 use the normal lightmap to render all static surface like floor and the walls.
    At last ,we all know now: the tool set is the key. the most important key...copying the rendering tech is easy ......,but developing a real product pipeline is long way to go...

     I will keep giving some dev infos here. hope it can make you got the desire to join us if you are a 3d tool/rendering/engine dev guru!

    My email is puzzy4d@yahoo.com.cn . You can contact me if you think you want to get a very exciting job in realtime 3d rendering and game dev field

对象生存周期管理是C++工程最重要一个环节。关于此类问题《游戏编程精粹》（GPG）系列一直有文章在提。比如第三册 1.5 《基于句柄的智能指针》，第四册1.7的《弱引用和空对象》。在GPG4 1.7给出的代码中发现了一些问题。原始代码如果放入实际工程结果会很不美妙。这里提一下

原文对指针的包装做如下处理：

template <class ResourceType> class ResPtr
{

public:

     //一些构造函数

    ResPtr(const ResPtr<ResourceType> & resPtr);
    explicit ResPtr(ResourceType * pRes);
    ResPtr(ResourcePtrHolder * pHolder = NULL);

public:

   //析构
    ~ResPtr();

private:

//用这个中间层封装指针
    ResourcePtrHolder * m_pResHolder;
}

class ResourcePtrHolder
{
public:
    ResourcePtrHolder (IResource * p) : pRes(p) {}
    ~ResourcePtrHolder();

//用户对象指针放这里
    IResource * pRes;
};

template <class ResourceType> ResPtr<ResourceType>::ResPtr(ResourceType * pRes)
{
    m_pResHolder = new ResourcePtrHolder(pRes); //封装原生指针时，在heap生成一个新ResourcePtrHolder对象
}

template <class ResourceType> ResPtr<ResourceType>::~ResPtr()
{//空析构
}

其他ResPtr代码略，但值得一提的是没有 delete   m_pResHolder  字样...

也就是说假如直接使用ResPtr ，用一次就有一个  ResourcePtrHolder 对象泄露

代码提供了另外一套引用计数的指针包装版本，ResourcePtrHolder内使用了delete this 销毁内存。但依然有个问题：

ResourcePtrHolder::~ResourcePtrHolder()
{
    delete pRes;
}

首先IResource 对外部要管理的指针类型做出了强制性的规定。必须是从IResource派生的类。其次是在holder析构时，不由分说把一个外部传入要管理的对象指针的内容删除。这样强硬的策略我想无论放到哪里都会导致异常巨大的问题。即便是采用引用计数版本，在holder计数到0再删除自己，顺带删除管理的对象，对于外部来讲也是个黑洞。

1.7代码的质量让人惊诧，还不知道整本书有多少类似的

http://www.horizon3d.com.cn/news.asp

vc7.1的 MFC project

像素的buffer使用了D3D9的frame buffer surface。主要是为了以后CPU/GPU共同光栅化/raytracing 混合渲染实验的方便

目前只支持透视校正纹理映射的三角形光栅器
只简单的支持3DS文件

图片支持使用ALT的 CImage
没有做任何优化...

代码花了两个星期的晚上。技术细节有空再写

集成了ID SOFTWARE 公司DOOM3 SDK中 idlib 代码

如果有人有兴趣把SIMD优化加上，我再弄个SVN吧.....

回到20世纪90年代，PC上进入3D图形硬件光栅化时代。VOODOO取代了CPU 光栅化渲染。随后出现NVIDIA TNT。直到GEFORCE将3DFX吞并。现在GPU的演变已经8年，基于屏幕上每个象素的复杂计算已经可以让老shader程序员忽略C和HLSL的区别。

在下一代mmo 3d引擎工具平台开发之前，有必要重新回到GPU内部，关注几何与光栅管道。越来越复杂的shader效果一切均基于光栅器的运作机理。把工作从GPU搬回CPU目的为使图形开发人员打捞图形学基础，在次世代开发中更好的运用GPU功能。

softcore 是一个软件光栅器。用于从场景物体的geometry transform, clipping,lighting, texture mapping, gouraud shading，到最后光栅化显示的整个图形处理管道技术演示。此项目为了保持代码清晰，省略了所有优化。只在可以使用SIMD和MULTITHREAD的步骤做出了标记。为了便于学习，project整合了id software doom3 sdk中SIMD和数学库代码。

由于是两个星期业余时间制作，时间有限，主要目的在于演示3D加速核心算法，光栅化部分的tc，color数值计算和sampler部分仍然需要进一步tunning。需要去除溢出和浮点转整数规则调整。这些可由感兴趣人员自行修改。

softcore project

done:

* CPU soft rasterization

* Z-buffer

* Gouraud Shading

* Perspective Correct Texturemapping

* Near plane Clipping

* Back face culling(geometry)

* Directional lighting

not do:

x Phong shading/bump mapping

x Bilinear filter

x Mipmap

x Dynamic lightmap

x Vertex color export/import

x Optimization

以下是3DSMAX中场景原图。有了硬件BILINEAR效果还是不一样.....

后面给出技术细节