View Full Version : Vertex Position While Moving?

02 February 2009, 12:08 AM
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.

02 February 2009, 12:24 AM
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.

02 February 2009, 02:36 AM
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 %: %\n" 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)

02 February 2009, 03:44 AM
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.

02 February 2009, 04:04 AM
whoops... had it in there then lost it after trying a few other methods; code updated :)

03 March 2009, 08:11 PM
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.

03 March 2009, 08:19 PM
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 )

03 March 2009, 08:42 PM
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.

03 March 2009, 08:46 PM
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?

03 March 2009, 08:51 PM
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.)

03 March 2009, 08:56 PM
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:

Vertex 2: [203.938,-10.6897,-1.78367]
Vertex 2: [203.938,-10.6897,-1.78367]
Vertex 2: [144.898,-10.6897,14.4525]
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).

03 March 2009, 09:00 PM
Luckily I have just such a code already available.

That's what I was trying to replace with this. :D


Here is my little project.

I'm getting an "unknown system exception" every now and then. Any ideas what's causing it?

03 March 2009, 09:04 PM
Also looks like it's got some "First Run Jitters". And needs to get a crash out of its system when run from a cold start.

EDIT: Also from time to time.... all of the nodes converge into one place and slowly rise up into the sky.... don't know what's causing that either.

(Recommend use: an array of teapots selected.)

03 March 2009, 09:06 PM
just to follow-up on that 'internal delay' bit... doesn't look like that's actually it. Looks like max (or maxscript) event processing itself simply halts as long as you move the vertex around 'too quickly'. E.g. a timer (dotnet) set to poll the vertex position very 100ms will fail to fire when moving the vertex around quickly just as well.

03 March 2009, 10:18 PM
I don't think that's it either. I can slllllooowwwly move the vertex around for a minute. And it sort of flashes a bit. But won't do the proper transformation until the cursor stops.

Now I just need to get it to delete the gizmo when de-selected.

EDIT: Ok I fixed the deselection so the "non-realtime" update is a little quirky but I can live. with it. Updated script poste. (

CGTalk Moderation
03 March 2009, 10:18 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.