If you updated your CVS lately, you might have noticed some changes (some of them breaking your code perhaps). Read more about them here:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=3105.msg25327#msg25327
Also, jME now uses 1.5 language features, has a 1.5 build process, etc. (so you'll need a 1.5 or higher SDK).
There are still some unsolved problems (most notably, CompositeMesh is not working), and there will most likely be some more changes coming up for some of the features that are being worked on.
In my opinion CompositeMesh should be replaced with the new batch system.
Here’s the code:
jme_dummy_system_provider.zip
Explanation:
After implementing the SystemProvider, you have to create the following:
META-INF <directory>
|
+-services <directory>
|
+-com.jme.system.SystemProvider <text file>
The 'com.jme.system.SystemProvider' text file should contain the fully qualified class names of the providers you wish to add:
com.jme.system.lwjgl.LWJGLSystemProvider
com.jme.system.dummy.DummySystemProvider
And that's all. The system does acquire those providers information automatically, so you can set your desired provider by its identifier using 'DisplaySystem.getDisplaySystem(String)'.
Next, I'll try to get the ObjToJme working.
Hi again. The dummy is back with a vengeance!
Doesn't work as it is. The 'dummy' provider creates it's own 'dummy' classes which can't be recreated on loading when using other provider, as they're not the expected classes.
I'll fix that and post the code again. Sorry. Didn't notice that before until I tried the model import/export thing.
CompositeMesh will go bye-bye soon. Batches are already setup to be what CompositeMeshes were… The implementation is just not quite finished yet.
I'm checking that loader/saver issue, and I found that looks like its saving the specific renderer related class name for material and textures states, so as the instances are different between providers, they won't load if the provider is not the same.
Is that as intended? That is, the export data being bound to the renderer implementation?
getParent() method has been removed from GeomBatch! 
How do I get the node when doing mouse picking?
There's a public field parentGeom now.
Hi again,
Confirmed, the specific renderer state name classes are being stored, so you can't use the same jme generated between renderers (checked the actual loader/saver code).
By the way, great work on the new jme format loader/saver code 
Its a zillion times better than before! Now it would be really nice to work with it and adding features Congratulations!
Not really involved in this thread, but that hasn't stopped me before, so I'll interject my reaction to removing getParent() and having a public field for parentGeom. Isn't that a bit counter-productive? I mean, isn't having a getter usually a much better way to go as far as Java-centric development? :-p
darkfrog
parent in batch was not removed… In fact, parent was an artifact of batches being shifted over to being Geometry in the previous batch rewrite. Batches have always had parentGeom. A Geometry object is a collection of 1 or more batches. Each batch has a handle beck to it's parent. Parent in Spatial is a Node anyway.
llama said:
There's a public field parentGeom now.
yikes! this is going to be made private, isn't it?
definitely not private… maybe protected, shrug It doesn't alarm me either way.
Allowing direct write access directly to fields is never a good idea, IMO. So I think having non-final (and static) fields that are public/package visible is a sign of bad design in the most cases. But I didn't have a look at the whole new batch stuff, so might be that I miss the sense of that field - should all code (or subclasses) be able to alter it??
Since it will need to have set and get methods to function properly, it is functionally the same either way unless we were thinking about placing lots of checks into said methods. It is a matter of methodology. I'll make it protected (done) and provide bean style gets and sets (also done) since that is our style anyway. The ease of an external class in screwing it up won't change however.
Ok, I'm coming in late now cause Renanse just made the change already
Well, when you subclass something, it's an advantage if other classes use get*() instead of accesing directly. While we may not be able to think of any functionality that requires checks, I'm sure we can't think of all possible functionality for batches either. So wether it's public, protected, or private there should be a get* method.
I don't agree with irrisor it's always bad to have public fields. Eg. in the Vector classes it's perfectly sane.
llama said:
I don't agree with irrisor it's always bad to have public fields. Eg. in the Vector classes it's perfectly sane.
That's exactly a place where it is very annoying: you can't notice changes to those vectors if you hand out a reference to it. It's even a major disadvange of the jME scenegraph that it can't detect changes but computes all world vectors, boundings and other stuff each frame though probably not neccessary... of course this problem could be solved another way, but it would cause alot of pain...
Another point against having public fields is maintainability - it's hard to keep old code that references the fields directly when you later e.g. want to restrict access.
Some time we should discuss such change detection in the scenegraph btw. (but as you surely noticed I'm very short on spare time currently).
I agree that it would be great to detect changes… we already do that here for skinning to work efficiently. Makes sense. :) I'll just stop there for now until we can do something more about it. 
IMO detecting changes, and not recalculating once every update can make problems too. What if change occurs twice? Everything gets recalculated twice? I just noticed this behavior in AbstractCamera and LWJGLCamera. Each time it changes, it is recalculated, while there is still an update method which could be called only once when it is needed. Curently after update is finished on a spatial, the spatial can be considered "ready to cull/draw". If "onChange" eventing comes into play, which also recomputes world* data, then never can be sure, when an element is in final state for the current frame (yes i have threading in mind). Maybe have a "boolean changed" field, and onChange set that field, without recalculating?
It was a "please keep it the way it is" type of post, not suggesting any change anyway.
I will be setting CULL_NEVER on batches, so there will be no extra cull testing, so it should be fine. It might actualy be useful to CULL_DYNAMIC bigger lists of bigger objects, those objects the camera can go inside. So the answer is yes. Thanks.