/*********************************************************************************/
/* */
/* 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的情况……
