Dolphin, the GameCube and Wii emulator - Forums

(08-20-2021, 06:52 AM)Tino Wrote: [ -> ]Sorry, I'm a little to bussy the last year. hope to get some free time to make at least a last version.

Dont worry,we can wait

(10-15-2021, 08:42 AM)notmiguel Wrote: [ -> ]14-10-2021,we still haven't got a new version of Ishiiruka

Didn't we? I believe that every git push is built and added into "Latest" link on the 1st page :/

(10-15-2021, 09:45 PM)Alastor Wrote: [ -> ]Didn't we? I believe that every git push is built and added into "Latest" link on the 1st page :/

Oh,ok

(10-13-2021, 01:10 AM)Tino Wrote: [ -> ]1 Specular color is the color of the reflected ligth, advance rendering engines allows to specify specular maps with color support, but ishiiruka implements a simplified version ith only intensity of the specular reflection applyed, so yuo cannot represent materials that change the reflected colour. the simplification is simply to reduce texture memory usage.
2 rim effect is acomplished by "Virtual lights" in the sides of the screen thats the reason behing rim ligthing working even in games with no ligthing.
3 Default specular maps for the games are calulated using a fake value generated from the intensity of the colours in the game textures.
4 Shure no problem with the logo.

Thanks a lot for the answer ! I now understand better how it works.

However, I still can't have the specularity working right. Specular maps interact correctly with rim lighting, but I still can't get the lights to interact with stuff (including specualrity). The textures I defined as lights are surely brighter, but it doesn't change the look of other elements of games, may they be specular effects or normal maps.

Do you know a texture pack using material maps where I could look into the files and see what's different compared to what I do ? The only thing I found is the Henriko Magnifiko pack for Twilight Princess, which uses .dds which I should be capable of opening but for some reason none of the 3 softwares I used that are supposedly compatible with .dds can open those files, and online websites to convert only result in random noise.

And just to be sure I didn't do something wrong : I don't use mip maps, I have in the "Load" folder then in the game folder the textures to load in .png, their material maps in one file with the ishiiruka encoder in the format of texturename.mat.png, and if the textures emit lights an other file ending in .lum.png with the colors of the picture representing what is bright and in which color is it bright. Is everything with that ok ? Also, is the texture encoder mandatory ?

Hi Tino. In the Lost Kingdoms game, the only way to enable cutscenes and intro is to enable External Frame Buffer as Hybrid. But when I enable it, the graphic looks like Native and I can't increase the resolution. I use Intel HD Graphics 4400. Is there any way to fix this? Thanks.

Ok, so I found a cool software that brings other dolphin related software together (It's called Custom Texture Tool), and with that, I could finally convert to png the twilight princes pack and... I don't see any difference with what I do.

But I have new hypothesis for why specularity refuses to work : this software has the option to repair textures, but when I ask it to analyse directly dumped textures from dolphin, most textures are marked as having non-integer upscale. Does that mean that out of the box dolphin dumped textures may not work with some functionalities ?
And another question to be sure of how it works, specularity and normal maps require a light source to work, and this light source is defined through the .lum.png files. Am I wrong ?

@Subsonic (Paul): I wouldn't rely on my script to handle material maps correctly at the moment. While it does get some things right, there are some underlying issues with Ishiiruka Tool command line that aren't present in the GUI. The script uses v0.9.10 if using the programs pack, which still handles converting materials to material maps correctly, but there is a bug in 1.0.0 that makes them the original size they were dumped with.

Speaking of all that, I've been updating the code to handle material maps in CTT-PS which leverages Ishiiruka Tool to handle materials / material maps it finds in a pack. I've been testing Ishiiruka Tool 0.9.10 via command line and have found a number of issues. After that, I then realized there is a v1.0.0 of Ishiiruka Tool, so I updated to that, and found even more issues. So far I haven't even been testing with "emissive" textures (.lum), I figured there is enough issues already before trying to see what happens when those are thrown into the mix...

Global Issues:
• The -usebc7 command doesn't do anything.
• The -savecolor command seems to be acting as the -useBC7 command.
• The color texture is always saved whether the -savecolor flag is specified or not.
• There is no command line equivalent to Scale X/Y settings. This isn't too big of a deal since that can be done manually and fed to dimensions (which currently don't work).

Materials to Material Map:
• Material Maps are created at the dumped resolution from Dolphin, not the actual resolution of the texture. This does not happen with -frommaterial. Specifying width and height does not work around this, instead it generates an error. I have a feeling this happened with the addition of the Scale X/Y settings added to the GUI.

Material Map to Material Map (-frommaterial):
• BC7 Material Maps can not be converted to other formats (PNG, DDS-DXT5, etc). This generates an error.
• The -frommaterial command does not convert existing material maps to BC7 when using -compress -usebc7 -savecolor (whether they be PNG or DDS-DXT5, -savecolor is used because it acts as -usebc7). This also generates the same error as trying to specify the width and height.

Technical (DDS Header Issues):
• The DDPF_RGB flag is being set at byte[80] a value of (40 hex) to say there is uncompressed data, but Ishiiruka textures are not uncompressed.
• The dwCaps1 flags are not being set: DDSCAPS_TEXTURE, DDSCAPS_COMPLEX, and DDSCAPS_MIPMAP (when texture has mipmaps).

Long ago, I made this image to help me understand DDS headers a bit better. The DDS header issues are not even really an issue since they still work with in Dolphin Ishiiruka, it just prevents the textures from being opened in other image programs + I can hotfix those on the fly. But some of the other issues are pretty severe, especially the commands not working correctly (-savecolor/-usebc7) and the scaling issue when creating from materials. Not being able to convert existing BC7 material maps to other formats isn't the end of the world, but this also means they can't be resized.

---

Edit: So.. all of this led me to trying to create my own material maps (again), and the one thing I'm hung up on is the normal map pixel values in the generated material map. When the bump and spec is converted to the mat format, the pixel values are copied directly into the corresponding color channels. Easy enough, I could just directly import those into the red (spec) and blue (bump) channels respectively. But for the normal map X and Y values, the pixel values in the norm texture do not match the values in the mat texture. Some pixel values go up, some pixel values go down. I can't make sense of it, I'm not smart enough to understand what is happening here. Even if the values were "transformed" to a different range, they should all move in one direction, no? Does anyone know exactly what is going on here? Is there source code for the Ishiiruka Tool anywhere? Maybe that would help me to grasp what is going on.



Looking at the image above, it's obvious where the bump and spec values are coming from. What is not obvious, is how the normal map X and Y values are being calculated. There doesn't seem to be a consistency to how the new values are determined. Maybe some kind of filter is applied? Some formula that can either increase or decrease the value? Maybe the Z value from the normal map comes into play? This is really the only thing holding me up. While I have no problems using Ishiiruka Tool to create material maps, I can't really use it in its currently broken state. And I would like to be able to at least match what it is currently doing.

(10-16-2021, 06:03 AM)Subsonic (Paul) Wrote: [ -> ]Thanks a lot for the answer ! I now understand better how it works.

However, I still can't have the specularity working right. Specular maps interact correctly with rim lighting, but I still can't get the lights to interact with stuff (including specualrity). The textures I defined as lights are surely brighter, but it doesn't change the look of other elements of games, may they be specular effects or normal maps.

Do you know a texture pack using material maps where I could look into the files and see what's different compared to what I do ? The only thing I found is the Henriko Magnifiko pack for Twilight Princess, which uses .dds which I should be capable of opening but for some reason none of the 3 softwares I used that are supposedly compatible with .dds can open those files, and online websites to convert only result in random noise.

And just to be sure I didn't do something wrong : I don't use mip maps, I have in the "Load" folder then in the game folder the textures to load in .png, their material maps in one file with the ishiiruka encoder in the format of texturename.mat.png, and if the textures emit lights an other file ending in .lum.png with the colors of the picture representing what is bright and in which color is it bright. Is everything with that ok ? Also, is the texture encoder mandatory ?

the specular ligthing only works if the game has  ligths defined, the current version caanot add ligthing if the game does not already have ligthing enabled.
the tool is mandatory to create the material maps because they are encoded in a specific format.

(10-30-2021, 12:24 AM)Bighead Wrote: [ -> ]@Subsonic (Paul): I wouldn't rely on my script to handle material maps correctly at the moment. While it does get some things right, there are some underlying issues with Ishiiruka Tool command line that aren't present in the GUI. The script uses v0.9.10 if using the programs pack, which still handles converting materials to material maps correctly, but there is a bug in 1.0.0 that makes them the original size they were dumped with.

Speaking of all that, I've been updating the code to handle material maps in CTT-PS which leverages Ishiiruka Tool to handle materials / material maps it finds in a pack. I've been testing Ishiiruka Tool 0.9.10 via command line and have found a number of issues. After that, I then realized there is a v1.0.0 of Ishiiruka Tool, so I updated to that, and found even more issues. So far I haven't even been testing with "emissive" textures (.lum), I figured there is enough issues already before trying to see what happens when those are thrown into the mix...

Global Issues:
• The -usebc7 command doesn't do anything.
• The -savecolor command seems to be acting as the -useBC7 command.
• The color texture is always saved whether the -savecolor flag is specified or not.
• There is no command line equivalent to Scale X/Y settings. This isn't too big of a deal since that can be done manually and fed to dimensions (which currently don't work).

Materials to Material Map:
• Material Maps are created at the dumped resolution from Dolphin, not the actual resolution of the texture. This does not happen with -frommaterial. Specifying width and height does not work around this, instead it generates an error. I have a feeling this happened with the addition of the Scale X/Y settings added to the GUI.

Material Map to Material Map (-frommaterial):
• BC7 Material Maps can not be converted to other formats (PNG, DDS-DXT5, etc). This generates an error.
• The -frommaterial command does not convert existing material maps to BC7 when using -compress -usebc7 -savecolor (whether they be PNG or DDS-DXT5, -savecolor is used because it acts as -usebc7). This also generates the same error as trying to specify the width and height.

Technical (DDS Header Issues):
• The DDPF_RGB flag is being set at byte[80] a value of (40 hex) to say there is uncompressed data, but Ishiiruka textures are not uncompressed.
• The dwCaps1 flags are not being set: DDSCAPS_TEXTURE, DDSCAPS_COMPLEX, and DDSCAPS_MIPMAP (when texture has mipmaps).

Long ago, I made this image to help me understand DDS headers a bit better. The DDS header issues are not even really an issue since they still work with in Dolphin Ishiiruka, it just prevents the textures from being opened in other image programs + I can hotfix those on the fly. But some of the other issues are pretty severe, especially the commands not working correctly (-savecolor/-usebc7) and the scaling issue when creating from materials. Not being able to convert existing BC7 material maps to other formats isn't the end of the world, but this also means they can't be resized.

---

Edit: So.. all of this led me to trying to create my own material maps (again), and the one thing I'm hung up on is the normal map pixel values in the generated material map. When the bump and spec is converted to the mat format, the pixel values are copied directly into the corresponding color channels. Easy enough, I could just directly import those into the red (spec) and blue (bump) channels respectively. But for the normal map X and Y values, the pixel values in the norm texture do not match the values in the mat texture. Some pixel values go up, some pixel values go down. I can't make sense of it, I'm not smart enough to understand what is happening here. Even if the values were "transformed" to a different range, they should all move in one direction, no? Does anyone know exactly what is going on here? Is there source code for the Ishiiruka Tool anywhere? Maybe that would help me to grasp what is going on.



Looking at the image above, it's obvious where the bump and spec values are coming from. What is not obvious, is how the normal map X and Y values are being calculated. There doesn't seem to be a consistency to how the new values are determined. Maybe some kind of filter is applied? Some formula that can either increase or decrease the value? Maybe the Z value from the normal map comes into play? This is really the only thing holding me up. While I have no problems using Ishiiruka Tool to create material maps, I can't really use it in its currently broken state. And I would like to be able to at least match what it is currently doing.

didn't know about the missing functionality in the tool will try to fix it. About the encoding of the normal maps, normal maps are scentially unit vector values, what i do is read the values encoded in the original texture into floating point vectors, normalize them and then store the x and y component in the alpha and green channel, then the z value is reconstruted in shader using the formula z= sqr(x*x+y*y), normalization proccess can generate the difference in the values.

Thanks for taking the time to respond. I would definitely prefer fixes to Ishiiruka Tool rather than attempt to simulate it's behavior, as much of what you said about normal maps is currently over my head. I am interested in learning, so I'll see what I can figure out either way. Plus, even if I did understand, I doubt I could write anything that would have the same amount of speed as Ishiiruka Tool where generating material maps is really fast. When you release a new version of the tool with the fixes, I will definitely give it thorough testing!