Yes to the same file name. Here is a code:
class MyViewObserver < Sketchup::ViewObserver
def onViewChanged(view)
model = Sketchup.active_model
filepath="c:/temp/untitled.png"
keys = { :filename => filepath, :antialias => true, :transparent => true }
Sketchup.active_model.active_view.write_image(keys)
image_rep = Sketchup::ImageRep.new
image_rep.load_file(filepath)
mat=model.materials["TestMat"]
mat.texture=image_rep
end
end
model = Sketchup.active_model
view = model.active_view
observer=MyViewObserver::new
view.add_observer(observer)
As you admitted earlier API view manipulation calls from Ruby side take place one after the other (i.e. synchronously) so actually there is no need to use view observer to ensure that current view is “up to date” before PNG write activity I suppose. So in the sample above observer is used just to trigger PNG write activity after orbiting/panning/zooming performed by a user (not to ensure view refreshing after view manipulations from a Ruby side). The idea was to check current situation (in SU2018) in regards to file saving operations.
I think you mean that once file saving operation is called by Sketchup.active_model.active_view.write_image
it takes place as some parallel process, and active model view may change during that process (still not sure how it caused saving of an incompletely refreshed view in the past).
Anyway feels like code inside of an onViewChanged
in a sample above runs synchronously including Sketchup.active_model.active_view.write_image(keys)
call in SU2018 under win8. It means texture refreshing in a model takes place when saving of PNG is completed.
Speaking of saving/restoring of a camera, I think it would be nice to save/restore two more parameters of a camera object (perspective and fov).