There are two classes provided, AbstractHud and Abstractwindow (and the fxml version of them) wich are the most common entry points.
Basically the either provide a window kinda like swing innerframe or work on a fullscreen scene.
Also take a look at the examples in test, basically they already do everything that is necessary.
One noteable difference is probably, that you only have one Scene internally, wich has a group, where all custom stuff is attached to.
Hi, I haven’t been paying attention here for a while and was wondering if someone could sum up progress and point me in the right direction. I want to create an application that is not a game, but uses jme3 for visualization and using JavaFX for the windows and the rest of the GUI. The user should be able to interact with the JME3 view via the mouse (for example moving the camera).
So far I have had working the examples by David Bernard with JME3 inside an ImageView in a JavaFX window.
But then I got distracted and left it for a while hoping that things would advance a little. That was about 3 months ago. Now I have just setup a test project and have the JME3-JFX as a dependency.
With the exception of TestDisplayInImageView all the tests use SimpleApplication as a start point. Are there any examples of how to start out using AbstractWindow and would it better fit my use case of jme3 as a visual tool? I realise I could use the JavaFX 3d stuff as per some examples on the web but I want it to look modern, and all the JavaFX 3d stuff looks it was done back in 1987 on an Amiga 500. No disrespect to the Amiga, but that was 25 years ago.
It really depends on what you do, if jme is just a small part of a desktop appliation, jme in jfx makes sense.
But much more than rendering it is currently not added i think. (I never used that direction, so i cannot comment on details)
For the other direction, the other tests use both AbstractWindow and Abstracthud. (However in the fxml flavour)
In it I drive ChaseCam via jfx event. I didn’t reroute jfx event to an inputManager. My strategie is to use jfx event to do the final action or call onAnalog if the final action is not public (like ChaseCamere.rotate(…)
Thanks,
It’s a sleeping side project (low priority), I just share as a sample about how to use jme into javafx app.
If I continue to work on it, it was planned to provide highlighting and/or node editor. I’m not sur of the approach to use lib,… (recently I use freemarker as macro to experiment port of some G3D shader lib to jme).
EDIT: last year I wrote a webgl glsl editor for my webgl wrapper lib, you can try it at viewer for test - glf
I just came back to check out the forum after a few months, and I can’t believe I never saw this thread for the past year… I asked about something like this previously, I didn’t think we could combine them both… Awesome work!!!
I noticed a bug in isCovered(): The image is stored ABGR, ABGR, etc. not RGBA, RGBA. So final int alpha = data.get(3 + 4 * (y * this.pWidth + x)); checks the red component not the alpha. I don’t know if the error is here, or if the data is stored the wrong way.
@tuffe said:
I noticed a bug in isCovered(): The image is stored ABGR, ABGR, etc. not RGBA, RGBA. So final int alpha = data.get(3 + 4 * (y * this.pWidth + x)); checks the red component not the alpha. I don't know if the error is here, or if the data is stored the wrong way. :p
On windows it is BGRA_PRE rather than ABGR. But yes, you are right, this check should take pixel format into account, as I think that on linux it is ABGR format.
@abies said:
On windows it is BGRA_PRE rather than ABGR. But yes, you are right, this check should take pixel format into account, as I think that on linux it is ABGR format.
Ok, it might be related to JME3 3.0 compatibility layer. I’m using 3.1 git version - if you are using 3.0, then all jfx-jme goes through some emulation layer which I don’t really know much about.
In any case, we need to parameterize this method to follow selected pixel format, rather than to work only on windows-jme3.1
I have a few questions after working with JavaFX a few days.
I noticed something a bit weird. I remake my scene graph every frame, because it’s simpler than modifying an old one. So far it’s fast enough, and I do it a couple of hundred times per second. But I noticed that mouse click events often disappear when I do that. Say I have a Label, and it listens to MOUSE_PRESSED events. Only about every 20th time I press it does it trigger the handler. Is it an issue with JavaFX, or can it be fixed in JME3-JFX, do you think?
How does drag-and-drop work? I think I heard someone say you had to do something special to get it to work.
I was thinking about how one could change isCovered to somehow allow mouse click through some JavaFX thing that is not invisible. Has anyone done this already? I can think of a few ways with varying degree of difficulty and robustness:
Method 1: Use some specific alpha, like 126/127, to mean that mouse clicks on that should not count, but it will look like a solid color anyway, probably. Can it go wrong if something behind a 126/127 alpha thing is more transparent? Does the final image end up with some other alpha then?
Method 2: Pass all events to JavaFX. In JavaFX, use an invisible Pane as a parent, behind your whole scene. For any event that is not consumed earlier, that Pane gets the event, and then you know that it went through, and then JME gets it. Will that round trip cause noticable delay?
Method 3: Keep track of the shapes that you are using for things that should block the mouse clicks, and in isCovered check if the mouse is in any of the shapes. Should work, but is kind of tedious to implement, unless there is a smart way to get all the shapes.
1.)
i think events are invalidated if the object is removed,
why not hash your data, and compare if recreation is necessary instead, before doing it?
2.)
Take a look at the example for drag and drop.
3.)
-> 1 might make problems with multiple transparent objects behind each other, yes
-> 2 converting the events needs processing time, and i fell it is not the best approach here
-> 3 yeah not that nice to implement
I would suggest to make it an interface, and allow users to push via guimanager their own custom logic.
-> special thinking here is required as for usefull checks they would need access to jfx, but events are in jme thread.