[Code] New Material methods

[TIG]

See here for download http://forums.sketchucation.com/viewtop ... 77#p293677

---

TIG (c) 2010-2011
All Rights Reserved.
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES,INCLUDING,WITHOUT LIMITATION,THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

---

material_class.rb

---

Loaded by SKMtools.rb in the ../Plugins/ folder.
Adds new methods to to the Material class:

---

material.save_texture('folder')
It returns the 'folder/texture.jpg' [or .png etc] if successful or 'nil'.
e.g. texture=face.material.save_texture("C:\\Temp\\")
>>> C:\Temp\Brick99.jpg
If the 'folder' does not exist there is an error message.

---

material.save_thumbnail('filepath')
[or its alias material.write_thumbnail('filepath')]
It returns the 'filepath.png' if successful or 'nil' if not.
e.g. thumb=face.material.save_thumbnail("C:\\Temp\\mythumb.png")
>>> C:\Temp\mythumb.png
[If there's not a '.png' file-type suffix it will be made as one anyway!]
If the specified 'filepath' is a 'folder' then the thumbnail is made there
named 'doc_thumbnail.png' [the default name]
e.g. thumb=face.material.save_thumbnail("C:\\Temp")
>>> C:\Temp\doc_thumbnail.png
The thumbnail resolution is always 64x64px*** - always as a '.png' file.
If you specify a resolution it reverts to 64 anyway!
If the 'folder' does not exist there is an error message.
Needs Thumbnailer.class and ThumbnailerRGB.class in the same sub-folder.
If you are in SUp >=v8-M1 the built in method is used instead
'material.write_thumbnail(path, resol)'
- note, that the built-in method returns 'true' if successful AND requires
a alternative resolution to be passes as the second argument***, also you
must specify the full path+name and not just a folder path.

---

material.save_bumpmap('folder', boolean)
It makes the 'folder/texture.jpg' [or .png etc] and also a 'texturebumpmap'.
Returns 'folder/texturebumpmap.png' [always .png] if successful, or 'nil'.
The 2nd argument 'boolean' is optional - it defaults to 'false' if not set.
e.g. face.material.save_bumpmap("C:\\Temp\\")
>>> C:\Temp\Brick99_BMP.png
If you give it the second argument as 'true' it 'inverts' the Bumpmap,
e.g. invert=true; face.material.save_bumpmap("C:\\Temp\\", invert)
>>> C:\Temp\Brick99_BMPI.png [with 'inverted' Bump colors]
Choose to invert if you want to swap light and dark values...
If the specified 'folder' does not exist there is an error message.
Needs 'Bumpmapper.jar' & 'BumpmapperInverted.jar' in its folder to run.

---

material.export_skm(folder)
It returns the 'folder/matname.skm' if successful or 'nil'.
e.g. thumb=face.material.save_texture("C:\\Temp\\")
>>> C:\Temp\Brick99.skm
If the 'folder' does not exist there is an error message.
Requires SKM_class [SM.export(mat,'folder')] loaded too.

---

material.delete [or its alias material.remove]
It deletes that Material from the Model and any Entities that used it get
the Default Material [nil] instead...
Returns true/false on success/failure.
If you are in SUp >=v8-M1 the built in method 'material.remove' is used instead.

---

material.name="new_name"
it makes a cloned new-material from the original-material and gives it the
'new_name', if the name 'new_name' exists then it's made unique with a
numerical suffix, it gives the new-material to any entities that had the
original-material, the original-material is then deleted from the model
and material-browser: if the current-material in the browser was the
original-material then the current-material in the browser becomes this
new_material... It returns the new 'Material' name: to keep a reference
to the 'replaced' material use:
nname=(omat.name='newname'); omat=model.materials[nname] if nname
If you are in SUp >=v8-M1 the built in method 'material.name=' is used instead.

---

material.save_texture_and_thumbnail('folder')
It returns the 'sub-folder' if successful or 'nil'.
e.g. model.materials["My Mat"].save_texture_and_thumbnail("C:\\Temp\\XXX")
>>> C:\Temp\XXX\My_Mat
If the 'folder' does not exist there is an error message.
The 'sub-folder' is named after the Material [with some characters made
into '_']. The 'sub-folder' contains the Material's 'texture file' - e.g.
'Brick666.jpg' AND the equivalent thumbnail 'doc_thumbnail.png' - if the
Material has NO texture then there is only the 'doc_thumbnail.png' file in
the 'sub-folder'.

---

---

Donations:
By Paypal.com to info @ revitrev.org

---

Version:
1.0 20101210 First issue as combined class script
1.1 20101212 New save_texture_and_thumbnail('folder') method added.
1.2 20101222 Glitch with MAC file paths addressed.
1.3 20110106 Robustness improved with existing method checks...
1.4 20110116 Aliases added for .write_thumbnail() and .remove.
The .name='' and .delete methods now match SUp >=v8-M1 values.
1.5 20110116 Slightly recast 'aliases'.
1.6 20110213 MAC jar execution addressed.

---

[TIG]

Here is an update with a new method viewtopic.php?p=293701#p293701

[TIG]

This update viewtopic.php?p=293701#p293701 has been out for a week or two with other SKMtools tweaks - it now only makes the method if it doesn't exist - e.g material.name='xxx' is now include in the latest v8...

[TIG]

Here's an update viewtopic.php?p=293701#p293701
Material.class extensions - aliases added for save_thumbnail()==.write_thumbnail() and .delete==.remove. The .name='' and .delete methods now match SUp >=v8 returned values.

[thomthom]

SU8M1 didn't add Material.remove, it added it to Materials.

[TIG]

SU8M1 didn't add Material.remove, it added it to Materials.

But v8 did... [quietly!]

[TIG]

Here's an update viewtopic.php?p=293701#p293701
Material.class extensions - aliases added for save_thumbnail()==.write_thumbnail() and .delete==.remove. The .name='' and .delete methods now match SUp >=v8 returned values.
'Aliases' slightly recast to leave original new methods unaffected if used...

[thomthom]

SU8M1 didn't add Material.remove, it added it to Materials.

But v8 did... [quietly!]

? And it was removed? Because it does not exist at all in M1.

(Sketchup::Material.instance_methods-Object.methods).sort
["add_observer", "alpha", "alpha=", "attribute_dictionaries", "attribute_dictionary", "between?", "color", "color=", "delete_attribute", "deleted?", "display_name", "entityID", "get_attribute", "materialType", "model", "name=", "parent", "remove_observer", "set_attribute", "texture", "texture=", "typename", "use_alpha?", "valid?", "write_thumbnail"]

[TIG]

SU8M1 didn't add Material.remove, it added it to Materials.

But v8 did... [quietly!]

? And it was removed? Because it does not exist at all in M1.

(Sketchup::Material.instance_methods-Object.methods).sort
["add_observer", "alpha", "alpha=", "attribute_dictionaries", "attribute_dictionary", "between?", "color", "color=", "delete_attribute", "deleted?", "display_name", "entityID", "get_attribute", "materialType", "model", "name=", "parent", "remove_observer", "set_attribute", "texture", "texture=", "typename", "use_alpha?", "valid?", "write_thumbnail"]

BUT it IS listed in the API docs http://code.google.com/apis/sketchup/do ... tml#remove
ANYWAY... when they ever sort out their mess and if you have my SKMtools loading their '.remove' will get used in preference to mine!

[thomthom]

The release notes and the API docs are incorrect. It was added after this M1 release. I've notified them about the incorrect docs.

[Dan Rathbun]

The release notes and the API docs are incorrect. It was added after this M1 release. I've notified them about the incorrect docs.

I also made note, in a post to your "New Material methods! Thank you!" beta forum topic.

Also I think the v7.0 M1 build numbers are actually the M0 numbers.

[Dan Rathbun]

As we noted in the other topic Re: New Material Methods!, a method that acts immediately upon the receiver should (by Ruby convention,) use a ! on the end of the method name.

I would think in most cases such a method, if it's a dispose method, just calls the parent collection's element disposal method with self as the argument.

It's is kind of weird for code that is executing within the scope of an instance, to be destroying that very instance at the same time. In other words, the disposal call is made within the block of an instance method; and after the call is made, Ruby needs to return to the next statement after the call (still within the instance method,) but if the instance no longer exists, where does Ruby return to?

It's kind of the old "chicken and egg" scenario. But apparently Ruby can handle this without choking.

There are cases, as ThomThom pointed out, that it's easier to call a disposal method on the instance, rather then have to get a handle on the instances' collection object to call for the disposal.

[TIG]

Here's an update viewtopic.php?p=293701#p293701
The MAC jar execution issues have been addressed.