I have implemented DavidB’s (@david_bernard_31) solution for implementing JME3 in JFX and it has been working great so far: (Kudos and a big thank you for the elegant solution btw 
)
However now we have the problem that we want to have 2 imageviews at the time. One is the basic one displaying a storehouse in 3D and the second in a dialog where a 2nd view is shown. Both of them interactable of course.
Now I know the bind method in the JMEforImageView has a commentary saying only one Imageview can be binded but I thougt that is only because there is only one SceneProcessorCopyToImageView Instance. So I recoded the method to bind a new instance o the Processor to a viewPort I give it that I created using jmeApp.getRenderManager().createPostView(viewName, cam). I thougt it would work because the bind method does nothing else than get the latest viewport and bind it to the Scene Processor using jmeApp.getRenderManager().getPostViews();.
However not only do both imageviews show the same viewport they also dont get any of the eventhandling I attach to the jmeApp.
Is there something I am missing? Is there a way to have multiple interactable viewports on the same SimpleApplication?
I wouldnt want to have multiple JME instances, its eating alot of power and the software is supposed to run on tablets.
I need to see and to test code, to understand and to help you.
Maybe an alternative could be to stay with only one SceneProcessorCopyToImageView. But to setup up 2 viewports with 2 camera (like a split window) on the same display and to split the image after the read from GPU into 2 images. The final images are in fact fragment of the wall image.
Thanks for the suggestion, we looked into it, but EventHandling would have gotten complicated. Also disovered that you can pause the JME when entering and exiting the imageview so the performance is less of an issue with multiple JME Instances. We went for that since it seems to be the easiest to manage solution albeit the probably ugliest one. But we dont have anybody with much 3D experience so we thougt its better to not bite off more than we can chew and keep our schedule
Still thank you for the suggestion, I’ll definetly keep it saved as a backup in case something really does go horribly wrong with using 2 JME simpleApplications.
Aaaaand I am back. This time with a memory issue. Everytime I switch a storehouse and load it, the previous loaded storehouse/zone doesnt seem to be removed/GC doesnt run over it. I used JProfile but its nothing in my programm, it never exceed about 500mb, its some native library. I think its LJWGL but I am not sure. My memory usage just keeps increasing with every zone switch up until my RAM is full, then on it doenst increase in memory usage but also doesnt start lagging or anything. We did not have this issue when our software was running in JME, so I figure the SceneProcessor must be doing something to not free the data for garbage collection.
Anyone got an idea what it could be?
try manually calling System.gc() the java gc has some issues with directbyte buffer release, as it only sees a few bytes on the java side.
What exactly is your exception if you repeat till crash (if there is a real leak at some point it will)
Can you provide a simple sample app to reproduce the issue? It will help to debug and to profile.
I loaded an old version from SVN and it turns out we did have the issue back when we were using JME as basis and JFX on top of it. Guess we never noticed since we never did extensive testing. As for the application it never crashes. If I limit Heap size to 512m it does crash but not with 1024m. Makes sense those values I saw too while using jProfiler, the java application itself peaked at about ~800mb. But either way it just keeps rising until it fills my 8GB and then starts paginating the rest.
@david_bernard_31 I dont think I can provide a simple sample app. I doubt its a general issue but one with the way we are loading the storage areas. Its a monster process across many classes and I am guessing we forget some listener somewhere. Will have to look into it, I guess.