i have a command, running in a kind of "game loop",
the update happens with doc.Views.Redraw() and RhinoApp.Wait()
the thing is - what specifies the framerate? Because i noticed if i am in "orbit-mode" (right mouse button) the whole loop speeds up by 200%+..
is there any other way to keep the windows alive and increase the update rate?
Can you explain, in detail, what you are trying to do and what is not working? What you have provided does not give me enough information to make any suggestions.
ok sorry, for example:
protected override Result RunCommand(RhinoDoc doc, RunMode mode)
doc.Objects.AddPoint(new Point3d(r.NextDouble() * 10.0, r.NextDouble() * 10.0, r.NextDouble() * 10.0));
} while (!exit);
this adds random points, and updates the viewport, but if you start to orbit the view while the command is running, it suddenly loops much faster.
my question is just, is there a way to control the update speed / wait duration (i guess now its 60hz? - vsync?)
i can live without having control over this (and instead update with a tick event or something..), but if it is possible, please let me know.
> my question is just, is there a way to control the update speed / wait duration
do you maybe have any other suggestion how i can have just the active viewport redraw + orbit control? - i just measured the time of an action - 18 seconds vs. only 3 seconds if i orbit the view.. (i guess even if i could force the orbit view, there would be the problem that i cant access my usercontrol anymore)
I still don't know (fully) what you are trying to do (other than add some points to Rhino). More explaination (fully) would be helpful. Otherwise, I'm not sure I can help.
e.g. i imported a physics library and managed to make a box bounce around the xy-plane (drawing with displayConduit)
now this runs for 500 loops, which is 18 seconds, if i redraw+wait every loop.
If i start to orbit the view while the command is executing, the whole simulation finishes in 3 seconds (box bouncing much faster)
So i figure its not the redraw slowing it down (which doesn't redraw unless the 'wait' comes in), but something else, which is not active when the orbit mode is triggered.
I want to use Rhino to carry out some realtime stuff, and right now this 'wait' thing is severely slowing down things. Hope its clear, and there is a way to overcome this..
btw. the Sample you gave me regarding the classes problem, helped a lot - i am starting to remember/learning the concepts behind OO programming - thanks!
It’s hard to tell where the bottleneck is, or why orbiting the view speeds up your loop. I’m not seeing in your example how the loop even stops.
But. You are updating ALL views in your loop, whereas orbiting will only update the active view. Why don' you get a hold of the active view and redraw it instead? I’m not sure if pipelines and methods are accessible from what you doing, but the fastest way to get a viewport to update is (C++):
Noth will interrupt that, and is pretty much what things like the Spin command do.
If you have a simple example (full program), I’d be glad to step through it and see where the hang-ups are.
i think i found the source of the problem - its the Cplane/World Panel in the lower left corner. If i move the mouse fast while a command is running (screen refreshing) it slows down alot, as the cplane numbers get updated. If the mouse is stationary it get better, but still - while orbiting the cplane info is suspended - and then it loops supersmooth.
Is there a way to deactivate this - or maybe override it?
i will try to create a small sample plugin that shows the problem
You can turn off the status bar in Tool->Options->Appearance.
funny - it really helps. at least when i move the mouse it is not getting slower
i made a small example - if you orbit the view, it speeds up by 5+ times, but only if the viewport is maximized.
maybe you have an idea if i can do something about this. (rather to speed it up, than slow everything down)
sorry - now the right file