JME3 and Processing

I have just finished the first rough pass of integrating the Java project at with JME3 for displaying cool looking HUDS and screens inside worlds, check out the screen shot, it shows several processing ‘screens’ being painted onto JME Box Geometries, these are animated, and the animation looks good, when I get something more polished finished I’ll contribute the source. One problem I think I am already seeing is the memory consumption jumps quite a bit. These seem to have a lot of potential as either textures inside the game or as textures on Pictures used as HUDs.

Anyone else working with the Processing library?


How much frames are used in the process of drawing this onto a texture?

When I tried a swing jme bridge that was the bottleneck

atom said:
Anyone else working with the Processing library?

I really wish I was


I have a couple of test cases right now that have 3 or 4 processing ‘sketches’ running. Each sketch updates 60 times a second the image the texture should display. The frame rate on the sketches is adjustable, also it is possible to turn them on and off with loop() or noloop() methods. The fps of the JME3 application seems to be pretty good still, ~400fps for one and only about ~ 80 for the other. I suspect you would have to use these sparingly, but that is OK with me. I will get back to this thread with a sample to download as soon as I get a chance.


You should download the processing application and get started looking at the examples, it is really easy, has it’s own IDE. Easy as new…example…3D…etc.

If you want to use it stand alone or integrated into other Java applications you can find information in the sources in the PAppet class on how to do that. 8)

I have an example to try if anyone is interested. I would love to hear how it works as far as smoothness of the processing animations and fps in general.

JME-Processing B-Ball 8)

Just unzip and run ProcessingAndJME3.jar…



Oh, and you have to imagine the vertical rectangle close to the camera is a ‘hand’ that is shaky, it’s location affects the aim of the ball :wink:

1 Like

What about adding this to the contribution repo so people can download and install it easily in their projects

Hi Norman, I will do that as soon as I am satisfied with the quality of the source. The code still needs some cleanup, comments and there is still an issue with applets. If I try to run as an applet I get an error when trying to fire up the Processing Applet. Something like classloader access denied or something. I will work on it more and see if I can fix it. If I can’t figure it out I will post the exact exception and see if someone can help. Did you download the example and run it, did it run ok? Also, thanks for all your hard work norman, I have been lurking for a few months and really enjoy your forum posts :slight_smile:

Test worked good, but the number of textures was going kind of haywire, maybe you should reuse/combine the textures more often? Anyway, for the contrib repo you’d only need to commit a new jar every now and then or even let the project build when the plugin is built each time, so you can still apply fixes and patches… And btw, my name is really Normen :wink:

Really fun stuff, might be a good fit for a spotlight post later. Have you presented this to the Processing community yet? I’m sure they’d find it interesting too.

@normEn, :wink:

I also noticed the texture number swinging wildly up and down. I will see if I can take care of that. I haven’t really looked at the contrib repo yet and did not know how it works, I will check it out and I may be submitting something sooner that later :slight_smile:


Thanks for testing it, I have not submitted to the Processing community, thanks for the suggestion, I will do that.

The use of the contrib repo and how to wrap a normal java library as a plugin is all described in the documentation (F1) or the wiki.