Zero Division Error

[Justintime9]

I just made an animation in my age that involves stepping on a button, which will open a door on the other side of the age. I created the Quickscript, the animation, and updated the SDL file, but when I tried exporting it, this error came up:



I tried to figure it out, and it obviously has something to do with my animation, but I don't know what. Here's my AlcScript:

Code: Select all

BrownDoor:
    animations:
        - name: DoorOpen
          autostart: 0
          loop: 0
   
BrownDoorBut:
    quickscript:
        stateanimation:
            objectname: BrownDoor
            region: DoorButtonReg
            sdlname: DoorOpen
            avatar:
                animation: StepOnFloorPlate
                animtarget: DoorButtonEmpty
            forewards:
                animation: DoorOpen   
            backwards:
                animation: DoorOpen


The door animation is a location animation. (it slides into the ground). A
Anyone know what could be causing this? I've never seen this error before.

[Christian Walther]

Quick shot in the dark (too tired now for a detailed analysis) - it looks like there's something dubious about your ipo curve. Perhaps coincident handles or something.

[Justintime9]

Hmmm it's possible... are there supposed to be three lines for the ipo curve? (two straight ones and one curved)
what are coincidental handles?

[D'Lanor]

2 handles that cancel each other out. For example a rotation over 360 degrees, which has an end state identical to the start state. Depending on the "cleverness" of the code it may be mistaken for a rotation of 0 degrees. (just an example since PyPRP does handle this correctly)

Edit: Three lines is correct. There is one for each axis.

[Jojon]

Most likely, though, one of the curves have simply got two handles on the same frame, somewhere. Try to localise it by deleting half the IPO curve and export, see which half has the problem, then check half of that and so on, until you've pinpointed the culprit. Alternatively, if the curve is not very complex, just grab hold of each handle in turn - that should let you spot any duplicates.

[D'Lanor]

Two handles in the same frame? Is that possible? Handles are always replaced if you press i again in the same frame.

[Justintime9]

I checked, and there's only one handle in each frame (for each axis of course). For some reason though, when I exported this time I got this error: "Index error: list index out of range". Btw, my animation is only 3 frames long, in case that might be part of the problem.

[Christian Walther]

I've had a look at the code and what the line in question does is divide by the horizontal distance between a bezier curve point and its incoming tangent handle. So there must be a point in one of your curves whose incoming (left) tangent handle is at the same horizontal coordinate (time) as the point itself. That's what I meant by "coincident", as Jojon observed.

Perhaps you can show us a screenshot of your ipo window, with all curves selected and in edit mode, so the handles are visible?

For some reason though, when I exported this time I got this error: "Index error: list index out of range".

Hard to tell what the problem is without seeing the backtrace. (Don't we all love the non-existent error handling of PyPRP? )

[Jojon]

Three frames? Did you buy these doors at the Deathstar scrapyard sale? :D

@D'lanor:

(sorry about possibly going off-topic, but I want to write this...)

Yes, it is possible to place more than one point on the same frame (and things like frame 1.001), when handediting the curves. The obvious response to that might be "then don't do that", but I find it difficult to avoid, in order to get the exported animation to somewhat resemble what is seen in Blender.
Problem is that, in my experience, when you use the "i" key to insert keys, the handles on the new points will have their "clamped" flags set, limiting their vector with regards to the next point, but the exported animation will not have the clamping applied, always exporting the plain auto mode data, without clamping and with aligned handles (entry and exit vector in the same direction). To get to see something in Blender, that is close to what you get in Plasma, you have to make all handles plain "auto" mode, which seems to be a square b-spline, rather than nurbs and makes the handles point in the average direction towards the preceding and following point -- this crops up some serious overshoot in many cases, which can take quite a bit of tedious editing to get rid of and your change of direction may still have to turn out smoother than you'd like (I've got some stuff that should make a hard bounce, but the curve can't make a sharp turn, under the circumstances, with the dictated curve characteristics and a full frame between each point).

It would have been nice to be able to use free handles, so that one could make those "sharp turns", but I, for one, have not managed to get there. I have no idea what sort of interpolation modes there are in Plasma's animation system.


Justin: you could try to select all the points in your curve and hit Shift-H and Alt-H a few times, to look at the different ways in which Blender can interpolate your curve - the one with the (possibly) slanted handles, as opposed to nicely horizontal, would be the one you'll see exported. Forget about trying to use the handles to shape the curve - your edits are ignored and you'll end up with something close to Blender's "auto". Maybe this will automatically move out any null distance handle. If you have more than three points, that may be your problem, assuming intermediate points (between frames) are rounded to the nearest discrete frame).

EDIT: Confusing formulation hopfully made less confusing...

[Christian Walther]

To continue along those lines... I've just "had some fun" as instructed by the comment "the current tan values are a wild guess. Have fun." and have come to the conclusion that I get more accurate results dividing by 160 (+-5) than by 30*2*pi (=188.5). Which doesn't seem much less wild, unfortunately. Guess we have to wait for the code to do this correctly.

I have only used one curve segment, so I haven't run into Jojon's problems. Let me see if I can get sharp turns. I see nothing in the PyPRP code that would prevent them, but maybe Plasma does somehow.

I've also wondered, since Blender's 2D Bezier curves have much more degrees of freedom than Plasma's (apparently) 1D ones, would it be appropriate to have PyPRP modify the curve in the Blender file to match what was exported?