Guild of Writers

Does PyPRP have issues with exporting animations longer than 1200 frames?

I had cyclic animation of rotating SkyDome which was about 4800 frames long, but after exporting age in URU it looked like animation was trimed to the size of 1200 frames (so instead of full 3600 degrees rotation, SykDome was shifting at 1/4 of animation to initial state). And yes, I tested: after making animation 1200 frames long, it was looking good (except it was to fast for my purpose).

Lucky for me I was able to use script which uses SDL variable to animate SkyDome, but my question remains.

And while on subject:
I heard that there are issues with Teledahn sun animation: different players see it at different position. Is it true? If so: why and how can it be prevented?

Egon wrote:Does PyPRP have issues with exporting animations longer than 1200 frames?

It is not due to the length. I have animations way longer than that. But sometimes animations just get borked enough to break on PyPRP export. I never figured out what causes it and usually when that happens I just start over.

Egon wrote:And while on subject:
I heard that there are issues with Teledahn sun animation: different players see it at different position. Is it true? If so: why and how can it be prevented?

It will happen if the animation is excluded from saving to the age state, which is what Cyan usually does.

With Blender you don't have to worry because it makes animations save to the age state by default. This was multiplayer tested extensively btw with the looping elevator in Adrael.

And if your animation is an SDL animation you should be safe as well.

Did you edit that 4800 frame animation to 1200, using the IPO editor, or did you replace it with a new, shorter one?
If you haven't looked at the curves, there are a few things to consider:

- Blender doesn't in any way "record" your "mouse-play" transformations, prior to your stamping down a key, which means that if you rotate an object 270 degrees and then add a key, Blender will take the shortest route to the destination, placing the key at -90 degrees.
You can solve this, by either insert your two (beginning and end) keyframes and edit the latter in the IPO editor (my choice), or add several intermediary keyframes, at, for instance, 0, 90, 180, 270 and 360 degrees.

- I believe (could be wrongo) pyprp exports all object IPO curves as splines and all texture IPO curves as linear ones, regardless of which interpolation mode you have selected for each curve. This means an unedited object translation/transformation curve will have smooth acceleration and deceleration, which is not desireable for a simple spinning object.
You will need to adjust the spline handles, to make your curve linear.
Also; spline handles should be equidistant on the time axis, between keyframes, because that's where either pyprp, or plasma (don't know which) assumes them to be: they will be exported with the Y axis position seen in the IPO editor, but the X position is "hard coded". ( I use this Blender script, to help dealing with that last matter: download/file.php?id=1475 )

- I have experienced that parented objects sometimes appear to inherit the offset of their parents, relative to whichever frame you've got Blender's framecounter at, when hitting pyprp, whilst themselves still being regarded as being where they were in the world, at their own first keyframe position... or something like that.
For that reason, you may want to rewind Blender to frame one, before exporting, to avoid any surprise offsets.

Jojon wrote:Did you edit that 4800 frame animation to 1200, using the IPO editor, or did you replace it with a new, shorter one?

Actually both. At couple of first tries I was scaling IPO curve. But then I remember that there might be some issues with keys set at float points instead of integer values, so later tests I made by completely redoing RotZ curve from scratch. What's why I'm little worried by this:

D'Lanor wrote:

Egon wrote:Does PyPRP have issues with exporting animations longer than 1200 frames?

It is not due to the length. I have animations way longer than that. But sometimes animations just get borked enough to break on PyPRP export. I never figured out what causes it and usually when that happens I just start over.

Because I might stumble upon this issue with difrent curve (not tied to day cycle) without any good solution.

And yes I had sometime problem with Blender trying to be smarter then me (by changing 360 degrees to 0 degrees), but in the end curves always looked properly before exporting.

Jojon wrote:I have experienced that parented objects sometimes appear to inherit the offset of their parents, relative to whichever frame you've got Blender's framecounter at, when hitting pyprp, whilst themselves still being regarded as being where they were in the world, at their own first keyframe position... or something like that.
For that reason, you may want to rewind Blender to frame one, before exporting, to avoid any surprise offsets.

Thanks for the tip. This might help to solve problems with animations of some other objects in my age.

I had objects rotating around empty, and it worked fine. But as soon I added IPO curves animations to empty "strange things"TM started to happen (objects moving in completely bizarre way). It is strange because I was successful in "chain animation" of objects before (Shell 126).
I'm still in the process of debugging it.

In Breldur I'm using an IPO animation with more than 14000 frames - and it works well.

Egon wrote:I had objects rotating around empty, and it worked fine. But as soon I added IPO curves animations to empty "strange things"TM started to happen (objects moving in completely bizarre way). It is strange because I was successful in "chain animation" of objects before (Shell 126).
I'm still in the process of debugging it.

Some debugging later:
I still don't know the source. I do kind of know some reasons why final age in URU was behaving strange.
For some strange reason child objects attached to a parent object, sometimes have strange coordinates. I had child object whose origin point was exactly at origin point of parent object and in "Transform properties" window instead of Location 0,0,0 I had sometimes non-zero numbers. Redoing parent object and child object helped but that was in no way a solution to problem.

Also: if someone duplicates object must be aware of that deleting all curve animations does not destroy IPOdataObject. For that "X" next to "IP:ObIpo.XXX" (in Curve editor) has to be pressed. And IPOdataObject has to be deleted before duplication of object otherwise object will share the same IPO data.

In the end:
I had enough. After couple of days with this I give up on using parent-child animation because it just does not work properly.
It's a shame.

P.S.
What is a difference between export "As full age" and "Generate release"?

Hmm, child objects... you did not mention that. If they have collision that probably explains your problems. In my experience Uru makes any child object with bounds go out of sync with its parent sooner or later.

In terms of performance it is never good to use bounds for animated objects but sometimes you just need that collision. Use it sparsely though and only on the parent. Or consider using a simple collider animated separately.

D'Lanor wrote:Hmm, child objects... you did not mention that.

Well I think I did it in my second post, but they are unrelated to initial post which was about animation of SkyDome hence the confusion (I have a lot of IPO animations going on in my currently build age).

D'Lanor wrote:If they have collision that probably explains your problems. In my experience Uru makes any child object with bounds go out of sync with its parent sooner or later.

Actually I had notice issue You described at some point, so right now those object which I animate don't have bounds.

Here are steps for reproducing my current issue with child objects animation:
1) Add cube (call it "center") and enable "Actor" for it. it would be good if this cube position be couple of units above age center (position 0,0,0)
2) at frame 1 insert LocRot key
3) Move to frame 800, rotate 180 degrees around Z axis, insert LocRot key
4) go back to frame 1 and export - you got working rotating cube in an age
5) add another cube (call it "rotatingChild") and enable actor for it
6) make "center" parent of "rotatingChild" and align "rotatingChild" it so it would be 4 units away from "center" on X axis
7) go back to frame 1 and export - you got working rotating cube in an age, with another cube "orbiting around it"
8) for cube "RotatingChild" at frame 1 and frame 800 insert LocRot key
9) go back to frame 1 and export - You should have something exactly as in 7

Already at this there is something wrong, because after adding IPO curve to child object it's already is not rotating around parent object at proper position. It is now looking like it was rotating around Age center.

Also during debugging I notice that inserting only Rot key does not coses issues, and deleting Loc curves on child object make it animate again properly.

This bug is generally hard to describe but it looks like at some point location stored in child object animation curve isn't treated as local coordinates (meaning that they are only vector needed to be added to parent object), but instead they are treated as global coordinates.

I might have not notice that during work on Shell 126 animations, because I have there only object bouncing up and down.

Sorry, but for me it is doing exactly what it is supposed to do. Here is a video to prove it.



And it is LocRot as you can see here.

Just a thought but are you deleting the sav file of your age every time you change the animation? If not you can expect weird behavior.