Users browsing this thread: 1 Guest(s)
STM's Xenoblade resources
#1
EDIT: I'm moving this to this page on the VGR wiki instead. The text is left here for now but it will be a bit out of date.



If you've ever downloaded one of my Xenoblade model submissions, you've seen an included README file intended to help guide you through the trickier parts. But it's become very inconvenient to update each one of those submissions every time I discover the README needs an update, addition, or fix. So instead, those README files will now link to this thread, which I can update much more easily.

The first disclaimer

I'm posting this before updating any of my existing submissions (so I can put the link to here in their READMEs). If you download a thing and only get a .dae, you know it's not yet updated, because I have to add an .fbx (.dae doesn't seem to support custom normals). In that case, you should probably rely on only its READEME instead of this one.

The general disclaimer

I view tMR as a "casual-friendly" site - people don't need to know anything technical about whatever game they're looking for, they can just grab the model and be on their way. Because of this, my submissions make some minor changes to make the model more suitable for easy consumption, such as renaming bones like "hair_L_00" to be "hair_00_L" so they naturally mirror properly, or a face shape from "mouth_subomu" to "mouth_pursed" so people understand what it means without knowing the Japanese word. And sometimes, this also means making minor corrections to obvious mistakes, such as hair strands parented to the wrong side of the face, or mesh triangles that are part of the wrong object. If you're interested in a more "raw" representation, you're probably better off getting the tools and doing some ripping yourself. (Shameless plug: Monado Forge is what I use for my stuff, because I wrote it myself to get around problems that the other current things have.)

Things to know about these submissions in general
  • These models tend to have a lot of "endpoints" - bones in the skeleton used not for animation, but as reference points for HUD elements, special effects, and so on. You might have to do some hiding of the ones you aren't interested in.
  • Some programs can't handle importing models with more than one UV map, so I have to include side-models with only one UV each. These files have "splitUVs" in the name.
  • Similarly, there's also an extra "faceshapes" file that contains every morph shape as its own object, in case your importer can't handle that either.
  • Attachments (e.g. weapons) need to be parented to the root of the bone, not the tip.

Things to know about both versions of XC1 (XC1, XC1DE)
  • Most of the time, alt colour textures have the same name as the "base" version, but sometimes, they're named independently. That is, maybe the model pc267502 has its textures named as if the model is pc260502, but pc267501's are actually called pc267501. I've changed all such names to be consistent, so everything in an alt folder matches name with what it replaces.
  • Major characters have two types of faces. (Unless they're a Nopon.) There's the low-quality face, which is part of the head model, with three texture-based blink states and a single facial bone (jaw). Then there's the highly-detailed face, which is a separate model that replaces the LQF for pre-timed cutscenes, with texture sliding for eye movement and several bones for facial features.

Things to know about XCX
  • I don't have anything to put here yet. Maybe eventually...

Things to know about all Switch entries (XC2, XC1DE, XC3)
  • Many greyscale textures are channellized and combined into a single texture that's usually called "temp0000" (or temp0001, temp0002, etc). Most commonly, this holds the gloss map and metal map. Sometimes the AO map and emit map are also included. Other times, if two different colour textures have the same size, their matching channelled textures might share a temp file (e.g. maybe the red and green are for material 1 but the blue is for material 2). I should have left a note in the model's individual README of what belongs where if it isn't pretty standard. If it's really bad/confusing I might just split them out entirely.
  • Most skin materials are supposed to have an outline. However, at this time there's very little knowledge on how this data is stored or used, and I have no idea how it'd even be exportable into a submission. So you're basically on your own for this one.
  • Face meshes have fairly skewed custom normals. This is used as part of getting the "flat" look. Unfortunately, it also makes the terminator problem extremely blatant if you ever try to use raytraced shadows.

Things to know about XC2
  • With regards to temp0000 files, usually the gloss map is red, the AO map is green, and the metal map is blue.
  • Normal maps are stored in the game without a blue channel. This saves space because you can just calculate the blue from the red and green, but your 3D program probably isn't actually expecting to have to do this. Therefore, my submissions include a version with the correct blue channel added. (Later games use a newer fancier format that includes the blue channel without taking up any more space.)

Things to know about XC1DE
  • With regards to temp0000 files, usually the gloss map is red and the metal map is green.
  • Most things in XC1DE don't have AO maps - usually only the models that were made from scratch do.
  • The "modern" heavy armour textures tend to be named identically to their "legacy" equivalents, with pc012701 being called pc010701 and so on. I chose to rename all of these to their pc012701 form to eliminate confusion.

Things to know about XC3
  • All texture filenames in XC3 are hashed. Basically, they took the name and mathed it into a unique number so they're faster to find. It's possible to get the original name back, but it's so much of a hassle that it isn't really worth it for texture names, so all the images will be named "7a54db24" and such.
Reply
Thanked by: dhi_holo


Forum Jump: