Yeah I guess that's what causing this cus the CE3 RC will auto generate every .tif file to .dds file. So whenever we save the crytif file (with CE running in the background, I believe) it will generate 2 file at the same time; .tif and .dds.
So basically qsm-compose-temp.tif saved then qsm-compose-temp.dds auto generated -> then qsm-compose-temp.tif renamed to be wood_01_diffuse.tif (for example) then wood_01_diffuse.dds auto generated again, which make the first qsm-compose-temp.dds redundant and it'll be nice to have that auto deleted
you are right, passerby, however it does seems like something that the tool should come with though imo. Is there no single case where you would actually want to keep that generated dds?
That is true, provided it actually is a problem with the plugin and not documented behavior. Maybe someone who uses the tool can shed some light on this.
Based on my understanding, the first temp .dds file should be a duplicate of the correct (rename) .tif file, but somehow it's just put a image with Recourse Compiler Error text on it. And I don't see a point to keep it. Since saving manually as a crytif file didn't generate any temp .dds file, but well it's just wasting lots of time if we have to manually select target folder and choose file type every time we make a changes on the PSD.
@passerby - Nah, I don't see it as a crytif exporter problem, it's just the way it work. Every .tif file exported when CE RC run on the background (I believe so, haven't test it whether the temp .dds get generated as well if CE didn't run on the background). It can't detect whether it's a temp file or real file, every .tif detected gets a .dds. That's what I believe so far and requested it to be check and auto delete qsm-compose-temp.dds if detected.
So I've been looking into CryTiff and basically all the CryTiff is is a standard Tiff with some information placed into the File Information Section in photoshop here
Diffuse
Then when this file is picked up by the engine passed into the RC, it is converted into .dds based on what it reads in the file information section.
So really all you ever need is a tiff file. With the RC parameters passed with it.
Interesting! But where would the parameters come from? I can see a couple of options:
create our own window to configure maps
Save one file and then inspect it and re-use that
Bring your own settings
If we wanted to do the first, we would need to define a subset of settings that we care for. Or someone really patient has to re-create all options. That won't be me.
If we wanted to go with the second, that might work but could be a bit annoying?
I'll get together a list of common settings and see if I can dig up a little more information on what each one means. This way maybe it will be possible to just have a drop down of the options.
Ok so rather then dump all this out in a post I'll put it all into a txt file you can download and look through at your liesure but here is a list of all the presets (taken from rc.ini) As well as some other rc options grabbed using rc.exe /help > output.txt
Seems like all that's really needed for CryTiff is:
/m (mip level 0-6 so 50,50,50,50,50,50 is the default levels)
/mipmaps [0 or 1 (yes or no)]
/preset (The preset to use I've listed them all out in the text file.)
/reduce (How much reduction should be done based on what platform the textures are being displayed on) So Quoted "" comma separated values "pc:-1,ps3:0,wiiu:0,x360:0" 0 means stay at the resolution of the image a negative values means drop it down one level (so 2048 goes to 1024 etc etc)
and that seems to be all that's needed for CryTiff.
Thanks to Richard Marcoux's handy little python script I was able to print out all the RC options specific to CryTiff Only so I'll add that little text file here. All of these can be passed in the file and will be executed when the RC is run. (The rc will be run when the engine detects a Tiff file placed in a material slot. It will pass it to the RC the RC will look at the extra information in the file and use those as arguments then the dds will be generated and used in game)
Replies
So basically qsm-compose-temp.tif saved then qsm-compose-temp.dds auto generated -> then qsm-compose-temp.tif renamed to be wood_01_diffuse.tif (for example) then wood_01_diffuse.dds auto generated again, which make the first qsm-compose-temp.dds redundant and it'll be nice to have that auto deleted
Thanks man!
@passerby - Nah, I don't see it as a crytif exporter problem, it's just the way it work. Every .tif file exported when CE RC run on the background (I believe so, haven't test it whether the temp .dds get generated as well if CE didn't run on the background). It can't detect whether it's a temp file or real file, every .tif detected gets a .dds. That's what I believe so far and requested it to be check and auto delete qsm-compose-temp.dds if detected.
Diffuse
Then when this file is picked up by the engine passed into the RC, it is converted into .dds based on what it reads in the file information section.
So really all you ever need is a tiff file. With the RC parameters passed with it.
If we wanted to do the first, we would need to define a subset of settings that we care for. Or someone really patient has to re-create all options. That won't be me.
If we wanted to go with the second, that might work but could be a bit annoying?
Third: Is this possible?
Seems like all that's really needed for CryTiff is:
/m (mip level 0-6 so 50,50,50,50,50,50 is the default levels)
/mipmaps [0 or 1 (yes or no)]
/preset (The preset to use I've listed them all out in the text file.)
/reduce (How much reduction should be done based on what platform the textures are being displayed on) So Quoted "" comma separated values "pc:-1,ps3:0,wiiu:0,x360:0" 0 means stay at the resolution of the image a negative values means drop it down one level (so 2048 goes to 1024 etc etc)
and that seems to be all that's needed for CryTiff.
RC options Text File
By the way I use QSM every day it's the best.
Here is that file. Rc Tif Options