Load Material without Asset Manager

Hello everyone,

Is it possible to load a material without using an application’s asset manager?

Why am I interested in loading materials without the asset manager?
While developing my applications, it bothers me, that it is always required to pass the asset manager in every method, where a material gets loaded.

If it is not possible to load a material without an asset manager, is it possible to create a “local” asset manager?

Thank you!

You can use a static method to get the asset manager from your application without passing it everytime.
You can also make multiple asset managers (just create a new AssetManager() new DesktopAssetManager() and register all the loaders and locators you need) but it is generally not a good idea, since the asset manager handles caching internally.

1 Like

If you find yourself needing to load assets or material definitions in a place where you don’t already have an asset manager then there may be a way to reorganize your design.

For example, all app states will have access to application (and thus the asset manager). A Spatial’s controls do not but control.update and control.render are also not the best place to be loading assets or materials.

If you are like “what’s an app state?!?”… this documentation is not the best but will get you there eventually: Application States :: jMonkeyEngine Docs

…focus on BaseAppState and ignore AbstractAppState.

The high level explanation is that app states are kind of like “services” in your game and are a good place to house all of the overarching game logic. They have a lifecycle that follows the game, can be enabled/disabled/attached/detached as needed at runtime, and have easy access to all of the other app states (services).

2 Likes

@RiccardoBlb and @pspeed: Thank you both for the swift replies. I don’t know why it did not come into my mind to just create a new asset manager. I think this solves my issue and is acceptable from an engine perspective.

@pspeed: I understand your argument that I should rethink the design of my application, if I need additional asset managers to solve my problems. However, without presenting you my whole project, it is hard to understand, why I have the problem. So, I do value your hint, but I think I will just create a new asset manager wherever required.

Correction to my previous answer: the class is DesktopAssetManager and you have an helper method at JmeSystem.newAssetManager() .
I don’t know what your app is about, but if you do this only for convenience i think the static method approach is much better that creating new asset managers.

1 Like

Alright, thank you for the clarification. I appreciate your feedback… maybe I should put the effort in my project, and always use an application’s asset manager, if two engine leaders tell me to do so :wink:

Asset manager does more than load things. It also smart cache’s them. So it’s semi-important to only have one to get all of the benefits.

2 Likes

Why not just assign assetManager to a static variable, this way when you need it because you loading assets outside of an AppState you have access to the 1 assetManager JME creates. Just assign it to the static variable inside the main class.

I know it can be hard if your converting from another engine to convert everything into JME styling, vs. leaving code alone and just hacking at work around to get the coding working. can be from 100k of code vs. 1m line of code of conversion.

That is what I came across when converting my game, game asset loading was not done in a way that it could be converted to an appstate easily. It was all over the place. Each game Item loaded an asset, basically a Node/Geom/Spat defining and loading assets and that doesn’t fit in JME style.

So for speed of getting the game running I created a static assetManager variable inside my Globals class to gain access instead of passing it TO EVERY CLASS.

But if starting from beginning, I just write everything in JME style, so much easier. I’ve done 3 simple projects game since then and it is much easy to follow coding style, and cleaner.

1 Like