[Closed] Snapshot without destroying edge-index order
I usually use snapshot followed by ConvertToPoly when working with geometry as I find this to be way faster than clone. However, when using snapshot it seems to mess up the edge-index ordering.
Here’s a script to reproduce the issue:
tmpCylA = Cylinder radius:5 sides:5 height:15 heightsegs:1 pos:[0,0,0] isSelected:on
convertToPoly tmpCylA
tmpCylB = snapshot tmpCylA
convertToPoly tmpCylB
move tmpCylB [10,0,0]
polyop.setEdgeSelection tmpCylA 6
polyop.setEdgeSelection tmpCylB 6
When running the script above, you should see that edge-index 6 is different on the two objects, while the vert and face indexes seems to be unchanged.
Is there any way to prevent messing up the edge ordering when using snapshot?
You might want to ask that question again in the MaxScript subforum, not sure how many of the people frequenting it are also reading the main forum.
Have you tested if snapshot (mesh conversion) and conversion to poly gives the same edge order each time? Then you’d just have to add an initial snapshot or mesh conversion before you begin. It might be the primitive that’s converted differently.
Thanks for notifying me, I didn’t realize, I’ve moved it now. It’s not only for primitives, the same thing happens on all kinds of meshes it seems, but thanks for the suggestion
it’s to do with how a cylinder is converted to a mesh or a poly… when converting to poly the vert in the center of the cap is removed but when converting to mesh(snapshot) it remains
delete geometry
tmpCylA = Cylinder radius:5 sides:5 height:15 heightsegs:1 pos:[0,0,0] isSelected:on
tmpCylB = snapshot tmpCylA -- converts to a mesh
convertToPoly tmpCylA
move tmpCylB [10,0,0]
tmpCylB.alledges = on
tmpCylA.alledges = on
demonstrates the issue…
it’s due to the fact that unlike most other objects cylinder has a specific convert to poly function (in constructs a poly object) where as most other primitives just go via a mesh first
Thanks for your response. It makes sense when I have the cap, but why does it still occur when the caps are deleted?
tmpCylA = Cylinder radius:5 sides:5 height:15 heightsegs:1 pos:[0,0,0] isSelected:on
convertToPoly tmpCylA
polyop.deleteFaces tmpCylA #{1, 7}
tmpCylB = snapshot tmpCylA
convertToPoly tmpCylB
move tmpCylB [10,0,0]
polyop.setEdgeSelection tmpCylA 6
polyop.setEdgeSelection tmpCylB 6
seems to be an issue with snapshot conversion to mesh from poly…
tmpCylA = Cylinder radius:5 sides:5 height:15 heightsegs:1 pos:[0,0,0] isSelected:on
convertToMesh tmpCylA -- convert to mesh first
tmpCylB = snapshot tmpCylA
convertToPoly tmpCylA
convertToPoly tmpCylB
move tmpCylB [10,0,0]
polyop.setEdgeSelection tmpCylA 6
polyop.setEdgeSelection tmpCylB 6
Yeah I found that to work too, I’m just a bit skeptic about messing around with the source mesh. Morph targets would probably still work as the vert order is identical, but I can imagine it could cause some unforeseen problems. Ideally I would like the source mesh to be “untouched”, but that might not be possible?
Also, the collapsing seems to affect the speed a bit more
fn quickSnapshot obj =
(
comPanel = getCommandPanelTaskMode()
setCommandPanelTaskMode mode:#create
addModifier obj (Edit_Mesh()) before:obj.modifiers.count
maxOps.CollapseNodeTo obj obj.modifiers.count true
objSnap = snapshot obj
addModifier obj (Edit_Poly()) before:obj.modifiers.count
maxOps.CollapseNodeTo obj obj.modifiers.count true
convertToPoly objSnap
setCommandPanelTaskMode mode:comPanel
return objSnap
)
as i understand you do it for morph targets…
technically for it you need a mesh objects (which you do by snapshoting the node). but many poly and polymesh objects can change a topology after converting it to and back from mesh to poly. That’s how poly object create the poly structures. We can’t control it.
But go back to the original issue…
the only what you need is a node’s current mesh state with no difference what modifiers are applied to the node.
and this mesh is
node.mesh
you must use the mesh copy if you need to make an editable mesh object.