The Beta Actors - Viewing BETA animations and models

[Airikita]

Quite literally, I took object_oE3 and object_oE_anime, and mixed the two files... here's the result... Beta Saria:

 

 

 

 

 

 

I don't know what's making her polygons fly, but her model is in tact... I'm guessing her fairy might be an issue?

[Twili]

I'm EXTREMELY curious how you managed to load her with Saria's final actor, what with the difference in limb counts, because I've attempted such a thing in the past and it always froze for me if the limb count was different than the amount the actor expected. Possible tutorial in the future? 

[Airikita]

With actor models, you mostly need to point to the heiarchy, but also you need to add the animations and re-point the animations. I simply did that, but her polygons still shoot everywhere.

 

Aria is slightly different though.

[Zeth Ryder]

Its not her fairy, the problem lies in the object's DE commands. The actor uses the DE commands for the fading effect that the Kokiri use. You need to change the DE commands in object_oe3 to match that of the current Saria. So go in a hex editor and search "DE00 0000" You should find in the beta object a lot of DE00 0000 0D00 0000 those need to be changed to DE00 0000 0C00 0000. That will stop the glitching/polygons flying everywhere.

 

End result should be:

[Airikita]

Oh thanks Zeth... I would imagine that would be the same for other beta models?

 

EDIT:

I tried it, but it didn't change anything... I even tried changing every DE to 00 as described here:

http://z64.spinout182.com/index.php/topic,120.0.html

[Zeth Ryder]

DE's commands are just one of the problems and double check the animation's pointer in the actor, even one byte off can cause things like this too.

 

EDIT: Forgot to add, yes changing the DE commands also works for the other beta models that load up. Though certain DE commands can actually activate colouring on certain model pieces, like ex object_kw's boots that are normally vertex coloured by the actor.

[Zeth Ryder]

I tried it, but it didn't change anything... I even tried changing every DE to 00 as described here:

http://z64.spinout182.com/index.php/topic,120.0.html

 

If that didn't work, there is something you should double check in your work then, check the animation you ported making sure the pointers line up, as well as pointers in the actor. If all else fails, restart brand new and retry again.  I've had to do that before and usually retrying from scratch made it work properly. 

 

EDIT: I just watched your video again, is the target arrow lower then it should be? Because that might be related to this issue you are having and I haven't experienced that problem before. o.o

[Airikita]

If that didn't work, there is something you should double check in your work then, check the animation you ported making sure the pointers line up, as well as pointers in the actor. If all else fails, restart brand new and retry again.  I've had to do that before and usually retrying from scratch made it work properly. 

 

EDIT: I just watched your video again, is the target arrow lower then it should be? Because that might be related to this issue you are having and I haven't experienced that problem before. o.o

Well, technically I didn't port the model over piece-by-piece... so I imagine the target box might be the issue, but beta Saria's limb count is 0x26 whereas regular Saria's limb count is 0x10. I assume it's in the spot where normal Saria's limb index points to, which is attaching to Beta Saria's foot in this case.

 

A similar occurrence happened to regular Saria porting her over Ganondorf, and her polygons were flying around until I removed Zelda. My guess is that it might have something to do with how she faces Link, because Ganondorf would have a reference to Zelda in the same concept.

[john_smith_account]

Keep up the great work!  Whata say, lets fix em' all!

 

As a side note:

 

http://tcrf.net/Proto:The_Legend_of_Zelda:_Ocarina_of_Time_Master_Quest

 

It's not perfect, but it works well as a quick refernce sheet.  It's missing the beta castle guards, for instance, which I'm pretty sure Impa's head goes on to create beta Impa.  Oh well.

 

Good luck everyone, and happy hacking!

[Twili]

I attempted to load object_oB1 (alpha version of the bazaar/shooting gallery guy) over object_ossan, and the game crashed...but it was a less severe crash than previous attempts; the header for object_oB1's hierarchy lacked a display list count, and adding that allowed me a glimpse of the model as the shooting gallery was fading in, with the framerate remaining constant instead of dropping below zero with a completely black screen.

 

What I did was overwrite the first 0x66B0 bytes of object_ossan with all of object_oB1's file, and then chose an animation from object_o_anime to add to my modified object_ossan.

 

I used UoT SVN R10 to view the animations in object_o_anime and decided to use the one at 0x1300 (erroneously marked 0x1304 in UoT). So I copied the 0x480 bytes of data for the animation (beginning with the rotation values at 0xE90, ending with the header) and pasted them at 0x66B0 in the modified object_ossan.

 

I recalculated the two pointers in the animation header so they read 060066B0 06006A34 instead of their original 06000E90 06001214.

 

The header for the animation was now at 0x6B20.

 

To add the display list count to the hierarchy header, I copied the hierarchy (first 0x268 bytes of object_oB1/my modified object_ossan) and pasted it at 0x98D8.

 

This way, I wouldn't have to recalculate all of oB1's data pointers just because I added four bytes to the hierarchy header. AND, this way the header would end up in the exact same spot object_ossan's old one was (0x9B38).

 

So, I didn't actually insert any bytes because I could just change 08 00 00 00 (untouched from object_ossan's header which has a display count) to 0F 00 00 00.

 

Then the pointers to the limbs had to be recalculated. For convenience if you want to help solve the persistent crash issue (and I want you to help!), these are the new pointers:

 

060098D8 060098E4 060098F0 060098FC

06009908 06009914 06009920 0600992C

06009938 06009944 06009950 0600995C

06009968 06009974 06009980 0600998C

06009998 060099A4 060099B0 060099BC

060099C8 060099D4 060099E0 060099EC

060099F8 06009A04 06009A10 06009A1C

06009A28 06009A34 06009A40 06009A4C

06009A58 06009A64 06009A70 06009A7C

06009A88 06009A94

 

And the header just past the limb pointers should look like:

 

06009AA0 26000000 0F000000

 

Now, the things that I changed in ovl_En_Syateki_Man:

 

ADDIU instruction at 0x64 from 24E70338 to 24E76B20.

ADDIU instruction at 0xF0 from 24840338 to 24846B20.

ADDIU instruction at 0x10C from 24A50338 to 24A56B20.

 

(Animation pointers.)

 

Also these:

 

ADDIU instruction at 0xC44 from 24010008 to 24010017.

 

This previously selected the 8th limb (index value 7+1) of object_ossan's hierarchy (the head) to load the shooting gallery variant of his head.

 

Limb 0x17 (index value 0x16+1) of object_oB1's hierarchy is his head.

 

...

 

ADDIU instruction at 0xC58 from 27397E28 to 273932F8.

 

(0x7E28 was the shooting gallery version of object_ossan's head display list and 0x32F8 is object_oB1's head display list.)

 

Once you paste the modified actor and object files at their rom offsets and test in Nemu64, you should be greeted by the following images:

 

Child Shooting Gallery:

 

 

Adult Shooting Gallery:

 

 

NOTE: I adjusted the brightness and contrast, because like I said at the beginning of the post, these were taken when the area was fading in.

 

So yeah, help on the freezing appreciated. I think it's more stuff that has to be done to the actor. Because everything is pointed to as it should be in the object, and I changed the animation pointers in the actor. The fact that oB1's left arm is extended in an animation-defying way might be significant.

[â–²ChriisTiianâ–²]

I made this a few months ago, and I had forgotten that I made this.

 

This is object_oA10 (Beta Hylian Guard), completely restored without problems:

Uh yes, I need to move some model parts and make some adjust here, but anyway, the model is restored.

 

 

object_oA11 is the same, i think, but for some reason, crashes the game.

[Airikita]

Animations and everything I checked was re-pointed correctly in Saria... the issue is her display list most likely, because you can see her model and animations work perfectly. Her rendering seems to be an issue, however.

 

EDIT:

I found this in object_sa:

DA 38 00 03 0D 00 00 00

 

But this command does not exist in Beta Saria object_oE3... could this be significant?

 

 

EDIT2:

So I changed some things around, but I still get this one issue... the matter of her face is not right, and polygons are shooting all over still:

 

She is a lot better now though, as she doesn't crash Nemu. (Crap, I forgot to change her face to a static texture *facepalm*)

 

 

 

EDIT 3:

Polygons still flying around even with face fixed:

Viewing her with C-up seems to make her appear more solid, so I'm going on the assumption that it's in her AI where a limb index is being misread, and wrongly placed due to her Beta model having a different set of limbs.

Edited February 4, 2014 by Airikita

[â–²ChriisTiianâ–²]

This is object_oB1 restored:

Note: This beta model have LEGS, and as the Beta Hylian Guard, I need to move some model parts and make some adjusts here, but anyway, the model is restored.

 

 

[Zeth Ryder]

It's missing the beta castle guards, for instance, which I'm pretty sure Impa's head goes on to create beta Impa. 

oh you mean like these for instance? Also impas head is used ingame, its used in the cutscene with her running with Zelda. Not beta.

 

[Airikita]

Well I didn't change object_sa or object_oE3 to make Beta Saria appear... so I wonder if perhaps Beta Saria's hierarchy might be an issue? The only thing I did was add object_oE_anime to the end of object_oE3.

[Zeth Ryder]

Adding animations to the end of the file shouldn't be causing it, especially since object_oe_anime has very little animations to begin with in comparison to some of the models that have a lot of animations in it.

[Airikita]

Adding animations to the end of the file shouldn't be causing it, especially since object_oe_anime has very little animations to begin with in comparison to some of the models that have a lot of animations in it.

Wasn't my thought... also I noticed something odd about how Beta Saria is so screwy. It's not Beta Saria's polygons flying around, it's Link's. I remember some hacking a while back (me and someone else found this sort of thing) that hacking the vertices in the display list of another actor caused Link to warp in similar ways. I'm curious if Beta Saria's vertices in her display list are wrong in some way... I don't know if the hierarchy would cause a similar error though.

 

EDIT:

Here you can see the effects:

 

 

 

 

 

She doesn't make the display melt and bleed colors, but she manages to mangle up Link still...

[Jason777]

From what I remember, there are matrices involved with Saria.

[Airikita]

Actually, I found the error relating to the original Saria... I found that she not only had the limb count as 10000000 for her limbs, but she also had the value 0F000000 next to it. Looking at the limbs, it was pointing to her head. I took that, found the limb with Beta Sarias head, and added 17000000 next to 26000000. I had to shift things, deleted one irrelevant command, and re-pointed her matrices around to fit to the new changes:

 

 

 

 

 

So it was a bit of a re-haul, but thankfully it was a simple 64-bit shift and a 32-bit word next to the limb count (for alignment reasons, but also how the function was loading it from a 0x0008 reference in a certain function).

 

------------------------------------------------------------------------------------------------------

 

EDIT:

Saria displaying all the other BETA animations:

 

 

 

 

 

 

Animations are unchanged, so the glitchy animations are not my doing. I've seen Shiek have glitchy animations when switching them before, so the glitching on Saria might be irrelevant.

[â–²ChriisTiianâ–²]

This is object_masterkokiri:

 

Original:

 

 

Beta Restored: (Finally, a model with no issues :-P)

[Mallos31]

Does anyone have any idea what causes the crazy polygon explosion and occasional interface removal when there's bad models on the map? I've always been curious as to why something completely unrelated to link could grab one of his vertices and attach it to some crazy place. Also, I always liked Mr. Buttchin. He's awesome. 

[Airikita]

Does anyone have any idea what causes the crazy polygon explosion and occasional interface removal when there's bad models on the map? I've always been curious as to why something completely unrelated to link could grab one of his vertices and attach it to some crazy place. Also, I always liked Mr. Buttchin. He's awesome. 

My guess is it overflows the RAM, and chews out any other model/actor/HUD visual there is until it reloads, causing the flicker.

[Airikita]

Recently unearthed a beta nose ring for Cows:

The funnier part of this is that it does come next in the hierarchy, but Nintendo prevented cows from rendering it. Stranger still, the animation size dictates the cow should have 06 limbs, but is marked for 05... changing the limb count to 06 in the ROM does not make the game crash when a cow is drawn/animated, but the animations are distorted, suggesting a possible animation existing with the nose ring.

 

It looks a bit discolored, but I assume they removed it in the N64 release because it wasn't too important? So yeah... guess we know why OoT3D has cows with nose rings now.

[â–²ChriisTiianâ–²]

Recently unearthed a beta nose ring for Cows:

*image*

The funnier part of this is that it does come next in the hierarchy, but Nintendo prevented cows from rendering it. It looks a bit discolored, but I assume they removed it in the N64 release because it wasn't too important? So yeah... guess we know why OoT3D has cows with nose rings now.

In MM (J) 1.0, the cows have this ring, btw, good job!, how you have done this?

[xdaniel]

So wait, how did they make the cow not render the nose ring? Is the actor hardcoded to not render that particular limb or something? Because I've always seen it while working on actor rendering: