xdaniel

I read some old threads about Dolphin and this model format over at Emutalk, and apparently Link's eyes are kinda tricky to render correctly. They looked pretty much just like this in Dolphin as well initially, as far as I remember, until someone came along and cracked the format for good. Also, some more progress: One correct arm, and that's about it so far. EDIT: YES!

And the glitches you can still see there are most likely because I don't support weighted/skinned matrices yet. That looks a bit more complicated - as if normal matrices weren't complicated enough! - so I didn't yet try to get those going. It wouldn't even have made sense so far, considering even said normal matrices were never 100% correct, and I'm still not completely sure they are now. They seem to be correct, considering non-weighted models (like that damn crab - I've seen it so many times over the last week, I'm sick of it) and stage models (at least Outset Island, Forsaken Fortress exterior, Windfall Island, Forest Haven exterior) look pretty much perfect(?), translation- and rotation-wise. Texturing, colors, etc., etc. are something else of course, but the general shape is correct for those now. Also, also still broken because of the weighted matrices, have some Link and Tetra/Zelda:

And I beat Airman first try!

Now that's an interesting topic... First things first, it's been awhile since I've seen or read either of the shows in question, I haven't seen a shred of Kai - one reason being no-one's brought it over here yet, as far as I'm aware, otherwise I would've watched it on TV from time to time - and I have dropped Shippuuden several years ago. On one hand, this should give me some reasonable distance to judge them fairly, while on the other hand this means that my memory of each the shows might not be the best. That out of the way, here we go... Story: If you exclude any non-story or at least less important events from each, Dragon Ball probably has an edge over Naruto overall, yet I think the world of Naruto is more interesting and more defined, with its countries and ninja villages, their histories, etc. Yet again, I'm of the opinion that Naruto could've as well ended after the conclusion of the Chuunin exam or after Naruto and Sasuke's battle at the Valley of the End (or whatever it was called), because, while potentially interesting, the execution of the whole "bringing back Sasuke" thing fell kinda flat. An even more extreme opinion would be that they could've left the whole thing as a short one-shot and ended it after Wave Country - I wouldn't have minded, seeing how that first arc is my favorite to this day. Art and Animation: Covering both in one point, I can't really decide about the animation, as it's been so long since I saw DB or DBZ, but just in terms of the art style and still images (backgrounds, etc.) I have to give this one to Naruto. While Akira Toriyama is a great artist no doubt, I'm personally more of a fan of Kishimoto here - character design, background artwork, basically everything in that regard I like Kishimoto's takes on more. Characters: The longer Naruto dragged on, the less interesting the main characters became - maybe excluding Kakashi, especially after reading the Kakashi Gaiden chapters -, but then again, I have to say that Dragon Ball's main characters didn't really leave that big of an impression on me, either. Some of the side characters or even villians from both series were more memorable and interesting, like ex. Shikamaru, or Zabuza and Haku on the Naruto side, or the Red Ribbon Army and their commanders from Dragon Ball. Fillers: I did sit through 30 or 40 of Naruto's filler episodes before skipping ahead to Shippuuden, as I was still catching up while the fillers were winding down in Japan. And while one or two of those filler arcs actually were kinda good, overall they were way more annoying than anything else, especially when there wasn't yet an end in sight, around episode 180 or whenever. Now, while this might be down to how long it's been, I can't really recall any fillers that bad in Dragon Ball. The only thing that I do remember is that Snake Road or whatever the name was that Goku had to travel along in DBZ, although I have no idea if that really took as long as I think it did or not. Something you haven't mentioned, but is a pretty important point for me in any show, is the Music: I cannot remember any specific tracks from Dragon Ball or DBZ other than the first Japanese DB opening, whose instrumental version was occasionally used as BGM, as well as the obvious CHA-LA-HEAD-CHA-LA and We Gotta Power (or their respective German versions, anyway). That's unlike Naruto, which for me is the clear winner in this department. While I can't remember most of the track titles, Naruto had so many great BGMs that really set the tone of a given scene, getting you fired up for the unfolding battle, instilling a certain anxiety in you, making you melancholic or thoughful, etc., etc. Also, Naruto had some of the finest opening and ending themes ever - not necessarily the most impressive compositions, but very fitting and very memorable. And some of them even were a bit more - chock-full of Engrish or not, Akeboshi's Wind (ED 1) is a wonderful piece, similar goes for Sambomaster's Seishun Kyousoukyoku (OP 5). Yeah, I hope that made sense and wasn't too one-sided or whatever. It's late, I haven't seen either show in ages, so... yeah.

Uhm, an update of sorts, I guess - although I mainly want to say I haven't worked on this in a while, got distracted by WW/TP as one can probably see from the WW hacking thread. Do note that I am still reading this thread, have read your suggestions (here and in PMs), but don't yet have anything to say about them. I will keep them in mind, tho.

Freaking finally. Do note there still appears to be positioning glitches with certain models, but overall the skeletons are read and translated/rotated/scaled much, much better now. However, there's also still a big problem with most actor models apparently not loading correctly, which I haven't yet tried to figure out. I think it's obvious that something's wrong here...:

The only graphic problems I ever get with OoT - excluding the unfixed Debug ROM - is that the 8x8 debug text, ex. on the Map Select, shows up as garbage with some plugins or settings (Full TMEM emulation disabled, I believe?). Everything else is perfect, no matter which machine or reasonably modern plugin I use - my desktop (Radeon HD 5450 graphics), current laptop (Mobility Radeon HD 4570), even my old laptop (an ancient Mobility Radeon 7500). Your graphics chipset being the culprit is pretty much the only explanation left.

Also, one more thing I can think of related to DX and OGL: If all else fails, at least Rice in version 6.1.x should have one "Combiner Type" option for each. Try "For Low End Video Cards" or one of the "Limited x stage" options for DX or "OpenGL 1.4" or lower for OGL. This might help, but I can't say for sure; maybe those just make everything else worse.

.bck files - ID/type "J3D1 bck1", see first 8 bytes of .bmd/bdl and related files - probably contain animations, stored in an ANK1 chunk. That said, Wind Viewer C# is currently 100% broken, as I've been trying for two days to get the models' hierarchy to load and render correctly. Every model has a hierarchy, as simple as it may be, including the actual level maps, which is where the broken positioning of Outset Island in early screenshots/C builds came from. I got that "fixed" or "working" for part of Outset and maybe one or two more models, but everything else was garbage with level elements all over the place, let alone character models. I've been working with what's a somewhat simple hierarchy, the little crabs that run around the beach (Object\Kn.arc), but even after countless hours, I'm not much further: BMDview2 left, Wind Viewer C# right: You can kinda sorta with some imagination see a resemblance of a proper skeleton between karada and ashiL, but that's about it so far... I really hate skeletal systems. Who needs animation and shit when you can have something nice and permanent and static? /sarcasm

Nah, don't drop OoT just yet, hacking WW and TP effectively is still quite a while off. Viewing stuff might be possible somewhat easily by now, editing on the other hand is still a hex editor affair. That said, C# Wind Viewer has been improved some more, resulting in much less broken geometry or crashes (did I mention how annoying BMDs/BDLs are to work with?) and built-in RARC archive support - you can now simply open up a RARC file, Yaz0-compressed or not, the program reads its structure, and automatically renders all models it can find within. Each one can also be toggled on and off, which is useful for archives containing ex. item models, or for when there's still rendering or translation/rotation bugs:

Damn, that's quite an improvement over OoT's textures, isn't it? Anyway, as you might be able to guess, texture dumping is in and working. What's quite a problem, and the main reason why I'm not releasing this version yet, is crashes and broken geometry with many different models (E3 Outset Island, some of WW's items like the Hookshot, etc.). It often tries to read primitive data beyond the end of the chunk, which is of course a dumb thing to do... Not all previously untested models break it, tho:

Right, let's see, I mentioned rewriting the BMD parser, didn't I... I started rewriting it in C# as opposed to C. It's much cleaner already, but of course not yet on the level of its C incarnation, let alone BMDview2 - I'm about to get to SHP1 parsing, so that I'll see actual primitives again, and not just a bunch of gray points. And you know, considering this "language shift", it kinda seems like I'm mainly using C nowadays to prototype things, proof-of-concept-ish, while coding actual programs and such in C#. Anyway, Arcaith: Texture dumping will be the first thing I'll see about implementing when I get to dumping things, seeing how easy that should be. Models we'll see about, as it's not an immediate concern as mentioned above (especially now). EDIT: Time of day, 6:10 am. Reason for staying up: the C# BMD parser and renderer. Result: I think I deserve some sleep, all things considered: Finally my code's very close to BMDview2's visual quality

SanguinettiMods: I suppose it's slowly approaching an OZMAV2-like level, at least for WW (but only as TP's mostly untested). And I wouldn't rule out .obj dumping, but that's not an immediate concern for me right now - for now, improving/rewriting the BMD parser is more important, not to mention bugfixes and such. Sage of Mirrors: I think the level select menu doesn't have the unused dungeon rooms on it, but maybe the menu itself can be hacked to load them, ex. replacing one of the used rooms with a reference to an unused one, tho I'm not sure how. Edit: HA! Excuse my French, but fuck yeah!!

Alright, implemented texture wrapping, filtering (tho with somewhat broken mipmapping), blending modes, alpha compare and culling - again mostly thanks to BMDview2 -, some of which can be seen in the following screenshot: Not sure what I'll look into next - some texture coordinate glitches and fixing up the incorrect hierarchy usage (ignoring translation/rotation/scaling right now, which makes Outset Island's ground separate from its walls and houses -.-) - tho I really need to go over my awful code and rewrite it as well...

The position values are IEEE-754-style 32-bit (single-precision) floating-point values, where ex. 1.0 would be 0x3F800000. You can convert back and forth between their floating-point and hexadecimal representations using the calculators here: http://babbage.cs.qc.edu/IEEE-754/ Rotations are likely the same as OoT/MM's, signed 16-bit shorts from -32768/0x8000 to 32767/0x7FFF, which you can divide by ca. 182.0444444 to get their rotation in degrees. EDIT: An eternal struggle with several BMD files, some documentation on the file format and the BMDview2 source later... The randomly colored highlight in the first screenshot is the dzb file's collision, which TP doesn't appear to have (so no collision in the second shot) EDIT 2: http://magicstone.de/dzd/random/WWViewer_v002.rar (Win32 binary + source)

Huh, 0xBE? Here's how mine ended up: The green background is the inserted PLYR definition (0x0C bytes), the blue background is the actual PLYR data (0x20 bytes).

Looking at Siren's Room19's dzr myself now... Here's how it might (hopefully) work, step-by-step: - Go to offset 0x34, right at the end of the LBNK chunk definition, and insert 0xC bytes (0xFF for the moment) - The file's size increased from 0xA0 to 0xAC bytes, which is where we'll put our PLYR actor's data - Go to offset 0x0 and change the amount of chunks from 0x00000004 to 0x00000005 - Go back to offset 0x34 and enter the PLYR chunk's definition, overwriting the 0xFF's: "PLYR <0x00000001> <0x000000AC>" (0x504C5952 0x00000001 0x000000AC in all hex) - Go down to the end of the file (0xAC) and enter your PLYR actor's data (ex. take Room18's data from offset 0xC8 there, it's 0x20 bytes long) (- You'll likely need to adjust the player's coordinates so that he doesn't just spawn outside the room) ...and that should be it in terms of editing the file. ...and I just noticed you edited your post! Sneaky little fella Let's see... Yeah, you'll need to change the coordinates, otherwise Link will likely just fall to his death. And yep, noticed the exit as well, although I wasn't sure what SirenB was. So it's the boss room? That does sound interesting...

That should basically be it, yeah. At 0x000019AC I'd then put the PLYR actor's data, as per the description in the first post (0x20 bytes, starting with actor name, then parameters, then position, etc). As for 0x00000001, that's the number of <whatever>'s the chunk contains, so in this case, it would be one player actor, while with a normal ACTR chunk, you'd probably have something like 0x0000003A actors or whatever. Edit: Ah, too late, but good that you figured it out

Oh, "chunks" is what I call those PLYR, ACTR, etc. blocks, so the chunk definitions would be the list near the beginning of the file that has all those 4-letter descriptions, while the chunk data is what each definition points to. So basically, to try and add a player actor to the file, you'd need to add such a "PLYR chunk" to said list. Using E3 Outset Island as an example, its last chunk definition is at offset 0x28 and says "SCOB 0x00000001 0x00001974", thus ending at 0x34. Next, the file is currently 0x19A0 bytes long, so you'd need to insert "PLYR 0x00000001 0x000019AC" after the SCOB chunk - 0x19AC because "file length (0x19A0) + length of the new PLYR chunk (0x0C) = offset of your player actor data (0x19AC)". Now the file is 0x19AC bytes long; next thing to do is fix the other chunk definitions and add 0x0C to their pointers, so ex. "FILI <0x00000001> <0x00000034>" would become "FILI <0x00000001> <0x00000040>". I hope that helps somehow, it's a bit complicated and I'm not that great with explaining stuff.

fkualol: I suppose so: The DZR format is identical between the two games (plus eventual additional chunks that TP has and WW doesn't), but TP doesn't seem have DZB files? Also, the BMD parser and renderer is still junk. Well, that's probably obvious from the screenshot... Sage of Mirrors: If you can get the DZR back into the game - which I actually haven't tried yet at all - you could add one to the chunk count (offset 0x0, 4 bytes), add a PLYR chunk to the list (so "PLYR <player count, 4 bytes> <data offset, 4 bytes>"), add the actual player actor data to the end of the file, and fix the offsets in the other chunk definitions to accommodate for the added 12 bytes of the PLYR chunk (so ex. if SCLS was "SCLS 0x00000009 0x000000DC", make it "SCLS 0x00000009 0x000000E8"). Alternatively, see if there's a chunk you don't really need (tho that might be difficult, ex. I have no idea what's 100% needed by the game) and replace that one, along with its data, with your new PLYR chunk and data. EDIT: There we go, much better BMD support... Tho no materials, textures, matrices, joints, etc., etc., etc... Also, really messy code...

ZSaten by xdaniel and spinout (mips-eval, animation and hierarchy code)SM64toZ64 by xdaniel and spinout (scene and collision data generation)

Started writing a BMD model parser... That's supposed to be E3 Outset Island - pier in the lower right, the tower on the left, forest in the top right. Recognizable, but still a long way to go. EDIT, two hours later: Final Outset Island this time - much more recognizable, huh?

That's weird actually, seeing how any group with an alpha value that isn't 255 should be drawn after all opaque ones, otherwise the translucency might not work correctly. I'm also pretty sure I didn't change anything related to that recently. If I could use mesh type 2 the whole thing should/might be less of a problem, but I have no idea how to calculate the clipping coordinates needed for that. As for the other texture alpha channel glitches, I cannot say for sure. This is probably another problem with the rendering order, seeing how again alpha is involved. I'll try to experiment with this and see if I can come up with a concrete diagnosis and cure, so to speak... It might actually be a problem with the polygon type, see what the "Terrain Type" and "Environment" options are set to, and try setting them both to 0 if they aren't already.

The main thing I want on the 3DS in terms of hacks is a way to run import games. No matter if that means a flashcart and ROMs, a softmod solution or whatever else, I'd be all for it.