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.

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.

---

From: Abe Stephens [ " style="color: blue; text-decoration: underline; ">mailto: ] 
Sent: Wednesday, October 08, 2008 5:09 PM
To:  " style="color: blue; text-decoration: underline; ">
Subject: [Manta] Re: Some observations

 

Hi,

 

Comments inline:

 

On Oct 8, 2008, at 1:46 PM, Bo Huang wrote:

1)

The wasHit() function for RayPacket works by checking if the material corresponding to a ray is null.

 

When a RayPacketData is constructed, it does not set the hitMatl member array to null. Thus sometimes I receive erroneous hitMatl values when I call wasHit() for neighbor rays in the same packet.

 

Hence I explicitly added a memset to zero out hitMatl in RayPacketData’s constructor. It works for my purposes but perhaps there is a better way, knowing that under the current design perhaps one should not examine neighbor rays in the packet.

 

Call RayPacket::resetHits() first, see documentation in RayPacket.h.

 

I'm not sure what you mean by neighbor rays...?

 

2)

If I change

rtrt->changeNumWorkers(1);

to

rtrt->changeNumWorkers(2); //or more than 2

I get faster speed but the rendering becomes quite unstable. For example, some or most 64x64 tiles would be black periodically, even if the view is not changing. Or the tiles would overlap each other for some frames.

 

Does this occur for the default scene? If not which modules have you altered?

 

Also, are you using a transaction to call the method?

 

3)

I noticed at many places, vector math calculations are done like this:

 

// This is a vector multiplication

Real scale = 1/Sqrt(sum);

for(int j=0;j<3;++j)

data->normal[j][s] *= scale;

 

Why not expand this out to

            data->normal [0][s] *= scale;

            data->normal [1][s] *= scale;

            data->normal [2][s] *= scale;

 

The compiler is expected to unroll the loop.  Also, most fast code paths are implemented in SSE so this is probably a slow code path.

 

 

 

Or even wrap this around a vector library function vector_scale(float** normal, int idx, float scale) designed for data stored as

 

x0x1x2…xN, y0y1y2…yN, z0z1z3…zN

rather than

 

x0y0z0, x1y1z1, … xNyNzN

format?

 

The memory layout of normal[3][MaxSize] is the former. 

 

Abe