Some questions about runtime generated images used as textures

Troubleshooting graphics
1

Hi!



I've some doubts about some matters on runtime generated images that are being used as textures.



First, I would like to know if the flag TextureManager.COMPRESS_BY_DEFAULT, does effectively compress those images someway, and if it does, which sort of compression does use (maybe the s3tc?).



Second, I would like to measure how much memory my textures are using. I've taken a look on the code that does the measurement on each texture, but for what I can see there, if there's any sort of texture compression on the runtime generated images, isn't taking it in consideration. Maybe because the texture compression is done 'on the fly' by the video card and there's no way to know how much memory will it take at that point?



And third, if the textures are being compressed by the videocard so we can't know for sure how much memory do they required when they're used, is there a way in which I can get the maximum and currently free videocard memory?



Thanks a lot in advance!

2
  1. Compression is S3TC DXT1,3,5 RGB/A.  The default compression (if used) is DXT1 RGB or RGBA depending on source image.


  2. The Texture class knows how to calculate memory requirements for S3TC compressed images.  Have another look at Texture.updateMemoryReq


  3. From reading the OpenGL red book, it seems the best you can do is call to see if a given texture will fit in opengl texture memory (although you'll have no real guarentee it will be in the video card memory itself.)  If you find a way to determine max and current free video memory, please let me know. :slight_smile:
3
1. Compression is S3TC DXT1,3,5 RGB/A


very interesting. Too tired now, but tomorrow will come back here...

can it use 3 and/or 5 with alpha?

I think 3 was a  good intermediate point for the fact is surely more supported by old 3d, cards, but is just something I wildly suppose...

(but reply first to the tiger, I know too well why his question is more important han mine... ;) )


4

Thanks a lot for your answer, Renanse.



Then, what does happen when I do use a BufferedImage I created as a Texture, is that is just RGBA format. That's what I needed to know, I wasn't sure if it was then compressed in s3tc, or any dxt format when it was uploaded to video memory. So I've no compression of that sort then, unless I manage to compress the BufferedImage to any of that formats first.



If I find anything about getting the max/available video memory I'll let you know :slight_smile:



Thanks again for your comments :slight_smile:



Snaga: The problem is not what you can use, for textures being read from files, you can use any of that compression formats if you did save them already on that formats. The problem is when you do generate an image 'on the fly', which is just RGBA format, an has no compression. So it takes more video memory than a compressed texture. Something else to investigate, a way to compress images from code :wink:

5

@snaga, all 3 support rgb/a, not just dxt5.  sorry if I didn't make that clear.



Your BufferedImage will be either RGB or RGBA depending on if it's color model has alpha  (see bufferedImage.getColorModel().hasAlpha():wink:



That said, the way the TextureManager is setup right now, buffered image (or other awt image derivatives) will only go that far and not actually do all of the automatic compression, etc.  This is a mistake I'll look at correcting sometime tomorrow.  Such a texture should be loaded, cached and treated the same as textures loaded from a URL.



Hope that is what you were looking to find out!

6

Yes it is :slight_smile: Thanks a lot again :slight_smile:



I've been investigating about the available video memory, and looks like that from opengl there's no way to know about it. The cards technology vary too much to be predictable, and opengl does abstract enough from the hardware to not let you be aware of that 'low-level' info anyway.



So the conclusion is that the best chance is to have an approximation thanks to the measurements the Texture class do.

7

Hi again,



If anyone is interested, that is what I'm doing now to get the generated image, being processed as a compressed texture ('bufferedImage' is an instance of BufferedImage):



Texture t = TextureManager.loadTexture(bufferedImage, Texture.MM_LINEAR,Texture.FM_LINEAR, 1.0f, true);
t.getImage().setType(com.jme.image.Image.RGB888_DXT1);
TextureKey tk = new TextureKey(null,Texture.MM_LINEAR, Texture.FM_LINEAR,1.0f, true, com.jme.image.Image.RGB888_DXT1);
t.setTextureKey(tk);



For images with alpha, just change com.jme.image.Image.RGB888_DXT1 to one of com.jme.image.Image.RGBA8888_xxxx constants.