Render Animation very different from Viewport?

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.


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.


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:



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…


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.


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)



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.

camera (9.4 KB)

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.

Really. From the very start all he did was waste my time, which was already wasted dealing with this problem. I easily lost 2 days of work with this crap.

From the very start all he did was waste my time. He got called out first, I waited with no answer, so I called him out a second time and then he appeared, with little to add.

I am here using a piece of software I paid for, need this for a client yesterday, I post a thread that already has a day old, and all I get is a “guess” and a log. No more info.
I had to post another reply to get more information out of him. Will it get solved? When? What do I do meanwhile?
He then proceeds to recommend something, saying it will not really help in the next line. Note that, it is not an edit. It is not like the had an idea and then realized it would not work. Also, the recommendation was not useful for other reasons, which suggest a lack of commitment. Checking if other viewports (Rendered) work is basic before asking the user to try with said viewport.

After this, he proceeded to disregard my problem saying it was my fault, that my path sent the camera too close.

After being proved wrong, he finally decided to spend more than 5 minutes checking the issue. Again, nothing that would help me. Finding out what the problem is the first step in giving an user a solution. Naturally they would ask: “Great!, What now?” What next? How do we solve it?
The user does not care about the problem, it cares about the solution. Imagine the client’s frustration when you say you don’t know what next.

It is very frustrating to face replies of this kind. If Pascal would have ended his posts with “For now we don’t know how to solve this but we will look into into and get back to you as soon as possible” I would be able to at least sleep better.

To all this add the fact that every time I want to export my work out of Rhino I face a problem:

You can’t expect a single person to be available 24/7 to answer your questions immediately…
Also, both people that were trying to help you confirmed that the issue lies in the target distance from camera - something you did not know and later on utilized that knowledge in your own nice GH solution. Again, far from waste of time IMHO.

Yes, it is a bug (or just the camera animation did not catch up with Rhino display) - but you can’t possibly expect any issue found to be resolved immediately. There are 1000s of them and clearly everyone thinks their is the most important. You’ve been here long enough to know that.

He kind of did - or at least reporting an issue into bug tracking system is a standard course of action.
This is something that needs to be discussed and McNeel has developers all over the world working on different parts of Rhino. The issue you reported is touching several areas (display modes, animation tools, shadows engine) so it needs to be looked at first by the devs to decide what to do. The guess is Shadows engine is hardest to fix/least likely to change, so we’ll need to see if the camera animation tool can be tweaked and what workarounds are possible right now. “As soon as possible” is very relative - but typically is not a day or a week in the software development world.

I understand the frustrations of finding problems within the software, especially while on tight deadlines and by no means want to discourage you from reporting these with as much merit as possible. It helps though to have realistic expectations.

In case anyone else finds it helpful, here is the revised version of the script (previously not picking a display mode threw an error): PlayRecordAnimation.rvb (3.3 KB)


No, you are right, I expect the software to work OK, specially when using basic built-in functions. It is not like I was pushing it to extremes or using it in a way it was not designed to, cases in where a bug is much more acceptable. This kind of bug is no different as to having the circle tool fail.
On the other hand I never expected someone to be available 24/7, you can see this thread was already a day old before Pascal replied to it.

He did not, at all. If he had done that, I would not have had the need to ask for clarification multiple times. You can see just below his first reply I did that, and then I had to do that again at the end.

Seriously? This is poor support at it’s best. The easiest thing to say is “there is no solution”. Miraculously, against all odds, there was a course of action. Actually two at least: A custom script, a GH definition.

What is worst, both solutions did not come from McNeel. One from me, one from you. That is a disgrace.

Granted, the information about target distance that Pascal provided was useful. But because of you and me! Another user would have achieved nothing with said information. That information is only useful for the developers to fix the problem.

And this act of providing of information does not rule out the waste of time, at all. I don’t know how you arrive to that conclusion or how that logic of yours works, but that is simply not the case.
Seven comments were exchanged before arriving to that piece of information. Seven!

And then two additional ones where I asked for a possible workaround and was simply replied there was no workaround other than contacting the developers.

This is wrong on so many levels:

First, it should not be me the one asking for a workaround, that should be a given. The standard reply should be directed in solving my problem by providing workarounds in the form of. “You can try this, or that, rather than that you can also try creating a custom script if you know how to code, or try a GH script, there is a plug it that lets you control the camera”.

If I am not wrong @pascal knows how to code. If he does not have the time, I am sure another McNeel user could have done it, it would have been great if Pascal would have said hey @X can you hop in and try a custom scrip? But honestly, how long did it take you to write that code? 20 minutes?

Second it should not be me the one looking for workarounds. You see, not only did I have to “ask” for possible workarounds, I also had to “look” for them, google them, download a plug-in, create a GH definition, try stuff.

I made a bigger effort in solving McNeel’s flaw than McNeel itself.

RH-58118 is fixed in the latest WIP


Thank you @ShynnSup for taking the time to present and discuss this issue. This helped us fix it quickly.

1 Like

Hi, Rajaa and all,

I am still seeing this issue on Rhino7(with the most recent update). I am capturing a bunch of views in the Arctic view setting automatically using the C# component, and the automatically generated views all lose soft shadow completely. Any thought?



Please test in the Rhino WIP. This is where it is fixed.
Rhino 8 WIP is available to you now, so you can take advantage of this (and may other) improvements. See Welcome to Serengeti for details.

Thank you. I will give it a try.