I’m trying to learn how to use the Processing library with Eclipse to solve a puzzle (Rubik’s Cube) my son challenged me with. The main problem seems to be with using P3D in Eclipse. Here is the test code:
import processing.core.PApplet;
import processing.core.PConstants;
public class UsingProcessing extends PApplet {
// The argument passed to main must match the class name
public static void main(String[] args) {
PApplet.main("UsingProcessing");
}
// method for setting the size of the window
public void settings(){
size(500, 500, PConstants.P3D);
// size(500, 500);
}
// identical use to setup in Processing IDE except for size()
public void setup(){
background(0);
stroke(255);
strokeWeight(10);
}
// identical use to draw in Prcessing IDE
public void draw(){
line( 0, 0, 500, 500 ) ;
// line(0, 0, 0, 500, 500, 500);
}
}
With the above code, the output window is blank (nothing seems to be rendered), as shown in the left half of the below image. Also, the X to close the window and kill the process doesn’t work – I have to use the Eclipse stop button to halt the process. It doesn’t seem to draw anything, even after waiting several minutes, and the system appears idle.
If I remove the P3D option and instead use the two-argument size() method, the image on the right is output. This is the correct test output.
I have tried with Processing 3.5.4 and 4.0b2. I have tried uninstalling the JDK, JRE, and Eclipse, and reinstalling to no avail, despite building new Eclipse projects.
Any ideas what I might be doing wrong, or where else to look?
Just tried your code on my Eclipse setup and it works so I agree it is probably because you have not linked in the OpenGL library jars.
This shows my build path -
I think you have something weirder going on here. I would have thought you wouldn’t get as far as seeing a window if jars were missing, or at least see an obvious error message.
Maybe try porting the specs test example (from Examples / Demos / Tests) and compare the output in Processing and Eclipse.
Thanks for the ideas. I ran the Specs test, and got some interesting results. First, the Specs instance ran and created a blank window, as before. No indications of versions of different PGraphicsOpenGL variables as expected. This caused me to think that something is wrong with how the library draws. So I switched the println()'s as above to System.out.println(), and still nothing (in console or frame).
I moved the System.out.println()'s to the settings() method, and it produced all nulls:
null
null
null
null
null
So I set a breakpoint on the draw( ) method and discovered the method is never reached when using the P3D, but it is called repeatedly for 2D graphics (two arguments to size() method).
All of this is after again uninstalling Eclipse and reinstalling, but this time using a clean .settings folder (on my desktop).
Maybe the Java version? I remember having issues unless I used the Adopt JDK version, and if I remember right using the most recent version didn’t work when I tried. It works fine for me with P3D in IntelliJ Idea with Java 14.
There used to be a linker issue with certain versions of JDK on linux, but that seems to be gone now Choice of OpenJDK is Critical - #4 by monkstone, maybe it persists with Windows? Generally I don’t rely on an ide to pull in dependencies, I prefer to set up a maven project, but then I never got on with Eclipse preferring Netbeans, however any half decent ide should be able to cope with a maven project. That @quark got your project to run suggests something odd about your setup.
Yes, annotations are metadata - they don’t change behaviour of the code. In particular, this one just tells the compiler to flag an error if the method isn’t an override to catch problems.
Is this with Optimus? I was curious at the results for the spec test in Processing and Eclipse to see if you had different GPUs / drivers in play. If so, is there a way you can test with a forced GPU choice?
Always a possibility! Can you compile in Eclipse but run against the JDK inside the Processing installation? Eclipse should have an option for running projects against a different JDK to the one you’re running the IDE on, somewhere … (not my choice of IDE)
As a NetBeans release manager, and a big fan of Maven, I cannot help but agree!