/*********************************************************************************/
/* */
/* LrCore Development History & Notes */
/* */
/*********************************************************************************/
/*---------------------------- LrEnder Demo 0.1 ---------------------------------*/
2003.8.17
光线追踪框架
2003.8.24
基本几何体渲染
2003.8.30
贴图支持
2003.8.31
图形显示
2003.9.6
控制台程序
2003.9.27
场景描述文件支持
2003.10.12
BSP算法支持
2003.11.9
多线程支持
2003.11.16
GI算法支持
2003.11.17
Shader支持
2003.12.3
动画支持
2003.12.21
FastBSP支持
/*---------------------------- LrCore beta 0.5 ---------------------------------*/
2004.2.22
基础扫描线框架就绪
所有屏幕点一律转换到世界坐标系计算Shader
2004.4.13
完全改变基本数据结构和体系
2004.8.26
取消图形显示和控制台架构
提供VB库
2004.8.27
改为基于STL的数据结构
2004.8.28
完成全新场景描述语言的构建
2004.8.29
开始编译
2004.8.31
错误之莫名其妙，之隐蔽，之模糊不清，实属罕见
2004.9.4
记事本、VC、VB对文本中tab键的处理都不一样，导致格式不同！
可能的错误：
每次调用push_back都移动了内存地址，但原先的指针引用没有相应改变！
2004.9.19
完成shader变量类型支持
dangerous pointers that might change when rendering...
a_edgelink[]
a_trilink[]
x_edgelist[]
2004.9.26
MD系统被新博网络重装了，原来硬盘上的数据不懂还能不能弄回来！！！
得亏我在软盘上备份了Lr！！！
要不然哭都来不及！！！！！
2004.10.3
写了coding specification
依然不能正常运行，raytrace都不行。
按理应该在第119条扫描线处开始工作
2004.10.13
triangle_01 的 material 错误指向 Default Material
left edge 和 right edge 的 normal vector 数值居然相同
第221行出错！
i = 1
j = 3
错误可能和 x_edgelist 有关！
2004.10.17
终于找出错误原因了，原来是triangle fragment内存没有释放！
从213行开始处理遮挡错误
正确的排序应该是 1 2 1 2
2004.10.20
x_edge 位置错误，应该从 [ 329 194 ] 开始
2004.10.23
在循环中，应该用e的地方写成i，导致读写出错
循环中的变量在全局可见实在是危险！
x_edge 上有缺口，从298行开始debug
2004.10.24
发现在两个triangle的交点处z depth居然不相等！
推测是*面方程错误！
重新推倒了*面方程，终于得到正确的 x_edge 位置
在比较z depth的时候加了个模糊比较，得到正确的消隐效果了！
raytrace 还是一片漆黑……弄不懂为什么了
delete G-Buffer 出错，这个玩意本来就有问题！
2004.10.25
问题是重复delete造成的，因为delete并不会将指针设成NULL，
就像当初的free一样～
还没找到很好的字符串和消息解决方案
2004.10.26
在 i = 1 j = 5 处访问不该访问的端点缓存！
原来在循环中写 i < 100 这样的句子的时候，
当循环结束时，i的值并不是99而是100！
合并区间时当 i = 2 j = 1 时出错！
发现问题原因了，还是 push_back 导致内存移动！该死的！
能不能没有指针这个东西？
原来的 triangle fragment 链表方案根本不能减少内存用量，
反而增加了内存用量！float + void* + void* 占用 12 字节，
如果直接用 float + float 占用 8 字节，而且代码简化很多！
终于能正确处理消隐了！
2004.10.29
继续提供控制台渲染，但没有图形显示
暂时取消VB库
循环中边缘处的bucket改变了高度值，导致下一列的bucket范围错误
2004.10.30
多bucket模式能正确渲染了！一直是slnum惹的祸！
用max重建了场景，发现交点是正确的，
推测是判断三角区域的预计算部分出错了
object是被拷贝到BSP空间了，但是object里的vtxList和triList等却是空的！
raytrace终于能工作了！错误都出在原来的坏编码习惯上！
2004.11.2
不能重载new和delete操作符，调试版本暂时不用MemoryManager
anti-aliasing 慢的不得了，减少了内存操作后还是慢！
一直误解了，其实泛型算法不一定要用在STL容器上
扫描线反走样部分失败……还要继续调试……
一开始设计算法的时候就应该有清晰的思路和坚实的理论基础！
这样的程序错误多是可以理解的，但是也反应出设计时思想的缺陷！
很多错误是最初就可以避免的！
2004.11.3
重写了GBuffer部分，全部使用new和delete
取消aa pixel的动态分配！
反走样简直越反越走样，实在不行我只好启用另一套方案，用raytrace来渲染aa pixel
2004.11.4
用反走样模式进行区间扫描的时候，推测triangle排序不会出错，
错在对 nodelist 端点的访问上！
2004.11.5
nodelist 端点访问并没有出错呀，是在第3个区间z深度排序错误！
找出错误了！在反走样模式区间端点的z值是离散的没有连续性的，
按非反走样模式一样利用连续性来计算z值所以出错！
2004.11.6
MD内存访问出错，我就不明白 f_nodelist 释放怎么可能出错！！！
2004.11.7
TMD调试了这么久还是搞不懂为什么 f_nodelist 释放会出错！
推测是在draw_tri里导致问题，因为AABucket的render段代码和非反走样模式几乎是相同的，
而非反走样模式是可以正确渲染的！
进一步推测是drawAASample出错！
终于明白了！
前面浪费了大量时间调试render部分，其实错误出在分配图像大小不够！
错误的访问内存导致连带错误！
2004.11.8
试了一下用raytrace来渲染AABucket，速度还可以，
但因为raytrace和scanline渲染的结果本来就有差异，所以边缘不能很好接合。
2004.11.9
scanline模式下能得到正确的光照了，原来是view to world矩阵错误！
AABucket的象素方向颠倒了，所以出现裂缝！从150行开始debug
原来是因为edge couple的一边没有被放进AABucket所以没有效果！
酷！终于能正确反走样啦！
多个triangle的反走样还是错误的！！！
反走样模式下多Bucket渲染一片漆黑……
任何模式多线程渲染都是一片漆黑……
每个AABucket都要对triangle颜色重新采样！
2004.11.11
反走样边缘已经不错了，但相交边界的处理还很糟糕！
2004.11.13
AABucket中区间triangle排序错误，导致相交边界反走样错误！
相交边界能正确反走样了，错误是因为在AABucket中对方程系数进行了缩放，
但其实方程系数是不需要缩放的！
相交边界开始处的AAInterval被取消了！原因是两条边的AAPixel粘在一起了！
第 309 行出了个缺口！
2004.11.14
相交边界的问题解决了，办法是用aa_joint标记粘在一起的aa pixel
缺口问题是在aa bucket中边失活后找不到替代边！
该死的，活化边对应错了！！！
其实没必要把替代边放进aa bucket因为aa pixel很小，
而且找不到替代边的情况只发生在三角转折处，所以直接防止边失活就行了
三角表面有些奇怪的花斑……从177行开始debug
2004.11.15
花斑问题解决了，原因是aa bucket中draw_tri时zx没有缩小
处理tracer和bucket问题，多线程debug比较麻烦，先从单线程开始
担心什么来什么，特殊情况果然出现了！
当triangle正贴着bucket左边界时，这个triangle不会被渲染！
每行扫描后活化边的active要还原为-1，防止下一行使用旧值！
从bucket(4,2)开始debug
2004.11.16
不管是否渲染该行，都要更新数据，保证安全
跨越bucket边界的反走样成为技术难题！要重新考虑算法！
如果g-buffer最后一个象素是aa pixel，这个象素不会被渲染，
只要让g-buffer宽度增加 1 就能解决这个问题！
2004.11.17
重写了scanline内核！！！把反走样模式和非反走样模式的代码分开了！
代码更加清晰易读！！！
2004.11.18
如果this_interval被删除了，那么last_interval就不应该指向this_interval
删除了根本没用到的数据成员cur_normal和cur_uv！
知道错误原因了，非反走样区间范围不正确！
禁止g-buffer移动设置点就解决了！
2004.11.19
非反走样模式可以正确的避免重复进行 z depth 排序了！
但是x_edge2d的数据结构里需要增加一个active标记
多bucket反走样模式正确渲染了！原来错误出在最后一个区间没有被渲染！
必须单独添加代码特殊处理最后一个区间！
2004.11.20
写了exporter for 3ds max
导出了一个球体，在反走样模式不能正确渲染共享边！
正式改名为 LrCore
2004.11.21
可以正确渲染共享边了，错误很白痴，但是很难找！
把 1 / ( a * b ) 写成 1 / a * b 了！
2004.11.23
如果是一个edge2d指针，那么用==比较时只会比较地址而没有调用自定义==操作符，及其危险！
防止了共享边的三角之间求交线，可以正确渲染了！
2004.11.26
STL偷偷调用了结构成员中vector的拷贝函数，
导致内存用量激增，速度急剧下降！
原来暗自trace shadow我都不知道！
又是一个极白痴的错误！bucket重建边表时没考虑好重复边！
tracer行为错误是由于搜索bucket时忘了写return造成的！
2004.11.27
消除了表面缺口，原因是三角的三边有时会同时成为活化边，
这时还要加一个判断选出正确的两条活化边！
从bucket(3,3)第60行开始处理边缘奇怪的棱角！
找到原因了！边 k 值计算错误！k 是方程系数不能通过
取整后的 slnum 来计算，应该用精确值！
删了那个愚蠢的 sl_round ！帮不上忙还捣乱！
直接用 round 了！
2004.11.28
原来是 isOut 这个该死的东西计算错误导致活化边无法激活！
mip-map 支持，重新设计了贴图系统！
2004.11.29
光追踪的速度问题可能是太多物体都位于pObj造成的！
2004.12.1
重写了光线追踪的内核！！！采用了新的分割算法！！！
速度变得非常快！！！
2004.12.3
找到scanline出现小缺口的原因了，triangle的le和re被错置了！
由于使用了四舍五入，边有可能被提前删除而不被添加到AABucket中，
这样即使三角被加入AABucket也会因为缺乏边而被删除！
解决方法是添加所有边到AABucket再进行裁减！
2004.12.5
在bucket起始行会被误判断为 AAPixel
2004.12.6
改变了mip-map坐标系，重写了mip-map部分，大大简化了代码！
2004.12.7
推翻了旧的scanline内核重写了关键部分，大大简化了代码
大部分代码是基于STL的了
2004.12.8
表面出现奇怪的凹凸不*的现象，不知如何解决
2004.12.10
通过特殊 shader 判定错误出在 z 值的计算上！
2004.12.11
错误居然是不小心把 + 写成了 += ！
预计算时间太长了，还是不能完全正确的渲染反走样！
2004.12.12
当父物体被取消选择，子物体也应相应的被取消选择
z-buffer 精度不足会导致边缘严重锯齿，关掉 z-buffer 图像质量反而更好
2004.12.13
反射效果现在很糟糕，会有严重麻点！
阴影效果死都出不来！！！而且莫名其妙的 0.0 < 0.0 会变成 true 掉！！！
坐标系可以和 3ds max 对应了
2004.12.14
内部规定：如果一条边没有 t2 ，那么 t[1] 的值将被设成与 t[0] 相同！
重写了视域裁剪部分，理清了思路，大大简化了代码！
裁剪存在严重问题：会产生太多新多边形！
2004.12.15
解决了光线追踪的麻点问题，只要把包围盒扩大一点就行了，
因为当面和坐标轴*行时，它的包围盒宽度为0
找到一直没有阴影效果的原因了！参数 soft_edge 和 cut_shadow 应被初始化为1
2004.12.16
photon map 应该在 bsp division 之前初始化，否则子物体得不到 photon map 指针
2004.12.17
终于可以正确裁剪景物了！！！
原来错误出在：
1.没有防止对和裁剪*面*行的边的裁剪
2.没有标记位于*裁剪*面前的景物为不可见
2004.12.19
写完了shader范例
2004.12.20
处理了突然出现超亮 photon 的问题，
原因出在反射折射没有微*移光线的 src，只移动 pos 是不够的
微偏移量大小的选择非常重要！
2004.12.21
多线程可以正确渲染了，原来问题出在 LeaveData 前有一个 return，
导致没有 LeaveData
有些不可见的三角可能在裁剪中因为顶点可见而被判断为可见，
防止了这种情况，可以正确反走样了
LrCore 调试工作到此结束！！！
2004.12.28
偶然发现了 LrCore 反走样代码部分的错误，但是参赛作品已经寄去了……
错误又是逻辑不够完备造成的，就像处理了if但没有处理else的情况……