Render Animation very different from Viewport?

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)

4 Likes

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

2 Likes

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?

Thanks,

W

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.

Hello,

I am havin the same problem as Shynn - I have managed to record one animation in arctic as predicted, and then, without having changed parameters, the other animations don’t work anymore.
I think @pascal is correct, it is as if the view is too zoomed in and the shadows disappear. I tried it on Beta too, the problem persists. Any ideas? Why would one animation work and not the other? Im pretty sure I didn’t change the parameters. Thanks


oh my gosh BLESS YOU for this. you just saved me so much work and headache.