
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: 3

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!)


leedavidodea
Junior Member
https://github.com/leeodea/rtdt
Posts: 61

Post by leedavidodea 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)...

