Edit 1: The first letter of the topic name seems to have fallen off but I trust you to get the idea ...
Edit 2: ...and only now I see that the letter is there, but slightly misplaced... Where do these things come to me from? :D
Edit 3: -removed-
Edit 4: A safe version of the script attacehd now. It also has the work-around implemented that is mentioned below
I have got this script (WIP) that is using raytracing to scan the volume of an object.
What happens is, that when there is a small(ish) file to work on, and/or the content of the file is simple the first traceRay() throws a NullPointerException. This only happens on the first run of the script during a Java session.
The chain to the source is:
RayTracer line 610: intersection.intersectionPoint(0, intersectionPoint);
There the culprit must be either the 0 (which I find unlikely) or the intersectionPoint which comes from:
RayTracer line 599: Vec3 intersectionPoint = r.rt.tempVec;
Vec3 intersectionPoint = r.rt.tempVec;
which splits to
RayTracer line 582: traceRay(r, firstNode, intersect);
RayTracer line 574: Ray r = new Ray(context);
RayTracer line 573: RaytracerContext context = getContext();
traceRay(r, firstNode, intersect);
Ray r = new Ray(context);
RaytracerContext context = getContext();
RayTracerContext line 36: tempVec = new Vec3();
tempVec = new Vec3();
Obviously it would have to be the tempVec that is missing, but the question is 'why'? Is the r missing too or maybe the context?
I suspect that this has somethig to do with timing. In the Glass_and_Rock.aoi, if I pick one of the primitives for scan, the bug occurs but, when I pick the Glass, then not. The Tetrahedron is somewhere in the middle: When I had more objcts on the scene, the Tetrahedron was 'safe', but having deleted some stuff, irrelevant to this case, it no longer is (on my current gear at least).
What I have checked so far is, that it is not related to the 'atomic' rays. It happes with the older Rays too.
Now to handle the situation, I put the content of the inner scanning loop (j-loop) into a try-catch block. The way I did it, it consumes about 10% of the performance, so it's not that bad, but since, so far I have seen the catch reporting back only once per session, it feels somehow wasteful.
It just occured to me, that I could have a raytracer trace a couple of "warm up rays" before going to the actual scanning. Just a simple while-try-catch thing until there are no exceptions.
Sounds like a race condition. Some field is getting accessed before it has been initialized. Can you post the code you use to create the raytracer and do the scan?
@Peter, it's in his attached groovy script. Very neat experiments, mostly happening over on frienlyskies.
Oops! I missed that attachment. Sorry about that.
I tried running it on a few different objects, but couldn't get the error to happen. And I don't see anything in your script that should be causing problems. It's all single threaded. I wonder if it could be a strange behavior related to the Raytracer.threadContext, which is a ThreadLocal? That's supposed to be completely thread safe, which is the point of using it. But it looks like it might be returning the object before it's fully constructed.
Earlier I had a prototype script, that was using the existing scene and had no methods -- just ran top to bottom. The problem did not happen there. It came along somewhere, when I wrote this script all in methods and had it create a new scene for each scanned object. I can't really say when, because I had a session open probably for a few days in a row and this bug needs a recently opened session to appear.
Just out of curiosity I tried to generate the error with the Snow script. Put the content into a method and had it create a new scene for one object. No bug there.
Also rendering a picture before using the script makes the bug disappear.
So I wrote a warmup method that is called after finishConstruction(). It traces rays until one is good. There's never more than one bad one.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.