Greetings all. This Friday (it's Sunday now oh well)'s feature is a little different than the others: rather than explicitly focusing on TSC:E content, I've put together some information on some of the more arcane aspects of HCE's cinematic-related animation systems that we've been putting to use in TSCE. This is to potentially be revised, reorganized and integrated into a larger manual on Halo 1's animation systems, so any suggestions for other systems that you'd like to see included (as well as any desired clarifications or errors you find) would be much appreciated.

---

I: Animating the Camera

Did you know? You can animate Halo's cinematic camera from 3ds max.

Using the following script command...

(camera_set_animation <animation_graph> <string>)

(The first parameter is the path to the animation tag that you want to play an animation from; the second is the name of the animation in that tag.)

...you can play a custom animation on the game's cinematic camera. (You will need to give the game camera control - with (camera_control 1) - for this to have any effect). This is incredibly useful if you want to have more control over the camera in your cinematics than is afforded by H1's comparatively simple camera point interpolation-over-time system.

Camera animations themselves are simple. They take a single animated node (the node's name does not appear to matter). For the duration of the animation, the game's camera will match the position and orientation of that node. Once the animation finishes, the camera will remain where it was at the last frame. You must compile the animation as a .JMW file - otherwise it will not be able to move. (More on cinematic applications of Halo's animation formats further down).

These animations are obviously much easier to create if you have an actual camera in 3ds Max. Note that Halo's cinematic camera assumes default orientation along the positive X axis with Z up; while 3ds max's cameras are oriented along the negative Z axis with Y up. To account for this, just line up your camera node and camera object in 3ds max so that the orientations are consistent. (Even if you mess it up at first, it should just be a simple matter of rotating in 90-degree increments along the camera's or node's local axes to correct your mistake). Also note that, at least for the Blitzkrieg exporter plugin, it is okay to have your 'root node' linked to another object - even a camera. This means that if it is more intuitive to animate directly from your camera object - for example if it is using a follow-target or you want to use the 3ds Max camera controls to create your animation - you can just link your root node to it.

Also recall that Halo's default FOV is 70 degrees, but that users may change this value as they please. Unfortunately, I don't know if there's any way to control camera FOV via camera animations. Intuition might suggest that scaling the root node might do the trick, but thus far I have had no luck with that. If you want to change the cinematic camera's FOV, you can do so by preceding an animated camera call by setting a traditional camera point that has the desired FOV value. (I'm not sure what you'd do if you needed a custom-animated camera that gradually transitioned its FOV).



A side note: this means that you can easily do first-person cinematic animations. Just line up your camera animation with an animation for the first-person arms (plus whatever other props you need, such as weapons). When you're done, you can split up their animations and export + compile them separately. Then, place a scenery (or your favorite type of Halo object) with the FP arms model (and again, with any props you need) and play the camera animation alongside the arms animation. I don't think I've seen anyone exploit this yet, but if you were curious - it can be done.

II: Cinematic (and not) Unit Animations

As is common knowledge, you can play a custom animation on a unit with the script command:

(custom_animation <unit> <animation_graph> <string> <boolean>)

(The first parameter is the unit to play the animation on; the second and third specify the animation as in the above camera animation section; the final parameter specifies whether the animation should be 'interpolated into' - that is, whether the game should blend the animation in over a few frames or play it immediately.)

However, the type of animation that you're playing - a JMA, JMT, JMM, JMZ, or JMW - affects how much you can pull off with this command.

II - A: JMW - World-Relative

A JMW will play with the origin of the animation set to the level's origin. JMW has its obvious benefits: you can animate a scene as-is in 3ds max with your level geometry right there, and you don't have to worry about liming anything up afterwards. It is probably the simplest way to get a cinematic animation working in the game. However, it also has its downsides:

1) Units will not remain where they are at the end of the animation - instead, they will teleport back to their prior location
2) Units that have to cross large distances may appear to warp or phase in and out of the animation at its start and/or end. This is because of Halo's animation interpolation system - even if you turn off interpolation at the start of the animation, the object will still have to return to its original location, the duration of which is not affected by the interpolation flag.
3) If you end up having to move part of the level where the animation takes place, or want to reuse the animation somewhere else, you'll have to update every animation involved in the cinematic. For cinematics with multiple characters, this can be an enormous pain in the ass.
4) Collision geometry (and render culling) on models can begin to behave very strangely when they're moving large distances via a JMW animation.

Fortunately, you can pretty easily avoid these issues and still set up your animations in a consistent manner even if their absolute world position is important.

II - B: Moving away from world-relative

If maintaining world position isn't important - for example on the Truth & Reconciliation's gravity lift when all units should move up/down relative to their position when they started going up/down, lest they overlap each other; or if you just want to play animations on units where they are - then you don't need to worry about this part. Otherwise...

Pick an arbitrary point in your level geometry to act as an "anchor" for your cinematic animation. This point should be "inside" the level's playable space; recall that objects outside a BSP's volume do not behave as expected. This point might be somewhere in the middle of the cinematic scene, or the starting point of one (or all, depending on how much work you want to put in) of your animated objects. Record its x/y/z position; you can then place a cinematic flag marker in Sapien - just called "Flags" under the "Game data" section of the Hierarchy window - in your mission, which has the same position. Remember to divide the coordinate values by 100, as the ratio from 3ds Max standard units to Halo world units is 100:1.

Once you have your anchor point, you can move your 3ds Max scene such that the anchor is translated back to (0,0,0), with all other objects preserving their position relative to it. This way, everything will remain where it 'should be' if you play the animation back with the objects at the anchor.




Now, all you need to do is precede your cinematic animation calls with teleport commands:

(object_teleport <object> <cutscene_flag>)

(The first parameter is the object in your scene and the second is the anchor flag in Sapien.)

With this setup, you can use JMM, JMA, JMT, and JMZ animations without having to worry about keeping your animations correct relative to each other. (Again, you obviously don't need to do this if it don't need to control where your units are when they start the animation). These animations begin playing treating the target unit's position as the animation origin - hence the need for some sort of anchoring system to keep things consistent - but their benefits are many. Moving away from world-relative animations means that you can much more easily reuse animations (just place the anchor point(s) appropriately) and update them for level geometry position changes (just move the anchor in 3ds Max along with the geometry and re-enter its position in Sapien). Each format also has some unique properties that you may find beneficial.

II - C: JMM

As with JMW, JMM does not affect object position when it is done - objects return to where they were previously. However, also as with a JMW you can play JMMs on a vehicle and have the vehicle's entire body move during the animation. And as long as the animation returns the vehicle to where it originally was (or if you have another means of accounting for the end of the animation), you can use this to create some interesting features for your vehicles.

In TSC:E, we've created a looping Phantom strafing animation. We play this on our Phantoms whenever we want them to hover in an area to harass the player, but don't want them to look awkward just sitting there perfectly still. Because the animation does not translate much and loops reasonably fast (every 5 seconds), it does not have any significant undesirable effects on gameplay, and adds some nice flavor to something that would otherwise look quite dull. We use a continuous script to check a boolean variable; while the variable is true, it will periodically play the banking animation on the desired phantom. Once the global is false, it will go to sleep until it is true again. By timing things intelligently, you can seamlessly integrate such behaviors with normal gameplay and even 'real' recorded animations in some very interesting ways. (Custom JMM animations keep playing even if a vehicle is moving under its own power! However the same is not true of bipeds - see the next section.)




(The above Phantom is, as with many placeholder assets, a hacked version of a ripped model that has been modified to accommodate features we want to have in an eventual custom version.)

II - D: JMA, JMT, and JMZ

You can get bipeds to preserve their position after the custom animation completes by using these three formats. (Vehicles are more temperamental and don't like to be permanently moved around by custom animations). This can be immensely useful if you're looking to create new character gameplay features involving animations. JMA preserves horizontal position; JMT preserves horizontal position and orientation; JMZ preserves horizontal position, orientation and vertical position. Note that of the three, only JMA behaves the way you probably expect it to: the other two have some odd quirks when used for custom animations that you'll need to experiment with and get a feel for.

Also note that unlike vehicles, in my experience you cannot play a custom animation on a biped without interrupting its current actions until the animation finishes. That said, this may actually be a beneficial property depending on what you're using it for...

If you end up chaining multiple object-moving animations together in a cinematic, you may also need to keep track of your bipeds' offsets from the scene's anchor point(s) - however I'm assuming that if you're doing something that needs that, you're also capable of figuring it part out for yourself.

III: One last tidbit

If you're willing to get even dirtier with scripting: with Open Sauce's exposure of units' driver and gunner seat power properties to scripting, you can control object attachments (such as Pelicans' hover/jet thrusters) via script - removing one of the main downsides of fake recorded animations. It'll take some finesse to get them to transition smoothly, but that isn't a challenge if you know your way around HSC enough to implement some basic custom logic in it to be used in other scripts.
Edited by teh lag on Jul 21, 2013 at 03:23 PM

nice custom phantom

It is not a custom phantom. As with many of our placeholder assets, it's a hacked version of a ripped model that has been modified to accommodate features we want to have in an eventual custom version.

ahh gotcha, just thought from the lower front, so is there going to be both dropships? or a brand new dropship?

The camera tip in max will be greatly useful to create FP anims in game

The AR sounds more like an M4 than anything (not necessarially a bad thing, but it doesn't really give off the whole "Futuristic Weapon" vibe). The DMR, I will agree sounds much better than it did in reach. Sniper doesn't sound like the Sniper anymore, and it feels more like a M92 now. Out of all the weapons in Halo 4, I'm liking the new sounds for the Spartan Laser the most. It sounds like an amped up version of the regular laser, and it has a VERY strong hit sound.



http://www.youtube.com/watch?annotation_id=annotation_90653&feature=iv&src_vid=HLAasUgoGYk&v=GSu8TjOogy8

As you can see, the only really good weapon sounds are for the Needler :x




I actually started messing with this at one point, and admittedly it's a nifty little feature to mess with
Edited by R93_Sniper on Jul 21, 2013 at 04:18 PM

343 used some recordings of real weapons :P

This post has changed my life

I assume it's going to be that big "O_o" thing they mentioned about two months ago.


It's been made clear that phantoms will be the preferred replacement to spirits. Is that true for ALL levels, even a50? As I recall, the ending cinematic pretty much required them.
Edited by WWLinkMasterX on Jul 21, 2013 at 06:07 PM

the O_O thing is not for CMT. That was the H2SPP thread.

Speaking of the O_O thing, where is it? Did it happen? o.o

and then threw them out for bass dampened airsoft guns, don't argue with me about, if u seriously want to, then listen to the magnum sound again. also i fixed my own post from earlier.
Edited by greg079 on Jul 21, 2013 at 06:32 PM

We weren't arguing dude. We're actually agreeing. The Magnum sounds disgusting.

U mad, greg?

I was subtly explaining why they the AR and SR sound like modern firearms.

"we call it a flashlight replacement system . . . we call it flashlight replacement because it's not just an equipment system or an armor ability system, y'know it's pretty robust in what you can do with it..."

sounds cool, like what?

You could use it for a number of things, Perks, Equipment, Armor abilities. You can pretty much tie in anything to replace the flashlight, and then use scripts to dictate the rules for it. You could easily do equipment if you wanted too, or tie it into any script you have. The possibilities are endless with it really.

hay how did u guys get to slow down the burst on the br like that

This was explained in Ifafudfi's Media Month post on the 3rd here.

one of the reasons why everything is crap, its 2558... (yea I did the math on the first level from what cortana said... everything is random numbers...) not 2012, future guns!



oh god I can only imagine the possibilities... mother of god.... O.O I need bigger eyes for that face
Edited by rcghalohell on Jul 21, 2013 at 11:23 PM

What order are the maps being released in, also will there be a big gap in time of release of the maps.

There will probably be a significant gap between releases. As Killer said, they focused on b30.
Edited by Dumb AI on Jul 22, 2013 at 12:53 AM

The plan is B30:E. Then a 2-3 month gap and we will release one map for SPV3 each week. This is all tentative of course.

so... easter egg plans?

Also one more question are you guys add more sections to the level like spv2 or is it going to be halo 1 just with cmt additions? I know tsc:e is going to be new but I'm asking about the other levels

There will be parts added like SPv2, but more thought out n stuff, I guess

TSC is lucky to be even 60% done. You have a while to wait. The island alone is only about half modeled most of it is in the final draft stage. Then you have to long process of light maps never mind all the custom scenery objects we still need to make let alone the encounters and testing.


POA has new areas, as does Halo. T&R can only be extended in the ship, B30 is all new, and AOTCR has yet to be determined.
Edited by Masters1337 on Jul 22, 2013 at 02:30 AM

To be honest aotcr is fine the length it is if you added more parts without taking some out it would feel too long.

Part of the problem with new parts of it is the length, but also the squad limit we hit in SPV2. I Actually have been looking for ways to trim some areas of the level, the bridge where you get the banshee now has a path down to the ground, and all the scripts have been tweaked so that the rest of the level plays normal if you choose not to go inside more of those copy and pasted rooms to get the the elevator. Replacing those copy pasted rooms in other parts of the level is also an option for us.

nah guys, i'm not even upset. i'm mostly trying to prove to masters that the sounds are important, and that most of the sounds they have still need work, also trying to show him examples of what not to do. two of the things needing the most fixing are the shotgun and the suppressed weapon. i'm confident that both are WORSE than anything 343 could ever make, this is not an achievement to be proud of.

Explanation accepted.

oh god i hope its longer, more time on the campaign, besides, its not that long in my opinion, area 1, tunnel, area 2, up and through a few rooms, area 3, and then final

So what happened to the Mantis encounter(s)? Was that idea scrapped or pushed? Just curious considering we haven't heard all that much about it lately.

Mantis will be more for SPV3. So you're not hearing much about it because we're doing our best to focus on b30:Evovled first.

I hope the Mantis can jump.

i hope it dies instantly before it defiles my sacred ring, seriously, i think 343's game development plan was "do drugs". i played that part on foot, seriously halo isn't a mech game. PLIS NOH