Env3D, now with jME3

Hi all,



After a crazy week of learning and coding in jME3, I managed to port Env3D to jME3!



For those who are interested, env3d (http://env3d.org) is an educational 3D engine designed for introductory Java programming courses. Under the hood, it uses jME for all the heavy lifting.



A couple of unique features of env3d are: BlueJ IDE integration, and easy applet deployment. Both of these are now implemented with jME3. If people are interested, I can help write up a tutorial on running jME3 under BlueJ.



I managed to convert one of my student’s project to this new jME3 version:



Berts Adventure with jME3



Here is a link to the jME2 version so you can compare:



Berts Adventure with jME2

6 Likes

Cool, congratulations :slight_smile: So, you feel like your under-the-hood code got cleaner or rather more convoluted after the change? We didn’t get feedback about many real jME2 to jME3 porting attempts or results yet.

The code is definitely cleaner. What used to be dozens of lines of code is now a only few lines long. I think the change that is most significant is the material and asset management system. The new material system is so much more simplified and I found myself using very little “boiler-plate” type code.



One thing that got me in trouble was the use of Class.forName() to load classes, which is somewhat incompatible with the BlueJ’s class loading mechanism, but I managed to find a solution for it after some digging around with setting the context class loader.



All in all, I much prefer jME3 over jME2. Now I’m going to work on integrating some of the more advanced features like water and terrain.

Thats good to hear, @Momoko_Fan put a lot of (fruitful) thought into those. Any big problems with the different variable handling? Like no getLocalTranslation().set() or even cam.setLocation(spatial.getLocalTranslation()) from jME2?

Since jME2 is so different than jME3, my approach was to create a brand new project and re-implement each class one at a time. This makes porting painful but helps in my understanding of how jME3 works. It also makes missing methods in jME3 a non-issue as I was able to work around them most of the time.



One such example is the terrain system where the new version does not allow me to get the surface normal for any point easily. I was able to implement my own surfaceNormal method using the collisionPicking method of the new terrain system.

I’m diving in porting my old plugins to the new Alpha-4 platform now but I’m can help my self saying that I’m really impressive to see what@batkid are doing …



My dream is : “a KID or even a MONKEY :smiley: can make a serious/crazy/fun game…”



I’m not have much experiences with BlueJ but is there any chance we can have the game logic made by blocks like just drag in parts of a flow chart … :stuck_out_tongue: (It’s the sweetest thing which in the old day, I’ve dream that Java can do …)



Anyway, congratulations man… Keep up your definitely good work…!

We could easily add an Env3D API jar distribution to the SDK contributions update center. For all monkeys that still find jME3 too hard to code :slight_smile:

@atomix: Thanks! That is a dream of mine too! To make programming games/simulation as intuitive as possible – I am actually also thinking about how a “drag-and-drop” interface would work.



@normen: Sounds like a great idea! Just let me know what I need to do. Later on, I could even write up some tutorials on how to transition from env3d to jME3.

Cool, theres info on how to create a jar library for jMP in the wiki, down where the “recipes” are. First make sure you setup jMP correctly to develop plugins (first link on that page). For the descriotion stuff, you can also create manual entrys pretty easily using JavaHelp support in jMP. Nudge me when theres questions left.

Ok, I’ll take a look at jMP and see if I can get env3d integrated.

Wow that’s great @batkid , I know you’ve been contemplating this for some time :slight_smile:



More tutorials and downloads directed ad BlueJ/Env3D would be great. It’s definitely in our favor to appeal more strongly to educational institutions.

I have been looking at JMP and was successful in creating a lib module for it. I do have a couple of questions:


  1. Env3D comes with some assets (textures, models) – should I package them as a jar or an assetpack?
  2. I suppose I need commit access to the JMP modules area to include this in the update center?



    I also want to say that JMP is a great idea! It makes working with the jMonkeyEngine much more streamlined, and the scene and terrain editors could be very useful. I am thinking of actually creating an env3d module where users can create a basic env3d application, with palette for code examples and such. This would be great for a second semester course. I would then create some tutorials on env3d->jMonkeyEngine transition, etc. What do you guys think?



    For now, I’m also having lots of fun working with new features of jME3, including the jbullet integration. Here is an example program of env3d utilizing jBullet, particle effects, terrain, and simple water:



    http://whalechat.com/env3d_jme3/appletloader.html



    Let me know if the demo works for you.
  1. A jar would be best, you can add it to the standard env3d lib so it will be added to the users projects automatically when they add env3d.
  2. Yes, just PM me your googlecode contact
  3. Sure, thats what jMP was made for, more features for env3d development would surely be cool to have :slight_smile:

    Cheers,

    Normen

Looked at the applet, I had to allow an “unknown certificate” like 10 times or so, but then it ran fine. Looks cool :smiley:

@normen: which os are you on? I only need to allow it once on mine.



Also, the certificate is an unsigned one that I created… the reason why is because some features of env3d uses reflection – which counts as a security violation, so I need to resign all of the jars with a new cert (since java has a problem with mixed certificates). Sigh…

I am on OSX 10.6 with Java 1.6 and Safari (execute Java apps in browser process)

I was able to run it… only made me allow the exception once. Windows XP on Firefox, JRE 1.6.



The water is super-fast jittery but other than that it was fun.

batkid said:
@normen: which os are you on? I only need to allow it once on mine.

Also, the certificate is an unsigned one that I created... the reason why is because some features of env3d uses reflection -- which counts as a security violation, so I need to resign all of the jars with a new cert (since java has a problem with mixed certificates). Sigh...

I only had one unsigned certificate to approve. Reflection works fine with unsigned code, as long as you're not trying to access private methods/fields outside of what the Java language normally allows.

I have a few comments about the applet itself:
There's a lot of framerate dependence, if its high, then the "strength" parameter increases really fast when you hold the button, while it increases slowly when framerate is low.
The physics can get really slow at times, especially when there are a huge number of cubes around or you hit the house. You might want to use a HullCollisionShape for the house, or something even more basic, while the cubes should be faster if you reduce physics accuracy or try to play with the broadphase/narrowphase collision parameters (if any).
Momoko_Fan said:
I only had one unsigned certificate to approve. Reflection works fine with unsigned code, as long as you're not trying to access private methods/fields outside of what the Java language normally allows.


That's exactly what I'm trying to do :) I need access to private members so I cannot get around the custom certificate issue.

Momoko_Fan said:
I have a few comments about the applet itself:
There's a lot of framerate dependence, if its high, then the "strength" parameter increases really fast when you hold the button, while it increases slowly when framerate is low.
The physics can get really slow at times, especially when there are a huge number of cubes around or you hit the house. You might want to use a HullCollisionShape for the house, or something even more basic, while the cubes should be faster if you reduce physics accuracy or try to play with the broadphase/narrowphase collision parameters (if any).


Thanks! To keep things simple, the basic env3d framework is highly framerate dependent (everything runs in a single thread). I'll work on an example using threads to highlight the difference. I'll also check the various collision parameters.

I modified the input so it runs on a different thread – it runs better now.



Except that the collision with the house still results in a drastic reduction of framerate. I am already using a BoxCollisionShape for it. Also, I noticed that if the mass of the house is 0 (static), then the framerate is rock solid. You can switch the mass of the house with the “m” key to test.



Is this expected behavior? Thanks.



http://whalechat.com/env3d_jme3/appletloader.html