raytracing

0熱度

1回答

我有一個輸入爲一組體素與他們的中心（x，y，z）給出。我有一套線。我想找出一個線是否與給定的體素集中的任何體素相交。（是/否問題）。我正在使用的當前算法是遍歷整個體素集，直到找到與任何體素的交集。這需要很多時間。有沒有辦法做得更快？通過計算體素與線的中心距離並檢查它是否小於一些小數量，我發現體素與線的交叉點。

2熱度

1回答

爲什麼我的蒙特卡羅光線追蹤如此嘈雜？

我已經使用蒙特卡洛方法實現了全局照明，使用scratch像素教程作爲指導。我的最終形象非常嘈雜！下面的例子是在64個樣本，我以前使用過高達512，它仍然非常嘈雜。任何想法可能是什麼問題？編輯：這裏是128個樣本和16倍超採樣，產生2048個採樣的輸出。仍然有很多噪音！

2熱度

1回答

爲什麼我的鏡面高光橢圓？

我認爲這些應該是循環的。我認爲我的法線有問題，但我沒有發現他們有什麼問題。再次，爲法線找到一個好的測試是困難的。以下是圖像：下面是每個光我的陰影代碼，而忽略了對反射遞歸部分： lighting = (hit.obj.ambient + hit.obj.emission); const glm::vec3 view_direction = glm::normalize(eye - hi

1熱度

1回答

光線追蹤器 - 爲什麼我的球體邊緣有斑點？

我的光線跟蹤生成以下圖片：我檢查法線很多次，我完全相信，這些都不是問題。有沒有其他人有任何想法？

0熱度

1回答

金屬碎片着色器，訪問當前幀緩衝區顏色

我在寫金屬着色器。我想要的只是訪問片段的當前顏色。例如。在我的片段着色器，結束的時候，我把回報currentColor + 0.1，例如結果將屏幕從黑將白了FPS。這是一個繪製填滿屏幕的三角形條的基本程序。最終目標是在着色器內部寫一個路徑跟蹤器，我用opengl + glsl做了這個。我遇到了緩衝區問題。我認爲一個簡單的解決方案就是將當前的輸出顏色傳回給着色器並在那裏平均。這些都是

2熱度

1回答

禁止在GLSL中遞歸？

你好我是GLSL的新手，在嘗試寫下面的遞歸調用時遇到了這個錯誤。我已經看到了GLSL中遞歸光線追蹤實現的很多演示，所以我假定GLSL支持遞歸。這是不是這種情況？的OpenGL函數返回一個編譯時錯誤消息： Error: Function trace(vec3, vec3, vec3, int) has static recursion 這是我的函數定義 vec3 trace(vec3 ori

1熱度

2回答

快速SSE射線 - 四個三角形交叉點

我目前正在研究Path Tracer，並且正在尋找優化我的射線三角形交點的方法。我目前使用下面的SSE4實施穆勒 - Trumbore算法： bool Ray::intersectTriangle(const Triangle tri, float& result) const { __m128 q = _mm_cross_ps(m_directionM128, tri.e2);

0熱度

1回答

減少計算而光線追蹤

我寫我自己的3D遊戲引擎（我花了一年），我想創造我的CPU上運行的光線跟蹤（而不是GPU！）就目前而言，射線追蹤過程如下簡化：爲每個輸出像素投射射線。如果當前射線碰到物體，設置輸出像素的顏色爲「白色」否則設置爲黑色爲了提高光線跟蹤器的速度，我添加了一個球形邊界框每個實體。如果當前射線與邊界框相交，它將運行與實體的每個三角形的相交測試。我在射線三角交點和射線點距離上使用了最快的方法，但每

0熱度

2回答

16x16塊的平行光線跟蹤

我的光線跟蹤器目前是多線程的，我基本上將圖像劃分爲與系統一樣多的塊並且使它們平行。但是，並非所有的塊都具有相同的渲染時間，因此大部分時間的一半運行時間僅佔CPU使用量的50％。 Code std::shared_ptr<bitmap_image> image = std::make_shared<bitmap_image>(WIDTH, HEIGHT); auto nThreads =

6熱度

1回答

Möller-Trumbore是最快的路口嗎？

對於射線追蹤器項目，我一直在研究處理尋找光線和三角形（由三個頂點定義）之間相交的算法。到目前爲止，我發現Möller-Trumbore（MT）算法是普遍使用的。所以我的問題是1）有沒有MT的替代品或算法被認爲是計算交叉點的最快方法？ 2）如果是，MT是否被證明是最優的？或者有人可以想象發明更快的算法？編輯：我現在看到我的問題是非常相似的Ray-triangle intersection