Watch_Dogs Relief Mapping Mod by The Silver

You can test this to begin

http://www.mediafire.com/download/jjmsjhwk44riv2i/mask.7z
http://www.mediafire.com/download/dv3ka85i3396rqq/_metal.7z

 

Well you don't necessarily have to send me the tga, but a file format that I can actually open would be cool, my dds viewer and my image editing software can't open these dds...

 

Yes they are DX 12.1 BC7. I didn't find yet a soft that open them. So I am uploading the TGAs. 15 more minutes.

 

Here are the tga files in case of :

http://www.mediafire.com/download/n1zg598avoi3g94/metalTGA.7z

 

Why you have files that aren't even present in the vanilla game? Like "07_bloom_doublemetaldoor_s_high". There's no purpose to have a _s texture if the game doesn't use it (the specular is given by the _m texture most of the times, that's why the _s files is often "missing").
But moreover, why you still have blue/purple normal maps? If the texture originally have the orange normal map in the vanilla game you MUST keep it orange, unless it's a relief-mapped surface (so only if your file conflicts with one in my pack then it should be kept in my format, blue/purple). So the only surfaces that can safely have the blue/purple normals are the ones that already have blue/purple normals in the vanilla game and the relief-mapped ones, everything else must have the orange normal maps or lighting bugs are guaranteed.

PS: It doesn't matter if textures sizes doesn't match, the _d can be half the _n and the _m can be 1x1 pixels, it doesn't matter since the game will just stretch whatever it finds.

 

When I unpacked Windy_city.dat, I saw a few "_s_" files.
Otherwise I don't think the blue/purple is the problem here, as everything else is ok. And because the other part of the light is in the alpha channel as these textures are RGBA, where a heightmap is added.

I have ONLY ONE issue : a metal texture is reflective whereas it shouldn't !

Maybe I put an extra file and the game engine process it (even if it shouldn't)

 

No it doesn't.
Dude, I've checked the files that you sent me so I know what I'm talking about, there are unneeded files (not present even in vanilla so surely unnecessary) and a lot of normals that shouldn't be in the blue/purple format (this gives lighting bugs FOR SURE, it doesn't matter if you say that you don't see them).
The "reflective" metal texture is surely caused by the wrong normal map format, deal with that.

Now you can do one of these things:
- Be satisfied with your result and that's it, there's no problem for me but be aware that your texture pack is a mess as it is now, unnecessary files that increases its size for no reason and textures in the wrong format leading to lighting bugs, that's a FACT.
- Read papers about normal maps, learn why they have these colors etc, then realize that I've always been right and that everything would be already fixed if you just followed my advices from the start.
- Follow my advices, fix your texture pack, and stop spamming my thread with your stubborn posts about your broken work.

I'm sorry if I sound rude but I'm almost out of patience. I'm happy to give advices, to help people and even to teach them sometimes, but not when they spam about problems that are caused by them not following the advices that I'm already giving them.

 

I am sorry for having made you angry.

I just did a test and I though It was ok that's all. And I would like to share this with you, that's all. I like the result, except on this precise metal texture. But as I said before I could be wrong. But I was wondering why I found it ok everywhere but only 1 texture ?

It's a fact, I generated unuseful textures, because it's easier than choosing one by one the textures to create. But I didn't use these extra textures ! I use a batch script to only replace existing files, in the right place. So there isn't extra textures in patch.dat. I sent you them by accident because I took the files from a working folder (not cleaned).

So yes I tried things because I wanted to avoid the orange format, as I don't have Photoshop. I thought I achieved something interesting that could make things easier. I just wanted to share. Nothing else. As for now I am not interested in publishing a pack.

It's probably an impression, but I had the impression it was less detailed with your normals. That's another reason I tried this, to have more control

 

My normals are just the vanilla ones converted to the purple/blue format, nothing more.

Anyway, you can easily convert your purple/blue normal maps to the proper orange format (and the opposite) just by swapping channels, here's a quick visual explanation:

 

Thank you for the explanation. I saw that earlier in a video. Yes it's simple.

So which format to use for what purpose ? When purple, when Orange ? As I see in your picture, to use Relief Mapping it seems you need the purple with a height map...
If it's the case, it's what I've done. But it's apparently false.

If I understand, you have to switch channels and put blue to 0 and red to 255 to convert to Orange format ?

I searched a lot and I found the "orange" format only for StarCraft 2... I am rather stubborn when I want to achieve my goal the way I think it's the best ^^. Developer disease.

As a developer it would have been so simpler to use the same texture processing, embedded with DirectX SDK, for simple normals or POM...

 

Yes according to my "guide" to conver a purple/blue normal to orange format first of all you have to move the red channel to the alpha/transparency channel, then set red to full white and blue to full black.
The lighting problem caused by erroneously using a blue/purple normal map instead of the orange normal map is due to the fact that in the orange normal map the lighting info for the object is full white when lit from the right, so you get the "super shiny" lighting from some angles like in your screens.

I'm just as stubborn as you, if not more, and it's pretty much indispensable if you're a modder nowdays with these modding-unfriendly games like WD... :O

PS: They've used the orange format because every DDS format compresses red and blue a lot more than green and alpha, so the "orange" format grants the best quality overall because the channels with the info have a lot less compression artifacts (this "format" is a viable choice only if the alpha channel isn't needed for something else obviously).

PPS: The confusion of having both formats (blue/purple and orange) being simultaneously used by WD engine is understandable anyway, it took me a full couple of days to realise that when Relief Mapping is enabled the engine automatically switches the expected normal map format from orange to blue/purple (with hindsight it was obvious since it needed the alpha for the heightmap, but I was ignorant so...)

 

It was a reason for my stubborness : according to what you said, it would mean that everything is decided. You can't really choose where you can use relief mapping.
You can only put it where devs use a purple normal.

It's quite frustrating.

P.S : WD's devs made a wrong choice in my opinion. With the latest compression algorithms I currently use, the compression is very good.

 

You can't say unless you convert back one of your DDS and examine it, looking at the "composed" normal map it's almost impossible to see, but split its channels and you will clearly recognize the "blocky" compression artifacts on the red channel.

Anyway, nope it's not already "decided", I have actually enabled the Relief Mapping for these surfaces by editing the materials, so their expected normal map format automatically changed from the vanilla orange to blue/purple (the engine simply realized that RM was being enabled, and clearly it was coded to automatically change its expected normal map format accordingly).

 

I believe you but, just for a little instruction : http://www.reedbeta.com/blog/2012/02/12/understanding-bcn-texture-compression-formats/

Of course yes I should verify ^^

Otherwise, you say you altered the materials so that the engine dynamically convert the normals of these materials to use Relief Mapping ? Nice ! Did you do that for rocks too ?

So, If I already have a HeightMap in my purple normal, I have to put it on top of what there already is in the "orange" alpha channel ?

You could nearly say you designed WD ^^

 

Oh god... Let's make it even easier, I hope:

Is this material using Relief Mapping? No -> Must keep the orange normal map format.

Is this material using Relief Mapping? Yes -> Its normal map must be converted to the blue/purple format so the heightmap needed for the RM is stored in the alpha channel (instead of the "lit from right").

So basically keep the ORANGE normal map format for EVERY normal map that doesn't conflict with the files of my Relief Mapping mod. If it's one of the files of my RM mod then it MUST be in the blue/purple format, and in the now empty/unused alpha channel you must keep the heightmap from my files.

I'm sorry but I really think that I can't be more clear, I've already explained this in every way I know so I hope you got it now, because it's the last time I explain the same thing...


PS: I would love to be able to convert back your special dds and check, I'm sincerely curious.

PPS: No I haven't enabled RM for rocks because looked like ****.

PPPS: The heightmap is something specifically needed for the RM, so if the texture is not involved in any relief mapped surface then it's not needed obviously...

 

I am probably not clear. I am french, so my English is not perfect.

In short, I can't create other RM than the one you give us. Just modify them a little bit. It's sad. My question from the start was : "I want to create new places or objets with RM. How to do this ?"

If I want to put RM on a trashcan for example. In metals, you only provided the garagedoor.

So the reply is : "You can't do more than I did".

Here you can process my dds files :

https://developer.nvidia.com/sites/...s/NVIDIA_Texture_Tools_x64_2.08.0601.1625.exe

or this (for Photoshop)

https://developer.nvidia.com/sites/...iles/Photoshop_Plugins_x64_8.55.0109.1800.exe

Personnally, I use this package (but had to compile it)

https://github.com/Microsoft/DirectXTex

 

Yeah that's pretty much right, you got it. If it was so easy as just editing textures it would have already been done. Instead it involves some deep material editing and finetuning and debugging to be enable it and have it properly working, and this must be done on a per-surface basis (same texture can be used for more surfaces, and believe me it's a hell to work with), that's also why my RM mod includes a truckload of .bin files.

Anyway, how can I convert your dds to a readable format using the NVIDIA_Texture_Tools_x64_2.08.0601.1625.exe? Because from my tries it doesn't seem to be able to process your dds files...
Second question: The package that you had to compile and that you're currently using allows you to convert back your bc7 dds to a readable format like tga for example?

 

Yeah seems to be a hell. That's the workaround I tried all this time ^^. I was not satisfied with the reply "Do with what there is, do with vanilla". That why I was so stubborn.

For the textures, sorry I thought It would work with nvdecompress from the Nvidia Texture Tools (I use it to decompress vanilla dds to tga), but in fact no...

Use textconv.exe to encode and decode. I tested it works.
To decode, just type : "texconv.exe -ft BMP yourdds.dds" and you'll get a viewable BMP. You can get a TGA if BMP is not enough.

Here is my compiled texconv from DirectXTex : http://www.mediafire.com/download/acuqt2optu7gcst/texconv.7z

You need too https://www.microsoft.com/en-us/download/details.aspx?id=20914 (XNA Redists), the Windows SDK (https://dev.windows.com/en-us/downloads/windows-10-sdk), and the Visual C++ redists (https://www.microsoft.com/fr-fr/download/details.aspx?id=48145)

Inside the Windows SDK there is the DirectX SDK. Texconv roughtly made calls to DirectX SDK features.

Anyway, was this kind of RM used ? I didn't see any rock textures in your package.

 

What you see in the screenshot is just the usual "flat" normal mapping, I haven't touched rocks, no RM and no textures for them by me.


Anyway, thank you very much for the tool and the info, I've managed to convert from and to the BC7 format, and here are my results: DDS_Examples.7z

As expected every DDS compression creates blocky artifacts, it's just a matter of where they are, some algorithms compresses a channel more than the others to maintain quality on the important areas, others compresses all the channels at more or less the same ratio, and this seems to be the case with BC7.
You can see artifacts in the red and green channels, less than the usual DXT5 but they are there (check especially the borders of the bricks), however in the BC7 the alpha channel is compressed too and shows a lot of artifacts while in the usual DXT5 it's basically uncompressed and looks almost exactly like the source.
I've skipped the blue channel comparison because it was full white anyway.

So yeah the BC7 is one more option at our disposal, but it's actually just another tradeoff, no magic involved.


PS: Maybe BC7 is better for diffuse textures because in a "composed" final image the human eye can't see the blocky artifacts anymore, but this is true also for the usual DXT5 then...

 

Yes, when looking more thoroughly, it's a simple normal. Shame on me !

Thank you for the example ! Your observations are good here.

But it's a lot more complex. What's makes the complexity of BC7 is the compression modes, that allow to choose the tradeoff.

https://msdn.microsoft.com/en-us/library/windows/desktop/hh308954(v=vs.85).aspx

If you use mode 4 or 5, alpha channel won't be compressed. With 6 or 7, it will be, along the other channels.

So you decide which type of compression suits more your needs.

Here you probably used the mode 7. Globally it's sharper than DXT5 (especially the red), apart the alpha that is also compressed.

This texture concept is more based on hardware capabilities and DirectX features than the others that are just algorithms. That's why there are features level in the compressors (dx 10 to dx 12.1 currently).

A little extra info : BC6 is the only format that can store HDR images.


For exemple :

For orange normals, I would choose mode 4, if alpha channel is needed to be not compressed.
For purple normals, I would use Mode 1
For purple normals with heightmap, I would use mode 5
For diffuse, I would use mode 2 or mode 7, depending if there is alpha or not.