Sign in to follow this  
Guest

FS Texture Converter v1.03 here...

Recommended Posts

Hi all,As discussed in the previous thread, here's version 1.03. This fixes the problem going above a few hundred textures. There is no limit now (and no memory leak). As pointed out in the readme, you must have the latest version of Martin Wrights MWGfxDLL.exe package as can always be downloaded with this link:http://www.mnwright.btinternet.co.uk/download/mwgfxdll.EXEIf possible and if any of you have a few minutes, I'd like to get definitive feedback that this indeed has no memory leak on systems besides mine that I've tested on. If no feedback can be had, I'll release it to AVSIM tomorrow sometime. For now, you can download it here:FS Texture Converter v1.03 (499KB)http://members.rogers.com/eelvish/FSTexConvert103.zipThanks and sorry about the delay,http://members.rogers.com/eelvish/elrondlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I had to blink..do a double take, its been so long! I just read your note in the other thread, thanks for the comments. Sorry you've moved on, but it happens.Best,Bob B

Share this post


Link to post
Share on other sites

That's Great! Thanks Elrond!I also read the instructions on the command line - perfect! This will be as easy as pie!Is there an N-VIDIA bug or a problem still associated with this or are we safe to use your tool instead of MS's ImageTool?

Share this post


Link to post
Share on other sites

Hi Misho,As long as you don't select type 2 as the output format (DXT1 with Alpha - NVIDIA Method), there is no problem with the NVIDIA bug as their code won't be used (it'll use Martins code instead for all other methods). If you do select the type 2 NVIDIA method, I have retained the workaround in the tool to sort-of handle the problem in v1.03... While some textures may not be converted properly using type 2 NVIDIA method, the tool will create a list of those that were not and move the successful ones to a separate path. Those and only those that could not be converted with the method will be left in the original Base folder. That way, you can convert only the unconverted ones in a separate step with a different method, such as type 1 (DXT1 with Alpha - FS2K2 Method). Why anyone would want to do this (beyond testing) I don't know, but the option is there if needed. Details on how this is handled are in the readme.Otherwise, the tool should be complete for what one might use ImageTool for in regards to PhotoReal scenery. Unless, that is, you or others have a problem or need a new feature and say its not :-).Take care,http://members.rogers.com/eelvish/elrondlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

Share this post


Link to post
Share on other sites

Just a short follow up question - why was NVIDIA method used or neccessary in the first place?

Share this post


Link to post
Share on other sites

Martin's original DLL set only had the Nvidia code for DXT1, as provided in one of their SDKs, at the beginning. When the bug with their code became apparent (only shows itself with some alpha masks, not opaque-only textures), he kindly wrote replacement code. While Nvidia's code is faster, Martin's is of course stable :-).Since his DLLs retain the older method as well as the newer (for backwards compatibility), I also retain the option to use the Nvidia method in my tool. I could hide the method, but there may be some that want all opaque textures and might want to use the Nvidia method for that for possible speed reasons. In our case, its fairly unlikely, but the option is there.(As an unrelated side note: I forgot to mention in the other thread that my tool will internally convert any non-8bit alpha slices to 8-bit grayscale before calling Martin's conversion routines. So, if they happen to be in 24-bit format to begin with, nothing need be done by the user.)Take care,http://members.rogers.com/eelvish/elrondlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

Share this post


Link to post
Share on other sites

There have been some questions here on the TB forum about poor mip quality using the non-nVidia method in some instances.This is in fact due to the use of source images that have been 8 bit originally. The 8 bit dithering underlying the data (even if it has been expanded to 24 bit) clashes badly with the compression routines and can get quite messy.My personal recommendation would be to use the nVidia method if no water/alpha is involved and also in cases where the original data came from 8 bit sources. I would be the first to admit that the more complex code provided by nVidia does do better mipping (the main reason I switched to it. If it wasn`t for the "bug" I would have removed all my code)

Share this post


Link to post
Share on other sites

Martin/Elrond, have you read the thread in the scenery design forum in which I have described some mip diplay issues, I wonder if you would comment. I'm displaying some texture slices from a resample.exe based photoreal scenery project. To make an Ideal transition, I've determined the actual texture used by fs2k2 at the transition, and I've layered that texture into the appropriate slices of my project after running resample.exe. The source image is 24bit. I used Elronds resampling routines to pre sample the image to 4.8m/pixel from 4m/pixel and then resampled. Finally I used Elronds fstexconvert to combine alpha and main into dxt1+alpha (fs2k2 medthod).The problem is the timing for mip level of detail display. Sometimes there is a difference between my work and the default, which allows one to see the transistion line when they are out of sync. Once in sync, no transition is visible.I'm wondering if the nvidia code would resolve this, I'll test it soon, but I'd also like your opinions as to how this all works. Thanks,Bob Bernstein

Share this post


Link to post
Share on other sites

It may be that FS performs the mip-switching in "layers". If it does the normal terrain first and then does superimposed textures (such as the photoreal ones) after then the out-of-sync may be inevitable.There is nothing in the mip data itself that affects when it is switched. It's FS that decides when to switch to a different mip level

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this