Reading in a file-type that isn't a standard extension i.e., file.1 file.2 etc

Troubleshooting graphics
1

Hello all,

I am not sure if this is the right place, so please forgive me if this belongs in another forum.

Normally the file is a .bmp, .tga, .jpg, etc, but in this case I am given codes for .1, .2, and .3.

I am told that in all graphical languages there is a way to read the files, get the data and file type, and output it in which ever way I need.

The issue is that I am using user-supplied files, and according to the documents we can do this, but from the certain maps it seems that I have to have specific loaders that are registered. Now would I load these new values .1, .2, and .3, or just find a way to read them?

A company name LEAD Tools apparently is about to do this read and write them no problem. I know others in my field who are able to do this as well, so I am curious how this would be done/ is this a Jmonkey Issue, or more of a Java issue?

Thanks,

~Kz

2

The name of the file is definitively not a Java issue. The fact is, the name of the file is only a “tip” for the explorer (or whatever program which is using the file). Inside the file you have headers and other datas and this only define the type of the file.

You can read in a lot of place advices like “change the extension it will change the type” and it’s absolutly WRONG. You know, you can even create your own format and put a “.jpg” at the end and nothing will prevent you to do that (even if it’s not a picture at all !).

That said, let’s focus on your problem. I bet that if you know the type of file (for exemple if they are all jpegs with only “.1” “.2” etc. extensions) you can specify if to the asset loader.

Browsing on google for “java image without extension” i found this :

basically, it’s what i said, it’s a way to find the type of the file from its header. I don’t know how much “standard” is this and if you’ll be able to use it on android (or any mobile device).

If it’s not in the basic stuff of the asset loader it could be nice to give a look at this (maybe for the 4th version of jme ?).

1 Like
3

The AssetManager indeed requires the file to have a suffix.

4
@bubuche said: The name of the file is definitively not a Java issue. The fact is, the name of the file is only a "tip" for the explorer (or whatever program which is using the file). Inside the file you have headers and other datas and this only define the type of the file.

You can read in a lot of place advices like “change the extension it will change the type” and it’s absolutly WRONG. You know, you can even create your own format and put a “.jpg” at the end and nothing will prevent you to do that (even if it’s not a picture at all !).

That said, let’s focus on your problem. I bet that if you know the type of file (for exemple if they are all jpegs with only “.1” “.2” etc. extensions) you can specify if to the asset loader.

Browsing on google for “java image without extension” i found this :

basically, it’s what i said, it’s a way to find the type of the file from its header. I don’t know how much “standard” is this and if you’ll be able to use it on android (or any mobile device).

If it’s not in the basic stuff of the asset loader it could be nice to give a look at this (maybe for the 4th version of jme ?).

Thanks for this. I looked into this a little bit after I made a post, but wanted to see how it would affect Jmonkey.

So all I need to do is be able to read the header, but as both yohu and Normen were saying the assetmanager seems to need it to be the exact “.jpg” or whatever.

So is it impossible for me to use these images? I hope not… I could probably convert them all to add the .jpg or w/e suffix so it works with the asset manager, but we will see I guess.

5

This is not exactly true.

I wrote a “quick and dirty” code that show that the AssetManager case use a link to a file.

[java]
private Texture loadTexture()
{
File file_from = new File(“assets/Textures/Ground/Ground_test”);
Path path_from = file_from.toPath();

File file_to = new File("assets/Textures/Ground/Ground_test.png");
Path path_to = file_to.toPath();

try
{
  Files.createLink(path_to, path_from);
}
catch (IOException ex)
{
  Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
}
file_to.deleteOnExit();
Texture tex = assetManager.loadTexture("Textures/Ground/Ground_test.png");

return tex;

}
[/java]

This method create a link with the suffix “.png” and the asset can successfully load the file from it. So, if we add to this the method with the mime type in the topic i mentioned we can add the support for files without extension

(with the steps:
1 - detect the real type of the file with the mime method
2 - create a link (a hard one) with the good extension. Also consider the option “detect if a link is already there”.
3 - feed the asset manager with the link
4 - tag the link to be deleted on exit (to keep the place clean).
)

Note that when i try to create a symbolic link i get an exception (FileSystemException) and i think that it’s not a good idea to use this anyway as it’s wrote on the javadoc:

Where symbolic links are supported, but the underlying FileStore does not support symbolic links, then this may fail with an IOException. Additionally, some operating systems may require that the Java virtual machine be started with implementation specific privileges to create symbolic links, in which case this method may throw IOException.
So, a symbolic link is not portable and may require some specific authorizations.

I don’t know if it’s a good idea to implement this solution in jme.

6

This code above will not work with a deployed application where the file is in a jar archive and not in a folder anymore.

But we’re talking about different things here. Of course you can load any data via the java file io system and use it in your application. The AssetManager system however supports multiple ways to load data and has a slightly more strict way of loading it. In an iOS application the data is pulled from a binary file that is compiled from the assets data for example.

In the case of “loading some file” that is given by the user you will most probably have to handle the file io yourself and adapt it from platform to platform. E.g. loading an image works differently on android and desktop. So the AssetManager probably won’t come into play here anyway.

If on the other hand you have the file in place when you create the application then its no problem adding a file extension.

7

Hmm I see, so really I would be faced with an issue of multiple deployment then, but I still can read in the files just fine?

As to what seemed to be questions about exactly what I’m doing the images will be provided by the users, they will be normal file types, just with the different extension.

Apparently the industry I work in uses this syntax, and I never really thought about it, until now when I realized it’s not .1.jpg.

These are all textures, no models yet.

As you mentioned above the code would not work if I deploy it as a Jar file? If I deploy it as a regular windows, mac, or linux file would that work?

Mobile is a different thing it seems.

Also why wouldn’t the assetmanager play a role in what you stated above?

I appreciate the help from both of you, thanks so much.

8

The desktop deployment also works with jar files. To load these files via the AssetManager you’d have to create your own Loader and probably also Locator. As I guess the .1 .2 implies that these files somehow belong together that would even give you a chance to combine these at the loading stage already, e.g. by supplying a name that encodes the tile ranges you want to load.

As for loading otherwise, you can on desktop just use a java.io.File, load the data from that and apply it to your Image buffer, on Android you probably can get the data of photos in the image library with some API and use that data to construct an Image. In that case you don’t necessarily need the AssetManager but the solution isn’t platform independent. And again, if the files are available at deployment just add the suffix.

9
@normen said: The desktop deployment also works with jar files. To load these files via the AssetManager you'd have to create your own Loader and probably also Locator. As I guess the .1 .2 implies that these files somehow belong together that would even give you a chance to combine these at the loading stage already, e.g. by supplying a name that encodes the tile ranges you want to load.

As for loading otherwise, you can on desktop just use a java.io.File, load the data from that and apply it to your Image buffer, on Android you probably can get the data of photos in the image library with some API and use that data to construct an Image. In that case you don’t necessarily need the AssetManager but the solution isn’t platform independent. And again, if the files are available at deployment just add the suffix.

Sorry I seem to always forget to mention something when I explain .1 means front sided picture, .2 means top sided picture, and .3 means side picture.

So in a cube it would be front/back, top/bottom, left/right.

I think I’m getting a little confused, so I will try to ask something’s to clear up.

So if I do use a Jar I would have to do a bunch of additional coding, but if I do Windows, Mac, Linux and then do a seperate Android I should be okay(except for android needing something special it seems)?

Does bubushe’s example work in this case? I will start trying stuff out myself, thanks for the help thus far.

10

No

11

Okay… I thought you said above “This code above will not work with a deployed application where the file is in a jar archive and not in a folder anymore.”

Maybe what I wrote above was confusing.

Or maybe I’m still confused when converting the filetype works and when to use the AssetManager or not. I thought we always did.

Also SInce I am loaded these images .1 .2 and .3 to use on cubes, I hear I need to use what’s called a “Texture Atlas?”

Am I able to use the 3 images supplied by the users, create this atlas, and then use it?

According to https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:texture_atlas it says you have to export and create the Atleast in Blender, but I couldn’t make it inside Jmonkey?

12

Yeah, as said you could either make a loader or assemble the images and textures from raw data.