(06-16-2022, 03:22 AM)Alvare Wrote: Nice job on obtaining Majora's Mask's files and getting the colors to look and work correctly.
You'll notice how some of MM's environments look more detailed than Oot3D's.

Btw, I didn't have the MM files for a while. Had it some time ago after searching for hours and found it somewhere in a YouTube comment.
Anyway, I have them again as well now, using the tools you mentioned. 
You need the original cia files without decryption and don't have weird folder / file names. Some extractors can't read " ' " symbols too.

I'm working on a pretty huge MM ripping project.

So far I've ripped just about every "exterior" area in the game and given them plain English names to make them easier to work with. I haven't started on interiors like shops and dungeons yet.



There are 318 "scene" models in the game. Some of them are just empty dummy files with a single triangle, and most of them are the game's dungeons (each room in a dungeon is exported to a separate DAE model).

I couldn't find any solid information for translations of all the filenames, so I had to load them all one-by-one myself to figure it out. I wrote it all down here for anyone else's convenience so they don't have to go through all that work:

• https://docs.google.com/spreadsheets/d/1...sp=sharing
  

Its a spreadsheet list of every area in the game, along with English names, grouped into categories roughly in the order you encounter these areas in the game.

I've set up my own naming convention and been tracking progress on what I have/haven't ripped, as well as notes about issues from ripping (like certain areas are missing textures, etc). The lines with green checkmarks are areas that I've dumped into DAE so far, and the yellow lines are ones that I haven't gotten to yet.

I also included a list of all the useful links, programs, etc that I collected from various threads. There's some notes about the ripping/converting process, but some of the notes are only useful to me specifically (or reference custom scripts I wrote). I'll make these scripts public eventually, but I frequently modify them so often that I wouldn't be able to keep track of changes.

I've written python scripts (for both inside Blender and outside of Blender) to help better organize things.

1. One is an auto-importer that lets you "one-click" import multiple DAE files all at once (such as all of the parts of a dungeon, or Clock Town, etc) and it even auto-sorts them into their own Collection and parents to an Empty.
   
2. A script to fix the "bones" (any objects that are out of place) positions using the CMB Viewer's TXT dump data.
   
3. A bunch of scripts for fixing the vertex color, applying water shaders, alpha textures for trees, etc.
   

If anyone wants a copy of a script, just message me.

EDIT: @Alvare - I did notice that the vertex alpha blending doesn't seem to be preserved when importing into Blender 3.0 -- which is really strange because this version of Blender definitely 100% does support vertex color alpha channel (I've used it in other projects before). So I'm not sure what is going wrong there, I'll have to investigate it further later. Its possible the data is still there in the Blend file, but I just need to figure out some specific node arrangement -- or its possible Blender 3.0 is just ignoring the alpha and not importing it from the start. Not sure.

JamesO2 Wrote:@Alvare - I did notice that the vertex alpha blending doesn't seem to be preserved when importing into Blender 3.0

Blender doesn't import them. There's a patch to fix it but it's not moving very quickly.

(06-20-2022, 05:19 PM)scurest Wrote:

JamesO2 Wrote:@Alvare - I did notice that the vertex alpha blending doesn't seem to be preserved when importing into Blender 3.0

Blender doesn't import them. There's a patch to fix it but it's not moving very quickly.

Ah, so it is an issue with the collada importer then. From what I do know of Blender, basically every feature, importer, etc, is internally handled as an "add-on" written in python. So it shouldn't be too difficult to modify the collada importer to support one extra vertex channel. I'll look into the patch you linked and see what I can figure out from it.

If its anything like any other add-ons I've modified before, patching is as simple as copy/pasting the relevant code snippet into the right py file.

EDIT: Dang, it looks like the collada mesh importer is code is written in c++, so it would have to be compiled into the main Blender program I assume. That's a bit beyond my scope of knowledge.

Its weird because most of the other importers are written as python add-ons (obj, fbx, stl, gltf, etc), and can even be disabled in preferences.

EDIT 2: Ok, so the collada importer is actually a strange case -- it basically is the only exporter/importer not written in python, and there's a whole article written on the Blender website on why this is a special case, and also why collada is weird in Blender, and why this c++ importer is a clunky approach. And apparently they've been wanting to replace the collada code entirely for some years now, but just no ones gotten around to doing it: https://code.blender.org/2016/10/the-collada-case/

EDIT 3: I looked a little further, and there was a python collada importer in development years ago here: https://github.com/skrat/bpycollada
And it looks like a relatively recent continuation (2.8+ compatible) was continued here: https://github.com/ldo/blender_pycollada_importexport

I haven't tested it yet, but I'm posting it here partly as a note to myself for later, and for anyone interested in testing it.

I agree with the naming convention change. The one of Oot3D is very solid and easy to understand, while Majora's Mask's one is a little convoluted.

Just wanted to mention this quickly before you continue any further. Make sure you rip the CMB file directly from the tools I included, not converting/exporting them to dae.
Because if you do, you're gonna get inaccurate uv's with Cmbviewer's .dae exports. It's been known to me that in multiple occasions, it overshoots the bounding box. (f.e. in Ganondorf's Castle ganon_7_info, the round carpet)
It's not noticeable at first, but when zooming in on the uv edges and comparing both, I saw seams on the dae counterparts that weren't there before in both noclip.website and on the newer tool exports.

As for the Blender not importing vertex color alpha, I simply suggest doing the cmb import work with 2.79a build and then loading the saved file from another Blender to continue working on it from there.

(06-27-2022, 11:46 PM)Alvare Wrote: Just wanted to mention this quickly before you continue any further. Make sure you rip the CMB file directly from the tools I included, not converting/exporting them to dae.
Because if you do, you're gonna get inaccurate uv's with Cmbviewer's .dae exports. It's been known to me that in multiple occasions, it overshoots the bounding box. (f.e. in Ganondorf's Castle ganon_7_info, the round carpet)

Noted. I checked the ganon file you mentioned, and I see the UV seam bleeding. Using the Blender 2.79 CMB importer, I see that that bleeding issue isn't there, and the UVs are slightly different than the DAE exported ones I was using before.

But I already have an issue: Is there a reliable ZSI to CMB converter? I tried the method you mentioned in a previous post (use HxD to delete the ZSI header part, before the CMB part), but so far I've noticed this doesn't work for all the files.

I was able to import the CMB for the ganon_7_info OoT file using this method. But when I attempted to do this for MM's Termina Field "z2_00keikoku_0_info.zsi" file, the Blender 2.79 importer failed to load it, with a bunch of errors. Specifically:


Oddly, I was able to import the other "Termina Field" models (z2_02keikoku_0_info.zsi, which appears to be a culled version used for cutscenes or something). Just not the main Termina Field file.

From the error, and also just looking at the file in HxD, the main Field map (z2_00keikoku_0_info.zsi) appears to be encoded differently. Beyond that, I don't know enough to move forward.

And I think this might be exactly why I just went with using "N3DSCmbViewer-026-unstable" because that's the only tool I was able to get to actually work, consistently. All my attempts at using other methods produced errors.

Quote:As for the Blender not importing vertex color alpha, I simply suggest doing the cmb import work with 2.79a build and then loading the saved file from another Blender to continue working on it from there.

This is really smart, thanks for the tip. My only issue is that I wasn't able to get the CMB importer to work consistently for all ZSI files I tried. If I can't import the Termina Field CMB, then I'm just kinda shit out of luck.

I just tried using the HxD method to convert a few more MM3D ZSI files to CMB, and about half of them won't load in Blender. Again, just looking at the files in HxD, they appear to be encoded differently.

For example, a file that looks like this seems to load fine:


But files that look like this, won't load:


I'm sure its possible to convert the encoding, but I have no idea how. I can tell that the patterns are different, but that's all I know. I don't know what to do next.

I also tried the FinModelUtility, But I got nothing but silent failures with that too.

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.

(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:


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.

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.

(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.



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 MM3



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.

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. 
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.. 

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.


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. 

(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. 
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.. 

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.

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.

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. 

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.

Amen to that.
And you're welcome. It's good to know you actually appreciate the tools.

(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

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.