[SOLVED] How to load a Texture?

“Read the wiki!” ok, somebody needed to say that to such a question. However, I do this:

    getAssetManager().registerLocator("extrapath", FileLocator.class);

and

    Texture sheetsX=assetManager.loadTexture(msCont.sheet);

This works when my assets are all unpacked. But if I have some assets packed into assets.jar, and others on a separate folder that might or might not be present (read: dlc) then I get this:

java.lang.IllegalArgumentException: Given root path "C:\path\assets"
is not a directory
        at com.jme3.asset.plugins.FileLocator.setRootPath(FileLocator.java:54)
        at com.jme3.asset.ImplHandler$ImplThreadLocal.initialValue(ImplHandler.j
ava:120)
        at java.lang.ThreadLocal.setInitialValue(Unknown Source)
        at java.lang.ThreadLocal.get(Unknown Source)
        at com.jme3.asset.ImplHandler.tryLocate(ImplHandler.java:178)
        at com.jme3.asset.DesktopAssetManager.loadAsset(DesktopAssetManager.java
:360)
        at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.ja
va:391)
        at com.jme3.asset.DesktopAssetManager.loadTexture(DesktopAssetManager.ja
va:401)

What is “extrapath” pointing to? It’s relative to the root of the jar structure.

If you have a directory in the jar called “assets” then that would be what you register. Just the word “assets”.

You can also try/catch the line where you attempt to load the asset. If it doesn’t exist, catch the error.

While developing (unpacked assets) I have this:

Project\assets\Texture1.png
Project\extrapath\Texture2.png

With registerLocator, I can access both Texture1 and Texture2, if present.

When I build the game, I have

c:\mygame\lib\assets.jar (contains Texture1)
c:\mygame\lib\extrapath\Texture2.png

When I try to access Texture2 I get the above error

You must register this path in its entirety. As it is shown in the quote.

System.getProperty("user.dir"))

Will get your working directory. The directory the jar was executed in.

1 Like

Did you edit this for our benefit or does it actually say C:\path\assets?

And if it does, where in your code did you set that path?

And if you edited the message then don’t as that was some of the important parts.

I’ve shortened for simplicity; it was c:\mygame\lib\assets\

basically: the path where the game is currently installed and running + “lib\assets”. So this is where usually all the assets reside, which is right. However, it is a .JAR file (and is missing the extension as well) and not a folder, hence the error.

Which brings the question: If I register an AssetLocator with FileLocator, why does the assetloader use the FileLocator for the assets.jar?

  • There’s a bug, either on my code or JME
  • Different Locators aren’t supposed to be mixed within the same assetLoader
  • ???

I’ve never had this issue with registering locators.

The problem with us trying to help you is that we can’t see the relevant code and the error messages to match.

If assets.jar is on the classpath then assets will be loaded from it. If you manually specified a locator for assets.jar then that code is messed up.

he were asking about DLC before here:

now its only about loading Texture from external dir.

im also curious about it, lets say i create custom save/mod JAR file. and i know its dir(or just chedk files in external dir), for example:

File file = new File(JmeSystem.getStorageFolder().getAbsolutePath() + “/” + fileName + “.save”));

and use ZipFile and InputStream to read Textures/etc from JAR. (lets say this JAR is Mod and have settings/textures/models)

as i remember Minecraft also had mods in documents.
Since Steam do not like files within Game directory.

is it ok i use “File” here? for me assetManager is for internal game files, am i right?

or should i register this locator into assetManager while checking mod JARS?

If you are just loading your own random format, there is no strong reason to use the AssetManager at all unless you really want to implement all of the SmartCache stuff.

I load files all the time that having nothing to do with JME. I generally just use a URL/URI in my actual loader routines so that I can load from the classpath or file or whatever I want.

2 Likes

Thanks!

so main advantage of assetLoader is just “SmartCache” , quick access to assets and optimize to send to OpenGL, right?

so some “assets” like saves/etc even should not be loaded via assetLoader to save memory and not hold data in cache all the time.

If use assetManager to load Mod, it will cache custom format/etc files so memory usage will be bigger until user clear it, while GC could just clean it some time after loading if just use “File” and read what is needed.

While im not sure how much important is “optimizes the handling of OpenGL objects”, i belive Textures and Models should always be loaded via assetManager? here i dont for saves, where i also save alphamaps of terrains, should i use assetManager here somehow? (please note this textures are in JAR along with other files)

If i could i would like ask one more question:

  • when i know that some asset cached in assetManager will be no longer used(once it already were send to OpenGL buffer), should i clean cache from assetManager to optimize memory?

I made a test with minimal code and it works. So the issue is something else I did :frowning:

1 Like

DLC is different. It will be there at compile time but may not be at runtime.

Loading jars that may or may not exist in a DLC directory is essentially a plugin. If the jar exists then it should be injected into the class path at runtime.

This type of architecture is beyond JME scope. It’s a plugin system.

Edit: don’t know why this turned up at the top of the new replies list. Sorry for the graveyard dig.