Hi,
I need some clarifications.
In Skullstone we use DDS textures compressed in BC1, BC3nm, BC5 formats. I heard that some hardware or drivers may not support those compression, so the question is what to do in such situations?
Do I need to have an alternative textures, compressed to PNG? If so, how to load texture.PNG instead of texture.DDS, having material made in j3md file (not in the java code). Does AssetEventListener will help? Or there is completely different way to solve this problem?
j3m files are kind of made for this, you could have one jar with j3m’s pointing to PNGs and one with j3m’s pointing to the dds files (and obviously containing the images as well) and use one or the other depending on the system. A j3o will store the j3m path and use its data when a j3m was set on it once (if the j3m isn’t found it uses the material data stored in the j3o btw).
So I need a two different builds…
Or at least a two different assets packs…
Yeah, just create two folders, make a jar from each and add it to the classpath. Actually I planned this as a feature for the SDK (also for mobile vs desktop etc.) but some ant targets should do the trick.
Can I have two assets packs registered with AssetManager.registerLocator and with the same directory structure inside both of them?
I’m thinking of one basic (main) asset pack with everything I need: j3o, j3m, j3md, dds textures, png textures and so on… This asset pack would be registered always.
The second one would have alternative j3md files and would be loaded only if I somehow find that the dds is not supported. That second one would be loaded before first one.
So, correct me if I’m wrong, having both packs registered, I load dungeon1/wall/wall.j3o which is stored in the basic pack, it will load its material from the path dungeon1/wall/wall.j3md but because the additional asset pack was loaded first, the material would be loaded from there. It will have paths to the PNG files, for example dungeon1/wall/wall_spec.png, that file isn’t located in additional asset pack, so the engile will look into the main one and load a proper file from there.
Will it work this way?
I guess it would, can’t exactly say how the asset locators are worked off though. What I’d do is simply make two folders but make jars from them with the same name and keep one somewhere else in the dist folder… Register one of the paths for development and make the main jar name being injected in the main mainfest file (see build/assets-impl.xml). Now you can just drop one or the other jar in the lib folder and use the textures that way, using some kind of launcher or such. What ever way you do it I’d definitely keep both j3m/texture sets in a separate jar and use them interchangeably so you avoid name overlaps.
Complicated…
I’m thinking about a dirty hack…
TextureKey does not have an setter for file name/extension, but it can be serialized and deserialized with JmeImporter and JmeExporter… so… I’ll write my own class which implements both interfaces and with a proper code to change the filename/extension. When I need to load an alternate texture I’ll simply write its data into my object, change what I need to change and load the object’s data back into the TextureKey. All inside the assetRequested function.
I did worse things in my life 
Now the question is: How to determine if the BC1, BC3nm, BC5 and so on, are supported on the machine? During runtime ofc.
I normally use a test texture to load and if I catch the exception, I change from dds to png. Not a very pretty solution, but I make that test load only once, and I have a loader class that uses the assetManager
Which way do you change from dds to png? Is it something like Normen described? Or there is an another clean way?
I only need one jar for my project and this is what I use
My loader class test loads a dds to see if it can be done. If it succeeds all textures I load will use the .dds extension internally, if it gets an exception, I use .png. In my game code, to load textures all I use is something like
myLoader.LoadTexture("Textures/grass");
myLoader adds the dds or png extension based on the result of the test load.
For materials, I add a suffix for the material file name, like "_dds" and "_png" that my loader class use internally, for example
myLoader.LoadMaterial("Materials/table");
the loader adds the "_dds.j3m" or "_png.j3m" internally.
I get what @normen describes and that would be useful when you want to avoid a very huge assets.jar file that contains everything. but it really depends on the project
Actually a kind of hackish solution would be to rename .png files to .dds and include them into a separate asset package. When running on a system which doesn’t support DXT compression, include the alternate asset package and assign “AWTLoader” as a loader for .dds files.
Textures and sounds are the biggest assets in a game, I doubt its a good idea to just double that size by adding files willie-nillie.
Maybe I’m missing something, but what’s wrong with
boolean uncompressed;
if (uncompressed)
assetManager.loadTexture(xxx+".png");
else
assetManager.loadTexture(xxx+".dds");
Why mess up with materials etc?
Because this example means either a line of code for each texture you load or additional metadata in your application to assign materials/textures to models. (Which is fine if you are artist and coder in one person, if you have separate artists then not so much).
The goal is to have every model (object+material+textures) in one pack (directory) and possibly load alternative textures, having DDSs as a default.
By the way, do you know of any specific systems or drivers where DXT/BC compression isn’t supported?
I am not really aware of any – apart from mobile GPUs on phones and such.
Here is something about that: Switching default texture format to DDS - FlightGear wiki
I’m not sure if I need to worry about it.
A propos mipmap levels - it would be great if I could just say: Please only 6 mipmap levels.
Is that possible with DDS or with jME in general? I need that for a compact texture atlas with mipmaps.
Should I create another thread for that? 
Whenever you ask yourself that question, the answer is most often “yes”. Don’t be shy on creating new forum threads.