Notes on OpenGL

The Camera is always located at the eye space coordinate (0, 0, 0);
The GL_MODELVIEW Matrix transforms object space coordinates to eye space coordinates


Ray Box intersection

将一个Box看作是三对(六个)平面围成的一个盒子。 对于每对平面, 总有一个面与射线起始点较近, 另
一个较远。 射线与较近平面的距离记为Tnear, 射线与较远平面的距离记为Tfar, 因此有三对Tnear, Tfar。
如果最大的Tnear大于最小的Tfar, 则没有相交;反之相交。
Pseudocode :
set Tnear = – infinity, Tfar = infinity

For each pair of planes P associated with X, Y, and Z do:
(example using X planes)
if direction Xd = 0 then the ray is parallel to the X planes, so
if origin Xo is not between the slabs ( Xo Xh) then return false
else, if the ray is not parallel to the plane then
begin
compute the intersection distance of the planes
T1 = (Xl – Xo) / Xd
T2 = (Xh – Xo) / Xd
If T1 > T2 swap (T1, T2) /* since T1 intersection with near plane */
If T1 > Tnear set Tnear =T1 /* want largest Tnear */
If T2 Tfar box is missed so return false
If Tfar < 0 box is behind ray return false end


Depth of field, Circle of confusion Introduction

Circle of Consusion(CoC)以及Depth of field(Dof)是两个光学的基本概念。 这两个概念
紧密相关
1. Circle of confusion
点光源经过镜头在像平面成的像是一个点(物体位于焦平面上),保持镜头与底片距离不变,沿光轴方向前后移动点光源,
像平面上成的像就会成为有一定直径的圆形,圆形的大小取决于镜头孔径和点光源偏离程度。 图
Cirles_of_confusion_lens_diagram.png表示了CoC与物体距镜头的距离的关系。
图CoC_geometry_and_math_illustration.png显示了CoC产生的几何表示及其与物镜距离的数学关系.
利用相似性关系, 可推知:

\ref(CoC_Math.png)
具体推导过程可参照Wikipedia.

2. Depth of field
Depth of field是物体能够清楚成像的最远物镜距离及最近物镜距离之差。 由该定义可知Dof可由Coc
推得。实际上, 任何成像平面(眼, 屏幕, 等)都是有一定分辨率的, 以屏幕为例, 当CoC过大, 以覆盖了
整个屏幕(所有像素), 则整个屏幕模糊不清。 相反, 如果CoC较小, 以至模糊圈在一个像素面积之内,
由于一个像素很小, 人眼无法识别, 则图像很清晰。 肉眼所有识别的像素大小有一定标准, 则当模糊圈比该
标准小时, 肉眼无法识别。 这个标准用C_sharp表示。 因此当c < c_sharp时,能够得到较清晰的图像。
求解该方法可得z_min和z_max, Dof = z_max – zmin。


cuda GPU Computing Toolkit 编译错误的一些解决方法

1. gnu version 的问题
对于cuda 4.0来说, 如果你的gcc version > 4.5的话编译会出错。 解决方法是安装版本小于4.5的gcc。
以gcc-4.4为例, 下载gcc-4.4,
“wget ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.4.6/gcc-4.4.6.tar.bz2″。
编译gcc,
“./configure –prefix=/opt/gcc-4.4″
修改$CUDADIR/bin/nvcc.profile, 添加:
compiler-bindir=/opt/gcc-4.4/bin

2. can’t find -lcuda
首先确保是否添加$(CUDADIR)/lib及$(CUDADIR)/lib64的动态链接, 检查方法:
ldconfig -p | grep cuda
添加方法很多:
1. 在.bashrc添加相应的LD_LIBRARY_PATH
2. 在/etc/ld.conf.d/中添加一个文件cuda-lib.conf, 在文件中添加
/usr/local/lib
/usr/local/lib64

我在openSUSE11.4下编译时, 到此就能够正常编译, 但在fedora15下确遇到了问题, 后来才发现部分nvida lib在fedora15下
安装到了/usr/lib/nvidia下面, 这个问题似乎没有很好的解决方法, 一个勉强可为的方法是:
对于发生这种编译错误的项目的Makefile中添加
LIB+=-L/usr/lib/nvidia
或者直接添加到common.mk中,
grep USEDRVAPI common/* -n
–>common/common.mk:277: ifeq ($(USEDRVAPI),1)
跳到common.mk的277行,在-lcuda前添加
LIB += -L/usr/lib/nvidia

在编译完C后, 你会发现OpenCL的编译也会出现类似问题

其实我在ldconfig中发现/usr/lib/nvidia的动态库是已在缓存中了的, 不知道为什么链接不上, 还待高人解答


OpenGL version 3.3 使用extension 的两种方法

以vbo(Vertex Buffer Object)为例
1) 使用”glext.h”

#define GL_EXT_PROTOTYPES
#include “GL/glut.h”
#include “GL/glext.h”

////////////////////
之后可直接调用glBindBuffer, glGenBuffers等函数
///////////////////

2) 不使用”glext.h”
#include “GL/glx.h”

#define GET_PROC_ADDRESS( str ) glXGetProcAddress( (const GLubyte *)str )
PFNGLBINDBUFFERARBPROC glBindBuffer = NULL;
PFNGLDELETEBUFFERSARBPROC glDeleteBuffers = NULL;
PFNGLGENBUFFERSARBPROC glGenBuffers = NULL;
PFNGLBUFFERDATAARBPROC glBufferData = NULL;
PFNGLBUFFERSUBDATAPROC glBufferSubData = NULL;

void initVBO() {
glBindBuffer = (PFNGLBINDBUFFERARBPROC)GET_PROC_ADDRESS(“glBindBuffer”);
glDeleteBuffers = (PFNGLDELETEBUFFERSARBPROC)GET_PROC_ADDRESS(“glDeleteBuffers”);
glGenBuffers = (PFNGLGENBUFFERSARBPROC)GET_PROC_ADDRESS(“glGenBuffers”);
glBufferData = (PFNGLBUFFERDATAARBPROC)GET_PROC_ADDRESS(“glBufferData”);
glBufferSubData = (PFNGLBUFFERSUBDATAPROC)GET_PROC_ADDRESS(“glBufferSubData”);

}

int main() {
//init opengl driver
initVBO();
}

简要说明一下, 第一种方法使用glext.h, 其中已经包括extension的相应声明, 注意加入”define GL_GLEXT_PROTOTYPES”
对于第二种方法, 通过在文件内声明extension, 需要使用glx来获取函数的地址。

第一种方法的好处的代码简洁, 使用方便;但是不同的机器的glext不同, 因此在发布时需要将glext.h一直发布。 而第二种则没有这个麻烦。

显然如果你在加入”define GL_EXT_PROTOTYPES”同时使用”glext.h”的情况下, 还对glBindBuffer等作相应extension的声明的话, 则会有重复定义的错误.


linux下texlive 2010, 中文字体设置(使用fontspec)

之前在OpenSuSE 11.2上为xelatex安装中文字体设置, 非常顺利, 参考的是http://tech.techweb.com.cn/thread-272484-1-9.html, 将系统升级到11.4后, 再
利用先前的方法时, 则出现了一些莫名其秒的错误。 下面是详细的安装过程及错误解决方法:

1. 安装xelatex
zypper install texlive-xetex
2. 配置
sudo mkdir /usr/share/texmf/tex/xelatex/zhfontcfg
sudo vim /usr/share/texmf/tex/xelatex/zhfontcfg/zhfontcfg.sty
按照之前给的链接中的方法, 需要在该文件中加入一段代码。 对于texlive2010, 由于newfontinstance不可用, 因此应该做一些适当的修改, 如下是我的:
\ProvidesPackage{zhfontcfg}
\usepackage{fontspec,xunicode}
\defaultfontfeatures{Mapping=tex-text}

\XeTeXlinebreaklocale “zh”
\XeTeXlinebreakskip = 0pt plus 1pt minus 0.1pt

\newcommand\fontnamehei{Adobe Heiti Std} %使用我自己带的字体
\newcommand\fontnamesong{Adobe Song Std}
\newcommand\fontnamemono{DejaVu Sans Mono}
\newcommand\fontnameroman{Times New Roman}

\setmainfont[BoldFont=\fontnamehei]{\fontnamesong}
\setsansfont[BoldFont=\fontnamehei]{\fontnamesong}
\setmonofont{\fontnamemono}

\newfontfamily\HEI{\fontnamehei} %new command 改为newfontfamily
\newcommand{\hei}[1]{{\HEI #1}}

\newfontfamily\ENF{\fontnameroman}
\newcommand{\en}[1]{\,{\ENF #1}\,}
\newcommand{\EN}{\,\ENF\,}
这里需要说明一下, 我在openSUSE 11.2上, 安装acroread后, 通过fc-cache -fv能够顺利检测到adobe的字体, 但在11.4上不行, 不知道是什么原因。 于是我直接将acroread中的相应字体拷贝到了$HOME/.fonts
目录下。
同时, 上面的配置文件最好不要直接粘贴。 我第一次直接粘贴后, 运行测试程序总是出一些奇怪的错误。
另外, latex给出的错误信息往往很奇怪, 在http://www.tex.ac.uk/cgi-bin/texfaq2html?label=errstruct中有提到这一点。 在这里尝到一个技巧, 如果看不懂错误信息, 就输入h, 这会提供一些额外的信息。

***********************************************************************

2011/9/15: 原来世界上还有ctex这么一个神奇的东西。


A sentence from “level set methods and dynamic implicit surfaces”

Equations that are true in a general sense can be used in numberical
approximations as long as they fail in a graceful way that does not
cause an overall deterioration of the numerical method.


Follow

Get every new post delivered to your Inbox.