After reading the manual page for the asset_manager, I’m interested in hosting files on a remote server for download when my application starts. I’m not sure I have the pattern to use straight in my head, though.
Is it recommended to create all models, textures, etc… convert/package them to j3o files, package those into a JAR and then download the JAR at runtime?
I’m guessing some workflow similar to the following:
Create Ogre files in desired application
Add files (including textures) into an arbitrary JME3 project’s assets/Textures directory
Convert the Ogre files to j3o files.
Package these new j3o files (with textures) into a JAR
Place JAR somewhere on server where it’s available for retrieval
Register an HttpZipLocator with the assetManager
Load specified model via assetManager’s loadModel()
Is there anything I’m forgetting or any gotchas I should be aware of? Maybe I have the process completely wrong?
It should work like that, yeah. There were some sun licensing issues with the HttpZipLocator though at some point, idk if they have been sorted out @Momoko_Fan?
I plan to add support for splitting the assets.jar file by having multiple assets folders (also e.g. for “low quality” and “android” only data packages etc.), that would give you the option to do this kind of thing right in the project. For now you can copy the target from nbproject/assets-impl.xml to your main build.xml file and adapt it so that it splits your data. Don’t forget to add any additional jars to the run.classpath.without.build.classes.dir property thats being built or else it won’t be added to the jar manifest and lib folder.
I plan to add support for splitting the assets.jar file by having multiple assets folders (also e.g. for “low quality” and “android” only data packages etc.), that would give you the option to do this kind of thing right in the project.
1) You're planning for a "save assets as JAR" command or such to the SDK? Anyway I can help expedite such a process?
Don’t forget to add any additional jars to the run.classpath.without.build.classes.dir property thats being built or else it won’t be added to the jar manifest and lib folder.
2) I'm a bit confused here. Additional JARs? Why would these JARs need to be in the lib directory if they're to be served remotely?
The assets are always distributed as a jar file, the point would be being able to have multiple asset jar files to split assets as well as make packages with the same assets for different platforms. Its mainly a task of making the appropriate ANT targets and creating/extending the options panels in the SDK to support multiple asset folders. Theres a few threads that have to be followed with this though as the ProjectAssetManager would probably also have to be extended. It does support multiple paths already though.
So in the end you’d basically get assets.jar and e.g. assets-extensions.jar and can put one or both files remotely (or distribute them).
The ones you would create. The target in that file builds the assets.jar when the app is distributed as you might see. My suggestion was to separate the assets into multiple jar files so you’d have to do that there. The property that is created (again, you have to look at the file to understand what I say) contains all jar files that are added to the main jar manifest, to have it load the additional assets jar file when its available in the lib folder you have to add it to that property.