SoD's Mods

[john_smith_account]

Good tutorial.  You might consider adding an alternate set of instructions for something other than GIMP though.

[SoulofDeity]

Good tutorial.  You might consider adding an alternate set of instructions for something other than GIMP though.

 

I'm not familiar with photoshop because none of the software I use is pirated.

[SoulofDeity]

So, a couple of things. First, I believe the palettes for skyboxes may actually be yuv16 instead of rgba16. Which makes them pretty much impossible to replace decently at the moment. As for the reason why mine worked, there is a second bit of info I found out. The skyboxes alternate where their palettes are loaded in tmem. As you know, the maximum palette size is 256 colors. Skybox palettes are 128 colors. The offsets they are loaded at are:

fine0: 128 (dawn)
fine1: 0 (day)
fine2: 128 (dusk)
fine3: 0 (night)

cloud0: 0 (dawn)
cloud1: 128 (day)
cloud2: 0 (dusk)
cloud3: 128 (night)

holy0: 0 (zelda's escape / ganondorf's appearance)
holy1: 128 (goddess cutscenes)

The reason this is done is so that the game can blend between skyboxes smoothly. It was likely my skybox was using a different palette that just so happened to make the image still appear somewhat the same. Below are all the skyboxes in the game in png format:

 

 

 

 

 

From top to bottom, left to right, these are vr_fine0, vr_fine1, vr_fine2, vr_fine3, vr_cloud0, vr_cloud1, vr_cloud2, vr_cloud3, vr_holy0, and vr_holy1

[SoulofDeity]

More rips from the vr files. These take forever to rip. Like Skyboxes, they don't use rgba16 palettes, so to rip them, I manually replace the skybox palettes in the game with the palettes from these textures twice, cut them out of the Rice ci bmp dumps, and delete every 4th byte.

 

 

 

 

 

From top to bottom, these are vr_ALVR, vr_DGVR, vr_FCVR, and vr_SP1a. I'll upload more later.

 

 

EDIT:

 

Here's a few more

 

 

 

 

 

From top to bottom, vr_NSVR, vr_KSVR, vr_GLVR, vr_ZRVR. That concludes all the shop panoramas. Next:

 

 

Above is the interior for a single house, vr_IPVR.

[john_smith_account]

Phenomenal!

 

Is there any chance you will make another tool for us less talented folk to be able to do this also?

[SoulofDeity]

Phenomenal!

 

Is there any chance you will make another tool for us less talented folk to be able to do this also?

 

I'm not going to make a tool because I've pretty much quit programming, but I can explain the process I used to do it.

 

 

What you'll need:

• Rice's texture plugin
• A hex editor (I use HxD)

 

Step 1 - Obtaining the palette

 

Because the color format of the palette is not RGBA5551 like normal (I'm under the assumption it may be 16-bit YUV, perhaps YUV844?) This will be the most difficult part to obtain.

1. Extract the file vr_fine1_pal_static.zdata from the rom. This is the palette for the daytime skybox in the game.
2. Extract the palette file of the vr file you are trying to rip. For example, vr_MNVR_pal_static.zdata.
3. Because the skybox palettes are 128 colors and the house interior palettes are 256 colors, you'll need to do 2 dumps. What you do is find the vr_fine1 palette in the rom, and replace it with the first 0x100 byte half of the palette, dump the ci bmp texture with Rice's plugin, move it off to the side, then replace it with the second half, dump the next texture. You should know which one it is because the texture will look scrambled.

 

Step 2 - Cleaning the palette

 

Now that we have the bitmap files with the 2 halves of our palette, we'll need to clean them both up by removing the unneeded information.

1. Look at the byte at offset 0x0A. It's the size of the bmp header, and will most likely be 0x36, so you remove that many bytes.
2. Remove everything after 0x200 because 128 * 4 = 0x200.
3. Remove every 4th byte
4. After doing steps 1, 2, and 3 for both files, append the one that was made from the second half of the palette to the end of the first one. The size of the file should now be 0x300 bytes if done correctly.

 

Step 3 - Constructing a tga file

 

Now that the difficult part is out of the way, we just need to create a tga file. If you don't know the exact size of the image, I suggest exporting a non-compressed indexed 256-color tga file with top-left origin in gimp or photoshop to use as a base. If you do this, the header size should be 0x12 bytes and you can skip step 1 below.

1. First, we create the header. From what I've seen, it appears most vr textures are 256x256 in size, so the first 0x12 bytes will be

   00 01 01 00 00 01 00 18 00 00 00 01 00 01 00 01
   08 20

   Where the 2 bytes at 0x0C and 0x0E are the little-endian width and height of the image. (in this case, 0x0001 which is actually 0x0100)
2. Directly after this, you paste-write the palette data we ripped earlier
3. Directly after the palette data, paste the texture data from the corresponding vr file we got our palette from, which in this tutorial is vr_MNVR_static.zdata. Because the texture is 256x256 in size, we'll be pasting a 0x10000 sized block. If you used a template tga, there may be 0x18 bytes left over that has a few null bytes with the text "TRUEVISION-X FILE" which you may optionally delete or ignore.

 

Now, you should be able to just open the image up in an image editor and see what it looks like. The vr files often contain multiple textures and palettes, and each texture has it's own palette. Eg. the second 0x200 bytes in vr_MNVR_pal_static are the palette for the second 0x10000 byte texture in vr_MNVR_static.

[SoulofDeity]

Here's more of the vr files:

 

 

 

 

 

 

 

 

[SoulofDeity]

and here's the last of them. (I would have put them all in one post, but there's an image limit)

 

 

 

 

 

[Jason777]

Nice job! I wonder, is there any documentation on how the camera switches between the different VR images? I would think it has to do with collision data.

[SoulofDeity]

Nice job! I wonder, is there any documentation on how the camera switches between the different VR images? I would think it has to do with collision data.

I assume for the non-skybox VR's that it's done instantly by just adjusting the camera angle and mapping them to the side of a cube like a skybox. For the skyboxes, it's a little tricky. Each of them use a 128-color palette, but the indices that they start at isn't the same because 2 palettes are loaded at once. The colors that the palette for each skybox uses are:

 

fine dawn: 128-255

fine day: 0-127

fine dusk: 128-255

fine night: 0-127

cloud dawn: 0-127

cloud day: 128-255

cloud dusk: 0-127

cloud night: 128-255

 

and I think

 

holy dark: 0-127

holy day: 128-255

[SoulofDeity]

Someone needs to correct the wiki. While trying to figure out how the lighting works in the game, I found out that it's incorrect.

 

Url: http://wiki.spinout182.com/w/Scenes_and_Rooms#Environments_list

 

It should be:

aaaaaa bbbbbb cccccc dddddd eeeeee ffffff gggg hhhh

a - ambient color
b - first diffuse light color
c - first diffuse light direction
d - second diffuse light color
e - second diffuse light direction
f - fog color
g - fog distance
h - draw distance

Proof 1

The equation to convert a directional vector to an angle-axis rotation is

 

angle = acos(dotProduct(Va, Vb))

axis = crossProduct(Va, Vb)

 

In the wiki documentation, the direction is 494949 and B7B7B7, both of which will return a dot product and cross product of zero because the x,y,z values are all the same.

 

 

Proof 2

Changing the color of light 1 to green and light 2 to blue according to how the wiki has it documented

 

 

 

 

Changing the color of light 1 to green and light 2 to blue according to how I have it documented

 

[mzxrules]

http://oot.cloudmodding.com/wiki/Scenes_and_Rooms#Environments_list This fine?

[SoulofDeity]

http://oot.cloudmodding.com/wiki/Scenes_and_Rooms#Environments_list This fine?

 

Yeah. It should be noted though that the first value in the environment list usually doesn't control anything. I had to replace the environment settings in the alternate scene headers to get it to work. Also, I think all of the environment settings might be loaded simultaneously for each scene header, because it's practically impossible to get a good lighting setup with only 2 lights.

[xdaniel]

Also, I think all of the environment settings might be loaded simultaneously for each scene header, because it's practically impossible to get a good lighting setup with only 2 lights.

gSPNumLights is called by the intro in Hyrule Field 50 times for two lights, by Kakariko 52 times for two lights, 10 times for 3 lights and 2 times for 4 lights, and by Kokiri 72 times for two lights and 4 times for 3 lights. So, having two lights actually does seem to be the norm, I think?

 

(Interpreting RDRAM dumps is fun! Not. And I'm far from done...)

[SoulofDeity]

gSPNumLights is called by the intro in Hyrule Field 50 times for two lights, by Kakariko 52 times for two lights, 10 times for 3 lights and 2 times for 4 lights, and by Kokiri 72 times for two lights and 4 times for 3 lights. So, having two lights actually does seem to be the norm, I think?

 

(Interpreting RDRAM dumps is fun! Not. And I'm far from done...)

 

In the hyrule field scene header, there are about 50 environment list entries between all of the scene headers combined. The first scene header has 16.

 

Anyhow, it's just a thought. I'm just skeptical of there being only 2 lights because it's not possible to place them in a way that doesn't create heavily dark areas unless you crank up the ambient light.

[haddockd]

Do not doubt the great and powerful xDan you fool!

 

Kidding, obviously lol

 

The lighting has been something that alluded me in my "complete" mod years ago so I am glad to see some work being done to add to the knowledge base!