HI all,
Just wanted to direct your attention to a code project we spawned off of the Whole Brain Catalog that integrates a JME2 Applet with GWT, so you can create web-based 3D apps! Its pretty neat.
Check it out here.
Best,
Stephen
1 Like
Very cool! We actually wanted to do something exactly like this in place of our Applet showcase, but I don’t think it will make the top of the priority list until post Stable.
You wouldn’t happen to have an online demo available would you? How about a video? 
I didn’t get the full scope of this at first, but when you say “create web-based 3D apps” and I read that the applet can “receive an event from the UI”, I’m starting to catch on to the idea here, and it’s grand! Are there any known limitations to the interaction? Could I very well create an elaborate interface for a bunch of parameters that I wanted to play with in a specific jME demo?
Edit: Erm, that big fat link to the online demo was always there, wasn’t it? Wuups! Well I tried the demo, though it’s loading very slow and I’m having trouble loading applets on my Ubuntu, so will have to test on Windows later.
Hello erlend_sh,
I am one of the developers of this project. There are some problems with the Java installation in Linux systems, more specifically most Linux systems come installed with a ICE version of Java instead of the Sun/oracle Java version, which does not yield good results when running Java Applets. You will need to install Java Oracle in your Linux machine and update your browser Java as well. Even then, the support for Linux is still in the works, so for best result I recommend using Windows.
Here is a video showing the online demo. http://screenr.com/XYY
“Are there any known limitations to the interaction? Could I very well create an elaborate interface for a bunch of parameters that I wanted to play with in a specific jME demo?”
The communication between the browser UI and the applet is happening via AJAX push mechanism. The interactions is happening using strings, meaning the UI sends a command as a string value to the applet, which is charge of parsing that string into an actual event. So if I understand your second question correctly, you could create that interface for a bunch of parameters to you wanted to play with in the JME demo. However, once the applet receives those parameters from the UI, you will have to parse them into real events for the applet (aka move camera, add another box to scene, etc…) since they are just going to be strings when first received by applet.
Thanks for the answers @jrmartin . Sounds to me like this could easily be a great project (with jME3 though) for a GSoC student. Only problem is we probably wouldn’t have an appropriate mentor available. Maybe next year?
Hello,
More progress has been done in this project. For the past few days, we have integrated what we called the Drag and Drop 3D upload feature in the project. This feature allows users to drag and drop any OBJ file from their desktop and have it render automatically in the applet.
You can visualize this new feature in this video. http://screenr.com/Wkb
As before, the code has been commited to our google code project repository found at http://code.google.com/p/jmonkeyengine-vaadin-integration/ , which contains a link to an online demo that allows you to play with this feature and visualize your own 3D objects.
This is really interesting :).
Uh oh!
Exception in thread "thread applet-org.jmeappletintegration.example.SimpleJMEApplet-1" java.lang.LinkageError: Version mismatch: jar version is '21', native libary version is '22'
at org.lwjgl.Sys.(Sys.java:103)
at org.lwjgl.opengl.AWTGLCanvas.(AWTGLCanvas.java:84)
at com.jmex.awt.lwjgl.LWJGLAWTCanvasConstructor.makeCanvas(LWJGLAWTCanvasConstructor.java:45)
at com.jmex.awt.lwjgl.LWJGLAWTCanvasConstructor.makeCanvas(LWJGLAWTCanvasConstructor.java:42)
at com.jme.system.lwjgl.LWJGLDisplaySystem.createCanvas(LWJGLDisplaySystem.java:212)
at com.jme.system.lwjgl.LWJGLDisplaySystem.createCanvas(LWJGLDisplaySystem.java:189)
at org.jmeappletintegration.example.SimpleJMEApplet.init(SimpleJMEApplet.java:211)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Hey Momoko_Fan, could you tell me what OS and browser you used to run it?
Thanks
- jrmartin
I am using Google Chrome on Windows 7 64 bit.
You might have accidently put the wrong windows natives with your jars.
I re-added the natives for lwjgl 2.1, you should have better luck next time you try to run it.
Hmm, still no go … X_X
I can’t reproduce the error myself in any Windows 7 machine. When you open the link it writes the .dll natives to a folder called “wbc-natives” in your home directory. Seems to me that the new Dlls are not not being written to the user directory (since the code won’t write the dlls if they already exist) and it’s still using the old natives that was making it crash in your computer. If you can, would you mind deleting the folder “wbc-natives” in your home directory and then trying to run it again? Thanks.
Still not having any luck with this 
I deleted the wbc-natives folder and tried different browsers.
I am afraid the applet might be cached somewhere.
By the way, how come you’re not using the LWJGL AppletLoader but instead use your own?
It could be that the applet caching is what is preventing it from running in your sytem, you can manually delete the cache from the Java Control Panel which can be opened by going to Control Panel-> Programs, double click on Java icon. A pop up window "Java Control Panel " opens, inside the view that shows when the tab named “General” is selected there is a button named “Settings” which once clicked opens a pop up window. In that pop up window there is an option to “Delete Files”, which will delete any previous caching done by the applet.
We tried using LWJGL AppletLoader before, but we were not successful and had better luck using our own. Do you see any advantages on using LWJGL AppletLoader?
jrmartin said:
Do you see any advantages on using LWJGL AppletLoader?
Some advantages include:-
- You can use stuff like LZMA and Pack200 compression (which is built into the AppletLoader) for small and faster downloads.
- Alot of testing and bug fixing has gone into the LWJGL Appletloader hence allowing it to work and deploy properly across many platforms and bug fixing continues as any issues are found, so much more reliable then a custom solution.
- Many problems with the Java plugin are actually worked around in the AppletLoader including the infamous download caching problems (the LWJGL AppletLoader has its own download system and doesn't use the java plugin one).
- Allows providing a nice customisable loading screen while it does all the downloading.
- LWJGL has a static api, all applets by default run in a single vm, so if you run multiple LWJGL applets you run into problems, the appletloader internally has fixes for this and allows LWJGL to work flawlessly even in the same vm. Running applets in a separate VM was only added in java 1.6.0_10+ and even then its not enabled by default.
jrmartin said:
We tried using LWJGL AppletLoader before, but we were not successful and had better luck using our own.
There is now a full 4 part tutorial on the LWJGL wiki covering all there is to know about the LWJGL AppletLoader, here
Lastly just a note, not sure if its a jME issue or just that your using the wrong class but AWTGLCanvas, isn't the best way to do LWJGL Applets, much better to use Display.setParent(Canvas canvas). Its much more reliable, stable and faster.
Thanks for the detailed information on the matter faust, I will take a look at it to see if it’s easier to integrate this time around . I am paritcularly interested in the LMZA and Pack200 compression feature.
Also, we used AWTGLCanvas since we followed the SimpletJMEApplet class provided by JMonkeyEngine to create our applet. We made a few modifications to that class, for instance extending AbstractVaadinApplet instead of Applet to maket it work with Vaadin. You can find the JME class we used as an example here.