Are there any circumstances under which a .jme file that is generated would contain explicit paths to the textures instead of relying on the texture paths set at load-time?
I only had a short glance at that new texture key/url stuff some time ago, but it seemed the absolute paths were stored, yes. (Which did not make much sense to me) . . .
converted milkshape files contain texture paths. YOu can replace the paths with
TextureKey.setOverridingLocation(new URL("http://localhost/models/"));
Personally I think this is very bad if it is keeping absolute paths…does anybody see any reason why it shouldn't be removed?
"very bad"? I think that's pretty strong. I could see a complaint like "uses a little extra memory that will under most circumstances be overriden at run time anyway" or something like that…
Reviewing TextureKey, it stores a URL, which can be used as is, or manipulated by a LocationOverride object to come up with a new URL (please remember that the behavior of a LocationOverride object can be user customized, so more than just the file name could be useful to the programmer.) This is not "very bad" maybe a little wasteful.
That said… Personally, I would like to see us move to a system where the app registers potential paths for assets like textures and from then-on only needs to refer to textures (or sounds, or whatever) by the file name itself, leaving locating the asset to the manager the paths were registered with.
When I wrote the texture loading stuff for my 2D games engine, I used relative urls so that you could have a relative path as well as just a filename, which is often useful when you get to the stage of having more than one "glow.png" or something similar. Code only ever had those relative urls, then a texture loader got them via class resources. Hopefully something similar to that would work? At the moment I have all resources in one horrible directory, but it would be much neater to split them up into subdirectories by plane, map etc. For the final game I imagine I would jar all the resources for distribution. Looking at the current code, it seems like it would be hard for a texture loader to work out which bits of the path to get rid of, whereas if it was standard behaviour to use relative paths it would be very easy.
Im getting to the point where the game will be creating .jme files. Similar to singoki, have many art works scattered around in many jar files.
Has this been tested using webstart where there are artworks across many jars in one .jme file
@renanse, okay, perhaps not as bad as I initially thought, but I had someone trying to load a model I had saved and although I had specified the directory where the textures were at it was still throwing an exception because it couldn't find something in P:workspace… and that's what has me bothered. I don't doubt it's a mistake on my part but still something that can cause people problems if they see if working fine on their PC and then when they ship it off to someone else it doesn't work and it's hard to figure out why.
The stored path shouldn't be trusted whether it's absolute or relative. You should always set the TextureKey's location override value, otherwise you'll have nothing but heartache.
then why save the paths at all?
As previously stated, path information, especially relative, can be used to target a specific version of an image file, etc. It's extra data that can be used by the programmer.
Just to give 2 more cents 
I have tons of pennies laying around.
Why using paths in the file are bad (relative or absolute). These are hardcoded values, store in a binary representation of a model. These are values that can not easily be changed, pretty much the very definition of hardcoded. Therefore, if you rely on these values, and say 6 months into the project realize you need to change the location of all your textures, you're screwed. However, if you define your location in TextureKey you can easily change this as needed (if you do it right you can define texture location in a props file and don't even need to recompile when the locations change).
So, why are they in there? One big reason is it then keeps the history of where the original texture lived, in case of future texture problems (which there always are). Renanse mentioned a few more.
My only point, is if you rely on data that's stored into a binary format referencing items that can change, prepare yourself for multiple re-exportings.
i doubt that this is useful for the .jme format, but if everyone is donating cents and pennies…
in my (almost forgotten) project i manage my textures by names. i.e. each texture has a name, and there's a mapping to those names with paths (could be also done with url's). that way if a texture or path changes, i only need to change those mappings.
I dunno… I don't think there is anything magical about the last section of a file name, such that relative paths are always bad. Any argument that can be made for only using the filename, and not a relative path, can be switched around, because both a plain filename and a relative one refer to a file at a particular location in a directory. It's just that the relative file refers to one that is inside one or more subfolders. You might change the folder at some point, yes, but then you might change the last part of the filename as well as the relative bit
Another point is that we still use packages in Java even though sometimes classes are moved from package to package - the point is that that situation is quite rare, and the benefit of having well organised classes all the time outweighs the possible inconvenience of sometimes having to refactor. If you have well organised resources referenced by a mapping, it should be easy to update that mapping for a new relative path anyway. Given that Java is already so heavily based on having a sensible directory structure for class files it seems odd to go flat for resources. If you find yourself still bothered about having a path - just pretend that the "/" in the filenames is the same as any other character like an underscore, just used to separate the name to make it more readable After all, as far as pretty much any code goes, it IS about the same. The only time you will notice the difference is that the resources folder is a LOT easier to look through with a file browser
darkfrog said:
@renanse, okay, perhaps not as bad as I initially thought, but I had someone trying to load a model I had saved and although I had specified the directory where the textures were at it was still throwing an exception because it couldn't find something in P:workspace... and that's what has me bothered.
Ok, I now understand the root of my confusion with regards this issue.
It seems that when I converted by .3DS files to .jme files I used the MaxToJme FormatConverter.
FormatConverter m2j = new MaxToJme();
java.net.URL turl = Application.class.getClassLoader().getResource("data/textures/other/");
m2j.setProperty(MaxToJme.TEXURL_PROPERTY, turl);
The only problem with this was that when I later tried to load the .jme file the texture's URL was a reference to an image in a .jar file.
mojomonk said:
Why using paths in the file are bad (relative or absolute). These are hardcoded values, store in a binary representation of a model. These are values that can not easily be changed, pretty much the very definition of hardcoded. Therefore, if you rely on these values, and say 6 months into the project realize you need to change the location of all your textures, you're screwed. However, if you define your location in TextureKey you can easily change this as needed (if you do it right you can define texture location in a props file and don't even need to recompile when the locations change).
Dandy, but if hardcoded paths are bad, and because many formats do that, the converters should *not* throw exceptions if it can't find a texture. :(