I have a ms3d model and it is textured. When I created it I have made it point to a texture that is in the same folder (relative reference).
When I try to load it in jME I get:
java.io.FileNotFoundException: .mecha_map.PNG (O sistema n
Can you provide a sample model file?
Here is the model:
http://somerobotgame.googlecode.com/files/model.zip
the binary data of model: (observe the relative reference to texture file)
MS3D000000 8
looks like the problem is the converter, with prepends the string with "file:/" in order to make a URL. Effectively, this means relative paths are useless.
Mccullochpitts said:
MS3D000000 8
I have ms3d files like this that will not load their textures. Some of them actually have a c: as part of the path - that really blows things up when I load the model under Linux.
It makes no sense to encode a path (relative or absolute) in the ms3d file, but there's no denying that there are files out there like this. I guess I could hack the ms3d files with a hex editor and remove any path prefix on the texture file name.
The MilkToJme.convert method takes an InputStream (good design) and not a File, but this means that there's no way for it to infer the location of the texture file from the location of the ms3d file. We would need another parameter to the convert method that contains the resource or filesystem path where the texture files live.
Cool! That will be a nice feature to look forward to.
It's actually a very challenging problem due to the fact that a locator must worry about multiple copies/versions of the same file. When you consider that Java has been around for a decade or two, and you still get questions about classpath and java.library.path, you realize that Sun hasn't even been able to come up with a decent solution. We suffered through years of MS DLL hell, so they didn't do much better.
Back on topic - for now I simply hacked the MilkToJme class to strip off the path found in the ms3d file, and I store the texture files at the root of my resource path. Ugh.
Or you could wait for the asset locating features coming in the next release. 
I'm my swing program i had the same problem of how to design a input method. I also went with InputStream and a path(in fact just a path that then created a input stream) but there is another possibility if you don't want to loose the http etc protocols. I think a URL or URI should have a method get input stream and a string origin. Another way to avoid the problem if you just need to catch a format expection is to wrap the given inputstream into a bufferedinputstream. This is useful for example for catching charsetchangedexception in html parsers and their ilk.
archo said:
I have ms3d files like this that will not load their textures. Some of them actually have a c: as part of the path - that really blows things up when I load the model under Linux.
It makes no sense to encode a path (relative or absolute) in the ms3d file, but there's no denying that there are files out there like this. I guess I could hack the ms3d files with a hex editor and remove any path prefix on the texture file name.
The MilkToJme.convert method takes an InputStream (good design) and not a File, but this means that there's no way for it to infer the location of the texture file from the location of the ms3d file. We would need another parameter to the convert method that contains the resource or filesystem path where the texture files live.
Why there is no sense to encode a relative path in a model file?
Why there is no sense to encode a relative path in a model file?
Okay, fair enough. But, I bet we all agree that it is a lot more difficult to justify embedding an absolute path than a relative path.
I think even a relative path can be a problem in the ms3d file, however, because the file is in a fixed binary format. Organization and deployment of content is complex enough already, without needing to worry about making sure that the file system layout or jar structure remains in sync with a hardcoded path in the model file.
Well, to justify reviving this near zombie: Have any of the developers looked into the MilkToJme source to see if the texture location logic can be improved? Perhaps the get/set property in FormatConverter could be used to specify texture location before convert() is called, and convert() could strip any embedded path (relative or absolute) if the texdir property is set?
just wonder if the end product, which is a jme object would be a better object model to dress with textures rather than the 3d model it self.
For instance, create a texture url to key mapping, convert the model to jme, then assign the textures oneself by looking for the names of the children per the key mapping.
`Just an idea anyhow
I have the same problem with jme 0.11.
If I load an ms3d-file, the texture is "located" (or not…) in .whatever.jpg and the model including animation loads otherwise fine - just without texture.
If I load an obj-file, i can easely edit the corresponding mtl-file to a relative path and copy the texture to that location. So theoretically it should load fine but jme crashes then with an nullpointerexception.
So: is there a solution for this problem yet? It seems quite common.
Thank you for your time.