3D picking_Python mode

edited March 2016 in Python Mode


I'm a beginner who's trying to pick a 3D box with a mouse click using the Shapes 3D and PeasyCam libraries in Python mode.

I referred to this previous discussion: http://forum.processing.org/two/discussion/4066/peasycam-cursor-location-in-comparison-to-objects-shapes3d-#Item_9, but I'm getting a NullPointerException.

Here's the code:


clicked = False 
picked = None

Boxes = [] 

def setup():

    cam = PeasyCam(this, 150) 

    b = Box(this,30,60,100)

def draw():



    if clicked :
        clicked = False
        picked = Shape3D.pickShape(this, mouseX, mouseY) 
        if picked != None:    
            print 'preso!'      


def mouseClicked():
    clicked = True

Can someone take a look over this?

Thank you,




  • As written, that code shouldn't even run at all. The indentation is incorrect.

    What is the exact error message?

  • sorry, something happened during the copy process, indentation above is now ok. the message says:

    processing.app.SketchException: java.lang.NullPointerException: java.lang.NullPointerException at jycessing.mode.run.SketchRunner.convertPythonSketchError(SketchRunner.java:242) at jycessing.mode.run.SketchRunner.access$4(SketchRunner.java:221) at jycessing.mode.run.SketchRunner$3.run(SketchRunner.java:117) at java.lang.Thread.run(Unknown Source)

  • I wonder whether the sketch's reference is indeed stored in variable this or self? :-/

  • @JonathanFeinberg The code works only the first time afterProcessing is opened. If I stop and run again, the exception occurs. If I quit and re-open, it works again. @GoToLoop this seems to be correct. thanks anyway!

  • This is due to a bad assumption in the design of the Shapes3D library, namely, that a Java VM exits when a sketch finishes, which is not true for Python mode (which keeps a sketch runner resident in memory). It will have to be redesigned not to use static variables in order to be compatible with python mode (and, I'd think, the ruby processing wrapper that's out there).

  • The Shapes3D library was created for use with Processing 1.2.1 long before the existence of Python and JavaScript modes (it was first released in December 2009). It was written in Java and uses standard Java language features such as static variables and method overloading. I put in a lot of time and effort ensuring my libraries worked with both 2D and 3D renderers and with popular libraries such as PeasyCam. It now seems unreasonable to expect this library to be forwardly compatible with every mode created afterwards.

    Just because the Processing IDE supports multiple languages doesn't mean we should assume that every sketch or library will work in all modes (although it is one easily made by beginners to Processing).

  • ... features such as static variables and method overloading.

    I love those too! <:-P

    ... that a Java VM exits when a sketch finishes,...

    I've posted the source code for the final steps to close a PApplet in this thread:

     * Some subclasses (I'm looking at you, processing.py) might wish to do something
     * other than actually terminate the JVM. This gives them a chance to do whatever
     * they have in mind when cleaning up.
    protected void exitActual() {
      try {
      catch (SecurityException e) {
        // don't care about applet security exceptions

    As we can see from the comment, some dev actually blames processing.py!!! >:)

  • edited July 2014

    As a Processing beginner, I can only thank you guys for sharing your work (never underestimated or taken for granted) and for finding the time to answer.



  • edited July 2014 Answer ✓

    pickerNode = CollisionNode('mouseRay') pickerNP = camera.attachNewNode(pickerNode) pickerNode.setFromCollideMask(GeomNode.getDefaultCollideMask()) pickerRay = CollisionRay() pickerNode.addSolid(pickerRay) myTraverser.addCollider(pickerNP, myHandler)

  • @quark I'm so sorry I never saw your comment until now. Please excuse my poor wording in describing the design choice as "bad"; I should simply have said "not compatible with the way I implemented Python Mode". Python Mode has enormous startup costs, which is why I go to great lengths to keep the sketch runner running between invocations of some sketch.

    Of course it would be unreasonable to expect any library author to design to the idiosyncrasies of some non-base mode. On the other hand, if it's possible to remove the assumption from the design of the library, that would be great, too. But it's not the "fault" of you or your library, and I regret giving offense.

Sign In or Register to comment.