Add cone primative about source HOT 9 CLOSED

cone primitive could be specified with two radii values and a height.

from source.

Cone primitive is now mostly working. Need to fix a bug where it fails at a certain angle.

from source.

Completed in commit 52c724e.

from source.

Closed prematurely

from source.

There appears to be a bug in the cone code, it does not appear to populate the next_intersection cache in the hit() method.

from source.

I found another problem with the cone. Turns out the new code section to detect the tip and base wasn't being run. Line 287 was commented out. Instead it was only using the crude method that moves the hit point in the negative direction of the surface normal. Lines 289-291. Anyway, the crude method was working fine but I know you would prefer to use the more robust method.

When I tried to run the more robust code, it failed to work again. I added some print statements to see when the cone tip and cone base segments are running, because the are really rare and should rarely be running. Turns out the cone tip code is running for nearly every ray. I added some debugging code on lines 312-316. Here is some sample output

cone tip
cone_height = 0.3
hit_point.z = 0.5213630038403056
diff = -0.22136300384030566

How can the hit_point in local space have a z greater than the cone height? That doesn't make sense. It should be between zero and the height.

from source.

The problem seems to be due to the z coordinate. Original calculation for interior point:

old_radius = sqrt(hit_point.x**2 + hit_point.y**2)
new_radius = old_radius - EPSILON

scale = new_radius/old_radius
x = scale * hit_point.x
y = scale * hit_point.y
z = hit_point.z

Keeping the z coordinate the same is what is causing the problem. It needs to move inwards like the others. Becomes:

z = hit_point.z - EPSILON * normal.z

from source.

Handing over to Alex to finish.

from source.

Cone added in commit 6770010

from source.