You'll want to use (Node) BinaryImporter.load(URL myUrl)
or (Node) BinaryImporter.load(File myFile)
I believe it loads any type of spacial and its children as it was saved. You can cast it as a (Spatial) or a (Node), depending on which would be more convenient.
You'll almost always need to cast it to Node, as anything with more than one part needs to be imported as a Node (i.e. a character holding a sword)
Yes, and in 5 years when some user creates custom models for the game, and the converter converts them to TriMesh objects, you would get a ClassCastException every time you try to run the game.
Both TriMesh and Node extent Spatial, so you're much safer casting into that. If you need to do something with the node, do it this way:
Spatial model = (Spatial) BinaryImporter.load(...);
if (model instanceof Node){
Node modelNode = (Node) model;
// operate on modelNode
}
From what I understand, in jme 1.0, a TriMesh is simply a List of GeomBatch objects containing the vertices,indices,normals,texture coords, render states,etc.
4. Furthermore: what things can be saved as .jme?? even whole terrains with textures as one file?
Anything that implements the "Savable" interface can be exported as .jme and other explicit types that OutputCapsule can accept as arguments. By default, if you export the root of a scene, the textures will not be exported into the resulting jme file unless you call Texture.setStoreTexture(true) or set Texture.DEFAULT_STORE_TEXTURE to true. You can reassign the textures by calling Spatial.getRenderState(RenderState.RS_TEXTURE) and then enumerate the set textures on the returned TextureState object.
It's better to store the textures separately from the jme file, though, as this avoids duplicating textures in memory in the case where you load more than one scene file into jme at once. What I have done is convert the individual images to .jme format by writing out the com.jme.Image file to avoid the overhead of decompressing JPEG and especially PNG images at run-time. The problem I had to solve, though, was that textures store their image locations as URL's not URI's so all the path names store in Texture.textureKey.path were absolute and moving the root game directory would break the loading process. So I came up with a method to relativize the URL to the game directory and then resolve it against the root path to the game directory. When I am done testing this and other related code, I can post it to the "User Code" section.
The BinaryImporter class was the thing I was looking for.
To improve the loading process and especially for my own convenience I have written a simple ResourceManager, which I implemented as a Singleton:
/**
* Singleton Ipmplementation ensures that only one instance is created.
*
* @author schneider
*/
public final class ResourceManager
{
//Global constants
private final String BASE_MODEL="mce/game/data/models/";
private final String BASE_TEXTURE="mce/game/data/tex/";
private final String BASE_IMAGE="mce/game/data/img/";
// Model URLs
public static URL URL_CHECKPOINT;
public static URL URL_STARTGATE;
public static URL URL_FINISHGATE;
public static URL URL_STONE;
public static URL URL_TREE;
public static URL URL_HOUSE;
public static URL URL_TRUNK;
public static URL URL_BIKE;