The short version is that we want to use jME3 to replace some old in-house software that still relies on Java3D for it’s rendering. We draw to an AWT Canvas. I’ve already gone through the tutorials for extracting the Canvas context from an application and embedding it in a JPanel, but this is still a little suboptimal. For example, one bug that we’ve encountered (on OS X, at least; can’t verify with Windows) is that if the jME Application captures the input, as in the Hello World example, then the escape key no longer frees up the input. Additionally, once in this captured mouse state, if I send Cmd+Q to quit the application, then the jME app receives this signal and disposes of the Canvas but the actual Swing app is still alive.
We work on simulation software, and already have a fairly robust in-house developed Swing app that implements its own input logic and application event loop. Instead of having the two loops fight each other or having to put in the effort to programatically kill all of this stuff from with in Application, we’d just like to investigate using jME 3 as a way to draw a 3D environment on a Canvas without all of the weirdness that comes from having an app living inside of another app.
Have you tried using jME3 AWT panels? They play a bit more nicely with Swing than the canvas.
Also, have you tried disabling input entirely? E.g. AppSettings.setUseInput(false)?
I have not yet looked at AWT panels.
We did set UseInput to false, and it fixed what we wanted to fix in the case of that specific example, but I’m dubious as to how complicated it will make handling input in the future; part of our simulation suite does involve engaging with the canvas using the mouse to affect changes such as moving the camera around or interacting with 3D objects in the scene by selecting them.
AWT Panels might be a good starting point. We’ve discussed internally writing our own subclass of Application, but I know this seems to be generally frowned upon. So I’ll definitely start with the AWT panels stuff.
@dljsjr said:
I have not yet looked at AWT panels.
We did set UseInput to false, and it fixed what we wanted to fix in the case of that specific example, but I'm dubious as to how complicated it will make handling input in the future; part of our simulation suite does involve engaging with the canvas using the mouse to affect changes such as moving the camera around or interacting with 3D objects in the scene by selecting them.
AWT Panels might be a good starting point. We've discussed internally writing our own subclass of Application, but I know this seems to be generally frowned upon. So I'll definitely start with the AWT panels stuff.
I doubt that it will help you to write your own subclass. The issue seems to be on the LWJGL side, with how it handles input in the canvas, so currently I do not see any way around it.
I played around with AwtPanels this afternoon, and it looks like it should suit our needs just fine regarding having multiple different views/cameras for one scene. I sort of fused the content in the Multiple Cameras tutorial with the source in the TestAwtPanels in the test package and it worked just fine. I didn’t do anything with animations (yet), but I can’t imagine that there will be any issues. Hopefully I’m not wrong.
Dealing with input is just going to take a little bit of work developing our own listeners.
It seems that the perceived “overhead” of having the application logic behind the scenes may not be too big of a deal.
Thanks so much for the quick responses today!
Yeah, if you can split your work into multiple preViews then its no problem doing this with one application, issues start when you need multiple AppState managers etc. but for most situations you should be able to just pass the relevant views/spatials to the AppState.
On that note: while that doesn’t directly concern what we’re doing with jME3 right now, in the future it might. There are situations where our multiple Java3D views aren’t simply different camera perspectives of the same thing, but rather multiple different, related visualizations in one GUI. When we port this over to jME3, would the “standard” here be to instantiate multiple jME applications and extract an AwtPanel from each one? I feel like this would be necessary not only due to the AppState but also the inputManagers as well as the AwtPanelContext instances, but the idea of “more than one application” seems to be a little odd.
Edit:
Also for consideration is a situation where I want to have different FlyByCameras for each AwtPanel even if they are all related to the same scene. I figured out how to spawn a new FlyByCamera and attach it to the inputManager so that moving the flyCam in one viewport also moved it in another, but I can’t see an immediately obvious way to have one application with two FlyByCameras. The solution at this point seems to be implementing a good old fashioned Java listener on top of the AwtPanels that controls the cloned camera attached to the viewport instead of having multiple FlyByCameras inside of one app.
I doubt reimplementing a rendering loop is necessary at all? I mean I guess you would want to use a separate thread for rendering anyway so just use the existing “Application” and treat it like your “rendering thread”. And I guess when its just about the visualization in separate panels you don’t have to have multiple rendering loops, no.
Not so much concerned about multiple rendering loops as much as I’m concerned with the separate panels having their own input and controllability, which implies that they would need disparate AppStates and inputManagers, etc.
@dljsjr said:
Not so much concerned about multiple rendering loops as much as I'm concerned with the separate panels having their own input and controllability, which implies that they would need disparate AppStates and inputManagers, etc.
For awt panels you have to pass the input component anyway, so just do that when the user switches focus. Also input doesn't have anything to do with "one scene" anyway. You can also completely ignore jme's input system and apply input else, from other sources.
jME3 doesn’t support input from multiple sources, so you have to use the setInputSource() to set which panel will receive input. Of course, since AWT panels are regular AWT components, you can use AWT event listeners with them just as with any other AWT component.
@Momoko_Fan said:
jME3 doesn't support input from multiple sources, so you have to use the setInputSource() to set which panel will receive input. Of course, since AWT panels are regular AWT components, you can use AWT event listeners with them just as with any other AWT component.
Mice don't support inputting to multiple destinations ;)
I think that I was thinking about things way too hard.
After reading your replies, using FocusListeners to shuffle around the Context’s inputSource and the InputManager and where the FlyByCamera was registered was extremely trivial.
Thanks again for all of your help, guys.