设置生成目标的输出目录

1
2

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/$<CONFIG>)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/$<CONFIG>)

Note $<CONFIG>应该在VS下才起作用

How near and far planes affet depth percision

• My openGL render depths are nearly the value of 1 why is that?
• depth buffer got by glReadPixels is always 1
• How am I able to perform perspective projection without a near plane?
• Why is my depth buffer precision so poor?

Reversed-Z Depth Buffer

I don’t know of any game engines where they attribute real-world units to lighting and material values, since those kinds of things tend to be driven more by the appearance than the physical correctness. The relative intensities of, say, a candle and a 100W light bulb are probably more important than the absolute values.^{Lighting: The Rendering Equation}

• What units should I use for lighting in a 3D rendering engine?
• Moving Frostbite to Physically Based Rendering 2.0
• Physical Units for Lights
• Physical Lighting Units
• Filament lighting/units
• Understand physical light units
• Lighting: The Rendering Equation
• Using Physically Correct Brightness in Cycles, emission

Align Main Camera

Click “Main Camera” in the Hierarchy and then select GameObject > Align with View. ^{How to Set Unity Camera to Scene View or Field of View}

如果想要Camera视口范围覆盖当前编辑View，可以通过在视口的gizmo辅助下调整Camera的FOV来实现。

背景

DirectX SDK自从Windows 8 SDK开始，是随着Windows SDK附带的，包含了各个历史版本的头文件、动态库和工具集，但是这些历史版本SDK的sample和辅助库D3DX9、D3DX10、D3DX11等就被丢弃了。

偶尔会遇到一些D3D的旧版本上古demo，可能就使用了一些旧版本的辅助函数，比如在看SSS效果的时候使用iryoku大佬的separable-sss，仅仅依赖Windows SDK附带的DX依赖是没法正确跑起来。

Quad with Bufferless rendering

如果没记错的话，最初应该是在OpenGL SuperBibile里面看到的无Buffer的渲染方式，把三角形顶点数据写在vertex shader代码里，在shader里通过index取相应的数据，当时感觉平平无奇。后来在SaschaWillems的Vulkan example里看到更精简的写法，当时表示惊呆了，使用gl_VertexIndex来构造顶点数据，画一个覆盖屏幕的quad。下面就是Vulkan example的实现。其中vkCmdDrawIndexed对应gl_VertexIndex, vkCmdDraw对应gl_VertexID；我是在GL环境下，则是glDrawElements对应gl_VertexIndex, glDrawArrays对应gl_VertexID。

1
2
3
4
5
6
7
8
9

#version 450

layout (location = 0) out vec2 outUV;

void main() 
{
	outUV = vec2((gl_VertexIndex << 1) & 2, gl_VertexIndex & 2);
	gl_Position = vec4(outUV * 2.0f - 1.0f, 0.0f, 1.0f);
}

Vulkan枚举值的字符串化

Vulkan中的枚举值做了很好的枚举类型管理，尽管还是是C类型的枚举，具有全局符号可见行；再尽管不似C++ enum class有严格的命名空间访问机制，但是仍然具备相应的枚举类型作为命名空间管理和访问。这为Vulkan枚举值的字符串转换提供了方便，可能这也是为何VulkanSDK给出了官方实现vk_enum_string_helper.h的原因。

以VkImageType为例，

MeshLab调试时加载的dll版本不对

从MeshLab 2023.12下载安装的2023.12版本，我在本地clone了一份源码编译，发现在C:\Users\Administrator\AppData\Roaming\VCG\MeshLab_64bit_fp\MeshLabExtraPlugins\2023.12位置存放了一套插件的dll文件，也就是这一套dll文件影响了源码的调试，也即调试时加载的这个目录下的dll文件，不是生成路径下的dll文件。

根据调用栈加载dll的路径就是这个路径：

OpenGL目前的最新版本是2017年发布的4.6版本，OpenGL老矣也不会再有更新了。尽管OpenGL是一套简单易用的图形API，但是很明显它并没有紧跟图形技术发展的脉搏，不仅仅落后于同时代的DirectX，其自身标准的取舍也使其变的碎片化。模式和兼容性就是其中恶心的一点，本文便是记录GLFW3在创建OpenGL上下文时设置模式和兼容性所设置的一些字段。

以前用GLFW3和OpenGL做一些demo时候，glfwWindowHint随意复制粘贴一下然后设置一下OpenGL Context的版本和Profile即可，并没有过多理会其他的字段的含义和差别。毕竟使用Modern OpenGL或者Core Profile的OpenGL，并不需要在意兼容模式下大量的固定管线API的功能。但是，当实际使用中涉及到了glLineWidth这种从上古时代OpenGL 2.0时期延续至今并在OpenGL 4.6中Deprecated的API，更骚气的是其能不能work还要取决于硬件能力和驱动实现，多重buff于一身，某些字段的设置开始变的微妙起来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
// glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GLFW_TRUE);
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6);
glfwWindowHint(GLFW_SAMPLES, 4);
glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE);

std::cout << "Vendor  " << glGetString(GL_VENDOR) << std::endl;
std::cout << "Render  " << glGetString(GL_RENDERER) << std::endl;
std::cout << "GL      " << glGetString(GL_VERSION) << std::endl;
std::cout << "GLSL    " << glGetString(GL_SHADING_LANGUAGE_VERSION) << std::endl;
GLint profile;
glGetIntegerv(GL_CONTEXT_PROFILE_MASK, &profile);
std::cout << "Profile " << (profile & GL_CONTEXT_CORE_PROFILE_BIT ? "Core" : "Compatibility") << std::endl;