Hi,
I am trying to do a fly through animation of a model in Arctic mode. For some reason, when I preview the animation, the viewport turns horribly different than the classic Arctic view. As if all shadows were gone and the definition was downgraded to none. Why is this happening?
See? It looks horrible.
What tool are you using to process the fly-through?
What do you mean what tool? This is a screenshot from my Rhino viewport, while the animation preview is running.
Are you just using Rhino’s built-in animation tools? (_SetFlythroughAnimation) Are you using Bongo or any 3rd-party plug ins?
Do these anomalies occur in any other display modes? Have you tried copying the Arctic display mode and modifying the settings to see if you can pinpoint a variable that effects the issue? Did you try recording the animation to see if the the output frames have the same problem?
Could you share a screenshot of the result you are trying to achieve and/or your 3dm file?
Just Rhino.
I did try recording and it looks like the preview.
Arctic has all default settings, didn’t try changing any.
It does happen in other display modes, like Rendered, but shaded and wireframe work ok.
Edit: It is replicable with any Rhino file.
Here a test.
test.3dm (2.1 MB)
This is what I want to see
This is what I see when animation is on preview.
hmm. I see the issue.
If I run the _Camera command and choose “Show” then adjust the “Distance to Target” variable in properties by dragging the Target Point, I am able to pick up the shadows. Unfortunately, I am unable to get the camera to retain this setting frame-to-frame. I’d ping one of the experts such as @pascal in the morning.
Any ideas @pascal?
My guess of the moment - shadows are screen based in Arctic and they are not being generated in time for the screen recording, or not at all. I’ll see if I can reproduce.
RH-58118 Arctic animation leaves out ambient shadows
-Pascal
Thank you Pascal. How much time does this take to be solved for the next release?
Or what workaround would you recommend? Maybe full rendered animation?
My guess is you could come pretty close with a rendered viewport, all objects white plaster and a skylight set. Groundplane set to use a material, not shadows only, or, set the background color to white.
hm - it is not the same as arctic. The arctic style soft shadows are too different.
-Pascal
I think shadows are also missing in RenderedViewport animation.
Hello - try this: Get a view that looks correct in Arctic and then dolly the camera forward into the scene - you will see as you get in closer the shadowing starts to disappear - I guess this is a characteristic of screen based shadowing.
Your path sends the camera in really close.
-Pascal
Hi, I believe that is not correct, at least that is not the case on my side.
I got really close here, and the result is still dramatically different than the animation.
Compare these two if not:
Animation:
Viewport:
There is something clearly wrong. It has nothing to do with how close the camera gets.
Can’t we just make the animation recording run a little slower so that it captures the shadows? Maybe a custom script that just places the camera into the points of the path curve and captures a screenshot to file? Should be pretty straight forward.
I am sure the function must already be written somewhere, that can save time in creating the script.
Your are correct- itis not just the location - it seems to be related to the distance of the camera to target relative to the distance to the objects… and, if you watch the camera widget travel along the path, it is the smaller kind…
-Pascal
Thanks for looking up on it in detail. What is the course of action here? Wait for the next release?
No course of action known, other than to get with the developers and see if there is one; my guess of the moment is, the ambient occlusion is probably not going to be changed first, I suspect the more practical approach would be to see what we can do to modify the frustum of the camera that tracks on the path in an animation. I have no idea, right now, what is possible.
-Pascal
I will try with a grasshopper script, thanks for wasting my time.
Oh man, really??? Not a very nice thing to say to folks who actually spent time trying to help solve your problem here, and not encouraging for others to help you out… Yeah, times may be stressful now but let’s keep it civil over here please.
Looks like there is an issue with what the automated animated camera/target placement does that the Arctic and some other modes don’t like, but the above “investigation” pretty much nailed what the problem is - since Skylight shadows are View-based (somewhat generated from Zdepth information I think) then camera target being too close to the camera results in almost no shadows. And the path animations will not let you change that parameter. So 90% of the work has been done already, far from wasting time (thanks @Pascal - I had no idea that if we push the target far, the AO shadows get nicer and darker! good find…)
So in case anyone finds that useful, I wrote a script that may help with the above animation problem.
It uses the “ViewFrameNumber” command to manually iterate through the current animation frames, and pushes the target to user-defined distance to fix the shading issue. There is an option to just “Play” the animation or “Record” - in that case you will be asked for the base file name and location and frame numbers will be added to file name. Additionally the script lets you pick any display mode, not only the one picked when defining animation. Recorded frames will be saved using ViewCaptureToFile command, viewport size, but if you need larger sizes you can change the “Scale” parameter in the command prior to recording animation - it is sticky. Note (and I think this is the case with any recorded animation) that the lens will be used from what you currently have set, no matter what was set while defining the animation.
Maybe that helps, for now.
PlayRecordAnimation.rvb (3.3 KB)
–jarek
Hi, thanks. I tried it and I am not sure it is working. It did run once, without entering a custom target distance, but not al frames got printed, it looks like it printed just 5 and then repeated.
If a custom distance is entered I get this error:
But don’t worry. I made it work with a Horster, a plug-in for Grasshopper.
All I did was divide my curve in desired frame count, use point as location of camera and move said point by a distance (target distance) by its tangent vector on the curve. With “animate slider” (right-click on slider) you can iterate through each point. Obviously if you have 960 points, then your animate slider should go from 0 to 960 and inside the “animate slider” menu you must set the frame count to also be 960.
