Car Animations

The technique of editing XML's in order to animate custom objects for RCT3 is only possible through the efforts of DarkHorizon and Krypt This method is especially useful because it allows the community to animate CTR's without relying on Blender. Coding XML's for animations can be challenging because in order to achieve accurate results we need to think in abstracts while at the same time producing precise coding to get items in the game to make specific movements.

The most accurate and predictable animation results are achievable when trains and flat rides are modeled in their idle positions with restraints and doors closed. Because of this animations will need to be set up so that they open car doors or raise the car restraints. This is what's called an Opening animation and such animations need to be sequenced in this order:

A

Opening: restraints raising, doors opening,

B

OpenIdle: restraints locked into risen position, doors held in opened state,

C

Closing: restraints lowering, doors closing, and

D

ClosedIdle: restraints locked into lowered position, doors held in closed state.

A, B, C, and D are known as set points. When these accompany our bones they identify when each part of the animation takes place.

We need to keep in mind five basics when animating car doors:

►

Which of the bones need to be manipulated?

►

Is it a translation or a rotation movement?

►

To where does the bone need transitioning?

►

How long do we need for the bone to take to make it's transition?

►

How long does the bone need remain in any position?

Unless specifically stated otherwise, the best place to put bones and set points in our model is at X+Y+Z=0 in our modeler.

Bone placement is different from particle effect placement in that bones may be stacked by the dozen at the same coordinate while particle effects for CSO's each need to be spaced a minimum of ½ meter apart. Although at a glance placing every bone at X+Y+Z=0 may appear confusing (for example, if your train car has four doors, two on the left and two on the right that would be around twenty bones in one place), bones may be grouped and their groupings temporarily spread out so that each group may be checked to ensure all the required bones and set points have been added. Just move all the groups back to X+Y+Z=0 before Importing. We give tips on a clean, efficient way to do this here under our header Creating Your Bones and Set Points.

The most efficient way to work with effect points in SketchUp is to group them, after which they may be conveniently moved or hidden. Even while grouped they will export to ASE individually so they don't need to be ungrouped before Importing.

Creating Our XML's

To start we give a complete description of the aforementioned A, B, C, and D:

A

Opening:

• restraints raising

• doors opening

After guests have ridden the ride this is the part of the animation that opens car doors and raises restraints just prior to guests disembarking. Through the Opening sequence we tell the game engine what bone to move, where to move it, how to move it there, and the length of time that any of these movements are to take place. This is the place to get specific with our rotate and/or translate values and it's up to us how long each part of this cycle lasts. In addition to ride and train cars being modeled in their ClosedIdle positions it is also recommended that we start with Opening because this sequence prepares the ride for the next load of guests. If no transition times is entered here restraints and doors will simply snap into their opened positions.

B

OpenIdle:

• restraints locked into risen position

• doors held in opened state

After the opening sequence is done OpenIdle represents the holding position of the opened items. OpenIdle will hold your item in the required position while guests board, e.g., the restraints will be held up or the door will be held open during this cycle. It is essentially the final position of the Opening sequence duplicated and then frozen into position. The OpenIdle position will be held until boarding is complete and the train doors are ready to close.

C

Closing:

• restraints lowering

• doors closing

This is the opposite of the Opening sequence. Closing marks the end of guests boarding the ride and indicates the train is preparing to leave the station or the cars in the ride are preparing to start. The coding written here will reverse the animations that took place during the Opening cycle. If we reverse Opening's coding and transpose the timings we're well on our way to writing a Closing animation. If no transition time is entered here restraints and doors will simply snap shut.

D

ClosedIdle:

• restraints locked into lowered position

• doors held in closed state

By now the game engine has reversed anything we've entered into our animation XML's and has returned the restraints or doors back to their starting positions which ensures that each of the following Opening cycles gets a fresh start and operates as expected so ClosedIdle is essentially the animation which confirms to the game engine that any restraint or door animations have run a full cycle. Enter zeros for any time, rotate, and translate values here. Any value besides 0 entered here for the time will be ignored by the game engine because with either the restraints or the doors closed and our train/cars now ready to depart, the train will simply get a move on. In ClosedIdle we have no control over how long a wait there is before the ride commences.

What's In An XML?

The first few times you do animations it is recommended to create four separate XML's, one for Opening, one for OpenIdle, one for Closing, and another for ClosedIdle. This will make it more convenient to focus on what goes into which animation. This method will allow us to easily focus on the animation that may need updating or correcting and prevents inadvertent adjustments to XML sections that don't need altering.

When you're done, your animations may be compared by opening each in Microsoft Notepad which will result in four separate instances of Notepad running. This is a little trickier to do with Notepad++ for which all four animations need to be opened in one instance, then the tabs for each dragged to your desktop to create four separate instances. Arraying your animations on your display screen so they can all be viewed at the same time makes it very convenient to look over and compare the contents of each.

Editing XML's may be done in any XML Copy Editor, in Microsoft Word, or in any other word processing application. Microsoft Notepad is not recommended for editing XML's due to its Draconian, single-stage undo feature being highly unpredictable.

Time values entered into animation XML's should start at 1 second and can increase from there in increments of 0.01 seconds. Most community members who write animations rely on increments of 0.10 or 0.25.

Distance values, otherwise known as translations, are written in meters with 0.25 being entered for a quarter meter (25cm) and 0.10 entered for a tenth of a meter (10cm).

Rotation values are coded in radians instead of degrees. A Google search will bring up links to several unit converters available for download. With a unit converter one would simply enter the degree value of the required rotation into one side of the converter which will tell you in the other side how much that is in radians.

When creating XML's, so that you'll always know what's what at a glance it's best to start labeling your animation bones with one of these five names:

►

bone_door

►

bone_restraint

►

bone_effect

►

ik_wheel, or

►

ik_RobotJoint

Any additional identifying information may be added to the bone's name to further identify it within your particular project. The first two are those most commonly used throughout our community: door Bone Effects and restraint Bone Effects.

Beginning And Ending Your Animation Fields

Here we'll take a look at how the animations are constructed inside the XML.

1

We'll start with the animation field:

A

<animation name=TheNameOfYourAnimation>

B

[Enter Your Bone(s) Here]

C

</animation>

Note there are two sets of <>'s

►

a header animation set <> (the opening set) and

►

a footer animation set </> (the closing set)

Each set has inside it the word animation. The header set of <>'s, A, tells the application reading the code that this is the animation's beginning. The footer set </>, C, tells the application reading the code that this is the extent of the animation field. Both the header and the footer together tell the application reading the animation that this is where animation coding is located. Your entire animation needs to be written in between A and C.

2

Here we'll code our bone transitions which are constructed in this way:

D

<bone name=bone_doorleft>

E

[Enter Your Transition(s) Here]

F

</bone>

Again you'll observe two sets of <>'s

►

a header bone set <> (the opening set) and

►

a footer bone set </> (the closing set)

Each set has in it the word bone. The header set of <>'s, 2.D, tells the application reading the code that this is the bone transition's beginning. The footer </>, 2.F, tells the application reading the code that this is the extent of the bone transition field. Both the header and the footer together tell the application reading the bone that this is where bone coding is located. Your entire bone transition (whether one line or many lines representing several transitions) needs to be written in between D and F therefore, D, E, and F will ultimately become 1.B.

3

Now we'll review the individual transitions for each of the bones you want to animate. This is where you'll include

►

translation code(s), and/or

►

rotation code(s), and/or

►

effect code(s).

Each bone will need to be assigned a mesh so that the game engine knows what it will be animating, e.g., the bone bone_doorleft will be assigned to the mesh you drew to make the left door shape in your car. This information directs the animation and tells the game engine what to do with what mesh and when, therefore, so any information you enter here will ultimately become 2.E.

Each bone needs to have a unique name. If we only created a single door on one side of the car our bone might be named bone_door. If we made a longer car and wanted four doors on our car, two doors on the left and two on the right, so that each bone is uniquely identifiable we might name these bones bone_doorleftfront. bone_doorleftrear, bone_doorrightfront, and bone_doorrightrear.

Our Introductory Animation

We've created a car model with two doorsfor which we'd like a simple animation where each door pushes sideways from the car for 10cm and then moves towards the back of the car by 1.5m.

Here is our car shape mock-up.

And these are the doors that will be animated for this car. As this is an introductory demonstration we'll confine ourselves to the use of a single door bone, bone_doorleftfront.

The meshes which are to be animated need to be grouped separately from everything else and also given specific animation orientated names.

It's extremely difficult to get a feel for the car and how the animations are working if any glassed areas are completely opaque. While we're still a long way off from applying the finishing textures to our car model the one thing we should do early is attend to the completed appearance of any glass panels.

Following is a screenshot of our door mesh bones and the animation set points, one point for each of the animations, The bones and the set points have all been placed at X+Y+Z=0. Note there are set points and a bone for the left door as well as set points and a bone for the right door. This is because one door will move away from the left side of the car and the other door will move away from the car's right side.

Again, to aid in making this demonstration easier to follow we'll only do the left door.

As you see we've linked the set points to the bone by giving them a label that includes the name of the bone. Any bone included with your car model when you export to ASE needs to be included in the animation XML's.

Making Progress With Your XML's

Now we need to animate the set points and this is where our XML's come in. Kiotho's blank XML templates (included in our downloads) will help us get started. There are four templates, one each for

►

Opening,

►

OpenIdle,

►

Closing, and

►

Closed Idle.

Copy and paste one of each from the download folder to the folder where you're working on your door animation. Open the one named Opening. You will see there are already seventeen lines of starter text in place.

Note there are header <>'s and footer </>'s for animation and another set of <>'s for bone. Note the transition coding for the set points (the potential translate and rotate entries) are situated within the bone header and footer <>'s. You will also notice all the header <>'s are closed out with footer </>'s. All of this is enclosed inside the model header and footer. The animation XML is the only place where we'll need to make a model reference and this is already comes with the templates.

You will have noticed that lines 5, 7, 14 and 16 are empty lines. Empty lines are not read or required when coding XML's and serve only to organize the data and make it more readable to those who are writing the code. You may include more empty lines in your XML or you may dispense with them altogether. Either is a matter of personal preference.

Drag the above toggle to a

convenient place on your screen.