Jump to content


Fastbee

Char anim render takes time to start

Recommended Posts

I'm getting into character animation enough to get some length to some of them.  When I go to render some 3,000 or so frames in and try to do a final render of a single frame 3,000 frames in C4D starts to take several seconds to start the render.  Something that would normally take 2 seconds to render takes 7 seconds.  Using the Point Cache tag makes the problem 2x worst making all the renders take 2x longer to start than if I didn't cache it and that is after I delete all the deformers, pose morph, and anything, but the point cached mesh.  This start up time before rendering seems crazy as when I scroll through the timeline the whole thing updates instantly.  The calculation is a straight forward deformer to mesh thing.  Even without caching it there should be nothing in the length of the animation that should effect start up time of the render.  It should plainly look at the position of the keyframed joints at the frame and do the deformation of the mesh as the bones dictate. 

Am I missing something?  Is C4D this bad with character animation?  Is there any way to fix this or any work around to make it not happen like a plugin or something?

Share this post


Link to post
Share on other sites

 

4 hours ago, Fastbee said:

when I scroll through the timeline the whole thing updates instantly.

Hi

 

All your issues seems to be render issues, the calculation is at render time and this is why the whole thing updates instantly when you scroll through the animation although even then the order or operation can delay certain aspects.  Do you have any dynamics that havent been cached?  Are you using GI. Out of interest if you used the standard renderer with no GI or additions do you get the same issues?  

 

I did a character animation project last year that have many keys but I didnt bake it all down, I cached what I could like dynamics.  I used Vray without GI.

 

Dan

Share this post


Link to post
Share on other sites
  • Topic Author
  • 1 hour ago, Rectro said:

    All your issues seems to be render issues, the calculation is at render time and this is why the whole thing updates instantly when you scroll through the animation although even then the order or operation can delay certain aspects.  Do you have any dynamics that havent been cached?  Are you using GI. Out of interest if you used the standard renderer with no GI or additions do you get the same issues?  

     

    I did a character animation project last year that have many keys but I didnt bake it all down, I cached what I could like dynamics.  I used Vray without GI.

    Yes it is all at render time.  No dynamic, no GI, I don't even have joint dynamics, no anything other than the character which is a single mesh.  When the problem came up I made the scene as simple as possible to try to find the problem.  The whole scene only is the character mesh, skin deformer, pose morph, and joints or if you are talking about after I tried caching it only the character mesh by itself because I deleted everything else to see if it would help.

     

    I had this problem with another project I was working on a while ago on a project that wasn't mine so I attributed it to the many xpresso tags they were using.  This scene is now as simple as character animation can get.

     

    Where you using Cactus Dan's tools by any chance?  I'm kind of thinking that might be a fix.

     

    I'm leaning to this being a bug because I tried putting a noise on the strength of the bend deformer and even 10,000 frames it it still rendered instantly without start up time.  The skin deformer seems like it should be the same, but it's calculating who knows what which gets compounded the more frames you get.  Doing this from anything like mocap data, miximo, or anything with a good length and amount of keyframes should present the problem.

    Share this post


    Link to post
    Share on other sites

    I used a combination of mocap for some scenes which was from a Mixamo rig, but it was a bear that had hair on.  He was carrying a dynamic fishing rod.  Other times not often but one scene had advanced biped  character rig, not issues there either.  

     

    Dan

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • On 11/9/2018 at 11:36 AM, Rectro said:

    I used a combination of mocap for some scenes which was from a Mixamo rig, but it was a bear that had hair on.  He was carrying a dynamic fishing rod.  Other times not often but one scene had advanced biped  character rig, not issues there either. 

    This is funny as it's not what I'm getting.  Testing it further it does not even need to have keyframes in the timeline for it to take longer to start the render.  Having keyframes does make it take longer, but all you need is any joints in the scene at all and it will take longer to start the render the more frames you have even if those joints have no animation.  In the file below I've made some joints and given them no animation.  Since there is not that many joints and they have no animation I've got 30,000 frames in there to better see the problem.  Please let me know if it takes longer to start rendering at frame 30k than frame 0 when you hit Render To Picture Viewer and if you are using Mac or PC.

    Link to file

    Share this post


    Link to post
    Share on other sites

    Hi

     

    Yes it takes 0s to render first frame, and 20s to start to render last frame although as you said there is no animation at all in the scene.  In r20 its 11s.  I put it through vray and its the same so its not the render engine its the pre processing of the whole scene gathering information it needs about the joints.  I never notice this as it only does this on the first frame them zips through all the rest of the frames.  In the event that the animation crashed or stopped id pick it up from the last frame, a few seconds pre processing didnt get my attention as after that it again zips through the rest of the frames after that.

     

    Im guessing that C4D has to look at every joint and process all its initial data even if there is no animation keys.

     

    Dan

    • Like 1

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • Thank you Rectro.  I'll report it to MAXON as a bug.  From my perspective even if there is keyframes it should look at the point data of the joints of only that frame and use that to figure out how the skin deformer is going to react.  It makes no sense to have it calculate anything else.  I'd understand if there was joint dynamics that something would have to be calculated and cached, but there isn't.  My guess would be whatever this bug is coming from is a big reason the character animation playback can be so slow.  Not so bad in the example I posted, but compound that by 1000x due to everything that can be added and you are talking about hundreds of hours of added render time if you want to render something on a render farm with 50 or so computers.  Once the farm gets to the end of the animation it starts to have all the computers jump around frames which means this precompute time will be for all of them for all the end frames.  In a long complex animation a computer precomputing time of 24 hours for a frame to start that would take 10 min. to render is a rendering nightmare.  I'm not exaggerating either.  I've seen renders do this.  Not sure it was just the joints doing it, but precompute times can be a huge killer on a farm.  Precompute times can be so bad it can be faster to render it with a single computer.

     

    It is interesting they made it almost 2x faster in R20.  To me 2x faster character animation playback should be a headline feature.

    Share this post


    Link to post
    Share on other sites

    i don't think it can be called a bug. it's only the first frame that has this prep time, so if you render a sequence from let's say frame 300 to 1000 only frame 300 will have this additional preparing time. the picture viewer just hast to play back the timeline until it is at that certain frame, each following frame will just have to calculate itself, so it renders more or less immediately. to me it just seems like the normal behavior of the picture viewer, which i'm sure MAXON is aware of, but haven't found a solution to solve it otherwise. if you run for instance an x-particles sim with complex stuff in it where you get a vp frame rate of only 1 or 2 fps you will wait several minutes for that first frame in the middle of your animation. it's always been that way, at least since i'm using c4d.

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • On 11/11/2018 at 10:37 PM, everfresh said:

    i don't think it can be called a bug. it's only the first frame that has this prep time, so if you render a sequence from let's say frame 300 to 1000 only frame 300 will have this additional preparing time. the picture viewer just hast to play back the timeline until it is at that certain frame, each following frame will just have to calculate itself, so it renders more or less immediately. to me it just seems like the normal behavior of the picture viewer, which i'm sure MAXON is aware of, but haven't found a solution to solve it otherwise. if you run for instance an x-particles sim with complex stuff in it where you get a vp frame rate of only 1 or 2 fps you will wait several minutes for that first frame in the middle of your animation. it's always been that way, at least since i'm using c4d.

    Xparticles is completely different.  It's doing an actual simulation and when that simulation is baked it will render without a pre processing time.  This is what I would expect.  When something is baked there should definitely be no pre processing time.  In the case of joints it doesn't matter if the skin object is baked or not it will have a pre processing time which gets longer the more frames you have even if there is no animation. 

     

    If you render a sequence from frame 300 to 1000 on a farm with 99 computers computer 1 will start at frame 300 and computer 99 will start at frame 993.  Let's say 10 computers finish earlier than the others.  Those 10 computer will then start to go mid way through the sequence of another computer.  When that finishes they will jump again.  Near the end all 99 computer are jumping to a new frame for ever frame giving you that first frame prep time for each and every frame.  Add to this that the pre calculation time is 24 hours and you got a big problem.  Now consider baking doubles the pre calculation time to 48 hours, as it does when baking a skin deformer now, and you have no way to fix the problem, but to use a single computer to avoid pre calculation time, render the whole thing from the start, and pray there is no power outage, all while missing your deadline because you can't render on a farm due to it actually being slower.

    Share this post


    Link to post
    Share on other sites
    36 minutes ago, Fastbee said:

    Xparticles is completely different.  It's doing an actual simulation and when that simulation is baked it will render without a pre processing time.  This is what I would expect.  When something is baked there should definitely be no pre processing time.  In the case of joints it doesn't matter if the skin object is baked or not it will have a pre processing time which gets longer the more frames you have even if there is no animation. 

     

    If you render a sequence from frame 300 to 1000 on a farm with 99 computers computer 1 will start at frame 300 and computer 99 will start at frame 993.  Let's say 10 computers finish earlier than the others.  Those 10 computer will then start to go mid way through the sequence of another computer.  When that finishes they will jump again.  Near the end all 99 computer are jumping to a new frame for ever frame giving you that first frame prep time for each and every frame.  Add to this that the pre calculation time is 24 hours and you got a big problem.  Now consider baking doubles the pre calculation time to 48 hours, as it does when baking a skin deformer now, and you have no way to fix the problem, but to use a single computer to avoid pre calculation time, render the whole thing from the start, and pray there is no power outage, all while missing your deadline because you can't render on a farm due to it actually being slower.

    i could be wrong, but i think i had that even with baked xp sims with meshing involved. and yeah, you're right about the farm rendering issue. have you tried baking it to alembic? 

    • Like 1

    Share this post


    Link to post
    Share on other sites
  • Topic Author
  • 4 minutes ago, everfresh said:

    i could be wrong, but i think i had that even with baked xp sims with meshing involved. and yeah, you're right about the farm rendering issue. have you tried baking it to alembic? 

    I think the meshing is calculated per frame.  That is there is points and it looks at those points and has to do a calculation to determine the mesh.  Not so bad unless the mesh is dense.  The meshing is also different because it will have the same meshing time with a baked sim no matter how many frames in you are.  That is to say frame 1 with 1,000 particles will have the same meshing time as frame 10k with 1k particles.

     

    Alembic is a good idea.  It could be work around since it gets rid of joints all together in c4d.

    Share this post


    Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    • Recently Browsing   0 members

      No registered users viewing this page.

    ×