I’ve started porting the org.lex mousemanager & strategichandlers to jME3. They’re pretty rough right now, but the mouse stuff is functional.
Download:
http://www.gravityresearch.us/portal/?p=57
2 Likes
Oh, cool. I moved this to “jme3 contributions” so it doesnt get lost too quickly 
If you have more things like these, post them there as well. Of course we’ll have to check the code before we add it to jme3 but its great to see contributions like these saving us some work! Thank you very much.
Cheers,
Normen
I’ll be cleaning the code up a lot over the coming days&weeks. I need to get permission from our gov’t customer to hand over our openflight loader (based off of the openscenegraph reader) and other items.
Oh joy, I’ve been waiting a long time for someone to do this actually 
Lex was about to do the port himself at one point, then he got busy with his Scala engine.
Sounds like you’re eventually gonna have quite a few jME3 projects scattered around somewhat. Do you think there will be a “common denominator” so to speak that will bind them all together? That way it’d make sense to create a group dedicated to such a project.
Well, the common denominator, so to speak, is OneSAF Ares. It is a composable sandbox engine based on top of jME. It is meant as an alternative front-end to the OneSAF simulation product. Various parts of the engine can be swapped out via a system composer tool: SceneManagers, GameState collections, etc. We have a core set of scene managers built up to populate the jME scene: Battle Space manager (lifeforms, vehicles, mines, weapons caches), Atmosphere manager (skybox, lighting – direction & luminance tied to sim), Warfare (weapon fire lines, detonations, fires, nuclear/biological/chemical clouds), HUD manager (2d on screen interface + tools for making tactical graphics (areas, routes, points of interest)), and the big daddy: Terrain manager.
All of the basic managers are meant to be extended or replaced all-together by co-developers, but we try to make them as complete as possible. For instance: my terrain manager is a modified quad-tree that renders OTF terrain data which uses integrated triangular irregular networks(ITIN) – great optimization for simulation activities, not so much for game/LOD activities. This lets us view 100% correlated terrain for the system. It also supports dynamic terrain events: cratering, revetment creation, trench creation, adding buildings/bunkers, etc. Because it is 100% correlated it has been a big help in debugging certain entity behaviors. In the future I want to port some of the work done in Biosphere3D for spherical clipmaps into jME. It will be height-map based and will have trade-offs when used instead of the ITIN terrain, but the idea is to use the right collection of game components for the desired effect.
I’ve also had to create a custom game state manager that allows me to mix&match components to create the desired game. For instance, we have a game state collections for creating: real-time strategy game, first-person control over entities (vehicles, lifeforms, robots), and a stealth viewer (think of this as a read-only view). Then it is a matter of using our system composer tool to drag and drop components into the system (core ares component, desired managers, and game state collection) and saving out the application composition.
What can be handed back over to jME will be mostly peripheral items developed to support Ares: model & texture loaders, strategic handler updates, etc. Ares itself is a part of OneSAF, which is GOTS / government open source software, and is pretty much limited to the DoD community. I don’t think you can get your hands on the software w/o a DoD sponsored program.
Finally back to porting our stuff over to jME3 full time now.
Had some time to complete most of the StrategicHandler’s functionality.
Download source&dist here: http://www.gravityresearch.us/portal/?p=67
The archive contains a slightly modified swingGUI. I would occasionally receive a GL bad enum error from the first Util.checkGLError(); in LWJGLImageGraphics.java line ~105. Choosing to ignore the exception is functional for now.
To test it out run this test:
jme3test.input.TestStrategicHandler
To-Do:
Update SwingGui and StrategicHandler to play nicer with each other. Need to add ability to disable SwingGui from sending AWT mouse events and let the StrategicHandler do it instead.
1 Like
Very cool, the StrategicHandler keeps coming up, I’m sure a lot of people will appreciate this being available for jME3 now.
I don’t get what it’s got to do with a Swing GUI though, what’s up with that? As far as general purpose use goes, I don’t see where swing comes in.
In my our sim product has an extensive collection of Swing-based widgets. Swing GUI uses the hardware mouse position to feed AWT input events. I’d like the ability to disable the feature of SwingGUI to have the StrategicHandler control the AWT input because the cursor location may not necessarily be the hardware location. Currently I have the SH using the hardware location for cursor location since I have bigger fish to fry in my jME3 application upgrade, so the cursor jumps when you rotate the view.