fix lighting bugs in dice cube

[BudgiePanic]

investigating:

• is 1. 'in shadow'?
• if it is, why is 2. soo bight?
• why did a 45 deg rotation in the y axis cause 3 to become so dark?
• why is 4/5 so radically different in brightness compared to the cube body

Originally posted by @BudgiePanic in https://github.com/BudgiePanic/PushingP/issues/73#issuecomment-1974166987

[BudgiePanic]

debugging pixel c: 785 r: 762

• 1. is not in shadow

[BudgiePanic]

• 2. pixel of interest is c: 816 r: 740

[BudgiePanic]

moving the light source to the camera location while keeping the cube rotated -45 degrees on y axis produced this image

suffice to say these shadows should not be present, why are these pixels being flagged as in shadow?

[BudgiePanic]

I think this would be easier to debug with a normal cube instead of a compound shape as the shape a in the dice compound shape

[BudgiePanic]

I think what is happening is:

• ray hits dimple
• shadow ray is cast
• shadow ray does not test against the dimple sphere
• shadow ray hits the dice cube from the inside
• difference operation rules does not filter this intersection because there are no dimple intersections
• point is chosen to be in shadow

but this needs to be confirmed

[BudgiePanic]

• [x] create unit test where ray hits (1.) assert the point is not in shadow

[BudgiePanic]

I think we got it wrong maybe we are supposed to perform all intersection tests first and then do the filtering of intersections at the end

the only difference is we need to curry the predicate down to the composite shapes like we are doing now?

lets make the unit tests and try this approach

[BudgiePanic]

for reference (to place a cube in the middle of the dice dimples)

new Cube(Transforms.identity().translate(1f, 1f, 1f).scale(0.50f).assemble(), diceMaterial), 

[BudgiePanic]

• another thing to try is to remove intersections that have shapes that fail the predicate within the compound shape filter method
  • not sure if it'll fix the problem, but its worth a shot
• also try allowing the dimple material to cast shadows, can't remember a good reason why the dimple material is not supposed to cast shadows

[BudgiePanic]

new unit tests to capture the 3 lighting conditions were created in commit https://github.com/BudgiePanic/PushingP/pull/73/commits/4fe548091468feb7db391db4053889add86e15e7

all of these tests pass when the dimple material does not cast shadows

[BudgiePanic]

the dimples are supposed to cast shadows

5 test conditions to verify in compound shape demo

• [x] 1. dimples on cube, light = camera position
• [x] 2. dimples on cube, light = (-2, 8, -2)
• [ ] 3. dimples on smooth cube, light = (-2, 8, -2)
  • failure 1: ray hits dimple and cylinder right underneath the under-point, no other intersections are returned, causing the system to believe there are no shapes blocking the shadow ray to the light source, making the pixel white (this could possibly be fixed by moving the dimples) (unit test: assert this point is in shadow)
  • investigate the compound shape filtering, error is likely happening here
  • failure 2: erroneous shadows in the number 2 dimple, cause unknown
• [ ] 4. dimples on smooth cube, light == camera position
  • failure: erroneous shadows around the dimples
• [ ] 5. non-rotated cube with dimples, check for artifacts
• [ ] 6. non-rotated smooth cube with dimples, check for artifacts

[BudgiePanic]

it would be nice if concrete shapes had a name attribute to help identify which shape is which in the compound union cube

[BudgiePanic]

found Heisenbug with TimingWrapper camera class

in the unit test I wrote, a normal camera was used. The output was different to the CompoundShapeDemo despite being the exact same scene

changing the unit test to use a TimingWrapper camera caused the output to become the same, but even more confusing, the output remained the same even after changing back to a normal camera

[BudgiePanic]

in a simplified test case, it looks like the bug is in the filtering of compound intersections method,

specifically in the case where left shape only produces one intersection (such as a plane, or high angle intersect on a cylinder with no lids)

[BudgiePanic]

when this is the case, the shadow ray intersects with the cylinder behind it, and has 2 intersections with the difference sphere in front of it. These sphere intersections are not being filtered, when logically they ought to

[BudgiePanic]

[BudgiePanic]

optimization for the future:

• when shading hit in world
  • you need to phong compute each light source, but you only need to cast the refraction and reflection rays once
• current implementation is casting refraction and reflection rays for every light source

[BudgiePanic]

I believe the root cause of the issue is that for shapes that do not enclose a volume, it is possible to cast a ray that will intersect with the shape only 1 time. examples include

• triangles
• planes
• cones and cylinders with no end caps

when this occurs the iterative algorithm in the CompoundShape::filter function will be in the following state:

• inLeft = true
• isLeftHit = false in this state, if the next intersection is for a different object the difference operation will always pass

we need to be more selective about when we set the inLeft flag because the ray might actually be leaving the object when it's first intersection is encountered

• [x] create a unit test for this edge case in CompoundShapeTest
• [ ] set the inLeft flag iff isLeftHit was true and at least one of the following intersection's shapes is also contained in the compound shape's left shape (if inLeft is true and we never encounter another intersection to 'exit' left that implies a logical contradiction, we aren't really inLeft in that case)

[BudgiePanic]

The proposed fix in the above comment is not working because under its logic, a ray entering a shape and a ray leaving a shape are the same, which isn't true

Instead we will try use the trick from Intersection::computeShadingInfo by looking at the dot product between the shape's normal vector at the intersection point and the negation of the ray direction

if this value is less than zero, the ray has come from inside the shape, and this we can set the 'inLeft' flag

[BudgiePanic]

not sure if the above approach will work because the method is not designed to be provided with the ray

of course I can make a new method that is though, I'll give it s try

edit: doesn't work either

we need a set up that will pass this scenario, with and open cylinder

[BudgiePanic]

As a temporary work around to this problem, we need only avoid the use of shapes that do not enclose a volume in compound shapes

[BudgiePanic]

now that I think about it, the real problem here is that the shapes that don't enclose a volume aren't solid shapes, which defeats the purpose of constructive solid geometry

to wrap this issue up, we'll

1. make an issue for adding constructive non-solid geometry (I believe it will need a whole new algorithm)
2. log warnings if a non solid shape is added to a CSG shape
3. modify the shape API to allow testing for whether a shape is solid or not
4. add unit tests for the shape to ensure they comply with this new requirement