|
Post by sbphillips on Aug 6, 2020 14:00:36 GMT
When I generate the glamour-shot for the area light it renders as expected when I don't include the box. If I add the box I get acne. I am assuming it is related to the box property shadow: false. Can't seem to figure out how to implement this. Tried checking "shadow" in shade_hit() and lighting() and setting intensity accordingly but to no avail. A little direction would be helpful
Thanks, Steve
|
|
|
Post by Jamis on Aug 7, 2020 15:51:40 GMT
Hello Steve,
The trick to implementing "shadow: false" is to change the shadow intersection routine. When intersecting the shadow ray with all objects, you need to ignore any objects that have opted out of shadows (that is, they've set "shadow: false"). In other words, instead of simply returning true if an intersection is found, you need to walk the list of intersections and only return true if any of them actually cast shadows ("shadow: true").
I hope that makes sense! Let me know if you're still not sure how this needs to work.
- Jamis
|
|
|
Post by sbphillips on Aug 7, 2020 17:25:17 GMT
Thanks for the help, I was close but not quite there.
BTW, what does setting the box color and arealight intensity to (1.5, 1.5, 1.5) do? I would think being over (1, 1, 1) would cause problems.
|
|
|
Post by inventordave on Aug 7, 2020 17:32:57 GMT
Multiplying a colour by light intensity 1.0 would leave the colour unchanged, multiplying it by 1.5 would grow it 50%, very easily finding yourself in a situation where final colour values became burnt-out white (>= 1).....
The lighting(...) function computes the final colour, at one point by multiplying 'effective_colour' by 'light_intensity'... If the intensity values are >1, the resultant values will expand, perhaps beyond 1.0 for any or all of the component r/g/b values...
It also depends on how you've coded your colour sub-system. In the part, perhaps, that converts normalised rgb values (0 <= v <= 1) to rgb "proper" (0-255 for each component - best to think of it as 0.0 to 255.0), your code should "cap" values above 1: if (v > 1.0) v = 1.0; if (v <= 0.0) v = 0.0;
Then, to get the RGB valuse, it's simply:
col_val = Math.floor(255 * v);
If you use a graphics library that accepts normalised rgb tuples (0 <= v <= 1), that library should cap them transparently.
If the appropriate subsystem didn't, surely it would either a) show no indication of the bug in the output image (<0 would be black, >1 would be white), or b) your program would crash...
You may find fundamental logic errors in your code, and in that case, most likely images would be black, or burnt-out white whenever/wherever you mixed multiple colours, or lighting(...) multiplied the internal colour value by an intensity tuple with values > 1.0.....
Did that help, or was it a useless answer??
|
|
|
Post by sbphillips on Aug 8, 2020 0:21:11 GMT
Got the first part of the Area Light done, now I'm working the "Area lights and Phong shading". Updated material.lighting and it seemed to work but it failed when I put the point light back in. A little direction on implementing the pseudo code line "for each sample on the light" for both area lights and point lights.
|
|
|
Post by Jamis on Aug 9, 2020 4:12:52 GMT
For point lights, "for each sample on the light" is a loop of exactly one iteration --- the point itself. For area lights, the line refers to the section above it titled "Randomly sampling your area lights". In this case, you'll iterate over each of jittered points, accumulating the contribution from each of them. (You're basically treating each of sample as a single point light.)
Does that clarify at all?
|
|