|
|
Post by mrwetsnow on Nov 9, 2019 18:21:38 GMT
The pseudocode for the planar mapping doesn't handle negative coordinates correctly.
point(0.25, 0.5, -0.25) | 0.25 | 0.75
let v ← p.z mod 1
v here will be -0.25, while it should be 0.75.
|
|
|
|
Post by Jamis on Nov 9, 2019 23:01:48 GMT
mrwetsnow -- you're right, but I think it probably depends on your programming language. Ruby does what the pseudocode describes (gives 0.75) but Javascript (for example) gives -0.25. If your language gives -0.25 for that modulus operation, you'll need to adapt the pseudocode accordingly.
|
|
|
|
Post by mrwetsnow on Nov 11, 2019 20:02:41 GMT
Yes, turns out this is not well defined. Go (which is what I am using) seems to keep the sign. Apparently C++ is implementation dependent. Fun times.  |
|
tiegz
New Member
Posts: 5
|
Post by tiegz on Apr 20, 2020 2:05:07 GMT
Just ran into the same issue as laserbrain -- I think the upper/lower cube faces in the reference image have the X axes swapped.
(Loving this bonus chapter, btw!)
|
|
|
|
Post by inventordave on May 24, 2020 0:04:58 GMT
I'll be honest, I really don't think I know what I'm doing, but I have the following for my planar_map function, and it even scales fine if I apply a transform to the Pattern that my code produces. Below is the output of the basic test suggested in the bonus chapter (without a scaling() transform applied) function planar_map(p) {
/*
var u = p.x - Math.floor(p.x)
var v = p.z - Math.floor(p.z)
*/
var u, v
if (p.x<0)
u = Math.abs(Math.floor(p.x)) + p.x
else
u = p.x - Math.floor(p.x)
if (p.z<0)
v = Math.abs(Math.floor(p.z)) + p.z
else
v = p.z - Math.floor(p.z)
return { u: u, v: v }
}The (untransformed) pattern in action:  And, just to prove my point, here is the same scene with the Pattern.transform set to m().scaling(2,2,2)...  |
|
|
|
Post by chrisd on Sept 3, 2020 0:33:32 GMT
I found another issue with the chapter: function cylindrical_map(p)
# compute the azimuthal angle, same as with spherical_map()
let theta ← arctan2(p.x, p.y)
let raw_u ← theta / (2 * π)
let u ← 1 - (raw_u + 0.5)
# let v go from 0 to 1 between whole units of y
let v ← p.y mod 1
return (u, v)
end functionIn order for that to pass the unit test, I had to do arctan2(p.x, p.z) not p.x, p.y.
Agreed.
And in the code for spherical_map:
let vec = vector(p.x, p.y, p.z)
The = should be ←
|
|
|
|
Post by Jamis on Sept 22, 2020 12:41:03 GMT
Thank you! I've fixed those errors in the bonus chapter.
|
|
|
|
Post by bit101 on Oct 23, 2022 15:34:17 GMT
Regarding Cube Mapping; isn't the X-direction of the "Up" and "Down" side of the cube reversed in the fold-out image here: www.raytracerchallenge.com/bonus/images/tmap/cube-face-mapping.pngThe U-vector should state " -1 .. x .. 1" (and not the other direction) -- just as the "Front" side. (The two tests "UV mapping the upper face of a cube" and "UV mapping the lower face of a cube" were failing for me, so I doubled and then tripled checked both my tests and my implementations for "cube_uv_up" and "cube_uv_down" and realized the image must be wrong.) Yup. I spent a long time puzzling over this one. The tests for `pattern_at` were failing, and the top and bottom faces were rendering wrong. But switching those properties fixed both. This did, however, break the previous `cube_uv_up` and `cube_uv_down` now had to be adjusted, as they were relying on the reversed u - x mapping. |
|
