I found an example in an Atom add-on, but it is imbricated in a complex code that I don’t want to use such as a rotating empty along with its handler. And I’m not good enough to isolate what I need. Yes its a problem when you’re a kid and want to do adult things ;-).
So…
I was wondering if somebody knew a “simple” way to figure out if blender is rendering. I have a modal timer that I want to stop when rendering because it can cause crashes.
By the way, I have other questions : is there a way to know when
You can add a frame_change handler to your scene as well. It will fire as the animation occurs. Put a counter in the frame change and if the count goes over 1 then your are rendering an animation.
I see what you mean, but in fact it can’t work for what I want to do :
my modal timer runs to compute some calculation when the camera moves and/or frame change, except when rendering (or blender craches). What I want to do is to detect the beginning of image or animation rendering to stop the timer and detect the end to restart it. Beginning and end of rendering is easy. Beginning and end of animation rendering, I don’t know… and frame_change handler does not trigger in the same time as render one… so, 2 solutions :
I restart my timer at the end of every render and stop it at the beginning of every next one. So my timer runs for some ms (?). Why not.
I stop my timer at the beginning of the render of the first image and that’s all. I add a button to restart it.
If you have a better idea… but don’t spend too much time for that. These 2 solutions are enough for me :-).
Thank you for your help.
Timer Detects If Animating:
Well, let’s say your modal timer is running at 0.1 seconds. You could add some decision code in the timer that scans the current frame and increments a counter. In that same code block the next thing you do is check the count against some threshold time. So if you get 200 same frame counts in a second then you are probably not animating. However, if you get a much lower count of same frame numbers in a second then it is likely that the frame just changed? So there would be latency in the system based upon the speed of the modal timer. But the timer could set a flag depending upon which state it guessed it was in.
If the timer is changing the scene then it should probably not be running while rendering. Move the changing scene code into the frame_change handler. The frame change should be calling the same change code that the modal timer is calling. That way the timer could just run and monitor the scene, but when rendering or animating, the frame change would take over and insure the scene change get’s implemented.
Also, in the end if you can successfully bake your animation, you could turn off the timer and everything for rendering from those baked keyframes.
Ok I take my courage in both hands and I dare say I do not agree :-). Timer cannot detect if animating, and for two reasons at least. I should arbitrary choose a limit for secondary counter block inside my timer, but that’s impossible.
First reason : My script calculates the vertices of an (more or less) horizontal plane that are in the field of the camera. If the camera looks to the plane, it is a few hundreds of vertices and it takes less than 1 ms to compute. But if the camera looks to the horizon and is far above the plane, I can have 2 millions of vertices, or more, and calculation time can reach 2 minutes, even more. Thats why I put a option button to engage or disengage the modal timer.
Second reason : Is about the same. When rendering animation, I’m not sure that my render time will be the same for each frame, so how can I choose the limit beyond which I’m probably not animating ?
As for calling the calculation code through the frame_change handler, I fully agree, and I did this already, as soon as I could get rid of context problems (thanks to you, remember another thread). In fact, I call the same code from the timer and from the frame_change handler. The frame_change handler is for rendering and animation, and the timer is for the scene setting/tuning in a given frame. An the timer can be disengage if the plane is really big.
Ok ok, maybe it’s difficult to understand, but it’s difficult to explain to :-). You win. I send you my code, with the scene I work on. Please don’t look at the code, it is very ugly, it is still in progress and I decided to clean it (I hope I can). Just look at what it does and you will understand. It’s not an Add-on, so Alt-P, and you’ll have a panel in the tools panel. There is an animation, if you play with it you will see what it does and what problems I may have. Play the animation in camera view and in top view. You will see that the number of vertices varies a lot, along with the calculation (and animation) time (No sync).
Of course you don’t have to. But I think it’s faster than trying to understand what I wrote (my english is not so good).
And by the way, if I don’t speak to you before, Merry Christmas.
I’m not a developper. I just like to tell stories. For one of them, I needed an infinite plane on which I could apply modifiers. Of course an infinite plane is a problem. So I decided to TRY to write a script that would show only the needed parts of the plane. Taking in account that I’m not a developper and that I’ve known blender for less than a year, I’m rather happy with what I did (self-satisfaction yes).
Now I would like to clean my code but I don’t forget the reason why I wrote this : tell a story. So…
should I move straight to my goal and don’t spend more time on this script (selfish)
work on it again, improve it, clean it, share it (selfless - I don’t forget that blender community is full of altruistic people)
(self-satisfaction yes).