Different renders using RENDER(F12) & ANIMATE (sequence)

Animation tools, character animation, non linear animation

Moderators: jesterKing, stiv

Post Reply
chipmasque
Posts: 0
Joined: Mon Aug 20, 2007 6:31 pm

Different renders using RENDER(F12) & ANIMATE (sequence)

Post by chipmasque »

I'm testing a complex rig I've built that uses pydrivers.py IPO drivers for certain bones that correct for deformation problems such as those at ankles, knees and elbows. This is an alternative to using shape keys, but is automated much the same way.

The rig works as designed, and when the pydrivers.py are in effect, the corrections are applied in real time as the rig is manipulated. When a single frame is rendered, using either the RENDER button, F12, or a single-frame range with ANIMATE (e.g., 56 to 56), the renderings show that the corrective deformations are applied properly.

However, when using ANIMATE to render a sequence of frames, I get different results. In these frames, the correction applied to the deformations is not current with the frame, and seems to "lag" the current frame by one, e.g., for frame 56, the correction for frame 55 is applied. This indicates to me that the IPO driver values generated by the pydrivers.py script are not being updated properly when a sequence is rendered with the ANIMATE button.

This thread on another Blender forum -- http://blenderartists.org/forum/showthread.php?t=119652 -- has more detailed info and some images I put together to document the problem. Has anyone on this forum experienced this? Am I missing some essential aspect of using a pydrivers.py script. Or does this sound like a true bug that needs reporting?

I'm currently using 2.46rc1 in WinXP Home.

SaltyOREO
Posts: 0
Joined: Thu Apr 19, 2007 8:12 pm
Location: Colorado

Post by SaltyOREO »

not an admin but i think that this belongs in the "Coding Blender" forum.

As for your problem, i personally have no idea what your problem is. Try checking the FPS and possible lower OSA to lessen calculating times so your computer can catch up maybe :?

Hope this matter gets resolved
Brandon

chipmasque
Posts: 0
Joined: Mon Aug 20, 2007 6:31 pm

Post by chipmasque »

Thanks OREO, but this is one of those problems that crosses over a number of areas. It's directly related to animation, but also touches on using Python scripting, since it uses scripted IPO channel drivers. But part of the question is why a diff between frames rendered with F12 and frames rendered with ANIMATE. That could be considered a rendering issue. Its all inter-related, but the fundamental problem arises only when doing an animation. Hence the choice of this forum section.

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

The pydrivers are still a work in progress. Note that you *are* using the svn development version rather than an official release.

Best thing to do is file a bug report with an attached .blend showing the problem.

chipmasque
Posts: 0
Joined: Mon Aug 20, 2007 6:31 pm

Post by chipmasque »

Right. stiv, I know that 2.46rc1 isn't "release" status yet (but they intend it to be very soon), and my main reasons for posting were to

1) see if I was missing some aspect of using the scripted IPO drivers that would solve the problem (i.e., user error instead of a bug)

2) see if this had already been identified and reported -- no need for duplicate bug reports

On a side note, I've written a small script that negates the problem by automating some discrete UI steps and bypasses using ANIMATE for an image sequence rendering. I'll post it if anyone's interested.

NielsBlender

Post by NielsBlender »

.,

Not seeing the pydrivers, the 'lag-bug' looks like a 'cycling-lag', which might not be the case if there really is a pydriver-update-lag but then again it would probably had shown in both render-types.

A work around could be an extra script ON RENDER, to re-apply the active-poseMatrix or re-apply them separate loc, quat, size.

A solution you might not want to consider but is the better solution if you would ask me... is to use the new constraint-SCRIPT.

chipmasque
Posts: 0
Joined: Mon Aug 20, 2007 6:31 pm

Post by chipmasque »

The Script Constraints look really useful, but I've already invested a lot of hours into the pydrivers.py approach (begun before the new constraints were available) and my rig is built to use them, plus there's a whole new learning curve to using the Script Constraints that I just don't have time to invest in right now. The script I wrote to avoid using ANIMATE for sequences seems to work OK, though I have to write an Esc detect into it (duh) . :wink:

As far as the "lag" goes, I've checked for cyclic dependencies and there are apparently none. Not sure what other sources might be, perhaps it has to do with bones driving bones within the same armature, or some difference in the routines that handle rendering a still and rendering a sequence that wasn't known to have this consequence under these conditions.

NielsBlender

Post by NielsBlender »

chipmasque wrote:plus there's a whole new learning curve to using the Script Constraints that I just don't have time to invest in right now.
To save you some time, when you do want to...
Basic handling within a scriptconstraint is easier than the pydrivers-principle.

Using pydrivers you normally throw in the name of the bone(and posematrix) then you look-up the other bones(targets) and apply a different matrix to the pydriven-bone. (You probably have a script that sets other bones having constraints as well(or are 'py-driven' against eachother), I think there the boggle is at the end... ;) )

The constraint-script delivers you the matrix of all target-bones automaticly (the bones you would normally have to 'look-up') and of course the main-bone-matrix is there as well... When you do want to set other bones using the constraint-script, the function to evaluate an earlier bone is there...this will prevent 'lags' and possible wrong calculations...

Niels

Post Reply