MAXWELL plugin Authors?

JD Hill

I don't think there's any other way. I have worked over this particular piece of code a lot...I have tried using a Group instead of a Face, but that becomes a pretty bad idea when the Outliner is opened and there are lots of Groups/Components. I've tried all different combinations of start_/abort_/commit_operation, and haven't found any combination that yields a useful or predictable result. If you skip those, you can stay out of the Undo stack. Which is good, because it is only when using them that I was able to produce a few bugsplats when the records they added were undone.

I would kill for a better way of getting a texture on disk.

thomthom

@jd hill said:

I don't think there's any other way. I have worked over this particular piece of code a lot...I have tried using a Group instead of a Face, but that becomes a pretty bad idea when the Outliner is opened and there are lots of Groups/Components

oh... ... goes to rewrite some code

@jd hill said:

I've tried all different combinations of start_/abort_/commit_operation, and haven't found any combination that yields a useful or predictable result

No - using abort didn't work well?

@jd hill said:

If you skip those, you can stay out of the Undo stack.

? How do you mean? You avoid the undo stack by not using start_operation?

jeff hammond

@jd hill said:

Adding a temporary Face in order to write out a texture via a TextureWriter.

i tried the maxwell demo and noticed it included one of my pet peeve features (and i guess it's this temporary face thing that causes it)

the peeve is:
upon launching SU or a new su window, the model isn't 'new'.. if you close the window then you have to go through the 'do you want to save..?' dialog..

i'd rather the window stay fresh until I personally do something to it.

JD Hill

@unknownuser said:

and i guess it's this temporary face thing that causes it.

I understand, but actually, it's not related to this issue at all, and it should not happen in all cases. If I set a single attribute on the model, then SketchUp will put up that dialog. So I'll look into it and see if there are some cases where I am, but do not strictly need to be, persisting data.

Of course, everything here changes with the new ModelObserver.onPreSaveModel method. I would obviously prefer never to store anything at all until you are actually saving the document.

@thomthom said:

Using abort didn't work well?

Not as far as I've been able to determine. I've tried aborting rather than erasing, committing after erasing, using different combinations of flags in start_operation, and I have not found any way to handle it cleanly. Were this Cinema, you'd just make a new document, in memory, do the work there, and then delete the document.

@thomthom said:

@jd hill said:

If you skip those, you can stay out of the Undo stack.
? How do you mean? You avoid the undo stack by not using start_operation?

Well, I thought that was the case, but now double-checking, it certainly seems not to be.

thomthom

@jd hill said:

Well, I thought that was the case, but now double-checking, it certainly seems not to be.

YEa - you should be getting lots of small ones. start_operation is for grouping items on the undo stack.
If only the transparency flags where working better.

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.