• Advertisement
Sign in to follow this  

Comparing 2 textures [solved]

This topic is 4615 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'd like to check if 2 textures are identicall or not. For the moment, I get the first mipmap level, then the description. Depending of the format, I compute the size of the textures (in bytes), lock the entire textures, and simply do a memcmp on the 2 pointers. BUT with compressed .dds (DXT1, DXT2, etc.) I have a problem : how do I compute the actual size of the texture to feed the memcmp function ? I someone can help me on that, or tell me another way to do the compare ... thanks in advance ^^ [Edited by - paic on May 31, 2005 9:43:43 AM]

Share this post


Link to post
Share on other sites
Advertisement
One way if im correct is by caculating the crc32 of the textures and comparing that. Another way is with a texture manager, I use one for my projects but generally I just compare the textures file name because I generally use external resources.

How ever if you had a texture manager you could always caculate the crc32 of each texture at initilization, however this may lag a little, so good to put in a load screen.

Share this post


Link to post
Share on other sites
In theory you should be able to use any file-diff tool. It probably can't show you the differences for binary files but should be able to confirm if the files are the same. However the files must be identical, not just the image described. If you want to do it at run-time from your program, just generate a texture from each image file using D3DX functionality maybe and compare the data there?

Share this post


Link to post
Share on other sites
Ok, seems like I wasn't really clear

@DevLiquidKnight : I'm needing that function for a texture manager ^^ Checking the filenames is not enough : what if graphists export 2 models in seperate directories, with the same texture ? And to complicate, they even changed the texture name ! (Aaah those nice graphists who seem to like making our lives like hell ^^) To compute crc32, I also need the size of the data block, which leads me to the same question : how do I get this size for a compressed texture like DXT1, etc. ?

@d000hg : loading the texture using a D3DX functionality and compare the data ... ^^ That's what I already do, and it's good for standard texture : ARGB, RGB, L16, etc. because from the texture format and size, I can compute the size of the data. But my question was : for COMPRESSED textures like DXT1, DXT2, etc. I don't know how to compute this size, and so, i'm unable to compare the data.


However, your answers gave me an idea : just compare the FILES instead of the image data, it's easier ... but slower :(


So if noone have another solution, i'll compare the 2 files, but I'd like to avoid it as much as possible ^^

Share this post


Link to post
Share on other sites
You could perhaps load the texture itself into memory which would uncompress it and compare it there.

The texture manager is not just a function its a singleton class. ^^

Share this post


Link to post
Share on other sites
Quote:
Original post by Nik02
Maybe this will be of help. Haven't had the need to calculate compressed DDS memory layout myself, though, so I cannot confirm the info personally.


This should work for him I think, it gives equation:

When computing DXTn compressed sizes for non-square textures, the following formula should be used at each mipmap level:

max(1, width ÷ 4) x max(1, height ÷ 4) x 8(DXT1) or 16(DXT2-5)

Share this post


Link to post
Share on other sites
Thx a lot Nik02, that's what I was looking for ^^

Share this post


Link to post
Share on other sites
I really hope this isn't to compare textures to remove copies from your texture manager. You're going to send load time through the roof, if it is. =)

Share this post


Link to post
Share on other sites
@Grozzler: Yes it is ^^ nooo, don't screem, it's not that bad ^^
explanations :
1) It's only during loading time, so in worst case, loading will be slightly longer (of course, in case of streamed loading, I'd have to rethink that, but i'm not there, and it's just a matter of a few lines of code to remove)
2) Before doing a comparison like that, I first check the file's name, its property (size, format, pool, etc.) so I almost never reach the texture comparison code.

It's just here as a final check in the case the graphists were vicious enough to rename a texture and re-use it in another model ^^ Doesn't happen very often, but can save a little amount of memory, and you won't see the difference in loading (I just finished testing my code and it works quite well ^^)

Share this post


Link to post
Share on other sites
This is a bad idea. Don't compare textures at all. Just ignore this and kill the graphic artists if it happens often.

If you absolutely must compare textures, do as DevLiquidKnight says and calculate a CRC hash for each texture and store that in your texture manager.

When you detect a duplicate texture, you shouldn't silently discard the duplicate, but you should hook it up to a tazer and send a 100,000 volts through the graphic artist.

Fortunately, mine are now trained rather well. It only took a few jolts... I do miss the smell of well-roasted flesh, though.

Share this post


Link to post
Share on other sites
hi,

thx for your concerns, but : why do all people keep saying : "don't do that, do this" without any explenations ?

I'm desperately looking for informations !! Comparing 2 textures is bad ?? yes ?? but WHY ??

I understand that it may be bad for the performance, but I said something before about that : early rejection makes the case where I compare the textures really rare.
second, here is a simple timing of this piece of code (2 timeGetTime() on both side of the testing function. I know it's not the most precise but it's sufficient) :

1024x1024 DXT5 (approx 1Mo) : 0.001 second
1024x1024 RGBA : 0.006 second

So. Is this really unacceptable, knowing that the case when I have to compare the textures occurs quite rarely ? (the graphists with who I work are not so bad after all ^^)

I'm NOT saying i'm right or something like that. It's just that I don't understand why you say "this is a bad idea" :/

Share this post


Link to post
Share on other sites
It's a bad idea because you're creating extra code (with extra possibility for errors, more maintenance etc) for a problem that you shouldn't have to deal with. Also, you're not solving the problem, but partially working around it. "Partially" because there are many ways textures could be equal without being byte-for-byte identical. The solution to the problem is good communication with the artists.

Finally, comparing two textures may be fast enough, but what about an actual game scenario? If I check my past game projects, there hundreds, even thousands of textures, many of which have the same dimensions. If I were using this technique, loading as few as 100 textures, I'd have to do 5000 compares. Even at 1 millisecond per compare, that means doubling the load time of my game.

Share this post


Link to post
Share on other sites
k, I'll think about it, thx for the reply ^^

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement