Forum Replies Created
-
Posts
-
感谢闫老师,完结撒花. 我也抛个砖
就游戏业界的话,站在一个技术美术的角度,我感觉理论方面,对大部分项目,闫老师的课程已经提供了足够好的基础. 毕竟实时图形界基本都是炒离线界的冷饭, 但无论如何, 做实时在实践方面还有很多可以进阶的, 比如:
– 如何hacking,使得实时效果接近离线效果,然而保证性能优化,比如布料和头发的BRDF如何简化, 渲染管线中那些什么TAA, SSR效果如何实现,多光源怎么处理, 体积渲染如何简化等等.
– 如何利用显卡机制和系统API, 最大化优化渲染性能, 比如可以了解显卡的原理,DX的API,PS/XBox/苹果/安卓的特殊机制这些,
– 如何满足风格化的Art Direction, 借助图形学的原理, 提升渲染效果和资源生产效率, 比如做NPR二次元有很多很多trick
– 如何配置动作系统,使得角色可以自然的跑酷和战斗. 比如试试做个黑魂的战斗或者刺客信条的跑酷
– 如何落地,让一套新的渲染/模型制作/动画/特效系统,方便艺术家使用, 比如战神4做的风系统,Horizon做的云系统,自己可以尝试复现
– 游戏引擎中的物理如何运作, 由于引擎大多使用物理中间件,比如Havok/Physx, 可以看看API
理论上也不复杂,不过很多时候还是自己遇到了项目中的很多需求,亲自做过才有体会.个人推荐
– GDC历年的Talk
– RTR4
– 熟悉一个3D制作软件, 我推荐Houdini.
– 在项目中学习, 入行选择做引擎程序/客户端程序/技术美术/技术动画/VFX之类的大多会和图形学有交集共勉
你好，我机器是四核八线程的i7,这个是物理的不用设置的。我是原生ubuntu环境，不过跟虚拟机应该一样的。代码里开了8个线程，我就默认系统线程池自动分配到了一个物理线程做一个工作线程了。
C++我也不太熟，平常c#写的比较多。写std::thread老给我报类型错误，指针引用傻傻分不清，然后写std::future就能跑。望大佬讲解。
比如一段示例代码如下：
someReturnType someFunction(parameterA, parameterB); std::vector<std::future<someReturnType>>> futures; // dispatch all thread for(uint32_t i = 0; i < NUM_THREAD; i++) { auto fut = std::async(std::launch::async, someFunction, parameterA, parameterB); futures.push_back( std::move(fut) ); } // join all results for(uint32_t i = 0; i < NUM_THREAD; i++) { auto result = futures[i].get(); }这里someFunction就是一个干活的函数，我dispatch了NUM_THREAD个的someFunction，它们就在不同线程跑了，参数列表的区别使得每个线程干的不一样。
This post has received 1 vote up.学习一个，所以OpenMR和std::thread有啥区别？
我查了下有个帖子https://stackoverflow.com/questions/23258037/openmp-vs-c11-threads
说OpenMP减少了些线程切换的overhead。那么我们让开启的线程数等于物理线程数，不就一样了？我是直接用的std::future语法, 开O3, 4核8线程, 784/spp32，接近三分钟
十分推荐编译开这个优化编译O3, CMAKE里加一句 set(CMAKE_CXX_FLAGS “-O3 -pthread”)，这里我顺便加了std::thread同样疑问…不过我这里,SAH构造BVH时间确实是跟bucket的数量成正比,当然32个bucket时时间也没多多少.
一个猜想是,SAH在以下这种极端情况下表现比较好:一组面数量很多,另一组面数量很少,这两组距离很远.
我们这个case里,就一个bunny,它还是比较紧凑的不太会出现那种极端情况.
(当然另一个猜想是我代码写错了….This post has received 1 vote down.你好，我的理解是
point = point + kn * n * h(uv)
这个代码中，h(uv)是一个标量，表示的表面沿法线位移的距离。point = point + kn * n.cwiseProduct(payload.texture->getColor(u,v));
这里面，贴图采样的是一个Vector3f，当然如果贴图的rgb通道都是表示高度的灰度且一样的话，是没问题的等同于标量。但是作业框架里给的那张hmap.jpg，看上去像是个法线图，它三个分量不一样。其实这里我对作业框架有点存疑的，我觉得hmap应该是一张灰度高度图才对，我试了一下把hmap当法线图转出来一张高度图(附件hmap_normal2height.png)，然后光栅化出来是附件disp_n2h_question.
当然如果直接把hmap当成法线贴图，shader里也直接用法线图的方法，见附件disp_n_question，我觉得好像效果更好。你好，RTR4说硬件会自动偏移采样点。我再摘抄一段RTR4的文字，在P141
If all MSAA positional samples are covered by the fragment, the
shading sample is evaluated at the center of the pixel. If instead the fragment covers
fewer positional samples, the shading sample’s position can be shifted to better
represent the positions covered. Doing so avoids shade sampling off the edge of a
texture, for example. This position adjustment is called centroid sampling or centroid
interpolation and is done automatically by the GPU, if enabled. Centroid sampling
avoids off-triangle problems but can cause derivative computations to return incorrect
values另外你引用那个博客讲的应该是准确的，MJP是ReadyAtDawn的图形大佬，教团1886那个工作室。
This post has received 1 vote up.把我缩进吃了。。。
对于某个像素： z = 计算像素深度 foreach 亚像素 if 相交测试通过: if 亚像素深度测试通过： 存储当前亚像素深度(z) if 存在亚像素通过深度测试： c = 计算像素颜色 foreach 通过深度测试的亚像素 存储当前亚像素颜色(c)谢谢补充，老师讲的像是SSAA。
MSAA的问题我工作几年了一直没想清楚过:(，还是写代码重读RTR才想明白一些我的理解是，子样本是可以单独给一个x4的缓存的，我不确定硬件里是不是这么做的，可能需要老师解答一下。但framebufferx4这样太耗空间了，一种优化方式是：有需要的像素维护一个子样本array就行。微信群里有个大佬提到过，感觉有点像OIT维护一个链表的深度样本。
肯定还是需要存储子样本的颜色，在resolve阶段做个平均的。只是怎么存储我有点异议。
This post has received 1 vote up.谢谢回复，是的，这样动态维护可以降低显存空间。
我的做法是亚像素直接使用像素上的颜色和深度
伪码大概是：
对于某个像素：
z = 计算像素深度
foreach 亚像素
if 相交测试通过:
if 亚像素深度测试通过：
存储当前亚像素深度(z)
if 存在亚像素通过深度测试：
c = 计算像素颜色
foreach 通过深度测试的亚像素
存储当前亚像素颜色(c)resolve阶段：
foreach 需要处理的像素：
计算亚像素平均颜色，赋进framebuffer请大佬们指正
怎么吞我回复 是不是不能贴图片引用
—–
谢谢楼主总结，我也查了些资料，这里做个补充贴一张RTR4的配图
个人理解硬件实现上，是不会把color buffer/depth buffer x4的，但确实per pixel多存了一些样本。需要注意，这些样本可能是相同的。比如配图中的例子，0/2/3处的红色的color/z是相同的。per pixel上并不需要计算sub-pixel的颜色和深度，而仅仅是在通过相交测试的sub-pixel中，保存了同样的color/z。
这也就是MSAA与超采样的区别，MSAA里，每个像素只有一次深度和颜色采样(或说光照计算)，而超采样需要per sub-pixel都做颜色和深度采样。体现在代码中，应该是per pixel只有一次getColor和compute_z。
也因此MSAAx2的时间应该小于没有AA的四倍，笔者的例子中，MSAAx2是1.4s,没有AA是0.55s，两倍多一点。
这里可以注意，sub-pixel的样本不需要全屏存，其实只有边缘处是需要的。如果某个pixel的sub-pixel样本全部通过深度测试，那最后resolve阶段我就不用去平均这里sub-pixel的颜色，直接拿color buffer就行。这也就引申出右侧EQAA，既然样本可能一样，那我维护个表和索引就行。图中这个case，就少存了两个样本。一些当代硬件就是这么实现的，比如Apple的GPU Enhanced MSAA
