MTM2.com

Using Binanimator (both Oliver's and MDMRE's) it is not possible to define a sequence with more than 20 sub-models. Is this a limitation of Binanimator or of MTM2?

Why do I ask this? I build an animated watch (seconds and minute hands) each from 12 positions. The seconds work fine (fps=0.2), but not the minutes. The corresponding fps is (0.0033333.. =1/300) which does not work properly. Maybe because of rounding errors the watch is not in synch.

Any ideas (besides labelling the model as "bargain watch")?

> Using Binanimator (both Oliver's and MDMRE's)

Generally, OP's is the better of the two.

> it is not possible to define a sequence with more than 20 sub-models.

Unknown. Nobody's done it or reported trying.

> Is this a limitation of Binanimator or of MTM2?

A guess : both. Usually, it's not necessary to use so many frames in an animation. The in-game morphing eliminates the need for every frame. For example, if you want to get from frame A to Z, you might only need the intermediate steps of say H and R - the game will create the frames in between. This is why the rex bin and the pterodactyl appear to move smoothly when in fact there are huge gaps between frames.

But you knew that.

> I build an animated watch

Assuming the computer and game calculate the time correctly. If not, what follows doesn't matter anyway.

> (seconds and minute hands) each from 12 positions. The seconds work fine (fps=0.2), but not the minutes. The corresponding fps is (0.0033333.. =1/300) which does not work properly. Maybe because of rounding errors the watch is not in synch.

Is this all on the same model, or different models?

If on the same model, then you can't use the same spacing and different timing.

If on different models, how you'd align them in the game is more than I want to guess.

============

Some math (for my own sake)

For seconds

60 frames at 1 frame per second
30 frames at 0.5 frames per second
15 frames at 0.25 frames per second
12 frames at 0.2 frames per second
6 frames at 0.1 frames per second

For minutes

60 frames at 1 frame per minute (or /60 = 0.01666 per second)
30 frames at 0.5 frames per minute (or /60 = 0.008333 per second)
15 frames at 0.25 frames per minute (or /60 = 0.0041666 per second)
12 frames at 0.2 frames per minute (or /60 = 0.00333 per second)
6 frames at 0.1 frames per minute (or /60 = 0.001666 per second)

I think as long as you stay within six decimal places, the "game" handles it fine. But the repeating values will probably mean you gain/lose at a constant rate.

One possibility, it seems to me, would be to find a number of frames that would rotate in the same span of time but without using rounded values. I assume you want accurate time if at all possible. (eg, for seconds, ten hands at 0.01 fps ; for minutes, ten hands at 0.001 fps - the hands would stay in sync but the time wouldn't be very accurate)

What happens if you use a value like 0.004166666666 in bin animator and then examine the control bin in a hex editor to see how those numbers are stored? It might reveal something about the nature of the values being used. And who knows, maybe you'd be able to edit them right in the bin itself.

============

> Any ideas (besides labelling the model as "bargain watch")?

Digital. Using animated textures.

Using fewer models causes more dilatation during the morphing processs. This is OK for a dinosaur but not for a watch.
I know you know that.

Two different models, one for the seconds, one for the minutes.
Your guess is right: SIT-file editing, lol.

Your numbers match mine. Regarding your comments about rounded values, you should keep in mind that 0.1 (decimal) has no finite digit representation in binary (because 2 and 5 are relative primes, for those interested in number theory). That means that 1/8 or 1/16 are better candidates than 1/10.

My problem was: the seconds (fps 0.2) remain perfectly in synch, with less than 1sec error in 30mn, while the minutes (with the fps rate 0.0033333) apparently had an error of one minute in 5. But this was just caused by a deformed the clockface (I adjusted the height for alignement with other buildings ).

An interesting observation is that apparently MTM2 keeps an internal counter of total racing time used to determine the status of the animated model , i.e. when leaving the track and coming back, the clock is not reset but continues running from where it was.

> 1/8 or 1/16 are better candidates than 1/10.

Probably better than 0.0033333 too ;-)

> the seconds (fps 0.2) remain perfectly in synch... while the minutes (with the fps rate 0.0033333) shows an error...

We're probably stepping beyond my area of expertise but it would seem to me that 0.2 is far more precise than 0.0033333, and that if you could represent the minute value by an equation we'd see better results. I know that whenever I write a script or little program that deals with inexact numbers I always defer to equations in such instances. However, I don't think we have that luxury for animated models.

> when leaving the track and coming back, the clock is not reset but continues running from where it was.

The game does several weird things like that. I bet if you start a different track and then return, the clock would be reset.



> with less than 1sec error in 30mn

LOL, I hope you walked away and then returned to the computer in order to figure that out, hehe.

The main problem appeared to be none, [I edited the post above]. 0.0033 works well enough for 1 hour. I'll try the hour hand now, let's see what happens with 0.000277777... fps.



Well, then get ready to send the money....

Has anyone made an animation with more than 16 frames? that works in the game? If so i'd love to see it cuz anything over 16 gives me a game access violation. I'm using OP's Bin Animator. I must be doing something wrong but haven't figured out what yet. It's not like i'm exceeding any vert or face limitations because my test model only has one face and three verts.