I have read a little bit in various places about texture arrays, a method of having multiple textures on a single mesh. Does JME support this out of the box and if so, how can I use it? I’d prefer to not write my own shader if possible. I’m specifically looking into it as a high-performance replacement for a texture atlas as those can take quite a bit of time to stitch together at runtime, which is necessary in my case.
yes. but you need to check that if your hardware support TextureArray.
Take a look:
Yes, JME supports texture arrays.
No, that doesn’t automatically mean that you can have a mesh with multiple textures on it. That would be up to you to write a shader to use the texture arrays. None of the standard JME shaders support this as for regular models a texture atlas would be used.
In that case, do you have any recommendations for having a more efficient texture atlas generation? In my case, I need it as my game supports mods (and running many of them together) and most mods will need to add textures that will all be used in meshes together. Splitting up the meshes by texture would mean too many meshes.
I don’t know. I know how to write shaders so I would write my own.
…but the problem you are trying to solve is one of the harder problems to solve. It’s why 99% of games have extreme limits on this sort of flexibility.
Is there a thread-safe image class that can be efficiently transferred into JME?
I don’t know… you don’t really need one, though.
The grass shader that @canis85 implemented (that I use as a base for my fur) uses both texture arrays and in engine generated images. I know it’s not exactly what you are after, but it may be a good place to poke around.
I was thinking of a possible way to improve the speed of texture atlas generation.
You don’t need thread safe images for that. Generate the image on another thread. Pass it to the main thread… never the two shall cross.
The main reason for the multithreded texture atlas generation is to decrease the time it takes to load the world (a similar game can take 10+ minutes due to this issue). If I generate the texture one the JME thread or my own thread, it still prevents world loading from taking place.
You do not need thread safe images to do that. But now I’m repeating myself.
Generate the image on a background thread. Then hand that image to the main thread.
Never once. Not ever. As in never… did you require two threads to access the image at the same time. ie: no thread safe images required.
…but that’s the last time I’ll say it… so just reread it a few times.
Yes, I could do this. But, the mesh/world is unable to appear in the main thread until the image is passed to it. My game won’t know what images to include in the atlas until the user loads a world. When they load a world, it can start building the atlas on any thread, but, unless multiple threads can build the atlas at the same time (and maybe even then), it would take too long to load the world as creating the atlas is part of loading the world. Also, to be clear, I am expecting literally tens of thousands of textures in some use cases. To summarize, even if I run the texture atlas generation on a background thread, the game will still stall until it is generated.
Umm… good luck with that.
They are almost all low resolution (64x64 max, most will be 32x32).
If they are literally different texture objects then it doesn’t matter… you will overwhelm your GPU no problem. It doesn’t matter how big they are… all of those texture switches will kill you.
This is why it’s a hard problem that most games don’t allow. Offline processing will be key.
So you’re basically saying that arrays won’t work anyway and that an atlas must be used to make them all be in the same texture object?
Also, I’m not sure what you mean by “offline processing.” The game’s server won’t have texures at all…
this is correct, you will have to use an atlas
Offline as in not rendered while the game is running (nothing to do with networking), but processed before hand.
Would a video card even support a texture atlas large enough to hold tens of thousands of 32x32 textures?
In a 1024x1024 texture, you can hold 1024 32x32 texture. So you’d only need 10 of them to hold 10,000 32x32 textures.
…it’s still kind of a near-ridiculous amount of textures to try to manage at runtime unless they are already managed as part of a sprite sheet or something.