problem with refraction?

[Peter Eastman]

At what point does trueNormal have the wrong value? The most obvious connection to direct lighting is that true normals are queried inside traceLightRay(), which is called to determine the contribution of each light source. But it uses the last element of the workspace array (trueNormal[maxRayDepth]), so that shouldn't interfere with other uses of elements from that array.

Peter

[Luke S]

At what point does trueNormal have the wrong value?

Sorry, I was wrong about this. Partly confused by the multiple threads, took me a while to get the hang of tracking exactly where I am.

I've run another experiment, which I will leave for you to interpret for the moment.

• Set a camera such that the field of view is entirely in teh shadow zone.
• Set a breakpoint at RaytracerRenderer.java Line 1552. (if (hitObject.getMaterialMapping() == null))
• Toggle visibility of the shading cylinder. Note in the stack frame that the level 0 tree depth ray and intersection point for worker thread 1 are the same either way.
• When you dig into hitObject, you will find that matMapping == null and mapping (texture) tracks back to the default texture, though that is not what is set for the cube.

Now I am really, really lost. Is the construction of renderingMesh being affected by the presence of other meshes being added to the scene?

[Luke S]

I'm banging my head on a brick wall here.

Just re-ran the "test" from above and I cannot duplicate the supposed results. All material mappings, etc. seem to make sense.

However, the rendering bug is still happening. @peter can you at least confirm that you see the actual rendering artifact?

Just also figured out how to limit my testing JVM to 1 core, so won't have to work around multiple worker threads. I really don't want to give up on this, but I'm not sure exactly what I'm looking for. I'm going to list observed effects without my inferences, which may be wrong. Any thoughts on what to look for?

• Given two mesh objects and a primitive light,
• Where one object shades the other from the light
• The shaded area will render as if the object has no material.

[Luke S]

Just ran some step-throughs in debugger that have me even more frustrated. I focused on just a couple fo specific lines, and the results would suggest that everything is working perfectly.

Line numbers refer to RayTraceRenderer

I tracked a single eye ray from the time it first intersects the cube in my scene till it spawns its child ray(s). I was able to lock AOI to a single core, so got the first ray, same origin in both cases.

• 1567 NextMaterial is the refractive material from my cube
• 1611 'temp' is -.03 -.67 -.74 //direction of refracted ray.
• 1618 d == .67 //calculated from other properties, just a handy spot to do a consistency check.
• 1634 temp still matches direction as before, not modified without 'Gloss' being set. Here it is being placed as the direction of the 'transmitted' child ray.

Exact numbers are not the point here, what is the point is that in both the problematic case, and the one that renders correctly, these values are the same. This is true despite the fact that an enclosed object is displaced in where it is rendered from case to case, so presumably, the rays that intersect it must be bent differently at some point.

Not sure what this implies for the location of the bug.

[Peter Eastman]

I was certainly able to reproduce the problem in Nate's original scene. I'll try to look into this more and see if I can spot anything. Unfortunately, I'm going to be away for a couple of weeks, so it may be a while before I can actually debug it properly.

It does sound like the problem is related to tracking which material it's currently inside.

Peter

[Luke S]

Okay, thanks for looking. I'm going to keep poking at this one in the meantime. Perhaps I'll find it...

[Luke S]

Hey, this has been tickling the back of my mind for months now. I may take another stab at it in the next few days. Has anyone had a flash of insight/random thought/ etc. that might make the job easier?

[Nik Trevallyn-Jones]

I just saw this thread - yet I believed I was being notified of all AOI messages.

In my experience, any problem that is sometimes reproduceable and sometimes not - and/or where values in the debugger make no sense, or even seem "impossible" when compared to the code - are almost always thread-safety issues.

So once you find a field that "cannot possibly have that value", track back in the source until you find the point where it could get that value, and then start reasoning about how one thread could end up seeing that value when according to the code either that thread, or some other thread should have changed the value by the current point in the code.
Then look for memory barriers between those 2 points in the code.
A memory barrier is either:
a synchronized block;
access ofa volatile;

Common fixes for thread-safety issues include:
changing global state (eg class-level static fields) to being ThreadLocal;
making classes immutable;
using Atomic types;
making shared fields volatile, and understanding how the "happens-after" contract work with volatiles;
* "correctly" applying synchronized blocks;
* where "correctly" is left as an exercise for the reader, and is generally considered to be of NP complexity :)

Cheers!
Nik

[Luke S]

Thanks for the hints, I will keep them in mind. This one, I think, is the current blocker for preventing a new release.

This bug is definitely 100% reproduceable, given the right setup. It manifests even on a single thread, in a location that is owned by that thread.

I've been having trouble tracking exactly where some of the values come from.

Part of the code uses a Ray[] accessed by an int. index for performance reasons, and what I need to find is where the rayArray[1] object is created. Not easy to set a breakpoint for that.

[Luke S]

So, a little progress that may actually take me nowhere.

In the problematic case, the renderer is no necessarily using a null material. Instead, it applies the IOR of the material that is mapped in the shading object. AFAICT, it is not using any of the other specifications.

I see that every rendering thread has its own RenderWorkspace, with a recycled object pool. I'd assume that this is to avoid object creation overhead.

I also see that the methods spawnRay() and getDirectLight() will copy a reference to some of the object pool objects into local variables, like so:

RGBColor col = workspace.rayIntensity[treeDepth+1];

//and a bit futher down

temp = workspace.ray[treeDepth].tempVec1;

And then goes on to manipulate the object directly using the local references. This makes it hard to track exactly what object is actually being updated. I am pretty certain that somewhere in here, the wrong object is being accessed or set. Just need to figure out where.

[Luke S]

@Nathan Ryan, Nik, and anyone else bit by this bug: I've checked a fix into github. I appreciate the patience and hints.