r746, ME1 Textures Improper Install; Mips? Alpha?

[giftfish]

First, this is a monumental achievement. I just perma-replaced my very first texture for ME1 with 100% success. Yay! Sort of. There's some type of issue with alpha.

I used CDAMJC's Avina body textures. Both the diff and VFX texture. Here's what it should look like; this is with Texmod:

Here is what the exact same two textures look like, installed with Texplorer:

Obviously there's a problem. Her body is almost invisible; her head almost as much.

Since the texture works properly in Texmod, that leads me to think the following:

1. Improper alpha in the texture
2. Bad alpha handling in Texplorer
3. Bad Texturegroup re-assignment
4. Bad texture replacement
5. Incorrect INI setting
6. ?

Here's what the alpha channel for both new textures look like in GIMP:

I understand the black/white concept of alpha, but I don't understand the discrepancy between the alpha layer thumbnail (white/opaque) and the alpha layer on the actual image (black/transparent), as displayed in GIMP. Presumably, CDAMJC knows what he's doing and the alpha is correct, but I don't know this for certain. Upon extracting the vanilla textures, their alpha is identical to each other and to the modded textures.

Here's a side-by-side:

The left one is a DIFF, the right a SPEC. The Texturegroup changes from this to LightandShadowmap

So... any idea what the problem is?

[starkgate]

What does the vanilla alpha look like ? I don't think it is a bug with MEUITM either, but you never know.

[giftfish]

@CreeperLava --

Upon extracting the vanilla textures, their alpha is identical to each other and to the modded textures.

In short, black in the image, white in the alpha thumbnail. Modded and vanilla alpha are identical.

[giftfish]

Thought I'd post something that installed perfectly... just because.

Here's Kasumi looking perfect in ME2 with JeanLuc's texture that I made a couple tweaks to. The diff, norm, spec, and spwr have been edited:

If there is an alpha issue, I'm guessing none of these are affected.

[KFreon]

That's suuper weird.
I'll see what I can find but one there looks greener than the other. Which is which there?

[giftfish]

@KFreon -- Top is vanilla, bottom is modded. I also noticed it was more green, but that shouldn't be affecting the alpha, which is what seems to be the problem.

One thing I should also point out is that CDAMJC has this perma-modded into his EXE version of MEUITM, and I know from our PMs he's made most of it based on the current stable. That suggests we've implemented something that has changed how alpha is handled -- at least in some instances.

Kasumi aside, this indicates we need folks to do additional testing on alpha-sensitive textures. Facial textures would be a good example.

[KFreon]

It'd be good to narrow it down to just that extra green diff.
If you just change the spec, does it behave as expected?

To be clear, I have no idea what could possibly be causing this, but that extra greenness raises my eyebrows.

[giftfish]

Uh, I can do the replace quick just with the spec. Gimme sec.

[giftfish]

@KFreon -- Nope. Slightly different results, but same basic issue:

What's really strange is that it's affecting her head, as well, but her head is a totally different texture set. Just look at the ME1 textures for her head and you'll see what I mean. You can see it in the comparison in the OP, too. I am only replacing the two body textures, but that replacement is changing her head, as well.

So, are you convinced the textures themselves are formatted properly alpha-wise, based on my screenshots?

[KFreon]

Yeah. The textures themselves look fine.
I don't know what the heck is going on there.

It's possible that that spec is used for her head as well?

Also, so the spec only makes a mess, does the diff only make a mess too?

[giftfish]

Yeah, it's like installing it basically makes it disappear. I'm wondering if the texture simply isn't being installed properly, period. I haven't had the chance to test anything else for ME1, yet; I wonder if it's just this one or if there's issues with alpha, period.

[giftfish]

Hrm. K... the VFX texture is a DXT1... what about the 80%/20% thing we were talking about in the other thread?

Let me try to replace just the diff and see what happens...

[KFreon]

That's why I want to know what happens with the diff only.
Cos that did occur to me too.

[giftfish]

Sorry, I missed that originally.

So, diff is a problem, too:

This result is surprising. I am 100% sure I vanilla'd files in between, and replacing the diff also prevents the VFX texture from being shown. It's like she's barely there.

[KFreon]

Yeah...this looks weird alright.
I dunno what to say about it.

[giftfish]

What I want to know is how CDAMJC got it installed into his game, and if anyone else has had the same problem.

One thing I haven't tried is installing it via TPF Tools rather than Texplorer. I'll post the issue today in the Stable Thread on the forums and see if anyone else has had the same problem.

If nobody responds, I'll try PMing CDAMJC on Nexus and see what he has to say.

[giftfish]

Tried with TPF Tools and same basic results. This time I did try installing the new head diff as well, though. Here's what happened:

[giftfish]

There's an issue with the EngineFonts that I'm wondering if it has to do with this. Check out how it looks in r746 and something like... r720, I think:

[starkgate]

Did you rebuild the thumbnails, by any chance ? There is a minor issue with rebuild thumbnails per folder, where the thumbnail would appear white until you reload Texplorer.
Edit : Forget it, there's definitely an issue. Even double-clicking shows up entirely white on my side.

[giftfish]

@CreeperLava -- Yep, and I did rebuild the thumbs, anyway.

[KFreon]

WTF. I swear I checked those cos I noticed they were white in someone elses screenshot.

[KFreon]

HAHAHAHAHAAAAA
Ok, so it's not broken. Its just that there's no RGB; The text is all in the alpha channel...which is white.
So it's white on white. Much amusement.

Bad news is...I dunno how to fix that while still having everything else working.
The reason it worked before is because I used to merge the alpha down instead of stripping it out.
We changed it to remove alpha so that other textures were visible though.

[giftfish]

@KFreon -- Okay, so some new info. I finally got around to testing a different set of textures for ME1. We definitely, definitely have a problem for texture replacement in ME1. A problem that does not occur in ME2 or ME3.

Here's CDAMJC's Elcor texture under Texmod:

And, here it is permamodded via TPF Tools:

Pretty much like Avina's body, but more opaque -- which makes sense -- as Avina is mostly transparent, anyway.

And, here's another piece of the puzzle that's interesting. This was happening to Avina, too, but with her VFX, I wasn't 100% sure it was relevant:

So, maybe this "alpha" issue, is actually a mips issue. If distance affects the problem, that certainly suggests mips.

I should also be clear that these textures have not been autofixed. They are properly formatted, installed without error, and these are the results.

It would also be very, very handy if someone else can replicate these issues on their ME1 install. I'm aware there are various INI settings for ME1 to handle larger textures and some of these are 2K and 4K textures. We also need to be sure that isn't the problem. I wouldn't think so, as I'd think the toolset should be modifying the INI that if something like that is required for proper installation, but... who knows.

@KFreon, @SirCxyrtyx , would looking at the modded files with ME1's Package Editor point us in some direction? There's a UPK and 3 SFMs for the Elcor. For Avina, there's 2 UPKs. I can zip them up and toss up a link.

EDIT: I double-checked my INI and here's what I have set up for the modded LOD group:

TEXTUREGROUP_LightAndShadowMap=(MinLODSize=256,MaxLODSize=4096,LODBias=0)

Not sure if any other INI setting that I might have changed would affect the rendering in game. This seems to be the logical one

[KFreon]

Hrm....
Lets summarise:

• Avina is more transparent than normal, but that fixes itself with distance.
• Elcor is black up close, but normal at a distance.
• All textures fully formatted. No autofix.

Interesting...that gives us a place to start anyway.

What happens if you remove that ini line? Or change the MaxLODSize to 2048?

[giftfish]

@KFreon -- I definitely wouldn't suggest removing the INI line. My INI is lightly-modded, and that line is vanilla; if BW put it there, it should stay there. The INI was my first thought, but I've verified that line against a vanilla INI; it's not the problem.

If we really want me to make sure it isn't modded INI's, then I should back them up and just let the game create new ones upon re-launch. However, the thing is, is that my INIs, if anything, should improve the situation. I modded them long ago for MEUITM, to make sure they would maximize texture quality with higher rez textures. The exact sort that I've installed for Avina and the Elcor.

Avina. It's not just that she's transparent, but you can tell on her body that the texture is basically not there, or barely there. She is a solid blue shadow. My guess is that if she were more "solid" (less transparent) like the Elcor, she'd probably look solid black like him.

[KFreon]

I'm fairly sure there's code that adds that line to the ini, and I make the point because there was an issue ages ago related to the lod settings in the ini.

I'll look into it, but more relations between the textures would be good, like size, format, etc

[giftfish]

@KFreon -- FYI, Just changed the Issue title to more accurately describe the problem.

I haven't rolled INI's back to vanilla yet -- I'll do that momentarily, but K, I know for certain that line is not added by the toolset. Despite not rolling back yet, I know that b/c the various sites I use to tweak the INI, always quote the vanilla INI settings and then comment on how to change them, such as:

http://forum.bioware.com/topic/215916-making-the-most-of-your-me1-pc-experience-maximizing-graphics-and-sound/

and

http://www.tweakguides.com/ME_8.html

Both mention the exact same line and quote the same vanilla setting I pasted above. But, I'll be sure to double-check it when I allow the game to re-generate the vanilla INIs. I'll also zip those up so you can take a look -- assuming you don't have them. Do you have ME1 installed?

Btw, do you want me to maybe PM CDAMJC on Nexus and see if he might have some ideas? Or not quite yet?

[giftfish]

@KFreon -- Here's a thought... and I will really laugh if this is all (sort of) my fault.

Is the toolset supposed to modify an INI? If so which one(s) and which setting(s)? I just remembered that I keep mine set to "Read Only" to dodge the ME1 bug where it just randomly decides to regenerate and replace your INIs, undoing all previous edits. After having this happen to me more times than I'd like to count (and me not always keeping a backup of my current version) I finally set them to read-only so the game couldn't screw me anymore. But, if the toolset is supposed to modify a setting, that means that it probably can't do it.

If this is the problem (I sort of hope it is, b/c then the issue is solved), I'll need to talk about it on the wiki. I'm almost certain I got the read-only idea somewhere on the BW forums, so there's a very good chance that other folks modding ME1 have done the same thing and will experience the same problem.

[giftfish]

@KFreon -- Finally got some confirmation that this isn't just me. Deager gets the same results.

Currently waiting to hear whether his INIs are modded at all, and what the situation is there. I'll edit this with an update when I find out.

[HuntersRun1]

Heh Deager beat me to it. New user and I was browsing the me3explorer website when I saw you wanted confirmation on this issue. so as I was already in the middle of a mass effect playthrough did some testing and got the same results. I am unable to register there(cannot see code) so I am posting this here.

Some notes from testing (unsure what might be useful): Win 10-64 bit. I got the same issue as others whether tpftools or texplorer. I was using meutim but I reinstalled my backups. After testing I reinstalled meutim and I noticed that the textures were still vanilla. I deleted the shader cache using the configuration.exe and the meutim textures reappeared. I did not delete the cache during testing so I am unsure if that makes a difference or not. Also my ini's were set to uncheck read only.

[giftfish]

@HuntersRun1 -- Thanks for all that info, actually... the shader cache is another good thought. I'm running the shader cache fix, and I'd be surprised if Deager wasn't. I wonder if that could be involved.

Have you tried backing up your modded shader cache files (assuming these are the ones CDAMJC provides) and trying vanilla ones?

[giftfish]

FYI, I've verified that reverting shaders to vanilla doesn't help, nor does deleting the shader cache.

This indeed seems like a toolset issue. We now have replication in triplicate and I'm out of ideas on what else it could be.

[giftfish]

@KFreon -- Any thoughts on this, btw, now that we're certain it's a toolset issue?

Also, like I said previously, I know from speaking directly with CDAMJC that he has used mostly the current stable to build the EXE version of MEUITM. This version installs all ME1 files, with the textures already permamodded in. So, whatever problem we have now, it does not exist in the current stable.

Not like there aren't a bajillion changes between r653 and r747, but between that and the issue with mips/alpha that we're seeing, maybe that gives you some ideas?

I'll try re-building my ME1 tree again today, just to double-check on debug output. Be sure nothing looks wonky.

[KFreon]

I haven't had a chance to look into this, but there was a similar issue ages ago with null mips on top. Salt implemented a top null removal feature, a button I removed not long ago due to it being inconsistent, and that I thought the problem had gone away.

That's where I plan on starting, then I'll compare the "stable" with the latest rev and see if anything in the texture or PCC handling has changed.

[giftfish]

@KFreon -- Does that problem only affect ME1, though? That should really be the largest clue -- something that affects ME1 and not ME2/3. Texture handling for ME2/3 basically seems to be perfect, short the few issues Creeper has been tracking with alpha, autofixing, conversions, and stuff.

[KFreon]

Yeah back in the day it was me1 specific.

[KFreon]

I don't suppose you have a save I can use? I don't want to have to get all the way to the citadel to test this one.

[giftfish]

Of course I do :)

Sending to you on Skype.

[KFreon]

After an entire day of testing, SUCCESS!!
It was all down to how Texplorer does installation to multiple PCC's.

What I was doing:

• Load pcc
• Load texture2D
• Modify texture2D
• Save pcc
• Copy changes of texture2D to all remaining pcc's

What I should have been doing:

• Load pcc
• Load texture2D
• Modify texture2D
• Save pcc
• REFRESH PCC and TEXTURE2D so changes are propagated through the remaining pccs.
• Copy changes of texture2D to all remaining pcc's

Apparently the former wasn't good enough for ME1. At this stage, I'm too lazy to find out exactly what this changes, by which I mean why does the object have to be regenerated? It's changed enough for the first pcc, why not the rest?
Curious, but no time or patience for that level of debugging.

EDIT: This may explode some things come to think of it as I also allowed external textures to be directly modified...I may need to revert that. I'll put a rev up here for some intermediate testing to see.
Check it

[giftfish]

Looking forward to testing this.

One question, though. Does TPF Tools use the same method of replacement? Presumably so? Just pointing out at the problem was discovered with Texplorer, but isn't isolated to it.

Will test today, and see if I can wrangle up some others to test :D

[KFreon]

I didn't test Texplorer actually, just TPFTools, but they use the same methods.

[HuntersRun1]

So I ran a quick test. Note the texplorer gui has scaling issues so I couldn't change the game. I had to import the me1 tree from a previous rev. I ran the avina and elcor textures through tpftools and it seemed to have worked. I didn't notice any adverse effects, but I was only in the game for a minute.

[giftfish]

Yep, it's definitely working :D

[giftfish]

@KFreon -- Hmmm are you certain this change was pushed into the rev?

I just installed CDAMJC's Avina's body DIFF via Texplorer, and she's disappearing again. This was indeed fixed in the most recent text rev you posted on the forums, but I'm pretty certain I tested it via TPF Tools, in case that matters.

---

EDIT: On a whim, re-tested this via TPF Tools and the TPF. Installation via that method worked perfectly. So, it seems that Texplorer and TPF Tools use different install methods? That seems... problematic >.>

[alvarome]

Hi:

I have just ran some ME game textures install test. FWIW, all went ok here.

I installed all three CDAMJC´s Avina textures separately -cheking in game after every single install- and all seemed to work here.

I also installed the Avina.tpf file and it worked too.

And I also installed all Elcor .dds files and no LOD problems so far.

I deleted shaders cache previously -and after- every install just in case that would have any side effect.

HTH!
Alvaro

EDIT --> I used TPF/DDS tools for those test!

[giftfish]

@alvarome -- Yep, it's definitely just Texplorer that's the problem. Thanks for the verification :)

[KFreon]

Fixed. Same issue as before, since again for some reason there's multiple installation methods, even though they do basically the same thing.
I'm hankering for a rewrite again.

[giftfish]

I'm also hankering.

K, can you put up a test version of this, so I can test prior to the next rev?

[KFreon]

Will do.
EDIT: Test build.
ME3Explorer_Stable Prep.zip

[giftfish]

@KFreon -- Does this have all the changes for all the issues you just closed? That way, Creeper and I could give everything a preliminary test. Assuming everything's fixed, then the official rev could be the the final testbuild for the stable.

[KFreon]

Yes it does. Test away :)

[starkgate]

On my side of the world I'm already gone from home, so I won't be able to test for a week or 2.

[giftfish]

And, fixed in the prebuild for r749 :)