Invoking jME StandardGame multiple times

Before I get to my question, I should probably explain that I'm not using jME to develop a game per se.  It's really being used as a visualization tool in a larger project, a segmentation system for extracting structures from tomographic volumes generated through electron microscopy.  As such, the user may do some segmentation operations on the volume, perhaps drawing contours on a set of 2D slices out of the 3D volume, sending those contours to a surface tiler and then showing the 3D results.  That's where jME comes into the picture.



As such, the user may display and close the jME window multiple times in a session as new surfaces are added or they wish to view different datasets entirely.



The problem I'm having is after I close StandardGame by either the windowing system's "go away" button or by explicitly calling StandardGame.shutdown() and then try to later on start up a new StandardGame session, the geometry displays flat and white – that is, there's no shading or any lighting effects at all.



I've tried calling StandardGame.reinit() tor reset the system but that doesn't do any good.



So, I have two questions: first, is there something I should be doing either at the jME level or at the LWJGL level to either reset things or properly shut down the system, or, second, should I be simply keeping the StandardGame object around and just feed it new geometry every time I want to view something.  If the latter, is there a way to intercept the window manager's close window action?  I know how to do this in Swing, by setting the window's defaultCloseOperation to DO_NOTHING and intercepting the windowClosing event in the standard manner with a listener.  I don't see a facility within jME to do that, but perhaps I've missed it in my reading of the documentation.  Perhaps this is a LWJGL method of some sort that I'm not finding.



I originally developed this tool using Java3D and it seemed to allow multiple invocations, but for a multitude of reasons, mostly involving compatibility with some other projects in my research lab, I decided that I needed to use jME as my graphics engine.



Any help provided would be appreciated.



If I'm using jME in a way that is basically incompatible with its design philosophy, I'd appreciate knowing that, too.

I guess it should be possible to do it like you do.



Can you make a small example to reproduce the problem easily?

Core-Dump said:

I guess it should be possible to do it like you do.

Can you make a small example to reproduce the problem easily?


I'll try to put something together.

In the meantime, your reply sounds somewhat dubious.  Can you suggest a possible better way?

I think I found the problem, though I'm not sure I understand why it's a problem.



I was not locking the Spatial object I was attaching to the root node.



It's not clear from the javadoc or the example code why this needs to be done.



Can someone enlighten?


Locking a spatial creates a display list, it shouldn't have to do anything with restarting a StandardGame.

Also look at the code for spatial.java - lots of big clues there :slight_smile:

JOC said:

Also look at the code for spatial.java - lots of big clues there :)

I have spent a bit of time poring over the source of Spatial.java but didn't see anything that leapt out in front of me, waving it's little hands.  Care to elaborate?

In re Core-Dump's reply, yes, that was my understanding: of course Spatial.lock() creates a display list, which is why invoking that method didn't make a lot of sense with respect to the problem I was having.  I just observe that without the call, I have the problem reported above.  I can only speculate that it might have some side effect on the state of OpenGL but I'm open to other explanations.

BTW, in my extremely humble opinion, the method name lock() is somewhat misleading.  When I first looked at it, I expected it would be some sort of thread synchronization mechanism, a la the POSIX pthread_mutex_lock().  Something like Spatial.createDisplayList() might be more descriptive.  But that's probably just me and my C programming background showing.

i know what you mean, i'm a c programmer as well :slight_smile:



Trying to for example move a locked object won't work since its translation is 'saved' in the display list, so the name kinda fits.



But back to the problem, if you post a small example, how you restart StandardGame we can easier track the problem down.

I apologise for my previous reply, when I saw your post - I kinda saw it as "It's not clear from the javadoc or the example code what this does." and not what you actually typed…

My bad - thats what you get after far too many hours staring at text on a screen and a week of reading documentation from an outsource team in India . . .



As C.D. says - I too am curious how you are starting and stopping your standard game - especially the starting. Is it started from a java app or thru a command like exec or some other way?

Core-Dump said:
But back to the problem, if you post a small example, how you restart StandardGame we can easier track the problem down.

I'm not restarting StandardGame, per se.

I'm invoking StandardGame.shutdown(), which, according to the documentation is supposed to "Gracefully shutdown the main game loop thread". When I want to display my geometry again, I simply create a new StandardGame.

I suppose I could just keep the StandardGame object kicking around and restart it with the StandardGame.start() method.

I'll try to cobble together an example which exhibits the behavior but since I have a provision, if somewhat unsatisfying, fix, and other pressing tasks are pending in my work queue, it may be a bit before I can return to this.