Observations on animated props

[jondor]

As promised, images are now included

#1 Prop exemplars referencing ATC models must include the kSC4BuildingModelProperty (0xEA123CEF) property with the value 0xAA123BF9 for RKT0 referenced props, or with the same value in the correct rep for RKT4 referenced props or brown boxes will occur. (Blue highlight below)

#2 RKTMisc and RKT4xm properties reference mirrored versions of animated (and static in the case of RKT4xm) models.  If your animation is designed for transit use and is not wholly symmetrical, you will need to create a mirrored version to ensure proper placement on flipped or mirrored network tiles.  If mirror symmetry can be mimicked by swapping rotations, you can create additional ATC/AVP sets referencing the same image with the rotations swapped.  If it is symmetrical, simply reference the same model from both properties.  If you do not do this, the prop will disappear on flipped tiles. (Red highlight below)





#3 ATC files cannot share common AVP files.  Each ATC must have a unique set of AVP files or else brown boxes will occur. (Blue highlight below)

#4 ATC props MAY share a common image source, although the animations will not appear correctly in the Reader. (Red highlight below)



#5 Animation frames do not need to be square and should be as small as possible to minimize work done by the graphics engine. (see next point to avoid prop float)


They look square, but only zoom 3 is. z3:4x4, z4:10x9, z5:19x17, also note that zooms 4 and 5 are not divisible by 4.

#6 To minimize prop float and ensure proper positioning, the best method to determine the frame offsets is as follows: (This process will make more sense later with pictures, please be patient.)
   1)Locate a suitable anchor point on your model.
   2)Render one frame of your prop and take a screen shot of the preview, copy the entire preview space in your graphics program.
   3)Move the prop out of the way (if necessary) and create 4 planes of different colors with the four corners meeting at the anchor point.
   4)Without refitting the LOD shells, render and take another screen shot of the preview, copy this entire preview space as well.
   5)Locate the origin on the second screen shot. (I find the upper right of the four center pixels to produce the best result, but you may have to experiment.)
   6)Locate the same pixel on the first screen shot and determine the offset of the corresponding pixel in the clipped animation frames.
   7)Repeat for all four rotations and 3 zooms.
Your prop should remain fixed (at worst moving by one pixel when rotated) and be easier to locate when placing on a lot or t21 (the origin of the model will correspond to the placement coordinates on the lot.)

2: 4:
6:
This image shows the previous two superimposed on each other.  If you download it and zoom in a graphics program, you can see the pixel where the four planes meet the mount of the beacon.  That is the offset pixel.  Simply use the coordinate of that pixel relative to the cropped frame (and remember to count from zero).

#7 If the size of the animation frames are not multiples of 4, the source image should be saved without compression. (DXT1/3 compression will cause messy artifacts in the final animation if the frames do not align with the compression method's 4x4 blocks).

Compare my flashing beacon animation versus the default railroad crossing , the railroad crossing shows quite a bit of noise because the DXT compression alters the pixel colors from frame to frame.

Although this can impact the rendering of the game very slightly, the main impact comes as the textures are transferred from system memory to video memory.  Given the advance in video card and interface speeds and the relatively small size of these images, the difference is negligible unless you're running SC4 on a machine that barely meets the original system requirements (and if you have the NAM traffic simulator installed, you'll end up with much bigger problems running the game on a machine like that anyway).

#8 In the source image, if a line of frames nears the right edge but the remaining gap is not wide enough for an entire frame, drop down the the next free row.  The game engine will skip the blank space and continue on. (See the zoom 5 frames above.)

#9 ATC and AVP formats: (All mutli-byte words (16 and 32-bit) are little endian (LSB first))

ATC: ATC type value, source FSH Type, Group and Instance, AVP Type and Group, AVP instances for zooms 1-5 (in that order), Number of frames


AVP: AVP Type value, number of rotations (repeated twice), version and user data (best not to edit), plane (multi-fsh image index), source type (08 for fsh is the only valid value) and x and y offset of the first image of the rotation, frame width and height and anchor x and y coordinates

Rotations are in order W, S, E, N.  This differs from the normal prop order of S, E, N, W.  Comparing the default Maxis static RR crossing vs animated RR crossing:
I believe this is why animated stop lights appear to face the wrong direction in the lot editor.

There are several Maxis animations with 8 rotations rather than 4 and the requisite 4 additional sections (blue and purple blocks above), these are used for sprite animations (walking pedestrians and the like) which can move in 8 directions: N, NE, E, SE, S, SW, W, NW.  The exact order of these rotations still needs to be discovered.

Also, although the BAB tool docs claim that animations don't show up below zoom 3, I think that is due rather to the AppearanceZoomsFlag property of the prop exemplar (Traffic lights in particular are set to zoom 3 and higher, but the railroad crossing gates are visibly animating all the way to zoom 2.

One last note, there seems to be a limit of 128x128 pixels for any given animation frame.  My attempt to test out the anchor coordinates using a single frame animation spanning an entire tile resulted in the zoom 5 render being clipped and skewed while zooms 3 and 4 were just fine.

[SimFox]

will you follow with the pictures?
I'm interested in Animated Props, as I'm thinking of creating plugin for Bat4max that would produce them...

[jondor]

will you follow with the pictures?
I'm interested in Animated Props, as I'm thinking of creating plugin for Bat4max that would produce them...

I plan to, I need to find the time to go back through and make screen shots of the process.

The BAB tool wasn't suitable for the prop set I'm currently working on, I had to hand edit the frames and ended up capturing them using a different method.  It's time consuming, but it produces a high quality prop with a minimum file size.

[SimFox]

well "time consuming" part could be potentially automated with some MaxScript. PM me once you'll find time to get back to this.

[jondor]

Time consuming in this case because I had to hand edit the animation.  I'm going to attempt to document this process today, so stay tuned.

Edit: And now I realize I already said that several weeks ago.  Anyway, without hand editing it should be possible to automate most of the process except perhaps the determination of the anchor point, but that may be possible as well.  I don't know much about 3D modeling beyond a few basic skills.

Edit again: I have updated the first post with some details about the rotation order, especially important for anyone wishing to create traffic lights or RR crossing animations.

Edit once more: I believe I have cracked the 8 rotation mystery.

There are several Maxis animations with 8 rotations rather than 4 and the requisite 4 additional sections (blue and purple blocks above), these are used for sprite animations (walking pedestrians and the like) which can move in 8 directions: N, NE, E, SE, S, SW, W, NW.  The exact order of these rotations still needs to be discovered.

From this line in CameraRig.ms

rotStep               = 90.0,  -- how many angle views to a circle, buildings use 4, sprites 8 (16?)

And from examining the 8 rotation animations, they are all pedestrian animations.

[NCGAIO]

will you follow with the pictures?
I'm interested in Animated Props, as I'm thinking of creating plugin for Bat4max that would produce them...

Well I do not know if this discussion is dead but I believe it should even be possible to export animation by BAT.

Sifting through the DAT 1 found this S3D almost 15 seconds of animation!

.               5ad0e817 badb57f1 04300000

I can not imagine the work editing verticess .. 701 are Group vert.

I think nowadays, who can have a heavier hardware would run gladly modeling animations in the game.

Anyway I'm watching ....

[Lowkee33]

Edit: you can disregard most all of this

@NCGAIO:  BAB tool can make animations from regular BAT,  SimFox is looking for a similar process for fancy people.  I wonder amount the system load an animated prop has.  I don't know much about it, but there don't seem to be any LODs for an animation.  My computer has no issues with textures, just rendering the LODs.

Hi Jondor, thanks for the tutorial.  I have a few questions.

   I'm doing something pretty simple with BAB.  My FSH has been saved 256x256 pixels large.  However, the actual animation uses less than half of it.  Is it safe to say, open it in GIMP and cut it down to 256x128 (or how about to 127.  A regular model's FSH seem to need to have sides that are a square number amount of pixels)?

   In the AVP file there is a column for file position.  I'm sure you know, this number is the pixel of the FSH.  For example, I have a file position of 12304.  12304/256 = 48.0625, and .0625*265 is 16.  That frame of the animation is certainly at position 16,48 in the FSH.
   
   My issue here is that I would like to move the frames of the animation.  I figure with so much space in the FSH, I might as well use it with some higher def frames (if something like this is possible).  How would I go about this, there seems to be no mention of File Posistion in your tutorial.  EDIT: File Position is the X,Y offset

Thanks again.

[NCGAIO]

Sorry friend but you're confusing it all .. and I'll forward your response if I may, you have to move the template provided to create this kind of movement has nothing to do with the textures OK!