1)

If working with SingleSampler, a ray packet corresponds nicely to an 8x8 pixel area on screen. Thus for any ray index A in the packet, I know its top, down, left, right neighbors: A+8, A-8, A-1, A+1, mindful of modulo math of course. (Being unfamiliar and lack of docs, I do not yet know if neighbors can be inferred with other cluster, jittered, and etc. samplers)

 

Let’s say the first 32 rays in the packet intersect a plastic geometry and are each assigned the plastic material, and the latter 32 rays intersects nothing (the background). Because the Background is not a Material, the latter 32 rays do not get any assignment and their hitMatl remain the un-initialized 0xcccccccc.

 

Hence calling wasHit( 31 + 8) returns true, which is erroneous. resetHits() would be of limited use since it does not initialize the rays outside the packet’s begin and end indices. And resetting all 64 rays would wipe out calculated data.

 

Thus I added the initiation and sharing the experience in case it is useful.

 

 

2)

I reverted back to my first revision, in which I hijacked the for(;;) in void RTRT::internalRenderLoop(int proc, bool lateComerFlag), and stuffed this infinite loop into a WinMain(). Too bad the artifacts still appear for the scenes, default or not. Maybe this change is to blame.

 

Other than that, no change to where it is called or transactions. No addition or modification of modules in that revision.

 

 

3)

Understood.

 

For the memory layout, we have a Vector class in Manta that handles x0y0z0, x1y1z1, … xNyNzN.

 

Similarly, I wonder if an imagined Vector_grouped_by_component class catered to handle x0x1x2…xN, y0y1y2…yN, z0z1z3…zN would make the code more readable. Then again as you pointed out it is probably unnecessary.

 

 

Thanks

 

Bo