Export UV template about nifskope HOT 20 CLOSED

@neomonkeus And export from which block produces empty map? I have successfully exported a map from NiTriStrips, NiTriStripsData, NiTriShape, NiTriShapeData blocks.

from nifskope.

Sorry should have mentioned this is on the 1.1.4 dev version, don't know which you are running.
Not sure which blocks are currently affected as it was reported to me, so will follow up with a list.

from nifskope.

OK, like the issue Hana reported (though I don't know what REV she was using) this has crept in at some point. I have a build with REV 9234b95 that works fine. My latest builds do not.

Thing is, like I mentioned there, this could have been a consequence of porting to Qt 5 and nothing else. I need to track at which REV it first stopped working.

from nifskope.

I have a theory and it's not directly related to the Qt 5 port specifically. It's related to the FSEngine changes required and the fact that I didn't adapt the UV editor to grab the texture from memory for this Export command. Was unrelated.

I went back to 5b45d84 and it doesn't work.

from nifskope.

@neomonkeus I have no dev version, I am using 1.1.3 rev "36ebfdd" - latest official as I know.
@jonwd7 I am looking at version check you are using for setting a scale for havok. I think that test for Skyrim by checking only UserVersion against >=12 is not sufficient. There are nif files with User version 131072 or 196608 or nifs with User Version 12 but Version 20.3.0.9. I recommend to add also a check of Version == 20.2.0.7 to be sure (or nearly sure) that it is Skyrim nif.

from nifskope.

@ttl269 I was just using the version check used for every other Skyrim thing I saw in the code. As far as I could tell. I knew it definitely wasn't that stringent. But I need to create a ticket for version checking if I haven't already. Basically I'd like to simplify the version checking and add some more overloads to make the code more readable. But that's getting off topic.

I actually still had 4.8.3 installed. I just had removed the kit from the project... :) I was thinking of 4.8.5 maybe.

I will look into where the commit occurred but I assume it's not because of Qt5 alone.

from nifskope.

@jonwd7

1. I think that in time of writting the code of nifskope there were not probably known other variations of nif versions from other games or author forget them. So, when you will make version checking for Skyrim in new code, don't forget to test not only if UserVersion is greater or equal 12 (but Skyrim is done now, no next development of it from Bethesda, so I think that here can be used condition UserVersion == 12), but also test the Version to be equal 20.2.0.7.
2. If version checking is often used in code, it would be much better to fill game related booleans (for example boolean IsSkyrim, IsFallout3, IsOblivion etc.) after nif is loaded and use only these booleans anywhere in the code.

from nifskope.

Some observations. I figured out why it is that color at least. pntr.setPen( QColor( 0x10, 0x20, 0x30 ) ); but that doesn't explain why it's not filling in the data afterwards. I noticed that it takes significantly longer to churn out a TGA file (than 1.1.3). When I select '2048' for example, in a debug build it hangs for quite some time. I also think it has nothing to do with FSEngine like I previously thought.

from nifskope.

Just rewrote it since I couldn't figure out what the deal was.

Example: sprigganmatron.nif

from nifskope.

Is there any reason it's TGA-only? Qt doesn't have native TGA writes and I'd rather just use the built-in image saving functions, which would allow for PNG, TIFF, BMP (and JPG but I wouldn't allow that as an option).

The TGA code is repeated pretty much anywhere saving a TGA is an option. I could reintroduce TGA support with a library that is better integrated with Qt but for now I would rather just add support for more common formats and remove TGA.

from nifskope.

You can either do it as part of this issue or open a separate improvement.issue

from nifskope.

Well, while I was poking around I added some things. Wire color, including alpha. When saving as PNG the background is transparent. For BMP it defaults back to a white fill.

I added a checkbox for antialiasing too. It wasn't antialiased before.

For example:

Cyan, antialiased, transparent PNG

Same, with wireframe color at 25% opacity

You can see where stuff is overlapping more easily that way. If saving the PNG at 100% wireframe opacity and then lowering the opacity to 25% in Photoshop for example, you lose that information (everything is still equally opaque).

Using it as an overlay with the fully opaque wire color (1024):

The dialog looks like this currently:

The text in the cyan area is not edited, clicking it opens up a color picker. The text is there just because. The format is #AARRGGBB. This is what the Qt color dialog looks like when you click on the button:

You can see the alpha is 64 (40 in hex). The only annoying thing about the Qt color picker is there is no slider for the alpha. Manually entering it is the only fast way. It won't matter much. The default will be 255 (fully opaque) and hardly anyone will use it.

from nifskope.

very nice, one thought though. I know a lot of the UV maps from Bethesda overlap heavily, would it be possible to export each UV island as a separate layer?

from nifskope.

I've considered it but I don't know if the NIF stores the UV islands logically. So I would have to try to detect contiguous triangles. Only issue is that UVs can exist in exactly the same place, so which do I choose to go with which island. I would hope that contiguous triangles (islands) are also contiguous in their data storage. Regardless if they are stored sequentially, I'd still have to detect the separation between islands.

I simply draw triangles to an image given the points. The UV Edit widget however has some awareness of contiguity. If you select one vertex and Right Click > Select Connected it will give you your island.

What this means is that probably the UV Template will be integrated into the UV Edit widget and rely on its algorithms. I could then pick one point, find all connected points, remove all those from the remaining points, repeat until I have enumerated all the islands and there are no more points left. I then have a group of triangles that represent an island and can write this into its own image/layer.

Unfortunately I bet there are several models which have 1000+ UV islands. A file for each would be unwieldy. Qt doesn't have any native support for layered formats, so I'd have to create it.

from nifskope.

That seems a rather heavy a load for a limited use feature. maybe keep it in mind for when you are bored with nothing to do

from nifskope.

Very good to have possibility of saving as transparent PNG. Would it be possible to set a format of Wire color to #RRGGBBAA, i.e. to have alpha component at end of text? It would be more logical as this format is usual and also used in nifskope when editing Vertex colors, for example.

from nifskope.

@ttl269 No. #AARRGGBB is standard and it's the only hex representation for ARBG/RBGA that is recognized by Qt. That is, when feeding a QColor constructor with a string that begins with #, for it to recognize alpha at all it has to be in that format.

Like I said, the text is meaningless in that button. It's not directly editable and I may just hide it by making it the same color as the background. It's just there to feed the current color back to the color picker when you click the button.

from nifskope.

@jonwd7 Ok, I understand that ARGB is due to QColor constructor. Then it would be better to hide its text representation and leave there only solid color to not confuse nifskope users - Vertex colors are viewed and edited as RGBA. I think that saving UV templates as PNG with transparent background is great advantage even without user notice a possibility of setting a transparency of UV template itself. Maybe it would be better to rename "Wire color" to "Wire Color and Transparency" in dialog window, so user will know, that also transparency can be set via "Select Color" window.

from nifskope.

That's too long a title. I'd rather remove the Alpha from the color picker itself (it's actually the default to not have an Alpha slider) and then have a secondary field with a Wire Opacity %.

from nifskope.

@jonwd7 Having standalone field with Wire Opacity will be best solution. So, clicking on it brings some simple slider for setting it?

from nifskope.