[Plugin] Material_Maintenance v2.2 - 2013-01-13
-
-
-
So the folder/subfolder is OK and the images exist.
The image naming seems unduly convoluted, as it's adding some special characters etc...
Why not use eachmaterial.display_name
[with some replacement of characters like \ / : * ? " < > | etc] linked to a hash of the display-name containing its 'id' ?
The thumbnail-images names match the 'display-names' ? -
@tig said:
So the folder/subfolder is OK and the images exist.
The image naming seems unduly convoluted, as it's adding some special characters etc...
Why not use eachmaterial.display_name
[with some replacement of characters like \ / : * ? " < > | etc] linked to a hash of the display-name containing its 'id' ?
The thumbnail-images names match the 'display-names' ?This is sort of what I have done. i.e.
display_name + "_" + object_id + ".png"
with invalid windows file name characters replaced with the ¶ character. I know this character caused us problems in the marshaling on OSX, but forgot to remove it here. I will do so in the next patch.
I do not think this is the problem though as some of the .png files do not have this character in the name...
I will add some trace code (and remove the ¶ character) if you do not mind testing again CMD.
-
Why no just remove the miscreant character OR use an _ ?
-
The same like cmd, the folders and image files do exist.
ENV.sort.each{|e|p e};p -
@tig said:
Why no just remove the miscreant character OR use an _ ?
Three reasons (none valid anymore)
- I wanted descriptive file names (help with debugging)
- I wanted to be clear which chars I replaced (helped with debugging)
- I also have an OCD nerve and in theory by just deleting or replacing with a "ordinary" character could clash two similarly names materials that only differed in special characters (and yes it could still happen if each string have the same number of special characters all in the same positions but different characters or if someone actually used the ¶) but I felt the chances were sufficiently small.
I will probably go for using object_id as it will be exact(which I did not know existed when I wrote this part if the code initially).
-
You could make a ruby hash of each material 'display-name'/'id' [rather than it's Sketchup name which will involve [], <> etc if it has been 'imported' etc; this 'display-name' is used in the dialog, and it is then linked to the material's 'id' in the hash. That 'id' is then used for the temp thumbnail png file-name. They are both already unique.
The same applies to the component-thumbnail etc.
You can then use the linked name/id to find the material/defn / id, to associate the right png with the material/defn etc...
-
@tig said:
You could make a ruby hash of each material 'display-name'/'id' [rather than it's Sketchup name which will involve [], <> etc if it has been 'imported' etc; this 'display-name' is used in the dialog, and it is then linked to the material's 'id' in the hash. That 'id' is then used for the temp thumbnail png file-name. They are both already unique.
The same applies to the component-thumbnail etc.
You can then use the linked name/id to find the material/defn / id, to associate the right png with the material/defn etc...
Is there a reason I not just use the the material's
object_id.to_s()
as key and also as thumbnail file name etc. It seems unnecessary to concatenate with display_name and then hash, when object_id should be unique within one session...? -
How are you to show the display-name AND its matching thumbnail in the dialog etc ? Unless you have both to refer to ?
-
@tig said:
How are you to show the display-name AND its matching thumbnail in the dialog etc ? Unless you have both to refer to ?
I pass in both the name(as is without any manipulation), and the object_id to the WebDialog. This also allows me to uniquely identify which materials to change. i.e. I only pass the object_id (key) back to Ruby.
-
Great plugin...I've needed something like this for a long time.
The labels on the UI are getting reduced, regardless of window size.
See attached image. Any idea why this is?
I'm SU8 on Windows 7.
-
Sorry but it didn't work to me...
Any Update!?!?!
-
Looks more like an issue with SketchUp's installer feature... Can you install other plugins without problems?
-
Are you trying to install this RBZ file from a location on your computer - not the Internet
Do you have read AND write access to the 'plugins' folder?
NOT the 'user' one, BUT the main one in the HD folder tree...
If not then you can't auto-add files like this... -
[mod=Split topic:1mb3nheb]Split of the last few posts into a separate topic: http://sketchucation.com/forums/viewtopic.php?f=180&t=49354
Related to using object ids for retrieving object instances.[/mod:1mb3nheb] -
How about this different approach.
Avoiding worrying about 'id' etc...You assemble a collection of every material display_name and name, sorted ['matnames'].
matnames=[]; model.materials.each{|m|matnames << [m.display_name.gsub(/[/\\?%*:|"<>.,']/, ''), m.name]} matnames.sort!
You decide on what to gsub out etc...
You then iterate that array to make another array of those materials ['mats'].
mats=[]; matnames.each{|a|mats << model.materials[a[1]]}
a[1] is the material's name used to access the material reference.
At this point each index in the two arrays' point at a display_name (as a[0]) and its matching material.
Now make the thumbnail images.
matthumbs=[]; mats.each_with_index{|m, i|p=File.join(tempfolderpath, i.to_s+'.png'); matthumbs << p; m.write_thumbnail(p, 128)}
AFTER all of the assembly, you might also want to thinkabout the '<Default>' material and always have that as item 0 in each array; e.g.
mathames=[['<Default>']]+matnames mats=[nil]+mats matthumbs=[pathToDefaultThumbnailPNGinMMsubfolder]+matthumbs
###I suggest that you make a standard PNG, unless you want to create one based on the real two default-materials' colors got from:
model.rendering_options["FaceFrontColor"] model.rendering_options["FaceBackColor"]
You can then write the PNG's [or BMP file] bits etc using those color's RGB values to match... [I think that thomthom has some snippets on that - trybitmap2mesh
etc al - there's also some good stuff here https://practicingruby.com/articles/shared/oelhlibhtlkx ]You now have three arrays of various 'matching' things to do with the SKP's materials, using the same indexing regime...
Now... you assemble the materials list for the dialog...
For example, the item under the dialog's index '**3**
', has a 'name' text-string taken from the matchingmatnames[**3**][0]
, and it displays the matching thumbnail-imagematthubs[**3**]
, and that same index then used inmats[**3**]
is the actual SKP material to be used when the Ruby does the changing, swapping etc... Because the item's 'index' is a simple integer, then converting to and then from a string, is straightforward in a 'callback', or whatever you use...The same ideas would also apply to the 'component-definitions' - the only addition would be to separate the thumbnail images use say
i.to_s+'**x**.png'
for the components... -
@cmd said:
@myhand said:
Bug fix version V2.1.1 released.
... CMD this should fix your problem also as the trace code that had the bug in is also now removed.
Myhand,
Good stuff! no more errors!
.... but I am not getting material thumbnails nor am I getting component images to display.
Is this due to the change for mac?
Sorry this took so long but have been in the middle of something else. Here is a debug version that will trace the file paths the Javascript code is trying to load into the ruby console. Same install procedure as before.
Please send me the console output.
-
broken again
value = 0.0 !!!=> fromUIHandler: parameter string = 73-0__vzrefreshMaterialstruefalsefalse Error: #<NoMethodError: private method
puts' called for "73-0":String>`john
-
@driven said:
broken again
value = 0.0 !!!=> fromUIHandler: parameter string = 73-0__vzrefreshMaterialstruefalsefalse Error: #<NoMethodError: private method
puts' called for "73-0":String>`john
Hi John, I suspect you have installed an older version. I have just rechecked the Material_Maintenance_thumbnail_dbg_01.rbz file (you can unzip it) and the above two puts have been commented out. You can check by looking at lines 106 and 111 in the Material_Maintenance/Material_Maintenance.rb file within the .rbz archive.
Advertisement