raceTray() misfiring the first ray

  • Pete

    Pete - 2016-08-25


    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;

    which splits to
    RayTracer line 582: traceRay(r, firstNode, intersect);
    RayTracer line 574: Ray r = new Ray(context);
    RayTracer line 573: RaytracerContext context = getContext();

    RayTracerContext line 36: 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.



    Last edit: Pete 2016-08-27
  • Pete

    Pete - 2016-08-25

    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.

  • Peter Eastman

    Peter Eastman - 2016-08-25

    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?


  • Luke S

    Luke S - 2016-08-26

    @Peter, it's in his attached groovy script. Very neat experiments, mostly happening over on frienlyskies.

  • Peter Eastman

    Peter Eastman - 2016-08-26

    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.


  • Pete

    Pete - 2016-08-26

    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.

    Strange thing.



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks