[Closed] Annoying Change Handler/Callback issue:
I cannot find a callback that will return when an object’s geometry is changed(aside from #modPanelObjPostChange which only returns when actually in the modify panel).
Because of the computational intensity of the script, using registerRedrawViewsCallback won’t work as it causes too much slowing in the viewports.
So I figured that the Change Handler geometry could work. Because change handlers only operate on the selection on which it was executed, I had to rig a Change Handler up to a #selectionSetChanged Callback to reinitialize the Change Handler for new object selections. See below:
fn FOO =
(
if selection.count != 0 do
(
when geometry selection changes do
(
print "Geometry Changed"
)
)
)
callbacks.addscript #selectionSetChanged "FOO()" id:#1234
Now the problem is, there is a transform handler, a geometry handler, and a topology handler. The geometry handler returns on anything done to the object including transforms. I don’t understand why, but I need something that only returns on geometric change. This takes me back to my original problem of a computationally intense function being executed far too many times during normal max operation causing slowdown and poor performance.
Any help would be greatly appreciated.
-Dave
This is how I would have done it.
(Actually, I did just that a week ago in a script that must be floating somewhere around – it was about selecting loops and rings in EPoly using the SHIFT and Alt keys and clicking on an edge)
You SHOULD add the
handleAt:#redrawViews
keyword to the When construct though, this way the script will be executed just when the viewport is actually redrawn and will filter out all the redundant messages… You can probably keep track of the latest transformation of the object and filter out events you don’t want to act on I assume?
Thanks Bobo.
The script is part of a larger tool, and the part I’m working on is a “simple” poly counter. It counts renderable triangles(for games), polygons, verts, quads, Ngons, and Tris. Being able to calculate all that with each viewport redraw is what’s slowing down the system. I was hoping that I could just have the counter script update when an object is changed, but there seems to be no real way of doing that.
It gets complex because I was trying to get it to work on muiltiple objects at once, but to do so, it has to add numbers together, and filter out certain classes and superclasses, as well as check for selection states and do some lines of logic to check for errors and such. Doing all that at viewport redraw kills the viewport performance.
In the end, I think it’s too ambitious to ask the system to handle all that in realtime. I’ve set it up now so that certain computationaly intense counters(ie the counter that counts quads, tris, and Ngons) can be enabled and disabled with a button.
I just wish that the geometry and topology Change Handlers actually did what they were supposed to, as opposed to returning a value every time the mesh changes OR is transformed.
Thanks for the help!
-Dave