MAXWELL plugin Authors?

AdamB

Hi,

There appears to be a bug in the Maxwell SketchUp plugin. Essentially it presumes that no other plugin will be firings its Observers it sets up as SketchUp starts up - obviously not a great assumption. (Also if you turn on $DEBUG, Ruby complains about a few uninitialized instance variables as the maxwell plugin loads which is probably not ideal.)

Anyone know how to contact the authors?

Adam

Chris Fullmer

I believe he is a member here so you could PM him. JD Hill is his screen name. Here is a thread he posted in (about 7 posts down). Find the PM link to him next to his name:

http://forums.sketchucation.com/viewtopic.php?f=180&t=31062

Chris

AdamB

Nice catch Chris. Forgot about that thread - just hope he's the right guy.

JD Hill

@adamb said:

Hi,

There appears to be a bug in the Maxwell SketchUp plugin. Essentially it presumes that no other plugin will be firings its Observers it sets up as SketchUp starts up - obviously not a great assumption. (Also if you turn on $DEBUG, Ruby complains about a few uninitialized instance variables as the maxwell plugin loads which is probably not ideal.)

Anyone know how to contact the authors?

Adam

Apparently, during startup only, SketchUp doesn't like me doing something I do in my onMaterialAdd method. I was not previously aware of any problem here, because that method is never called when SketchUp adds its own materials; however, it is called when a plugin does.

I'll take care of it.

JD

thomthom

Any more details on what it was? Just for future reference to the rest of us?

JD Hill

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

thomthom

I see - because there is no other way to write out a material other than having an entity in the model?
(I briefly was looking at this last week. Was hoping to find a solution that didn't involve adding anything to the undostack or interfering with the model.)

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.