|
|
Post by Jamis on Nov 25, 2019 15:17:25 GMT
Oh, my. That's on me. I should have chosen a different iterator variable for that pseudocode! I'm sorry for the confusion, but I'm very glad you figured out the problem!
|
|
|
|
Post by atroxis on Nov 26, 2019 22:06:53 GMT
I had a very similar issue to the ones listed here but was able to figure it out with their help, so thanks everybody. For others' reference, I had 2 problems with my implementation: 1) I was confused by the "i == hit" part of the pseudocode and why the intersection input wasn't being used at all, and the more insidious error, 2) I hadn't implemented equality functionality for the Intersection class which wasn't flagged as being incorrect, but yielded incorrect results and was quite difficult to find. Here is my relevant code, for reference (I'm implementing this in C#). Note, that I call the intersection "i", so the "i" in the algorithm I call "j", and "j.S" correspondes to "i.object".
public static Computations PrepareComputations(Intersection i, Ray r, List<Intersection> xs = null) {
if (xs == null) {
xs = new List<Intersection>();
xs.Add(i);
}
// Other Computations code
List<Shape> containers = new List<Shape>();
foreach (Intersection j in xs) {
if (EqualityOfDouble(j.T, i.T) && j.S == i.S) {
if (containers.Count == 0) {
comps.n1 = 1.0;
} else {
comps.n1 = containers[containers.Count - 1].Material.RefractiveIndex;
}
}
if (containers.Contains(j.S)) {
containers.Remove(j.S);
} else {
containers.Add(j.S);
}
if (EqualityOfDouble(j.T, i.T) && j.S == i.S) {
if (containers.Count == 0) {
comps.n2 = 1.0;
} else {
comps.n2 = containers[containers.Count - 1].Material.RefractiveIndex;
}
break;
}
}
return comps;
}
I do really appreciate this book, though. I've been having a blast (aside from this problem) and it's been very well written and explained.
|
|
|
|
Post by inventordave on May 6, 2020 14:57:39 GMT
Jamis or anyone, such as fremag ..... I am optimising my raytracer (I have completed everything except CSG, including BVH optimisation). I have noticed something odd about my codebase. Outside of the tests we discussed above (I finally got the code right, I think), prepare_computations() is only ever called at one point, in color_at(). The problem is, this is how I call it: var comps = prepare_computations(h, r, [h]), so as you can immediately deduce, the whole algorithm discussed is effectively moot, and is never properly utilised, because the length of xs is always 1, so the loop iterating through xs only goes round once... This can't be right, can it?..... I have uploaded my latest codebase at: github.com/leeodea/rt-dtAs a quick guide, prepare_computations() is in "rt.core.js", color_at() is in "rt.shade.js". Where HAVE I gone wrong, lol....
|
|
fremag
Junior Member
Posts: 73
|
Post by fremag on May 7, 2020 11:08:26 GMT
In color_at, instead of:
var h = hit(intersect_world(w, r))
if (!h)
return colour(0,0,0)
var comps = prepare_computations(h, r, [h])
I think it should be:
var intersections = intersect_world(w, r)
var h = hit(intersections)
if (!h)
return colour(0,0,0)
var comps = prepare_computations(h, r, intersections)
|
|
|
|
Post by Jamis on May 7, 2020 15:29:01 GMT
What fremag said.  You want to make sure to pass all the found intersections to prepare_computations. |
|
|
|
Post by inventordave on May 7, 2020 18:27:17 GMT
Thanks very much!
|
|
You want to make sure to pass all the found intersections to prepare_computations.