Ladies and Gents:

These forums are now closed and registration disabled.

Please join us at our new forum on Proboards. Our hope is that these new forums are more stable, provide more and better features, and allow continuation of the project forums in a safer, more secure, long term environment.


--The ME3Explorer Team

Research | Animcutscenes + Matinee Editing

Semi-technical area to discuss content modding research and discoveries. Technical information necessary for coding tools should be posted in Technical Research on the Coders board.

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 28 Feb 2015, 23:52

So, I'm researching how to fix "floating Shepard and Kelly" during her Citadel convos (BioD_CitHub_UnderbellyP2_LOC_INT.pcc). Basically, I can approach this problem in 2 ways: change the FOV of the camera so their feet don't show, or, adjust their model locations so they are actually on the floor.

1. FOV -- After researching the FloatTracks (FOV) in the LOC_INT file, I was confused. From watching the dialogue, I could detect at least 5 different FOVs used during the conversation: full-height, knee-up, waist-up, chest-up, neck-up1, and neck-up2 (a bit closer). Yet, there were only 4 Float Tracks that specified 2 different FOVs (35 and 50), and these didn't define any camera.

And...then I looked in the main PCC and found this object:

203: BioStage_CitHub_Und.ST_citund_kelly_phase2_d

And what do I see when I inspect?


There are 8 cameras listed in this object. Each camera has a different FOV + DOF combination and has a name. BUT, all names are not unique -- which is interesting. I'm still researching, but this is the exact type of list I've been looking for in the LOC_INT.pcc. This list makes complete sense and appears nowhere in the Camera Editor.

I haven't get tested if changing the FOV here will change it for every shot with that camera in the dialogue. It might, but there's a chance some other objects are involved that I haven't found yet. I'm actually still a bit confused as to what type of object this is. Maybe the actual actor mesh or something? "BioStage" obviously has to do with scene setup, but I'll need to check the UDK reference again to freshen my memory.

2. Actor location -- This is something I've been wondering forever, b/c I need to fix the hand-holding animation for Shepard and Thane. How does the game specify an actor's location on the level during a conversation? In theory, I should be able to make a minor adjustment to the vertical axis for Kelly and/or Shepard, and that could also remedy the issue. The only thing I've found so far that might be helpful is a similar "Biostage" object to the camera one above: object 206 in the PCC seems to (maybe) provide coordinates for Kelly's model?

Anyway, still looking. Will post when I know more :)


Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 01 Mar 2015, 00:31

Looks like I've tracked down the location information. I've been trying to find the general stunt actor files for a little while.

Kelly's data is in objects 11622-11625 in the BioD_CitHub_Underbelly.pcc. It looks like there are XYZ location coordinates, but as float integers or something... ick. There are also references to her Hair, so I might be able to tone down the shininess and match the color a bit closer to ME2 :)

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 01 Mar 2015, 04:03

Holy **** I got this to work.

Reminder: this is a regular dialogue where everything is controlled by each line.

Ok, so the object I posted about, 203. Edits to the camera objects in the list will affect every line that uses that specific camera during the conversation. Changes to the FOV do exactly what you think they do -- they widen or narrow the FOV. But, they widen or narrow it all the way around the shot. In other words, the camera height/angle stays exactly the same, as does the DOF. So, if your actors heads are close to the top, they'll get cut off, lol. They may also get blurrier.

The answer to the height and angle issue is to adjust the "fHeightdelta/fPitchdelta/fYawDelta" fields. And of course for the DOF parameters. I'm still tinkering and am done for the day, but here's a comparison of a vanilla shot and an edited one:

Vanilla -- Oh, hello floating Kelly and Shepard >.>

Edited -- Yay! You can't tell everyone's floating anymore!

I've changed the height from 0 to 15 and the FOV from 45 to 35 which looks pretty good. But, Shepard is now right in the middle of the shot, which feels a little weird and is obviously different from the original. Tomorrow I'll play with adjusting the yaw (rotation), to get Shepard back to the left, which will also hopefully cut the salarian out of the shot. The presence of the salarian/asari has always seemed a little weird to me, since Shep and Kelly are having such personal conversations.

The only thing this method doesn't edit is the actual location of the camera actor. That's something I still can't figure out. 203 is a single object in the file that defines information for 4 different camera actors -- yet I have no idea where the actual actor objects are. I'm guessing those objects would have location data associated with them that would allow the camera to be moved.

One thing to realize when looking at FOVs across different camera actors is that they are relative depending on the camera's location. For example, a 35 FOV from a camera located at a 5m distance from Shepard will frame the scene differently than a camera from a distance of 10m. So, different cameras with identical FOVs can look different. But, in general, small FOV means more zoomed in.

Also, this means I can fix the particular FOVs that are blurry. There are a couple where Kelly isn't in focus, which seems weird. I think BW was trying for a certain "mood" but she really just looks blurry.

Btw, this also helps the cameraswitch objects and the "inherit" thing make more sense. If there's a cameraswitch at the beginning of a line at time "0f", a new FOV/DOF combination is being used. There can also be cameraswitches and cuts while the line is being delivered. If there's no cameraswitch or cut, then the game just keeps using the last one defined during the dialogue.



Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 02 Mar 2015, 23:22

Finally finished editing the camera for Kelly's pre-coup series of convos. The edits worked really well, but you do have to be careful since so many shots are affected. DOF, FOV, and height/pitch/yaw all worked as expected.

Results here:


Re: Research | Animcutscenes + Matinee Editing

Postby The Fob » 03 Mar 2015, 01:04

Ahhh, the stage! Very nice work giftfish. Congrats on figuring this out!
Results look awesome.
User avatar
The Fob
Posts: 702
Joined: 08 Oct 2012, 04:37
Has thanked: 242 time
Have thanks: 212 time

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 08 Mar 2015, 02:27

BioEvtSysTrackSwitchCamera Objects

Finally got a better grasp on these today. There's still some details I'm not clear about, but here's some additional research.

Example object inside BioD_CitHub_HospitalP3_LOC_INT.pcc:

1088: citprs_jacob_meet_d_D.Node_Data_Sequence.InterpData.InterpGroup.BioEvtSysTrackSwitchCamera

This corresponds to Shep's first line in this video, "Exactly, so you have to take the moments when you can."

Upon inspecting the object:

These objects help control what camera and FOV the game uses during a dialogue. They serve a similar function to the InterpTrackDirector that controls camera cuts. I'm still not 100% certain of the differences between the two, but here's what I think I know:

  • All dialogue have multiple camera "actors" located in different spots, often there are two (sometimes more) one for Shepard and one for who s/he is speaking to.
  • In regular dialogues, simple lines that don't have any camera panning/movement are controlled via BioEvtSysTrackSwitchCamera objects. These objects control on a per-line basis, what camera/FOV is used during the convo and when.
  • In animcutscenes, the camera/FOV used is determined by a mixture of the InterpTrackDirector and the BioEvtSysTrackSwitchCamera; ITD seems to take priority.
  • Also, BioEvtSysTrackSwitchCamera is also at least one way that the game controls the FOV at the dialogue wheel (DW).

Looking at the screenshot above, there are 3 "m_aCameras" and 3 corresponding "m_aTrack Keys," in order. Just like I've talked about in a few other research posts, the track keys all have ftime values. 0f (time=0) defines the starting camera on Shepard for the line. An entry for t=0 must always be present. The second track key identifies the wider shot used, right before the DW and the subtitle comes up. Note that both these have "false" in the "Usefornextcamera" parameter. The final track key which has "Usefornextcamera" set to "true" controls the FOV used at the DW.

One thing that should be confusing when looking at this is all the cameras have the same name "cam 1_2." This is where things get tricky. That's b/c all 3 of these are actually the same camera actor, using different FOVs (zoom levels) --the bottom two use the same FOV, which is why there's no change at the DW. This is all pretty easy to tell from watching the video, b/c the angle of the shot doesn't change, just the amount of Shepard that's on screen.

The difficult thing when it comes to editing these objects for, say, DOF adjustments, is that there's nothing that tells you which FOV a shot is using. If you remember from my previous post on the BioStage object, that object will tell you how many FOVs are associated with each camera. In this case, object 384 in the main PCC tells me there are 4 FOVs for cam 1_2. So, if you need to make a DOF adjustment to the cam 1_2 that's at the top in the screenshot, you have to take an educated guess and some trial and error to figure things out.

Basically, it's important to realize that in BioEvtSysTrackSwitchCamera objects, "camX_X" is actually a camera actor/FOV/DOF combination.

Last detail. FYI, you might think it would make sense to not have track key 3 and just set the "UseforNextCamera" for track key 2 to TRUE. That way, the same FOV would be used at the DW. This doesn't work. No idea why, but it doesn't. There must be a separate TK defining what FOV to use for the dialogue wheel.

I think that's about it. Let me know if there are questions :)


Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 01 Apr 2015, 16:49

A couple other new things I'm running across with Liara, and also some unknowns I can't figure out:

1. Convo Nodes that lead to more than 1 Interp.
Liara's IntroB Convo on Mars are full of these, and they make things very, very complicated. To make matters worse, they can lead to "supplemental" Interps that aren't the Interps for the actual spoken line.

For example, here's one small section of the convo. The Interp I care about is 3099, 2nd from the top, on the right:


Here's a close up:

One thing I've been trying to do in the portion of Liara's convo by the window on Mars was to make the exchange about her visiting Shepard (during encarceration) conditional. Due to the dynamic nature of the scene it also meant I needed to change the camera angle for 3099's Interpdata (1783). What I found out is that changing this angle worked for when the exchange is skipped, but it wouldn't work when the lines are retained. I still am not 100% sure why, but I suspect it has to do with the connections between this line and others.

2. "Conversation Cams"
I discovered an even clearer example of how Switch Cam objects area used differently from Camera Groups. Liara's dialogue has several cameras and there are frequently switches in the middle of lines. When the shot is complicated and there is camera movement, panning, etc, that's controlled by a Camera Group, like this:


This is object 2299. It means that the actual camera actor used for Interpgroup Cam1 is cam_liara3. "Cam1" is simply the name for the group.

If there's a Camera Interpgroup, then there must be an InterpTrackDirector defined in the InterpGroupDirector. In this case, that's object 2479. It looks like this:


Note that it is directing two different Cam Groups. And, in both cases, they don't refer to the camera actors themselves. This is unlike simpler dialoagues that do contain a direct reference to the actors (cam1_2, cam2_1, etc). Instead, it refers to "Cam1" and "Conversation."

Cam1's actor is defined by the InterpGroup with that name. For this line, Cam1 = cam_liara3. For other lines this will be different. In other words, "Cam1" doesn't always refer to the same camera, and therefore, the FOV in game can appear different for two shots in the same dialogue that are both controlled by "Cam1"

The "Conversation Cam Group" is actually the Conversation Interpgroup, which for this line is 2301. Within it is the BioSysEvtTrkSwitchCam object, 1356. Looking up that object, gives us this:


This refers to cam5_6. So, how this line works is when it begins, Cam1 is used (cam_liara3). Then, 1.75s in the director cuts to cam 5_6. This cam is then also used for the DW that triggers after the line, as indicated by Usefornextcam=T.

This should mean that changing the camera actor defined by Cam1's InterpGroup, should also change the camera angle used. This can be true, but there are other influences. For example, I found that using any actors that don't look like "cam_liaraX" don't work at all (for example, 5_6). In addition, using other cam_liaraX actors creates unexpected results -- at least in this dialogue.

3. Scene Shop Objects.

I've been trying to figure these things out for almost a week with no results. Here's what I'm talking about:


In Liara's dialogue these are used to control various aspects of the VS when they deliver their "Yeah, it was hard to leave Earth" line. I can say for sure that the FOV, lighting, and animations are influenced by these objects somehow. In this case, they produce different results depending on the player's romance status with Liara. No romance results in the VS getting a tighter camera shot and some panning.

What's most confusing about how this works is that there is only one Export ID for the line that each VS delivers. So, these objects can make the in-game results of the same Export ID appear different. If you look at the Interp, there are actually duplicates of everything present: Player/Player0, Liara/Laira0, AK/AK0, and so on.

The Interpdata for Kaidan's line is 1719 and this refers to two of the SceneShop Group objects (3228, 3229). 3228 is the "romance" version, 3229 is the "NoRomance" version. Inspecting those objects doesn't produce any recognizable results in the Properties. It seems like they should refer to Liara's romance bool or something, but they don't. All the references to the other SceneShop objects are made by the "Data" objects. (Where's the connection between these data objects and the Interp?? Or the data objects and the Group objects??) Each SceneShopData object points to: a Start object, a KisVarCheck, and 2 NodeScenes. The KisVarCheck objects seem to have something to do with determining if the player is romancing Liara, but there's no obvious bool or conditional reference in the properties. It could be in the hex. I've tried looking for bools and conditionals relevant to her romance in the hex for all the "romance" relevant objects, but haven't found anything. So, that's literally all I know about these. They are a black hole, lol.


These Mars dialogues are complicated. In some ways more than an animcutscene, b/c editing them produces unexpected results. The cam_liaraX groups seem like they can influence more than one line due to ConvoNodes that are attached to more than 1 interp. I've come across a lighting parameter that was affecting Kaidan's appearance two lines later. I did an ExportID swap--which is something that usually results in an identical shot--and this time it resulted in the actors "jumping" a bit during the line. And, then there is the issue I talked about in my first example above where swapping in a new camera creates different results depending on if the line directly before it was skipped or not.

These are all aberrations from "normal" dialogue editing. Short of animcutscenes, I haven't come across another dialogue that has worked this way and I've edited MANY by now. I should point out that all edits in the dialogue editor work fine (unlike an animcutscene). It's just once you start messing with the logistics of the shot, things get very dicey...and much less fun to edit, lol.

As usual, I'll post more new things as I run across them.

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 09 Apr 2015, 16:47

Wanted to put this info here to make sure it didn't get missed:

SirCxyrtyx wrote:While working on this, I came across an interesting property that can be applied to pretty much any InterpTrack. It's called ActiveCondition, and vanilla Unreal 3 uses it for disabling/enabling gore. Bioware has added 4 new conditions though:


If the condition is not met, the track won't play.

It's a byte property, and the type value is ETrackActiveCondition. I tested the BioMalePlayer one, and it worked. I haven't tested the weapon ones, but It looks like they depend on whether the actor associated with that track has a single or dual handed weapon.

Originally posted here.
Also, I figured out some things with Scene Shop. Will try to make a post once Liara isn't making me want to pull my hair out anymore :D

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 10 May 2015, 03:13

Gesture Tracks

Thought I'd toss up a couple more things I've learned about these while working on Liara's Presidium Date. First, here's a video that shows the bugged gesture and the fixed version (same one in the BackOff thread, if you've already watched it):

I tried to use the pre-Thessia version of the convo to try to decipher what was wrong, since those gestures weren't bugged. Those can be seen in the final clip above. They were somewhat helpful, but I also just ended up playing with some new values.

Liara's gesture track for the "It must be gone now...", is export 230:


Upon inspection you'll find that "WI_RailingTwitch01" is the gesture used. So, I looked up this gesture in the exports:


You can see that the entire gesture is 21.87s and is 656 frames. This is a long gesture for a very short line. I had two hunches: 1-the gesture was starting at the wrong spot in its sequence, 2- the gesture was playing at the wrong rate and had messed up "blending." Blending is what smooths the connections between gestures. Still not clear on how "blending" is different from "transition."

Anyway, all this information is specified with the gesture in the gesture track, so I went back there (vanilla on left):


I've talked about Play Rate previously, but haven't talked about Start/EndOffset. From what I can tell, I think these parameters help you define which section of a gesture to use. Say you have a 25s gesture, but you only want to use the movements that occur between 12 and 18s. To play those in game, you'd define those as your Start/End offsets in your gesture track.

What seemed weird was that a 21.9s gesture had a SO of 18.7, an EO of 0, and a play rate of only 80% speed. Those don't make a lot of sense b/c the gesture would end up too short, for one. It also seems like your EO *needs* to be greater than the SO (though, I could be wrong). Finally, the game tends to use a StartBlendDuration of 0.1 for most gestures.

To figure out a new SO, I assumed that 18.7 was in the right ballpark -- basically that the end of the gesture sequence should be used. Then I watched the bugged clip and back-calculated from 21.9s to how much time I thought the game needed to run the gesture at 100% speed during the line. The line's about 5s, so I thought 16.5s would work. Then I went ahead and put in an EO for the gesture, just using its sequence length. Finally, I adjusted the play rate and blend as outlined above. All of those worked together to produce the corrected gesture, which looks great. Which means I'm either getting the hang of this stuff... or I got ridiculously lucky :mrgreen:

The second problem was actually a lot easier to spot than the first, but harder to fix. It's harder to fix in that I really didn't fix it per se. I removed it instead.

Liara's "I don't know..." line (gesture track 222) actually consists of 3 connected gestures. Only the first one is bugged. The problem is that the game actually expects Liara to be leaning her hands against the railing at the start of this line. The same gesture is used in the Pre-Thessia version of the convo, where it looks fine. However, Liara *will not* be leaning against the railing unless the player allows the entire idle to complete at the DW, which takes about 10s.

It seemed like I should be able to fix this, but I couldn't. So, instead I "chained" the first gesture to the previous via the ChaintoPrevious parameter. This setting seems to have the effect of disabling the gesture. So, instead the game just blends the preceding idle into the following gesture. Depending on exactly when the player clicks on the DW, it can look smoother or a bit more abrupt. Either way, it looks a hell of a lot better than Liara's gymnastic antics.

I'm still a bit confused about the "Starting Pose/Offset" properties associated with the gesture track. This seems like it should describe what gesture is being used at the beginning of the line, and the offset would specify where in the gesture sequence it's at. But, that's not correct. If it were, that would mean the Starting Pose for each line would match the final gesture used in the line that precedes it. This is not the case.

Re: Research | Animcutscenes + Matinee Editing

Postby giftfish » 02 Aug 2015, 16:24

Static Cameras

I've finally located a missing property (piece of a property?) for static cams, which answers a question I've had for months now. First, a short bit of introduction for context.

Every line of dialogue has a Convo Node attached to an Interp. The Interp has links to a End Convo node and an Interpdata object. All aspects of the scene for that line are controlled by the interpdata. I should also note that all these exports are typically located in localized files (PCCs with the "_LOC_INT" suffix or whatnot).

Below is a screencap of an interpdata object in the Interp Editor:

This is a very, very simple line with only one interpgroup, "Conversation". You can see there's 4 "matinee tracks", one of which is a "Switch Camera" track.

This type of track utilizes what are called "static cameras," and you should notice something looks a bit odd. Namely, that there is a camera switch (a cut to different view), but... it switches to another camera with the exact same name. I can verify the change in shot in the game.

So... how does the game know the difference between the two versions of "cam2_1"?

The static cameras themselves are defined by the dialogue's Biostage object in the related main PCC. In this case, it's export 69 in BioD_CitHub_Hospital_KaiT1. If we look at that object, we'll see something that at least partly explains what's going on:

Namely, that there are actually 44 static cams set up for this dialogue, and HALF of them are named "cam2_1". The names are the same, but the camera parameters (DOF, FOV, etc) are different for each.

But, this information is incomplete. If you compare the hex on the left to the summarized properties on the right, there's a piece of missing information.

Looking at the offset 1F29 that starts with "nmCameraTag" there's an extra 4 bytes at the end that don't appear anywhere in the property:

FE 02 00 00= nmCameraTag
F5 02 00 00= NameProperty
08 00 00 00 = 8 (value)
C2 00 00 00 = cam2_1
03 00 00 00 = ??

The last 4 bytes is the camera's "identifier" of sorts. I think it's simply a count, like "cam 2_1 #3", or as Heff put it when I was running this past him on the TM forums, "cam2_1_3".

Sidebar: FYI, in this case, I think all cameras that are "2_1" are from Shepard's perspective. They show Kaidan. So, Shep is "2" and Kaidan is "1".

This also means that the Switch Camera matinee track must use the same numbers, and since there are two cameras in our track, the two cameras should have different identifiers in those locations. Which they do:

Obviously everything in the red circle is related to the first entry. I've also highlighted the number the corresponds to the second camera listed and checked all cameras in that list of 44. All names -- once you account for the identifier -- are unique.

Currently, the only way to edit this is directly in the hex. Heff is adding it to his library, but it hoping to patch it into an update soon. I'll let him comment more on that if he wishes to :)


The really important implication of this is that it should mean we can make new static cams. I had tried this previously without success, but I now know why I failed; I never gave it a new identifier. Static cams definitely have certain limitations since they are all linked to the same camera actor (which is in the same physical spot in the level), but the adjustments to yaw, height, and pitch actually do provide a lot of flexibility (I've adjusted these for Kelly in BO).

I'll post an update once I know if adding new ones works as expected.



Return to Modders' Research

Who is online

Users browsing this forum: No registered users and 0 guests