[Closed] Vertex Position While Moving?
Is it possible to get the position of a vertex in a mesh WHILE it’s being transformed?
I’m trying to create a transform gizmo thing using an editable mesh. But when I move the vertex it only updates when the LMB is released.
Ideas? I tried creating an instance and using the getvert() function from the instance (since the instance updates in realtime) but that didn’t work. I don’t know what else to do.
I ran into this just a few days ago, would be interested in seeing if there is a good solution out there.
My situation was kind-of the opposite. I was messing around creating viewport controls for bezier handles on a spline. The script controllers wouldn’t update as I moved the viewport controls but would work just fine during playback, once keys were set. I found that instancing the script controller that was controlling the handle’s position to an empty track of an exposeTM helper did the trick, but it was a quick hack and I didn’t really go much further with it.
edit: zap – can’t read.
edit2: let’s try again.
feh = undefined; gc light:true -- remnant from testing, good to keep up top so I don't...
-- ...forget to kill that nodeEventCallback
fn handleGeometryChange ev nd = (
obj = (GetAnimByHandle nd[1])
objMesh = snapShotAsMesh obj -- not needed if it's already a mesh
selVerts = (obj.selectedVerts as bitArray) as array
for index in selVerts do (
format "Vertex %: %
" index (getVert objMesh index)
)
delete objMesh
)
feh = nodeEventCallback geometryChanged:handleGeometryChange
ouch. lots of snapshots
edit 3: Works quite happily without the snapShotAsMesh if your object is already an editable mesh (suppose the same should apply to polies)
It might work better if you delete the TriMesh after each call:
delete objMesh
Otherwise it will be leaking like crazy me thinks.
whoops… had it in there then lost it after trying a few other methods; code updated
Ok. Finally got some time to come back to this.
Quick question what is the “GetAnimByHandle” function doing?
Why does the function have two inputs but none are called in the node change handler? How does that work?
EDIT: ahhh it’s related to the Callback.
EDIT EDIT: Oops already got a reply.
the nodeEventCallback lets you specify a function for the given callback type (instead of having a bunch of ‘node*EventCallback’ commands… e.g. ‘nodeGeometrychangedEventCallback’).
That function receives two parameters
- the event type
- the list of nodes, as animHandles, to which this event applies
We don’t care about the event type in this case because we’re only assigning this function to a single callback type (the ‘geometryChanged’ one). If it were assigned to multiple callback types, then the event type can be used to check which one was actually triggered. This would let you specify a single function to handle multiple event types.
The list of nodes -is- actually being used; specifically by the getAnimByHandle function (you’ll note I reference only the first element of the node list; unless you’re Q and can edit two meshes at the same time, that should be fine).
getAnimByHandle essentially returns the ‘anim’ that carries the animHandle specified. An ‘anim’ can be pretty much any maxwrapper (objects, controllers, materials, etc.), as opposed to <object>.handle (which is a different handle value!) which only applies to objects in the scene but otherwise serves the same purpose… having a unique* identifier for the item in question.
( * unique in the given scene – merging, x-ref’ing, etc. will break that )
Ok this is working… sort of ok for my purposes.
It works much much better in SO mode but doesn’t work at all when the object itself is moved.
Is there a way to have the nodeEventCallback execute when the node’s transform is changed. I don’t see it in the list of Events. I figure I could have a second callback but that seems really sloppy.
Also as I’m moving points here is what I’m seeing.
As it’s in motion it’s returning the original mesh but then when my mouse stops moving it updates. Why is it doing this?
Move the vertex a bit slower, perhaps.
Essentially, this is the output I get when I move a vertex normally:
#geometryChanged
Vertex 2: [203.938,-10.6897,-1.78367]
#geometryChanged
Vertex 2: [203.938,-10.6897,-1.78367]
#geometryChanged
Vertex 2: [144.898,-10.6897,14.4525]
#geometryChanged
Vertex 2: [153.754,-10.6897,22.5706]
If I move the vertex around like a madman, then indeed it doesn’t give any result after the first, until I stop moving again.
This might be an internal minimum limit for the delay (the node event system lets you specify a delay after the last event at which which time to actually call the function, so as to prevent calling heavy functions a lot – specifying this as 1ms didn’t help).
well it’s not supposed to work when you just move it; that’s not what you asked for
‘fraid you’ll -have- to set up a second ‘callback’ for that, as the node event system deals only with attributes of the node itself, not its transform.
Specifically, you’ll want to set up a change handler (when transform <objects> changes id:#test do ( <something> ). Keep in mind that you can only set up change handlers for a given set of objects so you may need -another- callback to destroy/create that change handler when objects get selected (doable via the nodeEventCallback again; ‘selectionChanged:<fn>’, or via regular callbacks #modPanelSelChanged, #selectionSetChanged, etc.)
Luckily I have just such a code already available.
That’s what I was trying to replace with this.
Moved: [ http://forums.cgsociety.org/showthread.php?f=98&t=736918 ]( http://forums.cgsociety.org/showthread.php?f=98&t=736918)
Here is my little project.
I’m getting an “unknown system exception” every now and then. Any ideas what’s causing it?