Users browsing this thread: 46 Guest(s)
(Another) Zelda Ripping Project!
I also tried the FinModelUtility, But I got nothing but silent failures with that too.
Reply
Thanked by:
Yup. Everything you said checks out. Something I've been dealing with as well. Encoding on Majora's Mask seems to be different and botched on a large portion of areas.
As well as something more unique of an issue.. Gomez. The Grim reaper boss from the Stone Temple, which is one of my favorite enemy designs.
Can't be extracted correctly either. Still to this day. Sad
Reply
Thanked by: JamesO2
(06-28-2022, 03:46 PM)Alvare Wrote: Yup. Everything you said checks out. Something I've been dealing with as well. Encoding on Majora's Mask seems to be different and botched on a large portion of areas.
As well as something more unique of an issue.. Gomez. The Grim reaper boss from the Stone Temple, which is one of my favorite enemy designs.
Can't be extracted correctly either. Still to this day. :(

Damn that sucks. The Gomez boss really was a stylish design.

So here's my question now: The encoding on certain MM3D files are botched... But the CMB Viewer program is able to open, display, and export all of the ZSI files that the CMB importer for Blender wasn't able to. Termina Field being the most obvious example.

CMB Viewer is definitely doing something to be able to get past the encoding issue. So it absolutely must be possible.

Hmm...

I just looked at the files again in HxD to see if I could find a pattern. The files that do open have a lot of "00" empty bytes in them, where as the Termina Field file doesn't. I also noticed that it starts with a header like this:

Code:
LzS��a���
� ��ZSI    ShUn�jenkins

The first letters being "LzS". And looking at the github page N3DSCmbViewer, noted at the bottom is this:

Quote:LZSS decompression code adapted from C++ code by ShimmerFairy
 
So I'm guessing that some of these files are compressed using this "LzSS" compression algorithm, and that explains the "LzS" header before the "ZSI". So CmbViewer is able to load these because it has code that is able to use LZSS to decompress these files first.

Compression would also explain the lack of empty "00" byes in those files. A quick search yields that LZSS is a common known compression algorithm: https://go-compression.github.io/algorithms/lzss/

The code that CMBViewer uses is here: https://github.com/xdanieldzd/N3DSCmbVie...er/LZSS.cs

I don't know C# well enough to do anything with that. I tried finding some stand-alone LZSS decompressors, but they just don't seem to exist -- any google search just led to sites like StackExchange where people were discussing implementations for LZSS in code. But nothing that's really "end user friendly."

I was able to find a few Python examples, but couldn't get them to run. And the PIP install for LZSS library failed for me for some reason.

---

(UPDATED: 2023-03-30)

It sucks that all of these tools each seem to be missing 1 or 2 vital components to make a single wholly functional tool. And they're all missing different parts of the puzzle.

Blender 2.79 CMB Importer: github.com/MeltyPlayer/OoT3D-Importer
  • Imports perfectly.
  • Preserves UVs, Vertex Colors, vertex alphas, bones, materials, everything.
  • Only works in a very specific older version of Blender 2.79.
  • Extracted texture files don't have ".png" extensions, which is a slight annoyance to work with.
  • EDIT: PNG issue above is only with an older version by MLG. Most recent version is by MeltyPlayer - make sure to use that version!
  • You have to manually separate the CMB from a ZSI file. Which is tedious. (sort of solved, see below)
  • It can't read compressed CMB/ZSI files. (sort of solved, see below)
  • There's no simple tool to just decompress a ZSI file.

JamesO2's ZSI Scene Decompressor: github.com/JamesO2x/Py-MM3D-LZSS-decompressor-to-CMB
  • I've created a tool that can decompress and extract ZSI files.
  • Works as of (2022-11-04) using Python 3.
  • Bulk converts ZSI scene files to CMB format, and also removes LZSS compression.
  • Works on "scene" files, probably doesn't work with "actors" (not tested)
  • Tested with MM3D and OoT3D
  • Does not convert models to FBX or other standard format, only to grezzo's CMB format.
  • So this Python script combined with the Blender 2.79 CMB Importer is now currently the best option for scene ripping.

Fin Model Utility: github.com/MeltyPlayer/FinModelUtility
  • Basically automates everything (extract RomFS, rip models, auto-converts them to FBX and GLTF)
  • Works with OoT3D, but I can't get it to work with MM3D at all.
  • Now works with MM3D
  • It seems to only convert the "actors" and completely ignore the "scenes" folder. So its only currently good for characters, not environments.
  • It automatically exports all the "actor" files into both an FBX and GLTF format. The FBX includes all animations too!
  • Can export models individually, or in bulk.

CMB Viewer (not recommended)
  • Simple to use, quickly load of ZSI files with one-click.
  • But the Collada export messes up the UVs badly, and doesn't apply bones correctly.
  • No options for other exports, or even just to extract CMB from ZSI files.
  • No batch/bulk converting process, so converting to Collada is tedious.
  • Blender's Collada importer is also pretty broken anyway, and doesn't import Vertex Alpha data properly.
  • This tool is no longer recommended.
  • Other tools work better now. But if you want a simple, quick, and dirty model rip (that lacks accuracy) then this is an OK tool.

---

Which is why I sorta just bodged together my own solution using a combination of tools and my own scripts. Specifically, I used:
  • My own Python script to bulk decompress the ZSI files into a CMB format: https:/github.com/JamesO2x/Py-MM3D-LZSS-decompressor-to-CMB
  • The MeltyPlayer blender 2.79 importer: https://github.com/MeltyPlayer/OoT3D-Importer
  • My own AHK script to bulk import CMB files using the above (because I could not figure out a way to automate this with Blender's python, likely due to how the addon was coded) and save them as 2.79 Blend files.
  • Appending the 2.79 Blend files into Blender 3.1, to take advantage of the newer tools and material features.
  • Export to whatever game engine/format you need.

In summation:
  • Fin Model Utility rips all the characters and their animations.
  • My hacky solution above rips all the scenes.

It seems like the Fin Model Utility is the only tool getting regular updates now. Eventually, I imagine it will be able to do everything.
Reply
Thanked by:
Quote:You have to manually separate the CMB from a ZSI file. Which is tedious.

...I don't find this frustrating or tedious at all. It is a common thing that each tool has it's advantage or drawback compared to one another.
The tools aren't build to be compatible with Majora's Mask to begin with, safe for N3DSCmbViewer.
Which was ultimately just meant to be used for extracting the archive and viewing the model.

Sure, having to hex-edit a header out of a file is time consuming, but easily done in a matter of seconds.
You skipped over Zar importer from Meltyplayer. https://github.com/MeltyPlayer/OoT3D-Importer. Which gets all actors and animations.
But, it has bone orientation problems due to Blender not doing it's calculations correctly. (Blender is kinda doing it's own thing with bone placement.)
You also skipped over the need to extract each actor's zsi archive to get the cmab file for mouths and eyes.

Quote:(Fin Model Utility) Works with OoT3D, but I can't get it to work with MM3D at all.

Well, if you looked and read the main page of the depository, you'd see the supported formats.

Quote:(Fin Model Utility) If something goes wrong in the middle of the process, no way to pick up where you left off. You have to run the whole process again.

That's a false statement.  When going through each zar actor, it can throw a detailed error and simply moves onto the next one in the list.

Quote:(N3DSCmbViewer) No options for other exports, or even just to extract CMB from ZSI files.

That's incorrect. You can click on Archive|Extract All to get everything instead of just converting to dae. This only works for .zar and .gar.lzs files with actors though.

Quote:(CMB Importer) Extracted texture files don't have ".png" extensions, which is a slight annoyance to work with.

Uhmm...? It does extract them correctly with png extension. There is however one particular instance in which if when an texture file shares the same name of the previous, the tool will put numbers behind the extension instead of behind the name. And that causes the extension to become unknown. But that's easily fixed with bulk_rename_utility or doing these few instances by hand.
Reply
Thanked by:
(06-29-2022, 12:03 AM)Alvare Wrote:
Quote:You have to manually separate the CMB from a ZSI file. Which is tedious.

...I don't find this frustrating or tedious at all. It is a common thing that each tool has it's advantage or drawback compared to one another.
The tools aren't build to be compatible with Majora's Mask to begin with, safe for N3DSCmbViewer.
Which was ultimately just meant to be used for extracting the archive and viewing the model.

Sure, having to hex-edit a header out of a file is time consuming, but easily done in a matter of seconds.
You skipped over Zar importer from Meltyplayer. https://github.com/MeltyPlayer/OoT3D-Importer. Which gets all actors and animations.
But, it has bone orientation problems due to Blender not doing it's calculations correctly. (Blender is kinda doing it's own thing with bone placement.)
You also skipped over the need to extract each actor's zsi archive to get the cmab file for mouths and eyes.

Quote:(Fin Model Utility) Works with OoT3D, but I can't get it to work with MM3D at all.

Well, if you looked and read the main page of the depository, you'd see the supported formats.

Quote:(Fin Model Utility) If something goes wrong in the middle of the process, no way to pick up where you left off. You have to run the whole process again.

That's a false statement.  When going through each zar actor, it can throw a detailed error and simply moves onto the next one in the list.

Quote:(N3DSCmbViewer) No options for other exports, or even just to extract CMB from ZSI files.

That's incorrect. You can right-click the main archive and fully extract it instead of converting to dae.

Quote:(CMB Importer) Extracted texture files don't have ".png" extensions, which is a slight annoyance to work with.

Uhmm...? It does extract them correctly with png extension. There is however one particular instance in which if when an texture file shares the same name of the previous, the tool will put numbers behind the extension instead of behind the name. And that causes the extension to become unknown. But that's easily fixed with bulk_rename_utility or doing these few instances by hand.

I feel like you took my list as some sort of disparaging comment against these utilities. To be clear, I was simply listing the roadblocks that I personally came up against with my specific goal of ripping just the maps from MM3D. That's all. They're all great tools for what they can do.

I'm not interested in the actors and animations for now, my main focus is on the maps. So anything you mentioned about the actors isn't really relevant right to me at the moment.

Yes, I'm aware that MM3D isn't listed on the Fin Model Utility github page as being compatible. I did read it. But again, my focus right now is specifically on the maps from MM3D, so I'm trying everything I possibly can. I had read on another forum that someone was able to get it to rip MM3D by changing a few settings with the OoT3D scripts, since both games have very similar RomFS file structures. but I wasn't able to get it to work for me.

When I ran the Fin Model Utility on the OoT CIA file, it only converted the Actors as FBX and GLTF, not the Scenes folder. It wasn't clear from the Readme that it would stop after just the actors. So I'm not sure if that's a bug, or if it was intended that way. I raised an issue on the Github asking for further clarification already.

As for N3DSCmbViewer, right-clicking any where within the program does nothing for me. The version I have is listed as "Experimental Cmb Viewer v0.2.6". I'm not sure if its the most recent version or not.

There is an "Archive" menu at the top, but its greyed out and unclickable. Not sure if that's what you're referring to by "You can right-click the main archive and fully extract it instead of converting to dae." But for me, the only option I have is to Dump as DAE format.

[Image: rgll225.png]

Is that option clickable for you?

There's 11 forks of this program, so I don't know if this is only an issue in the one I downloaded or not. I'm not sure which is the original, or most current version. It looks like most of the forks are just copies without any changes. Is this the original one? https://github.com/xdanieldzd/N3DSCmbViewer

I guess it doesn't matter much, since its 7 years old and not maintained anyway.

EDIT: I did some further testing. The "Archive" option is only available if you load an Actor file, and its disabled for Scene files. For scene's you can only use the Dump menu. This is even shown in screenshots on the Github (where the Archive menu is greyed-out with a Scene file open).

Quote:Uhmm...? It does extract them correctly with png extension. There is however one particular instance in which if when an texture file shares the same name of the previous, the tool will put numbers behind the extension instead of behind the name. And that causes the extension to become unknown. But that's easily fixed with bulk_rename_utility or doing these few instances by hand.

Yes, I installed the CMB importer add-on into the specific version of Blender 2.79 that you had previously linked in the thread. Upon importing a cmb file, the textures are loaded into Blender with only their Name (no .png), and when choosing the option within blender to "Make Files External" to unpack the PNG textures, they were saved to my computer simply as the the filename (kabe_01 for example, instead of kabe_01.png). The files were still correctly formatted as PNG, and I could open them in any art software. But the extension was omitted from the filename, meaning I couldn't double-click to open them, instead having to use "open with". All of the textures were saved like this, not just conflicting ones.

I just tested this with the ganon_7 cmb you mentioned before, with the circular rug. This could be a bug, possibly with blender, possibly with the addon. I would prefer you assume I am telling the truth, and not just incompetent.

The comment "Uhmm...? It does extract them correctly with png extension" comes off kind of presumptuousness/passive aggressive, and I don't appreciate that.

Here's screenshot of exactly what happens using one of the Scene files from MM3Very Sad

[Image: FXGZxpy.png]

The texture files are not named with their .png extension when unpacking from Blender 2.79. The file named "Sketchfab_UV_Checker.png" was a texture I added manually to a Cube in the same scene. When unpacking, this file did properly get named with its extension. So the problem is most likely with the Cmb Importer addon -- Its not adding the extension to the name upon import for some reason. Everything else about the addon works fine though, so its only a mild annoyance.

If its working for you and not me, then I don't know why. But I am absolutely not making false statements. These appear to be bugs (or incomplete features). Nothing I stated above is a falsehood or a lie. These are my direct experiences testing these softwares just today.

EDIT: It looks like there are multiple projects on Github with the name "Cmb Importer" for Blender, and I don't know if they are even related.

Are you using the one from MeltyPlayer here? https://github.com/MeltyPlayer/OoT3D-Importer

Because I think I may have installed this one here at some point: https://github.com/M-1-RLG/io_scene_cmb

I'll have to uninstall/reinstall the addon later to find out.

EDIT: Yep. The M-1-RLG is the original one (called Cmb Importer), and that one doesn't add the *.png to the textures. MeltyPlayer's version (OoT3D Importer) does. But confusingly, they both share the "io_scene_cmb" addon folder name, so you can't install both at once. I had already had the old one installed before finding this thread, and since both share the same Blender addon folder name, I assumed I had the "correct" one already because it's github is listed with 0 forks.
Reply
Thanked by: Kold-Virus
Quote:The comment "Uhmm...? It does extract them correctly with png extension" comes off kind of presumptuousness/passive aggressive, and I don't appreciate that.

That's not what I intended. I seriously feel encouraged to help you out.  Smile
So when I heard something didn't work exactly as on my pc I was literally confused like; "Uuhmm.. how? It should work correctly?..."
Might have worded that wrongly, but it's pretty funny to hear once more that I come across passive aggressive.
I've heard that on multiple occasions on different forums..  Ouch!

Quote:I feel like you took my list as some sort of disparaging comment against these utilities.

No, not at all. I felt no emotion whatsoever during the process of replying to you. I did disagree with some of the statements.
The archive extraction being disabled upon scenes is something you that you were correct about.
It's something I completely forgot about, but checked out right away after commenting.

I wanna say one more thing about N3DSCmbViewer, and that is that you should see the size difference between dae and fbx from cmb import into blender.
The dae files have some sort of fault in them that causes every node of the meshes to be duplicated in vertices. I mentioned this sometime ago on the models section, but I feel like I should tell everyone once more. It's really not good at all:

hairal_niwa_n zsi    320 kb original
hairal_niwa_n dae  498 kb 3dscmbviewer
hairal_niwa_n fbx   112 kb cmbimport

That is a huge difference. And this is on a small environment. Imagine this difference on an entire dungeon. Hell maybe using all of the files for larger projects. It'd get way too large.

Btw, I noticed you disabled file name extensions. I always leave that option on in windows explorer.
[Image: view-extension.jpg]

I really recommend bulk rename utility though. Takes a few seconds and can rename every extension as well as adding numbers at suffix or prefix of filename.

EDIT -
I took a look at my plugins for Blender 2.79 and noticed something strange. It's saying I'm using M-1's but I think I might have tricked my Blender.
The folders share the same name, but an older M-1 one is in appdata and the other in Blender install folder. xD
Doesn't matter though, the one from MeltyPlayer is the newer one. That is the one with both of the format support and forked from M-1's to further improve.
Now I now where the confusion came from. It's good to know you finally got the right tool. I'll update my previous post with the newer tool to prevent further confusion.

EDIT 2 -
Quote:There's 11 forks of this program, so I don't know if this is only an issue in the one I downloaded or not. I'm not sure which is the original, or most current version. It looks like most of the forks are just copies without any changes. Is this the original one? https://github.com/xdanieldzd/N3DSCmbViewer I guess it doesn't matter much, since its 7 years old and not maintained anyway.
Yes, like you say, these forks are all identical to xdanieldzd's. Probably accidentally forked by people not knowing what they were doing. And he quit the tool a long time ago.
I've heard him say on his YouTube channel that the people in this community were toxic. Constantly bothering him and asking him to continue working on it while he had nothing to gain from it.
Speaking of, I tried to be nice in helping you out. And you started calling me passive aggressive and my reply presumptuous. The latter of which is funny, because you assumed from me I knew which tool you used currently.

But hey, It's fine by me. Let's move on.  Smile
Reply
Thanked by: JamesO2
(06-29-2022, 07:20 AM)Alvare Wrote:
Quote:The comment "Uhmm...? It does extract them correctly with png extension" comes off kind of presumptuousness/passive aggressive, and I don't appreciate that.

That's not what I intended. I seriously feel encouraged to help you out.  Smile
So when I heard something didn't work exactly as on my pc I was literally confused like; "Uuhmm.. how? It should work correctly?..."
Might have worded that wrongly, but it's pretty funny to hear once more that I come across passive aggressive.
I've heard that on multiple occasions on different forums..  Ouch!

Quote:I feel like you took my list as some sort of disparaging comment against these utilities.

No, not at all. I felt no emotion whatsoever during the process of replying to you. I did disagree with some of the statements.
The archive extraction being disabled upon scenes is something you that you were correct about.
It's something I completely forgot about, but checked out right away after commenting.


Thanks for clearing that up. I must have misinterpreted your comment. I'm not upset about it, but I just wanted to be direct and address the matter in case there was an issue. Anyway, I'm sorry that you get that interpretation on other forums too. Sad



Quote:I wanna say one more thing about N3DSCmbViewer, and that is that you should see the size difference between dae and fbx from cmb import into blender.
The dae files have some sort of fault in them that causes every node of the meshes to be duplicated in vertices. I mentioned this sometime ago on the models section, but I feel like I should tell everyone once more. It's really not good at all:

hairal_niwa_n zsi    320 kb original
hairal_niwa_n dae  498 kb 3dscmbviewer
hairal_niwa_n fbx   112 kb cmbimport

That is a huge difference. And this is on a small environment. Imagine this difference on an entire dungeon. Hell maybe using all of the files for larger projects. I'd get way too large.


Good point, I noticed this too. One more little quirk to add to the list.



Fortunately, Blender has a really easy way to deal with this. You can select all objects of the scene, press TAB to go into edit mode, then select the menu option "Mesh ‣ Clean up ‣ Delete Loose". This should delete all of the duplicate vertices in the file.



Quote:Btw, I noticed you disabled file name extensions. I always leave that option on in windows explorer.
[Image: view-extension.jpg]


No, I have the filename extensions enabled in Windows. I always have this option on too. Re-read what I wrote, and check the image I posted again, you'll see that one of files does have a proper .png and the rest of them don't. This was definitely a weird issue with the M-1 version of the addon. I uninstalled the addon, and reinstalled the MeltyPlayer one, and textures were then packed/unpacked with the proper .png extensions.



Quote:I really recommend bulk rename utility though. Takes a few seconds and can rename every extension as well as adding numbers at suffix or prefix of filename.


Nice find. I'll check it out. Currently I use "Advanced Renamer" for bulk file name changing: https://www.advancedrenamer.com/



Both tools look like they have the same features basically, so its really down to personal choice. I like Advanced Renamer because it lets you toggle certain "methods" on or off, and even save presets. But I'll check out the one you mentioned for sure.



Quote:EDIT -
I took a look at my plugins for Blender 2.79 and noticed something strange. It's saying I'm using M-1's but I think I might have tricked my Blender.
The folders share the same name, but an older M-1 one is in appdata and the other in Blender install folder. xD
Doesn't matter though, the one from MeltyPlayer is the newer one. That is the one with both of the format support and forked from M-1's to further improve.
Now I now where the confusion came from. It's good to know you finally got the right tool. I'll update my previous post with the newer tool to prevent further confusion.
Haha, yeah I think I did the same thing. I had a version installed in AppData, and in the Blender install folder. I deleted both, and reinstalled the M-1 version by mistake, not knowing it was an "outdated" version. But when both were installed, it caused some weird issues too.



For clarity, I'm gonna refer to the MeltyPlayer version as "OoT3D Importer" from now on, since that's what the title of the Github says. Or maybe "MeltyPlayer's Cmb Blender Addon" or something like that.


Quote:EDIT 2 -
Quote:There's 11 forks of this program, so I don't know if this is only an issue in the one I downloaded or not. I'm not sure which is the original, or most current version. It looks like most of the forks are just copies without any changes. Is this the original one? https://github.com/xdanieldzd/N3DSCmbViewer I guess it doesn't matter much, since its 7 years old and not maintained anyway.
Yes, and these forks are all identical to xdanieldzd. Probably accidentally forked by people not knowing what they were doing. And he quit the tool a long time ago.
I've heard him say on his YouTube channel that the people in his community were toxic. Constantly bothering him and asking him to continue working on it while he had nothing to gain from it.
Speaking of, I tried to be nice in helping you out. And you started calling me passive aggressive and my reply presumptuous. The latter of which is funny, because you assumed from me I knew which tool you used currently.

But hey, It's fine by me. Let's move on.  Smile


LOL, this part I highlighted here is incredibly passive aggressive. You mention a 3rd party group of other people as toxic, then bring the subject back to me with "speaking of", which insinuates "speaking of toxic people" -- you are putting me in that category of "toxic people" without just directly saying it (passive). Then you follow up with "I tried to be nice" as if to imply I was the "not nice" person in the exchange. That's literally the definition of passive-aggressive behavior, and very uncool to do.



As an example, if I were to say "This group of people are rapists. Speaking of, lets also talk about your behavior." -- there is literally no way to interpret that as anything but a passive aggressive accusation. Like come on. You can't say something like that and then claim that you're the "nice" guy here.



With your last part, you were literally being passive aggressive, and then complaining about me "calling you passive aggressive" in the very next sentence. Come on man, have some self awareness.



Before this, I was willing to take your word in good faith and assume you had no ill intentions. But after that last part, its hard for me to tell what exactly you were trying to achieve. If your goal was to convince anyone that you're not behaving passive-aggressively, doing it in a passive aggressive way is a terrible way to do that achieve that goal. I'm still going to assume your intentions were good, but man that does not read well.

Earlier, I did not "start calling you passive aggressive" -- the direct quote of what I said was "comes off kind of presumptuousness/passive aggressive". The phrasing "comes off" here meaning "You may not have intended it this way, but it appears to be this way from an outside perspective". I was giving you the benefit of the doubt, assuming that wasn't your intention to come off that way, and also leaving room for myself to be wrong.



There's a huge difference between saying "you are passive aggressive" and "that thing you said comes off in a passive aggressive tone". One is a direct accusation, the other merely pointing out my observation of your phrasing.



I'm willing to admit 100% that my observation was wrong about your intentions, but the way you come off definitely reads as passive aggressive whether you intended to or not (especially your last paragraph). I just want to make you aware of that. If I'm not the first person you've heard that from, then there may be a hint of truth to what I'm saying and you might want to reflect on it later to avoid these issues in the future.



Anyway, to be 100% clear: I have nothing against you personally. I just want to clear up any misunderstandings. You've been a HUGE help in figuring a lot of this stuff out (especially the stuff about the vertex coloring a few pages back), and I really appreciate that. Thanks!



---



So about the different tools. I've come to realize that you're right about MeltyPlayer OoT3D Blender Importer -- it is definitely the most accurate ripping method (preserves UVs and Vertex RGBA, and imports bones correctly), and probably best method to use overall. My only issue is the LZSS/encoding issue, that it seems to just not be able to read some of the MM3D files. It works great on files it can read though. If that issue were fixed, it would basically be the perfect tool.
Reply
Thanked by: Alvare
Amen to that.
And you're welcome. It's good to know you actually appreciate the tools.
Reply
Thanked by: JamesO2
(06-29-2022, 01:30 PM)Alvare Wrote: Amen to that.
And you're welcome. It's good to know you actually appreciate the tools.

For sure, the tools are great for what they can do. I appreciate all the work rippers and hackers do. These people are at the forefront of archiving video game history.

All I am trying to do is accurately assess what each of these tools' limitations are. And maybe also collect that information all in one place so other people don't have to hunt down info across dozens of forums over the last decade just to find out.

Like the duplicate vertex issue with N3DSCmbViewer's DAE export you mentioned. I noticed that issue myself, but only after having already ripped dozens of models. This issue wasn't documented anywhere that I could find (until you mentioned it here) so it was only by total chance that I happened to notice that the Pirate Fortress had something like 6 million vertices, LOL. Then I checked other DAE files I dumped and noticed the same issue.

I was going to report the bug on the Github, but the Issues tab was removed there, so no one can properly document any new bugs. That means that anyone who uses the tool in the future also has to accidentally stumble upon the bug themselves (or stumble upon this forum thread) to even know it exists. Its a bit frustrating.

I don't mind that the tools have limits, but I would like to be able to know what those limits are and be able to report new ones. I understand that xdanieldzd doesn't want to maintain the tool, that's fine. But it would be nice to at least leave the Issues tab open for reports so other people can be aware. If the author doesn't want constant notifications for Issues, I'm pretty sure they can turn off notifications for just that in Github's settings.

---
EDIT:
I looked at the forks for the CmbViewer again, and it appears that one of them is 9 commits ahead of xdanieldzd's version.

NishaWolfe has made modifications recently to the program, and appears to be continuing its development with new features and bug fixes: https://github.com/NishaWolfe/N3DSCmbViewer

I haven't tried this version yet, but its good to know its getting improvements. I must have accidentally skipped over this one when checking the forks before. I wish Github made it more clear which forks were duplicates or which were ahead without having to manually check each one.

EDIT 2: I stand corrected: Github does have a tool to see which forks are ahead. Its in the "Insights > Network" tab: https://github.com/xdanieldzd/N3DSCmbViewer/network
Reply
Thanked by:
Hm.. interesting find. I'm curious to see what the differences between 026 and 027 are. I think I might've seen this one before but decided to stick with 026 for some reason.
Reply
Thanked by:
(06-29-2022, 04:26 PM)Alvare Wrote: Hm.. interesting find. I'm curious to see what the differences between 026 and 027 are. I think I might've seen this one before but decided to stick with 026 for some reason.

I'm not sure, I haven't tested it myself yet. You should be able to see a rough overview of the changes in the commit log: https://github.com/NishaWolfe/N3DSCmbVie...its/master

Here's a quick copy/paste summary:

Code:
NishaWolfe committed on Apr 12

+ Merge pull request #1 from NishaWolfe/scene_actor_info
+ added Z rotation round
+ Adjusted pos and rot to match COLLADA export
+ Updated version number
+ Added Scene Actor export
+ Added more actor details
+ Fixed formatting issue
+ Added basic build steps
+ Fixed for Visual Studio 2019

Looks like all the commits were on April 12.

If I get a chance to play with it later, I'll probably post any issues/improvements I find.
Reply
Thanked by:
I find dumping actor information isn't really anything of value for now.
Don't know what most of these names represent anyway and I much rather would go to the location in Citra or Noclip.website than trying to figure that out from some sort of list.
Reply
Thanked by:
(01-18-2016, 02:52 PM)JerseyXS97 Wrote: Hi i have looked all over for the korok statue you offer the apple to. if there is anyone that can help in getting me a OBJ of this model i need it for a project i am working on! hope to hear back from someone! i attached a image of the statue i am looking for. it is fairly common in the game and hopefully shouldnt be too hard to find. thanks everyone!
[Image: Central_Korok22_L.jpg]


This thread gained some traction, awww yea! Guy, TwiliChaos, and myself are ripping the models from all things Zelda. Currently in this thread are Ocarina of Time (3DS), Majora's Mask (3DS), and Twilight Princess (GC). A Link between Worlds (3DS) might be included in the future as well.



Ocarina of Time:


Majora's Mask:


Twilight Princess:


Breath of the Wild:
Reply
Thanked by:
Hello, I am looking for help to get a Collada file from Majoras Mask 3DS, and I think this place is the best place to ask as its activingly exporting the models.

I have been looking in this sheet about what has been extracted and whats next: https://docs.google.com/spreadsheets/d/1...=297092963

And the model I am after is "Inside the Moon - Tree Field", which according the sheet should have a Collada dump.
I know it has been done, but I have not been able to find it anywhere.
I tried to extract the model by myself, but I have not been successful with that either, so I would like some help with this.
Reply
Thanked by:
(10-29-2022, 11:49 AM)pikamaxi Wrote: Hello, I am looking for help to get a Collada file from Majoras Mask 3DS, and I think this place is the best place to ask as its activingly exporting the models.

I have been looking in this sheet about what has been extracted and whats next: https://docs.google.com/spreadsheets/d/1...=297092963

And the model I am after is "Inside the Moon - Tree Field", which according the sheet should have a Collada dump.
I know it has been done, but I have not been able to find it anywhere.
I tried to extract the model by myself, but I have not been successful with that either, so I would like some help with this.

Hi, I'm the author of that spreadsheet and also the one who has dumped the map files and converted them to a Blender format. Unfortunately I have had to put my ripping project on hold because I developed carpal tunnel syndrome in the middle of it. So I haven't been able to prepare the files into a "release" format, and thus I'm the only one who has them right now, which is why you can't find them anywhere.

I have all the files backed up in a Google Drive. If you want to PM me, I can give you the specific files you need.

In return, I would appreciate if you could maybe help me organize the files into a format so that they can be submitted to this site. Organizing would pretty much just contain minor adjustments to files/formats, folder organization, making thumbnails, and ZIPing them. Since having carpal tunnel, I am unable to use a computer for very long without pain and numbness, so I've just had this process on hold for months.

Anyway, PM me for details. I'll respond as soon as I can.
Reply
Thanked by: pikamaxi


Forum Jump: