Welcome
Ladies and Gents:

These forums are now closed and registration disabled.

Please join us at our new forum on Proboards. Our hope is that these new forums are more stable, provide more and better features, and allow continuation of the project forums in a safer, more secure, long term environment.

me3explorer.proboards.com

--The ME3Explorer Team

KFreon's WPF Rewrite

Development board for ME3Explorer tools. Please try to keep discussions for each tool inside its own thread.

Re: KFreon's WPF Rewrite

Postby Alvaro » 06 Oct 2016, 10:25

Hi KF!

Thank you for your detailed reply. Very informative and highly appreciated!

I´m in a hurry rigth now so I´ll leave a few comments latter today.

Anyway, and knowing we will be soon enjoying those travelling Mass Relays, here you got a last minute design suggestion for Texplorer! :lol:

Image

HTH!
Alvaro
User avatar
Alvaro
User
 
Posts: 83
Joined: 15 Mar 2015, 13:06
Has thanked: 8 time
Have thanks: 12 time

Re: KFreon's WPF Rewrite

Postby KFreon » 06 Oct 2016, 11:06

Interesting suggestion.
I don't know if I can live with it over there since it's kinda disconnected from the bits it's supposed to be connected to, but I'll think about it.
User avatar
KFreon
Toolset Developer
 
Posts: 1665
Joined: 16 Apr 2013, 00:57
Has thanked: 83 time
Have thanks: 520 time

Re: KFreon's WPF Rewrite

Postby Alvaro » 06 Oct 2016, 13:40

Hi Kf:

It´s so good to see all those changes and improvements you are sharing here in both Texplorer and TPF/DDS Tools. I knew in advance most –if not all- of my sugestions would become useless, worthless –or both!- for the rewrite because you already had them all well covered.

I.e. you are rigth and that searchbox at TPF/DDS Tools will do the trick instead any other shorting options. Or those coloured selectors indicating any issue with a texture (red for NFIT) will be superfine as well. I pretty much agree with you that to reduce to minimal user work is fantastic and I also find to receive info about what´s going on is much welcomed–a text / flag /selector or whatever showing textures that had been fixed for installing, tree duplicates et all. And the cherry of the cake is that texture bulk extraction from Texplorer! Wow! :)

Regarding drag & drop, yep, that´s exactly what I try here with no success. I recall when this was first available at one othe the older toolset revs and at least it worked for a short time back then. But never again. Anytime I try to drag&drop a texture –or a few- from Windows Explorer into TPF/DDS Tools pane, I can´t. My mouse pointer turns into that tiny “forbiden” icon so no way to release them. Do not ask me why.

About the thumbnails generation, I get the point about your “perceived performance” approach. Very interesting!

BTW, I do not perceive ;) any bottleneck at Image Editor but if you say you are going to improve its performance… Wow, it´s going to be instant then!

May I add an Image Editor suggestion here? Now, no matter how much instances of Image Editor you have running at once, they all share the path to the folder last used. This is quite useful if you have two Image Editor instances open to check files from the same folder. But if you have two instaces of Image Editor running to check files from different folders, you have to navigate once and once to pick up your files from every folder. Most probably there would be no need to implement this if drag and drops worked fine in future revissions but it is somethnig quite annoying actualy.

About the info stored in Tree.

What I see is that texture info is disseminated in some way. There is some info stored at the game tree (hash, name, format and Texture Package- but there is a few info available at Texplorer solely like size and LODGroup.

Thanks to the “export to csv” tool, we could ID and short groups of textures easily. i.e. all HMM_HED_ ones. From the .csv we had their hash and name in a second. But what if we wanted to know its vanilla size? We have to use a unmodded game and go checking into Texplorer. And even when Texplorer has a search box that will narrow the search to those textures, we´ll have to click and check them all one by one and take note of that given info.

If we could recover all that info from the Tree that time consuming task would be a piece of cake.

I know this is a very unusual request or, at least, something most users won´t worry about it at all but, well… why not? ;)

=================================================================
EDIT --> Just to add some (un)useful data here, I have a nice list of 3K ME2 and ME3 vanilla textures each that I would like to add the vanilla texture size info... but with current tools that´s simply impossible for me. I´m just triying to discover which ME2 game textures were in use but downsized in ME3 game by BW guys, most probably due the console storage limitations or the like. Just a nice dream for now...
=================================================================

Once more, thank you!!! I´m for one that I can´t wait to see those new applications released soon!
User avatar
Alvaro
User
 
Posts: 83
Joined: 15 Mar 2015, 13:06
Has thanked: 8 time
Have thanks: 12 time

Re: KFreon's WPF Rewrite

Postby KFreon » 06 Oct 2016, 23:15

Thanks for the suggestions :D
I'll see what I can do for the open dialog/recent folder thing in ImageEngine. It's normally handled by the OS, but I might be able to save the path for later.

Vanilla sizing and stuff can be put into the tree and subsequently exported using the CSV export feature. I'll add that at some point.
User avatar
KFreon
Toolset Developer
 
Posts: 1665
Joined: 16 Apr 2013, 00:57
Has thanked: 83 time
Have thanks: 520 time

Re: KFreon's WPF Rewrite

Postby Tarshana » 08 Oct 2016, 06:01

Just out of curiosity how do I put my info back into the TPF's? Before I would do a copy/paste info when TexMod popped up and was being auto-filled.
Tarshana
User
 
Posts: 58
Joined: 21 Aug 2016, 18:14
Has thanked: 3 time
Have thanks: 4 time

Re: KFreon's WPF Rewrite

Postby Alvaro » 08 Oct 2016, 21:55

Hi:

Thanks KF, once more, much appreciated.

I can see that to change the tree might involve new code to other aplications that read it so I also understand that may not happen soon. In fact, and knowing you are going to provide us some bulk texture extraction via Texplorer, I´m already trying to find a workarround using that to recover texture size from a bunch of extracted textures... via the file size or the like. Neither acurate nor instant but far easier than my current choices -none!-. ;)

On the other hand, the more the merrier! To have more info in the tree may lead to other uses at some point. Who knows.

I also wanted to share a tiny detail about TPF/DDS Tools installation. And tiny is

Here we got current installation indicators in TPF/DDS Tools:

Image

In previous, during installation process, we have the progress bar and a message informing about current texture. At this point we have no record about any texture left behind but on the debug log.

As soon as the installation task is finished we have this. The progress bar informs about task completition while messsage text reports about its success.

Image

But its position at the lower left part of the screen and its size might produce that users not familiar with the toolset and/or those that wrongly rely on the progress bar solely may miss some critical info.

Because if any texture is left behind, then we´ll have this:

Image

If a user miss that tiny "116", will not know that an error ocurred. And if that user exits the Toolset, the debug log is lost and with it the easiest way to know what happened here.

So I think that for those cases -textures left behind- it would be nice to have something so simple like this...

Image

Or, even better, like this... where there is a noticeable vissual change plus a clear indication regarding next step to follow.

Image

Another additional action could be to save the debug log automaticaly to a specific folder when an error ocurred. i.e.

HTH!
Alvaro
User avatar
Alvaro
User
 
Posts: 83
Joined: 15 Mar 2015, 13:06
Has thanked: 8 time
Have thanks: 12 time

Re: KFreon's WPF Rewrite

Postby Alvaro » 08 Oct 2016, 22:41

Hi again!

There is any chance we could have bulk operations using Image Editor?

Fact is that there are thousands of textures available to mod ME games but if you have apply the same format conversion (or other operations like delete or regenerate MIPs i.e.) to a bunch of textures we can´t but just one by one. And I hate to say that may be frustrating sometimes.

Of course we can always try our best to find a workaround using third party tools but Image Editor is soo good that would make sense to have that covered too, IMHO. Select the input folder containing the textures, select the operation required and that´s all.

Any chance, please? :)
HTH!
Alvaro
User avatar
Alvaro
User
 
Posts: 83
Joined: 15 Mar 2015, 13:06
Has thanked: 8 time
Have thanks: 12 time

Re: KFreon's WPF Rewrite

Postby CreeperLava » 09 Oct 2016, 07:46

In case you need to bulk regenerate MIPs, I made a script that will allow you to do this :). It's for Linux though.
User avatar
CreeperLava
User
 
Posts: 844
Joined: 07 Feb 2015, 21:52
Has thanked: 119 time
Have thanks: 83 time

Re: KFreon's WPF Rewrite

Postby KFreon » 09 Oct 2016, 08:30

@tashana: In the wpf rewrite, there'll be a section to add author and comment.

@alvaro: As for progress, I will take a look. Not at home now, but I had an idea that there would be an error section so when it finished there's a window to show the errors.

Re image editor, that can be arranged. Curious as to why with me3 though, since tpftools will Auto convert before installing.
User avatar
KFreon
Toolset Developer
 
Posts: 1665
Joined: 16 Apr 2013, 00:57
Has thanked: 83 time
Have thanks: 520 time

Re: KFreon's WPF Rewrite

Postby KFreon » 30 Oct 2016, 17:13

Giftfish -- Copying this from a different thread

I'm pretty sure I know why thumb gen is so slow, especially in regards to it being slower than an entire tree gen.
Short explanation: Tree gen grabs a PCC and reads all textures in it. Good for disk as it only has to read one thing.
Thumb gen is per texture atm, so it grabs a texture, reads the pcc, and regenerates the thumb. Rinse and repeat.
That means a single pcc might be read thousands of times instead of just once.
Saving suffers a similar design flaw. T'will be fixed.

Regarding "aesthetics", let me clarify.
I'm worried about losing the connection between the thumbs and the textures if they textures are rescanned underneath.
Like what if the textures are modified now (new dlc added, thanemod or something installed), the hashes won't be completely the same OR new textures are present.
The new ones won't have thumbnails AND/OR there might be other thumbs just sitting around not being used. Easy to bloat out of control.

Now, while I was saying all that, a few ideas occurred to me, BUT:
I'm not convinced that it's worth the effort. I will do some tests (scan without thumb gen) and see what happens.

I'm not even remotely considering removing thumbnails or their functionality. I like them too. Tried the old stable without them and couldn't find anything.
I'll do some testing and see what happens, but unfortunately I'm a bit burnt out again so dunno when I'll get to it.
User avatar
KFreon
Toolset Developer
 
Posts: 1665
Joined: 16 Apr 2013, 00:57
Has thanked: 83 time
Have thanks: 520 time

PreviousNext

Return to ME3Explorer Toolset Development

Who is online

Users browsing this forum: No registered users and 1 guest

suspicion-preferred