# Tag Info

## Hot answers tagged raytracing

17

Shapes appearing stretched in the periphery is a consequence of perspective projection. The wider the field of view (FOV) is, the stronger the stretching effect gets. To demonstrate the effect I wrote a quick example on ShaderToy: https://www.shadertoy.com/view/MltBW2 As you can see on the images below (corresponding to FOV of 40, 80 and 120; if I didn't ...

4

The space at which you transform your vertices is completely up to you, because it depends on what algorithms and kind of effects that you are trying to achieve. As of my personal experience, I usually shoot rays in world space because eventually we all need some sort of "world-space" acceleration data structure, such as a space-partition tree, that gathers ...

4

If your bunny is purely specular, then sampling the light directly at the shade point would give no contribution since the specular BSDF is a delta BSDF. It generally evaluates to zero for any direction other than the mirror direction. If it was a glossy BSDF, then it might be possible that the pdf value could be very small so that the monte-carlo estimator $... 4 If your plane has a normal of$\begin{pmatrix}0 & 0 & z\end{pmatrix}^T$, then your computation vec3 u = vec3( normal.y, -normal.x, 0 ).normalized(); vec3 v = normal.cross( u ); will result in u and v both being$\begin{pmatrix}0 & 0 & 0\end{pmatrix}^T$. A more general approach would be, for example, to compute the cross product of your ... 4 I wasn't really expecting that, no. The formula in the paper is not the most elegant - there's quite a few parentheses in there. In this case I think it's just a matter of shuffling the parentheses around a little in the get_k implementation - both terms should be divided by (1-r): float get_k(float r, float n) { return std::sqrt( 1.0/(1.0-r) * (... 4 Read up on the basics for ray-tracing here, Usually we don't mess up with viewports and stuff in raytracing, So I'm just telling you for the case where viewport equals the Image Width and Height. There are two cases when the field of view changes. Either you move the image plane back and forth or you increase the size. We choose to change$d$( former ... 4 Some elementary trigonometry tells you what to expect from this situation. The angle to see the shadow terminator is marked on the diagram, and a use of SOHCAHTOA tells you it's$\cos^{-1}\tfrac{1}{2} = 60^\circ$. Yours looks higher than that so your intuition seems correct. Stepping through the lighting code will help you see where it's going wrong, and ... 4 The issue was caused by an incorrect calculation of the reflection direction vector. With D ray direction and N the normal vector: R = D - 2 * dot(D, N) * N The issue was caused by calculating the components of R as follows: R[i] = D[i] - 2 * (D[i] * N[i]) * N[i] It took me a while to find the mistake because this produced a correct reflection with the ... 3 I have found the issue. The gamma correction was the correct value, the same as in the book (1/2), but the light source had the brightness of 1.0f. The book had set the light's brightness to 18.0f for all color channels. This would introduce color overflow if left at that, and the very light areas (above 1.0f, and subsequently when converted, outside the ... 3 Your main idea is more or less correct. The cosine hidden in the projected area measure$dA^\perp = dA\cos(θ)$compensates the weakening of irradiance due to incident angle (the Lambert's cosine law). This makes radiance independent from the incident angle. My guess is that the main motivation was to make it more practical to work with. The cosine in the ... 3 That's just how the Reinhard operator works. If the scene has very high dynamic range important detail may be lost near the high luminance region as you found since both will map near 0.99. Reinhard is a form of global operator. There are other types of algorithms using local operators which tonemap the pixel based on the intensity of the underlying ... 3 Operating systems cancel GPU program executions if they take too long. On Windows it is generally two seconds and on Linux it is five seconds most of the time, but it can vary. This is to detect GPU programs that are stuck and cancel them. There are different methods to get around this timeout, but they all require admin/root privileges, which is not always ... 2 First, the viewport size: $$h_x = 2*d*tan(\theta_x/2)$$ $$h_y = 2*d*tan(\theta_y/2)$$ Each pixel (from your diagram) has the following size in the eye coordinate system: $$W = h_x / (k-1)$$ $$H = h_y / (m-1)$$ Note that usually the field of view encompasses whole pixels and doesn't stop at the center of the edge pixels like your diagram shows. If$P_c$is ... 2 That's actually incorrect. You can transform every ray of your camera if you wish (and numerous implementations do so). There are some advantages and disadvantages to each method (e.g. if your rays are more than your vertices you end up doing more transformations, however you don't incur cache misses by running over all vertices). 2 So, for Uniform sampling the PDF is$1/2π$, For Cos-weighted its$cos(θ)/π$. The Lambertian BRDF has a$\pi$term as well in the denominator for energy conservation. When not optimizing things you should be dividing by$\pi$during the BRDF calculation, then dividing by the proper PDFs mentioned above. Considering all the factors into account, for uniform ... 2 My code is setup to calculate the intersection points of each of the spheres with any given ray and spit out the correct points to be rendered to the screen based on the type of boolean operation being performed (Union, Difference or Intersection). Then you need to do the exact same thing with the normals. Indeed, you would typically do this operation with ... 2 The normal of a given point on the height map is perpendicular to the 2 vectors defined by gx and gy. The original surface normal is not relevant to this. So in tangent space, the normal is: Vector tangent = Vector(1, 0, gx); Vector bitangent = Vector(0, 1, gy); Vector normal = normalize(cross(tangent, bitangent)); You then need to convert the normal from ... 2 As you said, the RTX Turing architecture comes with wired primitive-ray intersection, (to be more specific, triangle-ray intersection). The BVH is built by specifying the Bounding Box program to OptiX, the signature of which is: RT_PROGRAM void my_boundingbox_build_program( int, float result[6] ) As you can guess, the result must contain the minimun (3 ... 1 Disclaimer: It's been a long time since I looked at this sort of thing but here goes... Disclaimer2: On re-reading your question(s) I realised I might have misunderstood what you were asking. I'll leave this here just in case you were looking for this sort of reply. Are you rendering from the original Bezier patch definition (e.g. https://www.cs.utah.edu/... 1 Those are moire patterns. They are an aliasing artifact that usually occurs when sampling on a regular grid. Did you jitter the positions of your samples? If you just sampled an evenly spaced 10x10 grid within each pixel, that could explain it. Also, numerical errors or inaccuracy could it. 1 You're simply not normalizing correctly, since you've picked the pdf for uniform to be$1$which it is not, and for cosine to be$\cos\theta$which it is not. The pdf for uniformly distributed points on the upper hemisphere is:$p_U(\theta, \phi) = \frac{\sin\theta}{2\pi}$. The pdf for cosine distributed points on the upper hemisphere is:$p_C(\theta, \phi) =...

1

Let me first address some misconceptions you have: the theory states that we need to shoot x number of rays for each intersection No, the "theory" doesn't state such a thing. Note also that the paper @gallickgunner is referring to is inapplicable in this case since smallpt is based on the rendering equation and not the limited variant present in Cook's ...

1

During the implementation, the way rays are scattered does not actually change and remains random. Actually the way rays are scattered does change, specifically when you sample a light. In chapter 8 he makes a mixture pdf in order to sample either the light or the bsdf. What changes looks to be the contribution of each ray. This does change, but not ...

1

It's a variant to projective texture mapping. The simple way to do this in the fragment shader by using the position of the fragment to decide whether it is close enough to the plane of the laser to light up.

1

There are two ways to 'translate' your object. The first is by moving each point of your object by the desired translation. The second is by translating the origin of your coordinate system. In this case it's the latter. Basically it turns out to be the same, whether you translate your object by a vector $\vec{t}$ or whether you translate your origin by \$-\...

1

It'd be hell a lot easier if this were on graphicsexchange, since I can't use latex here but anyways. In the first pass of Photon Mapping you don't need to use the Flux form of rendering equation. You just divide the original flux coming from the light source among the N photons, then for each photon you use Russian Roulette to determine whether it reflects,...

1

The best algorithm depends on the condition like whether or not the square is axis aligned for example. I'm gonna discuss the more general case which can find find intersection for any arbitrary oriented square. The algorithm works by first checking the intersection of ray with the plane containing the square or rectangle etc. Then check if the ray is within ...

1

So, I figured it out. While UAV will be necessary when I start manipulating data in Compute Shaders, for the time being, SRV works fine provided the resource is read-only from the fragment shader. The two big problems were Creating an ImageTexture that was receiving the data. Note that the data copy was occurring just fine, but the texture was never used ...

Only top voted, non community-wiki answers of a minimum length are eligible