I have a medium complex mesh model - about 400K polys total with 500 different parts. My dynamic display is great - I can spin it as fast as I can move the mouse and no stuttering, TestMaxSpeed is 1.3 seconds for 100 redraws… (Quadro K2000)
Now, I want to rotate the model (not the camera) 360 degrees in 4 degree increments - so 90 rotations/redraws. The operation takes 5.2 seconds and there is noticeable stuttering; the speed of rotation is not constant.
Certainly, there is the actual calculation and transformation of the objects that adds to the load. To see how much that is, I cut the redraw and ran the script. It takes about 2.5 seconds. So if I remove that from the 5.2 second results, I get about 2.7 seconds left which should be the time used to to redraw the 90 rotations. That’s only half the rate that TestMaxSpeed gets. (And mouse tumbling is way faster than TestMaxSpeed, but I guess some display trickery is used to drop frames that are not needed…)
Why this is a problem: I’m scripting an animation in which I am rotating 300 different objects like the one above 360 degrees about their center, one by one… And the thing just bogs down tremendously. I cannot get a rotation speed as fast as I would like, but I am prepared to live with the 5 seconds per object…
What is a problem is that I cannot get smooth rotational movement out of it no matter how much I try. I need to use RhinoApp.Wait() to make sure it waits to redraw before doing the next rotate - otherwise it just freezes about halfway through, skips the last half of of the rotations and just finishes at the final position. But, as I said, the incremental rotations don’t all take the same time, so the movement is jumpy. I’ve tried to even it out by adding a dwell time after each rotation, but that is simply added after the RhinoApp.Wait(), so all it does is slow the unevenness down, not eliminate it.
It would be cool to use something like Bongo to do this, but I don’t know if it’s possible to program a rotation and then loop through it with 300 objects like you can with a script. So, any other way to insure that the redraws happen at a more constant rate?
I can provide some cooked-up samples (I can’t post the real stuff yet) if necessary…
I’m not sure what TestMaxSpeed actually does to the scene, but rotating the view with the mouse in an ideal world just changes the world transformation that is applied to each vertex when it is drawn to screen. Since that world transformation should be entirely done inside the GPU and no data be modified, the framerate should be independent from the rotation and entirely depending on scene complexity.
Now if you are actually rotating the meshes, you need to apply another transformation to each vertex and maybe reupload the modified geometry to the GPU. You accounted for the modification but transfer and scene initialization may take additional time that is not necessary when only modifying the camera.
As for frame sync: you typically get the timer ticks(milliseconds) from entering the frame, then another time after finishing the calculation. Then you can calculate the ticks already spent and wait the rest of the given ticks per frame.
Considering the time spent transforming 400k polys, two calls to get the current timer shouldn’t be too much of an overhead.
The other way is to set up a timer thread, that checks on your calculation in constant intervals and starts the next frame of you’re done. That’s a little less overhead in your calculation routine and with most parts of rhino being single threaded, another thread should do no harm. But you will drop an entire frame if the calculation isn’t done in time.
Then again, the timing thread might check back in shorter intervals if the first deadline was not met, then continue in regular intervals after the longer frame is done.
Yeah, just been checking this, the overhead is relatively small…
Most of the objects to be processed are not 400K polys, that was the “worst case scenario”, so I’m looking into reducing the poly count on the worst cases to help things along a bit…
The odd thing is, on the worst case scenario, the time it takes to calculate spikes periodically - which is what I’m seeing as jerky motion. In order to eliminate the spikes, I need to slow everything down to the the worst case… Below is a list of the time actually used to accomplish and redraw each rotation increment for 90 rotations - notice the repeating pattern of two successive rotations every 12 or so that take more than 3x the others, as well as the slowly increasing time for everything (+60% at the end) as the script rolls along… (sorry for the list length)
With… I start the timer before I run the rotation and stop it after RhinoApp.Wait() - which means it should wait until the redraw catches up. My feeling is it’s writing stuff to memory periodically or something… as the memory usage dramatically goes up as the script executes and I have to script ClearUndo after each 360° rotation. Just one of those makes the “idle” RAM usage go from around 275Mb to somewhere around 2Gb. If I don’t clear the Undo, in a few of those, my 16 Gigs are gone…
for i in range(90):
tickStart=time.time()
rs.RotateObjects(objs,orig,4.0,copy=False)
Rhino.RhinoApp.Wait()
print time.time()-tickStart
That sounds like a memory management problem. Looks like the undo buffer is expanded in regular intervals. The memory allocation will take some time.
Any way to disable undo for your script?
That might sound ridiculous but how about ClearUndo every other step or so? Don’t know how rhino handles those calls but that might at least prevent the spiking. If the undo records are just invalidated in the undo buffer to be overwritten or garbage collected later on, that might even be of little to no impact.
I don’t know if there is a scripted way to “suspend” the collection of undo - maybe I can just try temporarily allocating 0 undos and 0 memory to undo in Rhino General options… Nope, doesn’t help…
Hi Mitch, I just updatet Rhino to the latest SR and I get this same jaggyness. Spins, pauses, spins, pauses and so on.
I noticed as rotating a scene with 1000 cubes had this laggy navigation, so I tested testmaxspeed and saw the same there. The lag appears about every second.
My system has never been like this before.
Win7 Quadro 4000.
