[thinkbuild]

Greetings to all. First - JD: the plugin is beautiful, it has really pushed SU into the Maxwell world in a wonderful way. Thanks once again.

Here a few more comments - I'm not sure if they have been touched on in Stefan's extensive posts above, but I think not. My main issue is what I would call "material slippage" - ie, materials being somehow accidentally assigned. I agree with most of what Stefan says in his first post about the material panel not always being "active" and also think that the eyedropper should have an option-click add function if at all possible.

Q: What is the difference of using the SU eyedropper/paintbucket to your tools? If I use the SU eyedropper and copy an assigned mxm, isnt that then the same function?

Wish 1:
Why can't we have a Maxwell context menu for materials_?
This would be under :

-
separtate by...
UV overide...
-
export selection
selection info
-
current material is : <name of material >
assign material > (show list of materials, same as in material manager)



Wish 2:
rename materials in Mx scene manager, Materials,
right-click on name of material (instead of Silverlight Prefs), it should say,
"rename material"
"set to default"
"edit in MXM editor"

***
Now, my BIG problem/wish 3:

I find it very hard to understand what files will be produced on export - the issue for me is with the disk menu:

At the top, it says

Name / .jpg
Folder

Suggestion, Why not replace this with a structure like this:

Files
Image Name, Type (.jpg, .png, .tif, etc...)
MXS, Folder
MXI, Folder


I find that the file names often slip to some random value - rb.mxs ??? And it USUALLY (but not always) puts the .mxs in the folder for the image, but I am not certain - or am I missing something?

JD: Hopefully this is clear - If you like I can post screenshots of theses critiques/wishes .... please advise.

Otherwise, keep up the good work!

best to all from Berlin

[JDHill]

My main issue is what I would call "material slippage" - ie, materials being somehow accidentally assigned.

I guess I am not clear on what you mean by 'accidentally assigned'. Could you describe that in a little more detail? How it works is that the plugin uses whatever SketchUp material is assigned to an entity.

Q: What is the difference of using the SU eyedropper/paintbucket to your tools? If I use the SU eyedropper and copy an assigned mxm, isnt that then the same function?

The plugin's tool was added due to user request, mainly for the purpose of being able to select entities/materials without having the SketchUp material browser opened.

Wish 1:
Why can't we have a Maxwell context menu for materials_?

Something like this would be possible -- I'll play with the idea and see how it could work.

Wish 2:
rename materials in Mx scene manager, Materials,
right-click on name of material (instead of Silverlight Prefs), it should say,

The SketchUp Ruby api does not allow for this -- you have to use the SketchUp user interface if you want to rename a material. On the second part, this version of Silverlight does not support a right-click menu.

Now, my BIG problem/wish 3:

I find it very hard to understand what files will be produced on export - the issue for me is with the disk menu:

At the top, it says

Name / .jpg
Folder

Suggestion, Why not replace this with a structure like this:

Files
Image Name, Type (.jpg, .png, .tif, etc...)
MXS, Folder
MXI, Folder

I had setup similar to that a long time ago in other plugins, and people found it to be very tedious to use. So, the plugin always writes image/mxs/mxi files using the same output name. If you enter a name, it will be used, otherwise the SketchUp document's name will be used. If the SketchUp document has not been saved yet, then the output name will be 'Untitled'. Similarly, if no output directory is specified, the output will either go into the same directory as the current SketchUp document, or in the case that the document has not been saved, to [user folder]/Maxwell/output.

However, it seems you are saying the plugin is sometimes picking a random output name -- could you elaborate on this? It should be following the rules I quoted above.

[thinkbuild]

My main issue is what I would call "material slippage" - ie, materials being somehow accidentally assigned.

I guess I am not clear on what you mean by 'accidentally assigned'. Could you describe that in a little more detail? How it works is that the plugin uses whatever SketchUp material is assigned to an entity.

This is a difficult-to-reproduce, randomly occurring error in which, for example, the edge of window frame became an emitter.
I don't think it is any kind of a programming error, but rather a human factor error. I will try to pay close attention to the situation if I see this happening again in order that I can help you reproduce (if in fact there is a problem). By human factor error, I mean: I have a dropper to pick, a box to assign, and the plugin does not always give feedback instantly but rather needs a double click, click out, click in, etc. (as described in the other thread in depth) - thus, it is possible that with all the clicking, I myself accidentally assigned the edge of window to an emitter, without intending too.

This is part of the reason I have requested the added context menu which will (hopefully) show which material is assigned to the geometry, and/or allow it to be quickly switched without going into the silverlight plugin.

Q: What is the difference of using the SU eyedropper/paintbucket to your tools? If I use the SU eyedropper and copy an assigned mxm, isnt that then the same function?

The plugin's tool was added due to user request, mainly for the purpose of being able to select entities/materials without having the SketchUp material browser opened.

Yes, I remember this request and think it is a great addition. My question is however: if I assign a material using the SU material tools, specifically using eyedropper, then bucket, does it properly assign associated .mxm's? In my testing, it seems to do this, but I am trying to find out if this is expected behavior from your side.

Wish 1:
Why can't we have a Maxwell context menu for materials_?

Something like this would be possible -- I'll play with the idea and see how it could work.

Super! Would be wonderful for the above stated reasons.

Wish 2:
rename materials in Mx scene manager, Materials,
right-click on name of material (instead of Silverlight Prefs), it should say,

The SketchUp Ruby api does not allow for this -- you have to use the SketchUp user interface if you want to rename a material. On the second part, this version of Silverlight does not support a right-click menu.

OK

Now, my BIG problem/wish 3:

I find it very hard to understand what files will be produced on export - the issue for me is with the disk menu:

At the top, it says

Name / .jpg
Folder

Suggestion, Why not replace this with a structure like this:

Files
Image Name, Type (.jpg, .png, .tif, etc...)
MXS, Folder
MXI, Folder

I had setup similar to that a long time ago in other plugins, and people found it to be very tedious to use. So, the plugin always writes image/mxs/mxi files using the same output name. If you enter a name, it will be used, otherwise the SketchUp document's name will be used. If the SketchUp document has not been saved yet, then the output name will be 'Untitled'. Similarly, if no output directory is specified, the output will either go into the same directory as the current SketchUp document, or in the case that the document has not been saved, to [user folder]/Maxwell/output.

However, it seems you are saying the plugin is sometimes picking a random output name -- could you elaborate on this? It should be following the rules I quoted above.

I will pay close attention to this situation and try to report back, now that I know what it should be doing.

Nevertheless, I think it might be quite nice to have the option to rename everything as stated above.
If the boxes are left blank, then it should simply follow the very sensible rules you listed.

I think the confusion in the UI comes from the fact that after the "name" box there is a list of image formats, which might well lead the user to believe they are only naming the image file and not the whole suite of output files.

[JDHill]

This is a difficult-to-reproduce, randomly occurring error in which, for example, the edge of window frame became an emitter.
I don't think it is any kind of a programming error, but rather a human factor error. I will try to pay close attention to the situation if I see this happening again in order that I can help you reproduce (if in fact there is a problem). By human factor error, I mean: I have a dropper to pick, a box to assign, and the plugin does not always give feedback instantly but rather needs a double click, click out, click in, etc. (as described in the other thread in depth) - thus, it is possible that with all the clicking, I myself accidentally assigned the edge of window to an emitter, without intending too.

This is part of the reason I have requested the added context menu which will (hopefully) show which material is assigned to the geometry, and/or allow it to be quickly switched without going into the silverlight plugin.

If, in fact, an emitter was randomly generated, then I'd have to chalk it up to the fact that the material in question had used emitter mode when last-written using the previous plugin, because there are only two ways to get an emitter: (a) the material was saved that way with the old plugin, and (b) you set the material Character to Emitter in the new plugin's material UI.

On clicking in/out of things, I surely would prefer that you were able to enter/exit the context of an entity when the eyedropper is active, but as far as I am aware, there is no way to do that using the SketchUp API. So, you can only operate within the currently-active context. For what it's worth, if you pay attention to the tooltips when the plugin's eyedropper is active, you will see that it does tell you what is assigned to the entity currently under the cursor. As I say too, I will play around with this and see what use can be made of the context menu.

Yes, I remember this request and think it is a great addition. My question is however: if I assign a material using the SU material tools, specifically using eyedropper, then bucket, does it properly assign associated .mxm's? In my testing, it seems to do this, but I am trying to find out if this is expected behavior from your side.

What a plugin material is, is a set of attributes attached to a SketchUp material -- they are not two separate things. So, all assignment is ultimately handled and managed by SketchUp, whether you accomplish it using the regular SketchUp tools, or using the 'Assign to' button provided in the plugin's material UI.

I will pay close attention to this situation and try to report back, now that I know what it should be doing.

Nevertheless, I think it might be quite nice to have the option to rename everything as stated above.
If the boxes are left blank, then it should simply follow the very sensible rules you listed.

I think the confusion in the UI comes from the fact that after the "name" box there is a list of image formats, which might well lead the user to believe they are only naming the image file and not the whole suite of output files.

I don't entirely disagree, but I do prefer to start from a clean/simple place, and then carefully extend things out from there. The scenario becomes a little more complicated when I get time to add in some missing functionality (with respect to my other plugins), such as automatic output naming (i.e. auto-increment) and automatically appending the current view name to the output name, which are both features which were heavily requested, and implemented, in other plugins.