Alba wrote:"I was experiencing blocks of different colours along these panel lines after saving my work back into DXTBmp,"I noticed that behavior of DXTBMP myself. That is why I always save from a pristine image. The changes DXTBMP makes seems to be cumulative. I am always working from a layered file which is not saved through DXTBMP. If you use a tool such as FSR to check your work, you do not need to bring up FS9. FSR is a fine tool for lining textures up and such. Also, you need not close a texture in DXTBMP to check it in FSR. Leave the texture you're working on open. Each time you make a change to the texture file in whatever paint program you use to edit the texture, paste that result onto norm (or trans) .bmp and pull that into DXTBMP and save it. That way what gets saved by DXTBMP is a file that has never been touched by DXTBMP. Don't be afraid to use the buttons at the lower left for loading, editing, bring back and saving textures. They are arranged in a natural order - in fact the order that you would do the work in.The trick is to make sure that what DXTBMP saves is an image that in effect is new to DXTBMP. That will solve the color shift problems.I have noticed that sometimes DXTBMP wipes out the alpha channel and saves a solid black alpha channel. That seems to be more a function of what else is running in Windows at the time than any bug in DXTBMP itself. IMHO DXTBMP is a highly useful tool and Martin is forever to be commended for making it. It is definately worth what it costs us to use it.Bill

Sorry Bill that was not my intention.(dressing you down in public)Nevertheles it is vital to give answers to questions on this forum is such a way they can be understood clearly.So if somebody gives an incorrect answer ,due to less knowledge about the issue or not good reading of the question ,or just by mistake , I`ll try to give a correct answer.The best way not to get corrected is not giving incorrect answers.In case of giving incorrect answers myself , please feel free to correct me publicly on this forum, NOT by mail.Then the correction is of some use for others too.And thats all this forum is about.I can handle some bumps in my ego and do not want to hide them.Best regardsLeen de Jager

It is definately worth what it costs us to use it. Bill wrote about DXTBmp.As far as I know , DXTBmp is freeware. Messing up alphas is something wich ( people tell me) FSRepaint (wich costs us something to use ) sometimes seems to do.;) Leen

Hello again folks.I have downloaded FSR demo to use as a viewer. I understand about the dangers of continually re-saving the same texture file in DXTBmp. However, I cannot figure out how to get the file from PSP9 after an edit , back into the a/c texture folder without going back through the conversion process in DXTBmp.I am obviously not looking at this correctly. Could you advise me a bit further please?

To get the texture after editing ( as a PSP or PSD file ) back into the texturefolder as a DXT, you can do that without any problem via DXTBmp.Repeatingly saving THE SAME file in DXTBmp effects the quality of the file.BUT you are working on PSP or PSD and just save a copy as targa (with or without alpha) or BMP 24 bit to convert to DXT via DXTBmp.Saving to DXT3 gives a smaller file with 256 color-quality.It wil be of lesser quality than your PSD or PSP.Saving to 32-888 gives a file wich is bigger with 16 milj colors in a quality wich nearly equals your original.So doing this in this way, you create a NEW DXT file every time you want to view your paint in FS or FSR.See the sceme I made on the previous page on this topic.Leen

Hi Leen, thanks for sticking with me on this, I appreciate it.Yes, I was thinking along those lines regarding the file saves. I have not as yet simplified my folder structure although I have made separate psp and tga folders to save to. I will sort out my folders once I know what works.One more thing I have discovered. When I open the tga file in DXTBmp the alpha texture box now shows the bottom few lines of the image as not being pure white, 255,255,255. They are grey and black jumbled together. I refreshed the Alpha one time but on the next reload it was back to the same way again.Will I just refresh back to all white when I am completely finished?

Give me a screenshot pleaseLeen

Hi Leen, here is the shot. This is after an edit in PSP9, saved as tga, then opened in DXTBmp. The Alpha channel in the original textures is completely white. I do not know where the grey and black has come from.I have had to make an attachment. I do not know how to insert a picture like you did earlier.

To be frank.I do not know what happens.I never save to tga , I know in can be saved as.What happens to the alpha, no idea.Mayb you can go around the problem with saving to bmp 24 bit instead of targa and restore the aplha later.( the alpha saved from the original file).Or saving the PSD file( not PSP) derectly to dxt with ImageTool.Maybe Morgan can help?RegardsLeen

Hi Folks. I have finally and with your help successfully managed to finish my repaint. Like I said earlier, it was meant to be a simple rework and addition of new text. I have learned a lot about using the programmes and am gratefull for that.However, I am not sure why there is such an abrupt colour change at certain areas of the airframe. Particularly along the top of the fuselage and at the base of the tailfin. Also above the flightdeck windows.I have checked that the colour matches in each of the textures and rotated the aircraft in the sim to allow for sunlight but am dissapointed that the a/c has so much shade differences. I have read that this could be inbuilt in the model. Do you think that this is the case here?

>Hi Folks. I have finally and with your help successfully>managed to finish my repaint. Like I said earlier, it was>meant to be a simple rework and addition of new text. I have>learned a lot about using the programmes and am gratefull for>that.>>However, I am not sure why there is such an abrupt colour>change at certain areas of the airframe. Particularly along>the top of the fuselage and at the base of the tailfin. Also>above the flightdeck windows.>>I have checked that the colour matches in each of the textures>and rotated the aircraft in the sim to allow for sunlight but>am dissapointed that the a/c has so much shade differences. I>have read that this could be inbuilt in the model. Do you>think that this is the case here?I doubt it. Though, if it was the case, you

Alba, Try this procedure.1. open DXTBMP and load the texture file you want to edit.2. send the texture to your editor (PSP?)3. if you sent a texture to the editor, then it should open up in PSP as norm.bmp.4. open the layered PSP file for that texture that you got from a paintkit (they are there for many models out there). Alternatively, copy norm.bmp and make a new PSP file that can be worked in layers.5. Do a round of editing on the PSP file and save the changes as a PSP file. Do not close PSP unless you are finished.6. Flatten the PSP file and copy/paste the result onto norm.bmp. 7. Flatten norm.bmp and save it.8. Pull norm.bmp back into DXTBMP and save the texture file.9. Check the results with FSRepaint.Repeat steps 5 through 9 as many times as needed.The same procedure would apply to trans.bmp except that it comes in as an indexed color bitmap. This way the only file format conversions are done in DXTBMP and the file that gets saved is clean every time. This works well for me. The trick is to do all your editing on a layered file that is native to your editor. DXTBMP then becomes just a conduit for the DXT3 files FS uses as textures.Let me know how it worked for you. If you still have problems, feel free to email me.Regards,

I am sorry to say, but I do not agree with the procedure above.Alltough the procedure keeps the texture quality OK , the file may become instable.Doing it likewise the description above the same DXTfile gets saved multiple times in DXTBmp. ( pull back is re-laoding as I read it)We do not see the texture getting worse, that part of the file is refreshed each time.BUT other information in the file gets saved multiple times wich can give severe problems.On page one of this topic I wrote>>>Never open-edit-save and re-edit a file multiple times in DXTBmp.Each time a file is saved the quality gets worse.You may even end up with a file wich shows textures normally in DXTBmp , but wich is so damaged it can crash ( to desktop) FS.<<<>>>Multiple savings in DXTBmp are responsible for loss of quality and reliability of the files. Just ONE final saving of the texturefile in DXTBmp will do.If you have any doubt about that , just ask Martin Wright.He told me and I believe and confirm what he said about this phenomena.<<

Leen, I don't know what you are reading into my procedure - and the problem may well be just that you are posting in a language other than your milk tongue - but my experience with DXTBMP is that the proplem with color shifts is not a function of how many times a file was SAVED so much as in how many generations of saves there.Here is what I believe is the source of the problem. DXTBMP does a conversion from a standard windows bitmap to the DXT3 format when it saves. The two file types are quite different. I suspect that what we are seeing as "corruption" of the textures is merely an artifact of the compression process. It could also be related in part to Martin's implimentation of the algorhythm but I am leaning towards the former explanation.In any case the file conversion artifacts are clearly cumulative. When DXTBMP loads a texture file from disk, it does not appear to modify it. When it sends it to the editor as a standard Windows bitmap there is no evidence of any artifacts there. So if I edit the file, save it with the editor and refresh it in DXTBMP so far there has been minimal if any file "corruption". When DXTBMP then saves that result, I believe it is there that the artifacts are produced. Stay with me here.If I reload that texture at that time (or some other time) and send it to the editor then what is sent to the editor includes any artifacts of the prior save operation. So if I edit the norm.bmp in my graphics program, save the result, refresh and save from DXTBMP, then I have saved a file that already had some level of "corruption" and that tiny amount of "coruption" is added to in the save process.If, instead, I edit another file, copy/paste the result onto norm.bmp,save norm.bmp and refresh THAT into DXTBMP, I am saving a file with no appreciable "corruption". The secret is to use norm.bmp merely as a conduit between your graphics editor and DXTBMP. The only modification you ever make to norm.bmp is to paste the result of your last edits onto it to pass those changes back into your texture set via DXTBMP. In effect, DXTBMP is always saving a pristine version of the texture file. And you can repeat the edit-copy/paste-save-refresh-DXTBMPsave part of the process effectively an unlimited number of times without inducing any additional artifacts into the texture.Leen, this process works well for me. If you do not believe me, LOOK AT MY PUBLISHED WORK! All the texture files are clean. But stop stalking me. I am going to go to the mods. Here is that public enough for you?

I am defenatelly not stalking you Bill.Just answering to things you publish on this topic.This is a discussion about reprepainting.If fact that`s what this forum is al about.Discussions are very normal at this forum.People have different opinions.If you have any doubts about my explantion.Sent it to Mr Wright and ask him to give his opinion about my explanation.Here on this topic if possible.I cannot put it more clearly , maybe he can make you understand.Best regardsLeen de Jager