Init Error with Py5 in a P3D mode

[claudefalbriard]

I'v built an updated platform with a RISC-V processor RV2, Operating system: Ubuntu 24.04.4 LTS, OpenJDK Runtime Environment (build 25.0.2+10-Ubuntu-124.04), Python 3.12.3 and all the JOGL .jar files added in the CLASSPATH.
The DISPLAY variable was set to local: export DISPLAY=:0.
When running a sketch with a py5-run-sketch command inside a bash script, I get the following error message:

Java exception thrown by Sketch.runSketch:
java.lang.ExceptionInInitializerError
Java exception thrown by Sketch.runSketch:
java.lang.NoClassDefFoundError: Could not initialize class com.jogamp.newt.NewtFactory

Doing the same with P2D renders I get nice Py5 graphics with no errors. What is the best way to configure the 3D resources? Is there some
hardware graphics driver dependency for new RISC-V arquitecture like missing .so files in the JOGL package? Hints or insights are welcome.

[hx2A]

Hi @claudefalbriard !

I am confused why you are experiencing these problems. The P2D renderer is actually a watered down P3D renderer, so if the P2D renderer works, the P3D renderer should work as well. Can you share the code you are using? I'd like to see an example that gives this error and an example that works.

all the JOGL .jar files added in the CLASSPATH.

What do you mean by this? The py5 library comes with the JOGL jar files and it adds them to the classpath itself. If you'd like to test this, you can try this:

import py5
import py5_tools
print(py5_tools.get_classpath())

You can then verify that all the listed jar files exist.

[villares]

Cheers @claudefalbriard !

To be clear the default py5 renderer, when you use something like size(500, 500), is not P2D, I don't know how to call it (the default Processing renderer?)... P2D comes into play when you call size(500, 500, P2D) or py5.size(500, 500, py5.P2D) if you are using module mode.

[GoToLoop]

, I don't know how to call it...

It defaults to JAVA2D; which is also a valid render mode string constant:

https://en.Wikipedia.org/wiki/Java_2D

https://GitHub.com/processing/processing4/blob/processing-1314-4.5.3/core/src/processing/core/PConstants.java#L60-L73

[claudefalbriard]

Dear colleagues,

Seems like I got into a snooker situation under Ubuntu 24 using a the Python venv based instalation procedure. Here the results from my testings:

My machine is of different arquitecture (riscv64) so I have done a manual execution of the Thonny install bash commands, line by line. See the resulting PIP list below.

When using the setuptools at its current version the Thonny package manager is not able to search the py5 package using its Manager function (input inhibited). When doing a backgrade of the Python setuptools to a previous version like 80.10.2 the lookup and download works smooth, but it throws an error like this:

× Failed to build installable wheels for some pyproject.toml based projects
╰─> jpype1
Process returned with code 1

Attached
(.mypy5) orangepi@orangepirv2:~$ pip list
Package Version

---

argcomplete 3.6.3
astroid 3.2.4
asttokens 2.4.1
bcrypt 5.0.0
bitarray 3.8.1
bitstring 4.4.0
cffi 2.0.0
cryptography 46.0.7
dbus-next 0.2.3
dill 0.4.1
docutils 0.21.2
ecdsa 0.19.2
esptool 4.8.1
intelhex 2.3.0
isort 5.13.2
jedi 0.19.2
librt 0.9.0
mccabe 0.7.0
mypy 1.11.2
mypy_extensions 1.1.0
numpy 2.4.4
packaging 26.1
paramiko 3.4.1
parso 0.8.6
pathspec 1.0.4
pip 26.0.1
platformdirs 4.9.6
ptyprocess 0.7.0
pycparser 3.0
pylint 3.2.7
PyNaCl 1.6.2
pyserial 3.5
PyYAML 6.0.3
reedsolo 1.7.0
Send2Trash 1.8.3
setuptools 80.10.2
six 1.17.0
thonny 4.1.7
tibs 0.5.7
tomlkit 0.14.0
typing_extensions 4.15.0
websockets 13.0.1
wheel 0.46.3

Current standard version of Jpype is:
jpype1 1.7.0

Quick Fix: Try installing an older version that might have better compatibility.
Backgraded version is now:
jpype1 1.6.0
A manual install made a building wheel message, spinning long but completed sucessfully.

Only the JDK Version 25 works fine with my screen on the RiscV64, JDK Version 17 does not.

Default renderer with no choice displays 800x800 nicely and with good animation speed.
The P2D and P3D renderer throws an error.

Java exception thrown by Sketch.runSketch:
java.lang.ExceptionInInitializerError

Conclusion: Likely some issue, or conflict with the Jpype version.

[hx2A]

There is a problem with JPype 1.7.0 right now. It is a pain to get it to compile from source which is required on MacOS machines. I recommend going to 1.6.0 instead. They will release 1.7.1 soon to (hopefully) make this easier.

[claudefalbriard]

Sample py5 source code for testing:

p = 0.0
t = 0.0

def setup():
    # P2D causing error
    size(800, 800, P2D)

def draw():
    # background(128)
    global p, t
    stroke_weight(1)
    begin_shape()
    t = 0.0
    while t < 50:
        x = 3 * exp(0.1 * t) * sin(t * 2 * sin(p)) + 400
        y = 3 * exp(0.1 * t) * cos(t) + 400
        curve_vertex(x, y)
        t += 0.1
    end_shape()
    p += 0.001

[hx2A]

Can you install the Processing IDE (the PDE) and try running a P2D or P3D sketch through that? I suspect there is something more fundamental at play here explaining why OpenGL doesn't work.

[hx2A]

Here is the download page:

https://processing.org/download

The Linux download is for Intel CPUs, which I don't think is what you want. You probably want the Raspberry Pi download.

[hx2A]

After thinking about this some more, I have an idea.

The OpenGL functionality requires native libraries, and py5's code queries Java to get the Operating System and CPU architecture to pick the correct set of native libraries from this list:

https://github.com/py5coding/py5/tree/main/py5/natives

Can you tell me more about your machine and which set of native libraries is the correct one to use?

Since I've never tested this on the machine you are using, it is possible it is picking the wrong one or maybe not adding anything at all. If you can get the P2D or P3D renderers to work with the Processing IDE (above), then I think it is likely that this is the case. If so, I'll need your help to test a few things so I can fix this for the next version of py5.

And even if you can't get the Processing IDE to work, this still might be the problem. But let's take this one step at a time.

[claudefalbriard]

You are right, there seems to be an arquitecture mismatch between my new processor board (arquitecture=riscv64) and the
currently supported machine. See the display from snap install of processing package:

orangepi@orangepirv2:~$ sudo snap install processing --classic
[sudo] password for orangepi: 
error: snap "processing" is not available on stable for this architecture
       (riscv64) but exists on other architectures (amd64, arm64).

A native adjustment is required to compile and link the new header files and make it availabe to processing and Java. I've tested the JPype1 undeer the latest JVM Version 25 and the basic funtionality and calls are working. Looking forward to hear your instructions how to add support for the emerging riscv64 to enable the P2D and P3D renderers in Py5. Here the link to the RISCV organisation https://riscv.org/

[hx2A]

How different is riscv64 from Raspberry Pi's arm architecture?

Can you run the following code and tell me what the output is?

import jpype
import jpype.imports

jpype.startJVM()

from java.lang import System

print(System.getProperty("os.arch"))

[hx2A]

If the result is riscv64, and if it is true your hardware has a different instruction set than Raspberry Pis and Intel/AMD CPUs, your only option here is going to involve compiling the JOGL libraries from source.

[claudefalbriard]

Confirming, the machine arquitecture is "riscv64". See the test log below

(.mypy5) orangepi@orangepirv2:~/.mypy5$ python test_arch.py
WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by org.jpype.JPypeContext in an unnamed module (file:/home/orangepi/.mypy5/lib/python3.12/site-packages/org.jpype.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

riscv64

[hx2A]

Confirming, the machine arquitecture is "riscv64"

That's what I feared. If you are feeling ambitious you can try compiling from source, but I imagine it will be time consuming and there is no guarantee it will even work.