Hello everyone. I've been messing around in jME for a few months now, and I have started to create some more complex scene graphs. Problem is - keeping this all in my head is a bit daunting, especially when I don't work on the project for a bit …
So I started writing a Scene Graph Browser to help visualize things. Of course, I started doing this before thinking about asking if someone else has done so already. So … has anyone?
Thanks,
-Ben
That might work, but I haven't yet found a way to grep the heap for objects of a certain class. Of course, I could make it so that my shiny root node keeps a static registry of all known 'root' nodes. However, this means than anyone using one of the built-in jme game objects (StandardGame, SimpleGame, etc) will not be able to use the browser - all of these game objects provide their own root node in one way or the other.
Ideally, I would like everyone to be able to add browser functionality with nearly no effort. Replacing your root node seems like it would require a bit more effort than simply specifying the name of a class object that will let me get ahold of a root node statically.
i think there is something around but i don't remember where/what/who 
Heh, sounds about right. I have searched through the forums and done some googling, but come up empty … so I figured I would query the forum population.
-Ben
http://www.jmonkeyengine.com/jmeforum/index.php?topic=6498.0
You could use that as a starting point!
Hmm … interesting. I will definitely be using that as a reference. Unfortunately, I already started building a TreeModel and have a bunch of Test cases against it … so I think I'll keep mine
I've actually got a few view-models planned for this, so I have a layer of SceneGraphElementDescriptors underneath my current TreeModel implementation. I figure this will allow me the freedom to write multiple renderers for the SceneGraph (TableModel, or even render it in jME itself) without rewriting all the fun attribute discovery logic.
Seems quite useful … although the UI is currently a bit rudimentary
I created a test project just to see how it looks, and then I hooked it up to the little demo game I am building to see how it handles a more substantial scene graph.
Now I just need to figure out how to visualize all the properties of each object. I want to create a IDE-style display of all the values each SceneElement has, so I can inspect them and determine whats going on with translations, light states, etc.
[attachment deleted by admin]
If I might add a suggestion which would make this browser rock… How about a basic stand-alone app which uses Reflect/Retrospection to access the rootSceneNode of a running JME game? Ideally, you'd have a game running, start up the browser and get an up to date list of the entire graph.
Should you not find this usefull, I might even be tempted to try something like that myself XD
Hm … sounds interesting to me. I can't say I have ever poked inside of another application instance through Java yet … but no better time to learn than the present.
First I will work on getting the browser working for the various aspects of the elements. I will be needing to some reflection work in order for that to happen, so it will be a good primer.
I'll see if I can get that to work and get a jar out there for everyone to play with.
MonkeyWorld3D also has such functionality, maybe you peek at their source and can use things from there.
I wasn't aware that it is even possible to "spy" on a running JVM with reflection - could anybody share some pointers?
You can do that with the debugger interface. From eclipse it's quite easy. eDOBS can already do that (shows your java objects as object diagram).
Ok - got a little sick the past few days, but I have shinies to show.
http://etistudios.com/gallery/main.php?g2_itemId=248
I dug into the new Java 6 Attach API and found out its pretty easy to headcrab a running VM. What you see here is me grabbing onto a running demo game and forcing it to load the JMX management tools so it can be my little zombie. Then I just ran a JConsole and connected to the newly exposed JMX interface. I randomly browsed into the OpenGL thread to see what it was doing.
I'll explore down this path a bit further tomorrow … right now I need to go pass out a bit before work starts again …
You might take a look at VisualVM as well…pretty powerful system.
I took a peek at that … looks like an upgraded JConsole with more shiny objects …
Nothing major to report today. I just refactored the application into a format I can live with and expand on.
So, mind if I get some community brainstorming action going on? So I can find and connect to a VM … thats all good. Now how do I go about getting the root node?
From inspecting all the jME classes, I find there is no static resource to poll for a game-wide root node. Instead, it seems up to whatever game framework used to do the job of tracing the scene graph, and handing it off to the renderer at the appropriate time.
Now if I can somehow manage to convince the VM to give me a list of all Node classes, I should be able to inspect all of them and figure out which one is the root (no parent). However, I don't know if this is a feasable angle to attack the problem from. The JMX stuff seems quite powerful in its ability to profile, but I haven't yet found any documentation on how I might poll all the objects on the heap in search of my shining root node.
Alternatively, I could have my application require a running RMI interface on the game itself. This would require some effort on the developer's part, to include my JAR and expose a root node, but I figure that would be quite minimal. I do know this is possible, so this is my backup plan in the event the former line of exploration fails.
I was pondering the same question these last few days. I think it would be difficult to "find" the root node, seeing as there may be many (one in each gamestate, multiple nodes which are explicitly rendered, etc.). Maybe if you discovered all of these nodes and then gave the option to select which one you would like to monitor. I don't know how easy it would be to find them though, so I'm kinda leaning towards exposing from within the app as the most likely solution. But I would love to see you figure it out through reflection, sorry I'm no real help.
Thanks for the input… any kind of input is help, after all
So I have polled around a good chunk of my peers, and the general consensus is that the JVM does not provide a facility to poll for instances of a class. I shall do a final sweep of my coworkers to pick at the few I haven't yet queried, but I presume the answer will be the same at the end of the day.
So my thinking has gone to this - I shall load in a JAR that provides the RMI interface. This JAR will be able to take two arguments: the name of a class, and the name of a method. In this way, I will allow the user to specify a static resource to query for the root node. This should make it incredibly easy for most developers to provide access for the browser, without having to include any foreign JAR files in their build. I may still want to provide such a JAR … we shall see if any functionality warrants it.
Lets see where this goes …
May have completely missed the point.
Create a new class that extends node, insist that only rootNode must extend this class. You now have a unique Type to look for.
Hows this coming? I’m really interested to see where you take this.
I’m finishing up a tool which provides the same functionality as your implementing but its not a monitoring tool. Its geared more towards setting up/creating a scene graph including interacting with it, along the lines of MonkeyWord. But the tree view and the guts that go with it I have, so when I saw your idea I wondered why I hadn’t thought of it. You got me really interested and I couldn’t resist trying my hand at it. I like what I came up with.
This is a great idea your working on, so if you want to exchange thoughts or team up I’d love to help.
Ah, excellent. I like the look of your tool - its actually functional, as opposed to the current status of mine
I have been a wee bit distracted by shiny objects (got a new laptop) but I am once again jumping onto the Scene Graph Browser.
I gave up on delving through the Heap - the only mention of that I could find was through their C API, and building a debugger on that level wasn’t something I was up to for this task. Once I had resolved myself to using simple client-server, I was struggling with getting an RMI server published once I had latched onto the target VM. So for the moment I have dropped that aspect of it and focused more on bare bones functionality, assuming the developer will easily be able to publish the game-side agent without too much trouble. I restructured the client to the point where I could live with myself, and got something actually somewhat usable out of it today.
Screenshot here.
Not pretty at all, no, but its all MVC inside, so I know it can grow easily. That is quite important, as I haven’t yet fully figured out what I want to do with this. I know I want to be able to inspect the various states (light state, texture state, etc) of each object, as well as modify it on the fly (that should be amusing). I figure that will be useful for trying out certain looks without having to recompile or hack in the debugger. I’m thinking this will be more on the lines of a dev tool than a design tool … but we shall see. Hopefully I am structuring the packages well enough that everything can be reusable.
It looks like you are much further along than I am. I had planned on including editor-like functionality when I had made the diagnostic aspect of the tool usable. You seem to already have that working quite well.
Are you planning on handling scene graph updates at all? That is something that I have been mulling over for a good chunk of the night. I think I may just have the agent poll for updates of its graph every minute or so. It shouldn’t be that hard to compute a diff between two scene graph descriptors and then notify any clients if there are changes to be had.
Of course, having the client poll itself is simpler … and offers flexibility. By default it could refresh every minute, but there could be a pause button to hold a particular description of the graph in memory for longer pondering.
I’ll try to post more often now that I am back in business, and less distracted by shiny things
EDIT: Heh, just saw your other post. Seems you already did everything! angry fist shake