|
By chris_85 - 9 Years Ago
|
I'm testing CTA3 and how it would incorporate into a Premiere workflow.
I created a single scene in CTA3 (which worked great--love the free-form bone deformations!). Once I was happy with it, I then proceeded to export the sequence (tried both AVI and MP4).
The problem I have is that the exported video is framed differently than what I see played back (via F12 aka Full Screen Mode without Safe Area, or just by watching what's in the safe area without going full screen).
For example, here's the final frame within CTA3 (which I like and is "correct"):
But here's the actual result of playing back the exported video: (Note also that F10 aka Current Frame Preview also exports an image identical to this one below.)
Is this a bug? Am I doing something wrong? (And if so, what am I missing?)
Finally, the bone-based animations do not play back in the exported video either. Is this a bug? Is this a limitation of the demo? If it is a demo limitation, what guarantee do I have that CTA3 really works right?
Thanks in advance for help!
--Chris
Windows 10, CTA3 DEMO (v3.01.1116.1), High-DPI screen
|
|
By Peter (RL) - 9 Years Ago
|
Hi..
I see from your screenshot that you have Live Camera ON. It may be that you something going on with an erroneous camera key that is causing the problem. Try turning Live Camera OFF to go back to the Preview camera and then try exporting the video again. Does the same issue occur?
|
|
By chris_85 - 9 Years Ago
|
Without live camera on, no camera movements play back, and my whole scene is worthless, as I have very carefully laid out camera moves. But I tested it anyway: exporting with live camera OFF exports a video where the image is completely static. This is still interesting information, because:
1. The puppet animations do not play at all in the rendered WMV (or other formats I've tried)--why not?!?
2. What is exported is *different* than what I see from within CTA3 when I play the project back (with Live Camera OFF)--why?!?
So: the Render > Render Video menu item in both cases (Live Camera ON vs OFF) renders a video that is different than what is viewed when played back within CTA3 with the corresponding setting. It's like the Render Video is using an improperly configured camera--it's partially correct, but the framing is different, and puppet animations do not play back.
|
|
By Edward (RL) - 9 Years Ago
|
Are you use the Trial version?
Take look the Trial part, there are some limitations.
http://www.reallusion.com/crazytalk-animator/download.html#comparison
|
|
By chris_85 - 9 Years Ago
|
This is clearly a bug in CTA3. I've been able to fix my scene to work. It appears that in 3D view, my background prop (i.e. the stars and sky) and the "hill" prop (back silhouette) where placed "below the horizon". This should be 100% legal, but apparently the Rendering engine behaves differently when exporting (perhaps refusing to be move below zero on the Y-axis?).
Once I dragged everything "up" (higher on the Y-axis so that nothing was below zero) and re-entered all of my camera and transform keys, everything finally exported identically to what I was seeing in CTA3.
NOTE: Moving stuff up on the Y-axis *also caused the puppet movements to start rendering again*! Is there logic in the Render Video to ignore animations on props below zero on the Y-axis? Something really strange is going on within the Render Video code that needs to be fixed.
Note that I did, for thoroughness' sake, try re-entering all of my camera and transform keys *without* moving the props above the zero on the Y-axis, and this did NOT fix the problem. So the problem did not appear to be the key frames, but rather something to do with the Y axis. Finally, I also tried running CTA3 non-high-DPI in case this bug was related to a high-DPI configuration. The problem persisted in both a "normal" DPI screen. Furthermore, my above fix worked both on a high-DPI screen as well as a normal DPI screen. So I'm fairly confident that this bug isn't high-DPI related, but can't totally rule it out since I work mainly on a high-DPI laptop.
Anyway, at least I can breathe a sigh of relief that I can actually use CTA3 for my Christmas project, although this bug really should be fixed--it's quite confounding otherwise.
--Chris
|
|
By chris_85 - 9 Years Ago
|
|
MYSTERY SOLVED!
This whole problem was caused because I had a prop in the scene without a check in the "Show" column of the Scene Manager. Apparently the state of the Scene Manager is IGNORED when using Render Video (or Current Frame Preview). Thus, this prop WAS rendered for the video, but was never rendered from within CTA3.
This also explains the lack of puppet animation on my export, etc., etc. Essentially the prop I had hidden (by removing the check from the Show column) was a dummy, static image I was using to allow me to position the props and final camera for the final composed image I was going for at the end of the scene. After I had things properly set up, I just "hid" it by unchecking the Show checkbox. I had no idea that CTA3 would choose to render it in the video anyway.
Is this actually *desired* behavior? It seems that it would be very useful to hide "utility' items like this that you'd never ever want rendered, but need to refer to occasionally in order to set up a scene. It seems that a checkbox on the Render Video dialog for "Render all props without regard for their "Show" status in the Scene Manager" would be good for two reasons: (1) It would allow both the current behavior of always rendering everything as well as the behavior of rendering only "Shown" items; (2) It would serve as a warning to newer users that the "Show" column of the is ignored if you don't tell it otherwise.
In any case *something* should be done, because is it both NOT OBVIOUS nor is easy to discover what's going on--i.e. that Render Video *purposely* renders something DIFFERENT than what is seen when playback is initiated within CTA3. The whole advantage of these tools is that what-you-see-is-what-you-get... except it isn't in this case (with no help in discovering WHY it isn't).
|
|
By Peter (RL) - 9 Years Ago
|
Great to hear you have resolved the problem. Your original post referred to a framing issue which made it seem like a camera issue initially. Now you have explained more it is clear there was a lot more going on than just a simple framing issue.
Regarding dummy Props showing in your renders. You don't want to use the Show checkbox in Scene Manager as this only applies to the preview window. If you don't want the prop to be visible in your renders just toggle the "Visible/Invisible" button on the top toolbar. Anything that is set to Invisible won't be seen in the final render.
|
|
By Peter (RL) - 9 Years Ago
|
|
chris_85 (12/8/2016)
This is clearly a bug in CTA3. I've been able to fix my scene to work. It appears that in 3D view, my background prop (i.e. the stars and sky) and the "hill" prop (back silhouette) where placed "below the horizon". This should be 100% legal, but apparently the Rendering engine behaves differently when exporting (perhaps refusing to be move below zero on the Y-axis?).
Once I dragged everything "up" (higher on the Y-axis so that nothing was below zero) and re-entered all of my camera and transform keys, everything finally exported identically to what I was seeing in CTA3.
NOTE: Moving stuff up on the Y-axis *also caused the puppet movements to start rendering again*! Is there logic in the Render Video to ignore animations on props below zero on the Y-axis? Something really strange is going on within the Render Video code that needs to be fixed.
Note that I did, for thoroughness' sake, try re-entering all of my camera and transform keys *without* moving the props above the zero on the Y-axis, and this did NOT fix the problem. So the problem did not appear to be the key frames, but rather something to do with the Y axis. Finally, I also tried running CTA3 non-high-DPI in case this bug was related to a high-DPI configuration. The problem persisted in both a "normal" DPI screen. Furthermore, my above fix worked both on a high-DPI screen as well as a normal DPI screen. So I'm fairly confident that this bug isn't high-DPI related, but can't totally rule it out since I work mainly on a high-DPI laptop.
Anyway, at least I can breathe a sigh of relief that I can actually use CTA3 for my Christmas project, although this bug really should be fixed--it's quite confounding otherwise.
--Chris
Just to add if you feel there is a bug or issue with CTA3 please report it in our Feedback Tracker. This is monitored by the CTA team and they will supply feedback on any bugs or issues reported. Thanks.
|
|