Face.position_material SketchUp 2014 regression

Marginal

Here's a weird one.

Under SketchUp 2014.0.4900 a (caught) exception generated by a call to Face.position_material appears to cause SketchUp to unwind everything back to the last Model.start_operation. It's as if SketchUp is internally calling Model.abort_operation (but no ModelObserver.onTransactionAbort is generated).

Example code:

Sketchup.active_model.start_operation('Do stuff', true)
entities = Sketchup.active_model.active_entities
f1 = entities.add_face([[0,0,1.m], [10.m,0,1.m], [0,10.m,1.m]])
f2 = entities.add_face([[10.m,10.m,1.m], [10.m,0,1.m], [0,10.m,1.m]])
material = Sketchup.active_model.materials.add("MyMaterial")
material.texture = "/path/to/some/texture/on/your/disk.png"
begin
  f1.position_material(material, [[0,0,0],[0,0,1], [0,10.m,1.m],[0,0,1], [10.m,0,1.m],[0,0,1]], true)  # bogus texture layout
rescue ArgumentError => e
  p "Oops #{e.inspect}"
end
f2.position_material(material, [[10.m,10.m,1.m],[1,1,1], [10.m,0,1.m],[1,0,1], [0,10.m,1.m],[0,1,1]], true)
Sketchup.active_model.commit_operation

Under SketchUp 8 & 2013 this creates two triangles, the second of which is textured. The console says:

"Oops #<ArgumentError; Could not compute valid matrix from points>"

Under SketchUp 2014, no triangles are created and the console says:

"Oops #<ArgumentError; Could not compute valid matrix from points>"
Error; #<TypeError; reference to deleted Face

It's as if the operation was aborted - the material and Face f1 have been deleted.

Weirdly, if I remove the start_operation and commit_operation calls the code behaves correctly (but naturally clutters up the Undo stack).

Has anyone seen anything like this before, and can anyone suggest a workaround?

(I could perhaps convert the faces to be textured into a PolygonMesh, use PolygonMesh.set_uv, and convert back again. But this implies deleting and re-creating the Faces which seems ugly).

tt_su

Hmmm... I can reproduce what you describe... Hang on.

tt_su

Yup! That's a regression in SU2014. An abort was added - with the intent that if the method failed it'd revert any changes it'd made so far. But the side-effect here appeared to be that it reverts the whole of the current operation - not just the current Ruby API method.
I'm logging this bug internally.

Marginal

@tt_su said:

I'm logging this bug internally.
Thanks.

Marginal

Fixed in 14.1.1282. Thanks.

tt_su

Thanks for reporting!