SoulofDeity

This is just me toying around with an idea, replicating the N64 combiner in Blender through the use of nodes. It actually works rather well. The above shows the equation: Color = (TEXEL0 - 0) * SHADE + PRIMITIVE. Alpha = (1 - TEXEL0) * 1 + 0 Notice that the shade property get the vertex color as input and converts it to grayscale, so in the render the corner of the cube appears darker shaded rather than blue. If there is some way to create and organize nodes from a script, this would be a lot better than using shaders. EDIT: An improved node setup that supports 2 passes This setup should be capable of recreating any combiner mode, with the exception of modes that include the parameters LOD_FRACTION, PRIM_LOD_FRAC, NOISE, CENTER, SCALE, K4, and K5. Though I'm pretty sure none of those parameters are even used in OoT/MM.

Just a bit of information I found out, there's a tool called GC Rebuilder that can be used to both extract and re-package .gcm files. I tested it myself on TP, and it works perfectly.

If they were accessed via segment 8, my import script wouldn't have loaded them. The only segments I specify when loading scenes are 04 (gameplay keep) and 05 (field/dungeon keep). That animation info will be pretty useful though if I try to tackle that Also, cleaning up the UI a bit to make it less confusing: EDIT: A bit better. Added audio options and Save/Load/Delete buttons for working with multiple headers and environments. I also added a new 'material' tab which will allow you to specify tile options like format and mirroring. If I can get some info on scene texture animation, I may be able to implement that as well.

Thanks for the motivation :3 It's better to export the models as FBX because they use vertex colors for shading. Otherwise, your exported model will appear dull and flat. I'm not certain if the ranch windows change color or not, but the new script will allow you to import alternate scene headers. It's likely that the window textures are located in the gameplay_field_keep file. For the V3 script, if you place it in the same directory as the zmap you're importing with the name segment_05.zdata, it might fix it.

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.

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.

That actually wasn't even from the script, it just sort of accumulated after I did a couple of dozen renders to test the lighting. However, there is a memory leak problem with the script as well. When you click one of the Actor/Object/Scene tabs, the memory usage spikes a little, even if the tab doesn't actually change. It maxes on ~19.3M. Whatever the problem is, it seems to be Blender itself that's the cause.

After figuring out how that the environment format was wrong, I went back and retried the lighting in blender with the correct colors; this time using ambient occlusion I'm still having trouble getting the lights to face the proper direction, but I think this does look a lot better. However....

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

I'm having a lit bit of trouble trying to figure out how replicate the lighting in the game. The best I could come up with was to enable environment lighting from the world properties, create 2 sun lamps with the appropriate colors (one pointing up, the other down) and the ambient sky color set appropriately. The model was imported using the old importer btw, just doing some experiments. I'm not entirely certain how accurate this is, it's kinda hard to tell without multitexturing and vertex colors working properly. In the normal 3D view, the scene looks like total shit.

Yeah, I'm going to add support for MM scene/room commands if possible. If I used xdan's tool, it'd spit out GLSL code, which isn't what I want. I want to use CG so that you can export them for use in Unity. Btw, it would be nice if xdan or someone could inform me about how the light direction is formatted in the header. I assumed it may have been an 8-bit signed integer euler rotation with range of -180 to 180, but it doesn't seem to be the case. I also thought it might have been a vector, where the light is supposed to look from (0, 0, 0) to (x, y, z), but that doesn't seem to be it either.

Thanks I just fixed a slight problem as well. For some reason, cgc wouldn't recognize the modelview projection matrix parameter when generating GLSL code, so to fix it, I was doing a manual string replacement. I searched the actual CG developer site everywhere and couldn't find any information at all, but I eventually found this site which hinted me to use state.matrix.mvp as the parameter hint and it fixed the problem :3 Now shaders load a little faster. It's still not the fastest though. Every time you click the "Show Preview" button, the CG shaders have to be re-converted to GLSL and compiled. Still, it's really clean, and I think I'm the first person to actually get CG shaders working in Blender.

Almost got CG shaders working. Just having a little bit of trouble getting cgc to spit out the GLSL vertex shader properly EDIT: Fixed it. Turns out I just did my multiplication backwards in the shader code Now CG shaders are working properly.

Since I've had nothing better to do lately, I picked back up on my Blender toolbox plugin. As you can tell from above, I'm adding new tool-panels for working with objects, collision, animation, and scene settings like environment lighting. I know that it's possible to use GLSL shaders in Blender, but I'm looking to see if I can somehow use CG; since it'd be a piece of cake to import into Unity. EDIT: It seems CG shaders might not be that difficult after all. I just need to add a new attribute to the Material bpy type that points to the textblock for the cg shader, then for each object assign a sensor and controller for a script that passes the shader to the cgc program from the NVidia CG toolkit to spit out the GLSL vertex and fragment shaders, then assign those to the Material. The only downside is that shaders can only be used with game logic, so I added a convenient "Show Preview" button to the toolbox.

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

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

Here's more of the vr files:

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. Extract the file vr_fine1_pal_static.zdata from the rom. This is the palette for the daytime skybox in the game. Extract the palette file of the vr file you are trying to rip. For example, vr_MNVR_pal_static.zdata. 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. 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. Remove everything after 0x200 because 128 * 4 = 0x200. Remove every 4th byte 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. 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) Directly after this, you paste-write the palette data we ripped earlier 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.

It could be because files like skyboxes and shop/house interiors are all loaded from external texture files even in OoT. Maybe it's a little less specific.

The reason that the entire hillside to west clocktown is missing is probably because that part of town is actually an object. I'm not 100% certain, but I think I recall coming across it once while I was browsing objects with UoT. Aside from that, excellent work!

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.

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

In several zelda games, there is a particular file called "gameplay". I don't believe this is gameplay in the sense how "how you play the game", but rather "game play" as in a screenplay in the form of a game. There are several reasons for this. Firstly is the fact that the layout of zelda games seems to borrow elements from screenplays. In Zelda64, you have actors and scenes. Each actor belongs a group and has an object; or alternatively, a troupe and a set of props. The scenes themselves not only tell which actors are within the scenes, but specify things such as weather, lighting conditions, and which troupe's (groups) will be needed. Both OoT and MM have a 3 files called "gameplay_keep", "gameplay_dangeon_keep", and "gameplay_field_keep.". The very first noun definition of the word keep is: "food, clothes, and other essentials for living", or in other words, a collection of props. In TP, instead of maps, you have stages. Aside from the internal structure, how the games are presented also suggests they may be plays. At the beginning of both OoT and MM, there is a narrative introduction. The next thing is that major enemies are introduced to the player The end of games print "The End", as if a story has just finished being told. Another thing is that unlike most other 3d action games the camera does not focus solely on Link throughout the game. The targeting feature focuses more on the enemies or objects, which ensures that the actions being taken are being recorded from the best possible angle. The sun flares in these games are also circular, as if the light is being glared off the lens of a camera Lastly, destiny also plays a huge part in each game. It's stressed that the actions of Link have long since been foretold, or in other words Link is simply acting out what has been written. Considering that early Mario games have had strong evidence for being plays as well, I don't think this is that much of a stretch. This is just a theory though, what do you guys think?

Sorry, missed that. Another idea is that it could have something to do with the fish. The code for the function that gets a particular actor may return null on error; and since Link's actor number is 0, the animation for the fish is being played on link's actor.

Have you tried using meta tiles and triangle strips? With triangle strips, the number of vertices needed is 2 to begin with then 1 more for every triangle.