Thursday, August 25, 2011

Intermediate Guide to SF4 EMG (Model) Swapping

Sloth86 has cracked model manipulation in SF4 wide open. It's now possible to swap models from character to character and costume to costume in a fairly consistent manner, thanks to sloth86's research. Additionally, he was nice enough to write simple, straightforward graphical tools that extend this ability to almost anyone. Just to be clear, though: this procedure often produces strange results, especially with respect to animations. Sometimes these results can be fixed through model editing, sometimes not.

In this tutorial, we're going to use sloth86's methods to take an EMG model from one character and replace it with an EMG model from another character.

First things first, lets get all of the tools we'll need. This is a pretty advanced procedure, so we're going to need piecemontee's SF4Viewer (aka, Asset Explorer), Kensou's Tool(s) and Sloth's tools, specifically, EMGSwap and DDSREFEDIT. Once you have those tools downloaded and organized, we're ready to get started.

First, identify which model you want to move and where you want to put it. I'm planning to take Guy's head (donor model) and place it on Ryu's body (recipient model).

Once you've got it all planned out, open both models (for me, GUY_01.obj.emo and RYU_01.obj.emo) in the Asset Explorer and find the desired objects--in my case Guy's 8th EMG (counting each model, starting from the top in the Asset Explorer's display)--and I'm going to replace Ryu's 12th EMG. The recipient's numbers are important, so write it/them down.
Now, select the donor object, right-click and choose 'Raw dump,' name it something informative (I chose face.emg) and click 'save.'
Next, armed with our model files and numbers, place both the donor *.emg file and recipient *.obj.emo file into the same directory as EMGSwap and double-click on EMGSwap to run it.

This window should pop up:
In the field labeled "Input EMO file," type the name of the recipient model, in my case RYU_01.obj.emo. Then, in the field labeled "EMG # to swap out," type the number of the recipient model you wish to replace, in my case 12 (for Ryu's 12th EMG model, the face). Next, in the field labeled "EMG file to swap in," type in the name of our raw-dumped donor model, in my case face.emg. Finally, in the field labeled "Output EMO file," we'll just leave the default 'new.emo' for now (we'll rename it to replace the old model later, but in the meantime, we don't want to mess anything up before we're sure it's cool).
Click 'Go' and cross your fingers. If all goes well, you should see a window like this pop up:
Looks good so far.

Now, lets check out our Frankenstein's monster by opening the 'new.emo' file in the Asset Explorer:
Yeesh, looks pretty freaky. Since Guy's head was sized and positioned significantly differently from Ryu's, we're going to have to change some things up to make it look normal again.

So, still in the Asset Explorer, lets select our newly imported model, right-click and choose 'Extract...' from the menu. Name it something informative--like face.obj--and click 'save.'
At this point, you might be asking yourself, "if I'm extracting and converting into an obj anyway, why didn't I just export from Guy's model and import straight into Ryu's model in the Asset Explorer, skipping all this EMGSwap bullshit?" Well, smarty-pants, most files in AE (including the *.obj.emo files we're messing with right now) include an index that includes the location and size of each and every file contained within. The Asset Explorer uses this index to determine what can and can't be extracted/injected safely.

However, sloth86's EMGSwap tool rewrites this index for us, so the Asset Explorer can safely extract/inject our borrowed models once EMGSwap has done its thing. Perhaps someday that same functionality will be integrated directly into the Asset Explorer (it's open source, after all), but that day is not today.

Anyway, so we've gotten our model swapped in, but it looks like crap and we'll need to use model editing to fix it. I'm not going to spend a lot of time on this part, since you should already know about model editing enough to fix things yourself. For me, Guy's head was the wrong size, so I needed to enlarge it and move it around a bit. I really should edit Ryu's neck to meet the head, too, but you get the idea...
Alright, with my edits in place, the model looks okay, but you'll notice that the skin looks all white and pasty. That's because it's looking to Ryu's first DDS texture, which corresponds to--you guessed it--his duffel bag. This is actually convenient for my purposes, since I can just replace the duffel texture with my donor texture. Thus, I won't need to edit a bunch of DDS references using sloth86's DDSREFEDIT tool, but you probably will (hence, why I included it in the tools you'd need to download).

I'm only going to use it a little, but I'll try to tell you more about it when the time comes.

In the meantime, we need to create some new texture and normal map containers to go with our new model. To do it, we'll use Kensou's sf4tool, just like in this earlier tutorial I made.

Open your donor's *.col.emb and *.nml.emb files in the Asset Explorer, find the textures that correspond to your donated model, right-click and choose to 'Extract...' them. Name them something informative (I used '' and '') and click 'save.'

Next, open your recipient's *.col.emb and *.nml.emb files in the Asset Explorer an extract *ALL* of his or her DDS textures. Be sure to name them something informative so you can remember which order they're stored (,, etc. and,, etc. work well).

Now, as per the aforementioned tutorial, create new *.col.emb and *.nml.emb files with your donated textures in the first position. (I actually replaced my recipient's first textures, so the order for mine was,, etc. and,, etc.) EDIT: I used the first position, but apparently the *last* position is more likely to work...?
At this point, you would run the DDSREFEDIT tool and input the number '0' into the 'new texture map' field and '1' into the 'new normal map' fields (assuming your recipient only had a single texture to begin with; this isn't the case with shoto original costumes, though, so count the textures if you need to, according to the instructions in the program; I had to use '5' for the normal map number), your modified *.obj.emo file in the 'Input EMO file' field, and the number of your recipient's replaced model in the EMG # field (in my case, it was '12'). You would then check the box for '+1 to every other normal map references' (this last bit was unnecessary for me because I replaced the duffel bag normal map with the donated normal map).

This was my result:
Anyway, if this last part seems confusing, don't worry about it. I'll be making another tutorial that goes over the texture reassignment tool using a more typical example in the future. In the meantime, try your best, share your work and ALWAYS MAKE BACKUPS.


Anonymous said...

My name is Gosha, i`amfrom Russia.
I want ask you some questions:
1)How to create lighting, invisible texture?
2)How change Akuma`s (a.k.a Gouki) hair to Ruy`s hair, for example)?
3)How to create normal texture for character?
Thank you for your comment :)

Anonymous said...

Hello Hunter

I was able to follow you right up until: "Now, as per the aforementioned tutorial, create new *.col.emb and *.nml.emb files with your donated textures in the first position. (I actually replaced my recipient's first textures, so the order for mine was,, etc. and,, etc.) EDIT: I used the first position, but apparently the *last* position is more likely to work...?"
On this point when you replace the recipients first textures ( I assume), what do you replace them with, the '' and why? I just renamed everything in order without replacing anything though, but my main issue here is that i am not able to grasp this in principle. I need to know what the ddsrefedit ACUTALLY does, like how does it tell Asset manager to place the rest of the textures in order using the single reference ('12emg' with the 0 and 6th texture). from the results I am getting It's always that I get one body part right, and the rest of the bodies textures get screwed up, so i don't know where I went wrong, might be the ordering from when I was in Kensou's tools maybe?
Did you ever get around to doing that tutorial on the texture reassignment tool?
Thanks. I'll just try to troubleshoot my problems in the meantime

Hunter K. said...

Heh, no, never did. And it's probably a good thing because DDSRefEdit has always been a problem for me. Honestly, I should probably rewrite this tutorial whole now that I'm more used to the process and sloth86's tools are a bit more mature.

Anyway, the concept is pretty simple: you swap in a model from somewhere else, add its textures at the end of the EMB, then use DDSRefEdit on the new model to point it at the new location (otherwise, it still points at whatever its original EMB's texture location was).

Kensou's Tool can be confusing. It puts your textures in exactly the order that they're listed in the little window; i.e, if you have them named,, etc., it bundles them in the reverse order by default >.< Knowing that, you can either number them in reverse order or you can edit the bundling order right in that little window (you can click into it and edit the text).

Hopefully that makes sense.

Anonymous said...

Dear Lord ><

After a little tinkering i was finally able to get the textures into the game. my only problem now are the normal maps. I managed to find this screenshot on the web, which cleared a few cobwebs for me:

onething I wonder is, if both the textures and the normal maps are bundled together under one emb, when I re-import this newly packed emb, what do I name it, col.emb or nml.emb. And would the game know that both textures and normal maps are indexed under one emb?

Hunter K. said...

Congrats on the progress. I know it can be frustrating...

That's just a difference between SFxT and SSF4AE: in AE, diffuse (i.e., color) maps are in the col bundles and normal maps are in the nml bundles. SFxT puts them all in one file. The ordering and reference numbers should be the same across games.

Anonymous said...

ah, okay. I have 2 more questions I think then I think I can be out of your hair.
Is there any special care or another procedure that needs to be taken when working with cloth, especially ones with loose hanging bits, because when I use this way of exporting, the cloth ends up flickering all around the bottom of the screen

Hunter K. said...

Yeah, anything that has movement needs bones to impart that movement. If the bone guessing goes awry, you'll end up with the kind of behavior you described. The best option for those parts is usually to make them transparent using col/alpha-based transparency for the parts that jump around. If that isn't possible for whatever reason, you may have to play around with skelswap to bring the bones over from the donor EMO, though that brings problems of its own. khaledantar666's tutorial here, while sparse, might be helpful:

Hunter K. said...

Of course, if you're up to it, you can export the misbehaving model as an SMD and manually fix the rigging in Blender.

Anonymous said...

I actually found something
(dear God, Sloth is a freakin genius). This is actually more suited to for my purposes.
I tried the skeleton swap but the cloth still flickered, and Ryu was now doing the splits out of nowhere cos it applied it to the entire skeleton.
So I was able to transfer clothes onto other characters using EMG swap v3, and they follow quite well and don't flicker so long as i use the 'bone matching' option. Only problem now is the clothes (though they are in place
) are rigid, static and don't flow. I'm not sure if this is a tall order but, if 3d software can read the weight painted on models, can it also read what cloth simulators were used on the clothes?

Hunter K. said...

Ah, yeah, EMGSwap v3 is definitely the one to use. I was under the impression you were using it all along. :O

SF4 engine doesn't actually do any kind of physics simulation. It's all faked/simplified motion intended to give the appearance of physics, controlled by some stuff in the *.bsr files. This info is assigned on a bone-by-bone basis. If you can manually rig models, you can attach anything to one of those faux-physics bones and it will gain that same motion behavior.

Likewise, if you take a model that depends on those bones and move it to a model that doesn't have them, it'll be stuck motionless, as you described. Does that make sense?

Anonymous said...

It does... so if I for instance took Ryu's head band, placed it on guy's head, without the info from Ryu's bones and *.bsr it will remain motionless. I see now why you suggested skeleton swap. Skeleton swap seems way too dangerous though so I'd like to take up your advise to "export the misbehaving model as an SMD and manually fix the rigging in Blender.". By the way I opened some *.bsr documents in the hex editor and I can definately see what you are talking about, the information definitely is there. I'm not very good at hex editing, but I'm actually kinda relieved none the less that the info is visible.
I don't know if the solution I have in my head is a fairy tale but here goes anyway. If say Ryu's headband is attached to one of Ryu's head bones, with all the information in it. Would I be able to see this info in the 3d software if I were to have the bones and the head band opened? Because IF I could, should I decide to EMGSWAP the head band into, say Guys mesh, one would think I would be able to copy this information into Guy's bones? Am I even close ><?

Hunter K. said...

Unfortunately, you can't swap individual bones, only entire skeletons. So, for your example, you would have to do an entire skeleton swap, which includes swapping bsr files to get the motion.

Sloth86 was working on combining skeletons and bsr files to give a character the bones and motion from both skeletons (I believe his SSF2 ending costume for Chun Li for SFxT used this technique), but he never released a tool to do it.

I've tried renaming bsr bones in hex but never had any real luck with it. I assume it has the same kind of interdependent index references, etc. that EMOs have, so by changing the name, I probably threw off a bunch of other things...

Anonymous said...

I guess cloth is as far as this swapping thing goes then ><'.

As for that last question, When I EMGSWAP, sometimes I need to retain the transparency in some things, but I don't see the original material properties in the emm files

Hunter K. said...

Right. You've got 2 options there: Modify the EMM(s) with EMMEdit to create a new section for your copied model (you can usually copy/paste it from the donor model; if not, they're pretty easy to make from scratch) and then check the box to 'export count to EMO' or whatever; or you can hex edit the EMO to make the swapped model have the same name as an existing object with the properties you want.

Anonymous said...

By some miracle I actually managed it through hex editing the *.emo :0.
But I would like to learn the EMMEDIT because I really suck at hex editing.
The duplicate material function is pretty neat but how do I assign that newly created material to the imported emg?

Hunter K. said...

That part is actually really easy. After you duplicate it, click the bubble in the main window to switch to that duplicated material, then change the 'Material Name' down in the bottom left window to match your imported EMG. Click 'Rename,' then, back in the main window, click 'Export Mat Count to EMO' (because the number of materials needs to match the number of EMGs in your EMO), and then click 'Save' to write your changes to the EMM.

Anonymous said...

OKAY! Wow, I mean holy crap dude, you have really really helped me a lot here bro o.0". Forever indebted.

Hunter K. said...

NP. Glad I could help. :)

Anonymous said...

I'd already asked over at shoryuken boards but to no avail. I am trying to swap Hakan's hat into Gen's model but the game keeps crashing for some reason. This would be the second thing I've imported into the model as I had already imported another character's hair successfully. It just crashes wit the hat. For future reference, do you know the likely reasons for a game to crash after a swap and where would I start preventing or troubleshooting these problems?

Hunter K. said...

Hey, sorry, I meant to answer you there but forgot to. The main causes for crashy swaps are skeleton problems (e.g., the hat is rigged to a bone that doesn't exist), bsr problems (again, references to bones that don't exist), and EMM/model discrepancies (usually, model isn't listed in the EMM at all).

The EMM thing is the first place I'd check.

Hunter K. said...

Oh yeah, col.emb texture reference problems are also common (i.e., hat looks for DDS #2 but that texture doesn't exist).

Anonymous said...

Got it, it was the missing dds causing the crash...
one more thing,on ddsrefedit, usually when assigning textures and normal maps I have to literally assign each texture and mmap one one to each emg. But whenever I tick the '+1 nmap' box it crashes the game, do you have any idea why his might happen?

njgamer69 said...

can you make a video about this

Analytics Tracking Footer