MAXWELL plugin Authors?

JD Hill

Yes, that's a nice idea in theory, but the point is that it is difficult to discern any consistency regarding if/how/when those calls work. I have in the past, and just now again, been going over this, trying to infer what happens, and I do notice now that it has much to do with things working differently in various contexts. I have three basic scenarios where I end up needing to write a new texture:

a textured material is selected for the first time
a textured material's color is edited via SketchUp UI
a material's color is altered via my UI -- goto (2)

In cases (1) & (3), I have found no way to prevent the necessary add_face, material=, erase_entities sequence from showing up in the undo stack, nor have I been successful in consolidating those three things such that they would appear as a nice, single undo item.

Case (2), however, apparently executes within a special context, where the only item added to the undo stack is an Edit Material action, regardless of what other actions occur as a result of it (i.e. apparently, within the context of onMaterialChange from a plugin's POV). So that's where the idea came from that what I do wasn't showing up; it really wasn't, but only when triggering the action via SketchUp's material UI.

In cases (1) & (3), with no start, abort, or commit, and after drawing a rectangle, I seem generally to obtain this sequence:

Undo Properties
Undo Properties
Undo Rectangle

Using start with [abort or commit] around the whole operation, this becomes:

Undo Properties
Undo Erase
Undo Assign Material
Undo Create Face
Undo Write Texture (the name given to start_operation)
Undo Rectangle

Attempting to use multiple starts/commits, with seemingly-logical combinations of the 3rd and 4th start_operation bool parameters, one can achieve different, but not necessarily better, results. On the hunch that maybe it would work better if an entire method were wrapped, I tried that too, but it made no apparent difference.

Therefore, I have to say, I do think that overall, the undo stack stays cleaner (would that it could be done truly transparently without all this hackery) when you do not use start, abort, or commit, with this specific operation.

I'd be curious to hear what you observe there, since you say you were working on the same thing.

AdamB

JD, I think you've got to bite the bullet and use the COM interface to get the ISkpMaterial, then extract a ISkpTexture on which you can call WriteToFile().

On a related note, anyone else experience that TextureWriter is stupidly slow for large images? ie a model has a 2000x1000 bmp texture and Texturewriter can take minutes to write it out.

thomthom

I just tried with a small experiment - related to another thread: posted there:
http://forums.sketchucation.com/viewtopic.php?f=180&t=31595&p=279046#p279046


tw = Sketchup.create_texture_writer
model = Sketchup.active_model

model.start_operation('Write Textures', true)

tmp = model.definitions.add('Temp_TextureWriter')
g = tmp.entities.add_group
model.materials.to_a.each_with_index { |m,i|
  next if m.texture.nil?
  g.material = m
  tw.load( g )
  p tw.write( g, "c;/temp/mat_#{i}.png" )
}

model.abort_operation

This writes out the textured material in the model without adding to the undo stack and without touching the model's entities - meaning it also doesn't interfere with the Outliner when creating the temp entities.

thomthom

@adamb said:

JD, I think you've got to bite the bullet and use the COM interface to get the ISkpMaterial, then extract a ISkpTexture on which you can call WriteToFile().

Via C or C++?
Or calling the SU COM via ruby API? (Is that possible?)

@adamb said:

On a related note, anyone else experience that TextureWriter is stupidly slow for large images? ie a model has a 2000x1000 bmp texture and Texturewriter can take minutes to write it out.

Haven't really timed things - but have some times thought that writing images took longer than necessary.

AdamB

It has to use C/C++ to talk to the abortion that is COM

Did a quick test on a Mac and it works fine and doesn't add any Undo transactions.

require "Texwriter.bundle"
a_material.dumptexture("/dodah.jpg")

Texwriter.bundle.zip

thomthom

Was it via the COM interface you managed to get the layer material?

AdamB

@thomthom said:

Was it via the COM interface you managed to get the layer material?

Yep. BTW You can get the Layer color etc but there doesn't exist an actual Material..

And here's a Windows build of it. Same method name etc

Texwriter.so.zip

thomthom

@adamb said:

It has to use C/C++ to talk to the abortion that is COM

I thought COM was a Windows thing...

thomthom

Adam - any chance you could post the source for these Ruby Extensions - as simple examples of interacting with the SketchUp COM interface?

JD Hill

@adamb said:

JD, I think you've got to bite the bullet and use the COM interface to get the ISkpMaterial, then extract a ISkpTexture on which you can call WriteToFile().

On a related note, anyone else experience that TextureWriter is stupidly slow for large images? ie a model has a 2000x1000 bmp texture and Texturewriter can take minutes to write it out.

Ugh. I'd rather not do that. And yes, my recollection is that WriteToFile seemed to be quite slow. But I don't use it; if WriteAllTextures fails, I fall back to using WriteTextureFileFromHandle. Can't say that I specifically compared the performance of that with WriteToFile though.

@thomthom said:

I thought COM was a Windows thing...

Not really, COM is just the definition of a set of contracts which are designed to allow unrelated components to connect to and obtain services from one another; roughly speaking, is_a? and respond_to? for C++.

And thanks for the idea of using a Definition; that's perfect.

thomthom

@jd hill said:

And thanks for the idea of using a Definition; that's perfect.

Mind you - if you don't use abort_operation you'll end up making lots of temp definitions cluttering up the In Model definition list.