Hi to all.
I've tried to search on the forum some informations about the jbin format and the jme format.
I've made two little programs to test the jme format and for what I've understood, the jme format stores the entire scene, not just the loaded models. Cause when I load the jme file that I've previously created it loads the model nodes, the textures and of course the models.
So I guess that the jbin format just stores the model data but I'm not sure cause I didn't try it yet.
Can someone tell me if I'm right or if I've missed something?
Thanks in advance.
nymon said:
I think most people just tend to 'make' their scenes in code, and not load them from files. But this is really only viable for smaller projects.
I've worked with building scenes from components in JME XML files for most of today, and have educated myself enough now to say that I respectfully disagree with your last sentence. This assertion seems to be based on the assumption that complete scenes are being loaded from the files, and if that were the case I would agree.
I have used this tactic with Java3D, loading components from files at runtime and grafting them into scenes, and I've just proven to myself that it is much easier to do with JME. Without this tactic, making a game with scenes dynamically composed of selections among thousands of models, would be impractical.
basixs said:
For clarity:
The 'jbin' format is the internal binary format that jME uses to load EVERYTHING...
The 'jme' format is intended as an external XML type format that can be used to store/read scene data, a scene or model (regardless of external format) is always converted into the jME binary format (jbin) when it is loaded (hence the final call to the BinaryImporter). I would think this format would only be intended to be used internally and not as an actual 'saving' format, but I could be wrong (and often am)...
I was not aware that .jme was reserved for the XML type personally either. All my binary files are .jme not .jbin :D
just for added clarity (I was re-reading this post and realized the way it was phrased was rather odd…)
The 'jbin' format is the internal binary format that jME uses to load EVERYTHING…
I would think this format would only be intended to be used internally and not as an actual 'saving' format, but I could be wrong (and often am)…
The 'jme' format is intended as an external XML type format that can be used to store/read scene data.
A scene or model (regardless of external format) is always converted into the jME binary format (jbin) when it is loaded (hence the final call to the BinaryImporter).
Depending what file formats you use (3ds is damn slow especially with larger complex files), I think that a caching in jme binary is not the worst idea. But since it's jme can change, the older binarys may be unable to be used later (try to load a jme1 in jme2 XD) so it's probably not the best to use them for any other purpose than caching.
This is true, but the jme binaries are more a delivery format than an archiving format, not just a caching thing.
You will always have your original models in <insert format here> but probably wouldn't want to distribute them that way with any finished product for any number of reason (filesize being amongst them!) - also your users wouldn't want to have to wait while everything is converted each time its loaded.
Part of the development pipeline would be to convert your graphic assets to the latest binary version as a side process, and although portability between versions is generally a desirable feature, in this case its not essential, as you can always re-convert your assets before release and take advantage of whatever performance benfits the new code offers (hopefully :D).
The only downside here tho is that once released, you are stuck with it (as you said) - and the version of JME.
The back-and-forth below justifies my opinion that we should not make this decision for the app developer. Looks like typical cases will not want to persist cache binaries, but it's an unfortunate fact of 3D programming that we often have to accommodate all sorts of unsavory constraints (including narrowing native 3D API support, and requiring specific JVMor JME versions) in order to attain acceptable performance. Working with 3D in Java, these tactics are often necessary to compensate for inferior support for hardware acceleration, etc.
I.e., I think the JME APIs should support persistence of binary cache files.
I was under a similar impression however i may be wrong can anyone shed some light on this??
What is this jbin format? How exactly do you export into it?
i think both terms 'jbin' and 'jme format' refer to the same way to export a jme scene through BinaryExporter/Importer no?.
The other way would be through XMLExporter/Importer.
jbin=jME-Binary
Not sure where it came from but:
http://www.jmonkeyengine.com/wiki/doku.php?id=unified_model_loading
/*
* This method opens a model in various format evaluating the extension
* In case in the same directory is already presents the same model in jbin format loads it
* Otherways load the model and save a jbin copy for the next time.
*
* Attention : in case the original model is changed you'll have to delete the jbin one the reload it.
*/
public static Node loadModel (String modelFile){
Node loadedModel = null;
FormatConverter formatConverter = null;
ByteArrayOutputStream BO = new ByteArrayOutputStream();
String modelFormat = modelFile.substring(modelFile.lastIndexOf(".") + 1, modelFile.length());
String modelBinary = modelFile.substring(0, modelFile.lastIndexOf(".") + 1) + "jbin";
URL modelURL = ModelLoader.class.getClassLoader().getResource(modelBinary);
//verify the presence of the jbin model
if (modelURL == null){
modelURL = ModelLoader.class.getClassLoader().getResource(modelFile);
//evaluate the format
if (modelFormat.equals("3ds")){
formatConverter = new MaxToJme();
} else if (modelFormat.equals("md2")){
formatConverter = new Md2ToJme();
} else if (modelFormat.equals("md3")){
formatConverter = new Md3ToJme();
} else if (modelFormat.equals("ms3d")){
formatConverter = new MilkToJme();
} else if (modelFormat.equals("ase")){
formatConverter = new AseToJme();
} else if (modelFormat.equals("obj")){
formatConverter = new ObjToJme();
}
formatConverter.setProperty("mtllib", modelURL);
try {
formatConverter.convert(modelURL.openStream(), BO);
loadedModel = (Node) BinaryImporter.getInstance().load(new ByteArrayInputStream(BO.toByteArray()));
//save the jbin format
BinaryExporter.getInstance().save((Savable)loadedModel, new File(modelBinary));
} catch (IOException e) {
e.printStackTrace();
return null;
}
}else{
try {
//load the jbin format
loadedModel = (Node) BinaryImporter.getInstance().load(modelURL.openStream());
} catch (IOException e) {
return null;
}
}
return loadedModel;
}
Seems kinda weird that its testing for modelURL==null, then USING modelURL (which is null) in the else... .
basixs said:
Seems kinda weird that its testing for modelURL==null, then USING modelURL (which is null) in the else... .
Haha, nice catch!
wait, thats correct 
first it tries to load the .jme file, if that is null, it loads the real model and converts it to .jme.
// try to load .jbin
URL modelURL = ModelLoader.class.getClassLoader().getResource(modelBinary);
//verify the presence of the jbin model
if (modelURL == null) {
// try to oad .obj
modelURL = ModelLoader.class.getClassLoader().getResource(modelFile);
....
Actually I was looking at the else, but yes I am definitely wrong there also and it is fine
Core-Dump said:
wait, thats correct :)
first it tries to load the .jme file, if that is null, it loads the real model and converts it to .jme.
// try to load .jbin
URL modelURL = ModelLoader.class.getClassLoader().getResource(modelBinary);
//verify the presence of the jbin model
if (modelURL == null) {
// try to oad .obj
modelURL = ModelLoader.class.getClassLoader().getResource(modelFile);
....
yeah in that instance a jbin is saved the first time u run it every time after that it loads from that jbin automatically and the only way to modify the model is to delete the jbin. However i don't think theirs much difference in performance (though i haven't stressed loading other file formats v loading jbin) and its odd because i just realized I've been mixing up Momoko_Fan with Mojomonkey as he was the one who briefed me a while ago on jbin. Srry for that. I do know that .jme is the native format of monkeyworld3D and in such believe the poster of this thread is correct in his beliefs
For clarity:
The 'jbin' format is the internal binary format that jME uses to load EVERYTHING…
The 'jme' format is intended as an external XML type format that can be used to store/read scene data, a scene or model (regardless of external format) is always converted into the jME binary format (jbin) when it is loaded (hence the final call to the BinaryImporter). I would think this format would only be intended to be used internally and not as an actual 'saving' format, but I could be wrong (and often am)…
They are both for the same purpose of saving an entire scene graph, and I was not aware that the extensions actually had any real meaning or association. Each have an advantage over the other…
Binary format is extremely fast to load and the file itself is very small. This lends itself to being a good format to save in when distributing your game. The catch is, it is not guaranteed to work between different versions of jME.
XML format is naturally a larger text file. It is also not guaranteed to work between jME versions, but because it is a simple text file, you can easily manually change the contents to migrate to another jME version. This lends itself to be a good format to use any other time than in a release of your product, i.e. dev cycle.
I think most people just tend to 'make' their scenes in code, and not load them from files. But this is really only viable for smaller projects.
The abilities of the two formats are identical. Everything that gets saved with the binary exporter will also be saved by the XML exporter, and visa versa.
I am sorry to fire this off without trying it myself (family is pulling my left arm away from computer as I try to type with right), but a quick look at the API spec looks like any Spatial should be (recursively) persistable and reconstitutable, not just scenes, no?
I want my app to be able to load meshes and objects from my runtime database and distributed files and graft them into my runtime scenes. If this is not possible now, could somebody in-the-know elaborate on the feasibility for me to add the necessary enhancements to permit this?
I have to quit for the day now, but will read replies about 8 hours from now, and will play with Spatial persistence if I don't learn anything to stop me before then.
Well i think it's fine the way it is currently, no need to add anything to that.
Cause this way the programmer is free to use it however he wants, cache, release, or just use it as a copypasta protection for the models in their game XD
I seem to have lost track of what this thread is about, and definately about where its heading 