Hey, quick question: I came in contact with someone who uploaded the SSBB models to Models Resource, and was told that he used BrawlBox to extract the models and textures, and they were automatically UV Mapped. However, when I exported a model from Brawlbox as a .DAE file, and the textures as .PNG's, the model isn't UV mapped despite the material already having the textures listed. Which version of BrawlBox exports the UV Mapping? I'm using v.0.77
Are you using Max or Blender? Because I export as .dae from BrawlBox .71, convert it to .fbx, and import it to Blender and the UVs are fine. (Importing the .dae to Blender also works, but then when you attempt the importing process of export-as-fbx-convert-to-dae-import-dae-to-Brawlbox, there's a glitch with the right side of the model; only the right side, which is even weirder O_O ) But yeah, try BrawlBox .71 and see if that exports the UVs properly. Since it works fine for Blender, I'm fairly sure that it should also work for Max. Post Merge: February 24, 2017, 08:53:17 AM
You might notice that this version is in a bigger .zip file and has a new directory structure. This is because it now supports python plugins! I have a couple I'm going to make and post in another thread.
Please test this version out and post here if there are any regressions from v0.77.
So, what's the changelog for this version? Because there were four very annoying glitches that persisted in 0.77 and 0.76, one of which was only glitchy in those versions and NOT a glitch in previous versions.
The glitch that was not in previous versions but is in the newer ones is the most annoying, and that is that if you attempt translating vertices that are rigged to more than one bone, they don't translate properly. The vertices will explode, moving all in different directions, and then if you press Ctrl+Z it doesn't even undo it properly. And you can't translate them back, either; they can ONLY move away from the model. And attempting to scale vertices will also cause this same glitch.
The second glitch would be that some models(I don't know what causes this, but it happens with some models), if you attempt to re-rig something 100% to one bone that it's rigged to(For example, if a head is rigged to the HeadN bone and the NeckN bone, and you want to rig it 100% to the HeadN bone), you can use the +'s and -'s fine, that won't do anything(Except that, because the other bones in the list are still in the list, glitch number one will still happen); but, if you attempt to write in the value 100 in the top box for the weight, it WILL look fine in BrawlBox, but the model will get destroyed in-game, although I can't say for sure if it's the UVs, the materials, the shaders, or a combination. The model will end up rigged perfectly fine, but it will look really weird. Two examples that happened to me are in the spoiler below.
Sometimes, in the preview window, (This particular glitch didn't happen in earlier versions, btw) certain models will turn either green, blue, or black, kind of randomly. I'm not certain as to what causes this, but based on how it happened to any of my "No Purplish Tint Sonic" models, where I edited the materials and also removed the color nodes, I think it has something to do with the color nodes.
Another glitch is that sometimes(Not always, but it is rather common), if you re-rig vertices, and then save and exit, if you re-open, the vertices that you re-rigged will be in different, randomized locations, but the model looked fine before. Fixing it, the only way to fix it is, in itself annoying, because you have to get out of the Weight Editor, unselect everything, then select the vertices that you re-weighed, translate them somewhere else, then translate them back. If you do this, when you save, exit, and re-open, they're fine, but this is really annoying, especially since it could cause the other glitch, if, when rigging, you don't rig everything to one bone.
There's this fifth glitch too, but I don't find it very annoying, because you can just use version 0.71 and it works fine, glitch-free. But in the later version of .76 or .77, if you use the Add New Object button or whatever it's called, with the same settings as in .71, the entire model will get messed up.
P.S. Now that Blender importing is literally perfect, these glitches aren't necessary to fix, but they still are annoying glitches, and I would like them to be fixed, if possible.
So, even though I fixed it by doing it a different way, it did happen to the Groose model that I used here(If you need to, I can provide the DL): http://i.imgur.com/19BUyLe.png
And here, in this different model(An edited Eevee model), you can definitely see what it did to the body:
No, haven't even resumed yet, been too busy; but, I have been having Kienamaru teach me a little about PSA I'm so ecstatic that he's teaching me this stuff!
Anyhow, there will 100% be an official Brawl Vault update(As well as a tutorial update) in the summer, directly after I finish the semester. There's also a chance that I could be able to do it before the semester ends, depending on how busy I am, but usually I have loads of extra time during the end of the semester, whereas in the beginning, I'm working crazily busy, and I'm almost halfway, and decreasing in how crazily I'm working, so it will probably be in a week or two that I'll resume, and then another few weeks until I complete the update.
Unfortunately, I don't do full character import requests. If you're interested in learning how to import him yourself, though, you can check out my Blender tutorial.(Btw, I'm currently working on remaking this tutorial from scratch so that it's more organized and much easier to follow)
Just saying, but the TopN visibility bone is always visible, so if you do want to have two models use the same outfit or something, you could have only the head and/or accessories, like if he had extra stuff on his jacket when he's an adult or something, have only these things triggered to a visibility bone, i.e. model changer, and the rest just as TopN. And if the size thing is a big issue, you could use the character switcher code that Samus/ZSamus, Zelda/Sheik, Wario/Warioman, and Bowser/GigaBowser use, to have an adult version in one .pcs, and a one-slot resize kid version in the other .pcs, and you could still use the visibility bones to make alternate versions per each of those two .pcs files, meaning that you would have twice as many options as you would have had (Without freezing the game), and you can, in addition, also have the two different sizes. Post Merge: February 10, 2017, 08:05:19 PMBut that's just my say/opinion.
Use sc_secharacter.pac in PF/menu2 its the same file as in common5.
But, use the latest version of BrawlBox. For Project M 3.6, they encoded the .pac file differently, so the latest version of BrawlBox is needed to see anything other than it appearing to be empty. I know, because I actually ran into this before, and then I found out that you just need to use the latest version of BrawlBox and just look at this separate file for 3.6. For more details, click here. Post Merge: February 10, 2017, 09:46:07 AMI dunno. When you say that you replaced the icons, did you replace the CSSs(These will have colored backgrounds; in vanilla Brawl, they're blue backgrounds, in Project M, they're purple backgrounds, etc.), CSPs(They will have transparent backgrounds, which'll look like checkerboards in BrawlBox), and Stock Icons in the sc_selcharacter? If so, you should be fine on all regular icons, with the exception of BP icons, which are in pf->info->portrite, as individual files per portrait. And in case you're wondering what each of these abbreviations is:
CSS: Character Select Screen - This is the miniature icon in the character select screen, where you click on the box to select that particular character CSP: Character Select Portrait - These are the different "skins" or "palette swaps" you can swap between after selecting a character Stock Icon: Pretty sure you know what these are BP: Battle Portrait - These are the portraits of the characters that appear in-game next to your health