[solved] Material causes Bugsplat

TIG

That SKM material works fine for me [Vista 32bit SUp8M2 Pro].
I have another RAL set with a very comparable 'beige' SKM - although the RGB are off by one or two.
Your SKM has a slightly larger xml file when edited...

    <n0;AttributeDictionaries count="1">
      <n0;AttributeDictionary count="1" name="maxwell">
        <n0;Attribute key="material" type="10">{"material";{"name";"Velvet_1001_Beige","alpha";1.0,"mxm";{"name";"Velvet_1001_Beige","thumb";{"dir";"C;/Documents and Settings/recording/My Documents/Maxwell/SketchUp/temp/thumbs","mtime";1282327667.0,"valid";true,"file";"Velvet_1001_Beige_1279301578.jpg"},"color";"134,124,113","file";{"dir";"C;/Program Files/Next Limit/Maxwell 2/materials database/mxm files/RAL Libraries/Velvet","mtime";1279301578.0,"valid";true,"file";"Velvet_1001_Beige.mxm"}},"textures";{"color";{"app";{"dir";"","mtime";0,"valid";false,"file";""}}},"color_mode";"app","mode";"mxm","version";"2.1.1.0","use_alpha";false,"color";"208,176,128,255","editable";true}}</n0;Attribute>
      </n0;AttributeDictionary>
    </n0;AttributeDictionaries>

It seems that the material has a Maxwell attribute added to it.
This does not affect me [I don't have Maxwell] but that might be what's causing you the issue.
Here is a modified version, without the attribute... Try that...

Velvet_1001_Beige.skm

Burkhard

Thanks TIG, that works. Can you shortly explain what these attributes effect for Maxwell?
The Materials should be linked to the mxm file RAL Librarie.

TIG

When you have certain renderers loading [I already know Twilight does this, and now I know Maxwell does too - and probably some other apps too], the renderer often has the ability to edit the properties of the SKP's materials as they might be used in the renderer; all of this while you are still inside the SKP. So for example a SKP material only has R/G/B/Alpha-transparency/Texture-file-data, BUT you might want additional settings for glossiness/reflectivity/etc in the renderer itself. So the renderer's material-editing tool adds these as "hidden attributes" attached to that SKP's material. When you export the material to the renderer, the extra info inside its "attributes" is also exported, so the renderer knows how reflective that material is etc... These attributes are stored with the material in the saved SKP; any material attributes are also replicated inside a SKM file when a material is exported outside of the SKP [as a SKM file], this is so when you reuse the SKM it already has suitable information for the renderer again...
Maybe there's a crossed thread in that SKM's "Maxwell" attributes causing the crash ?
As I said it loads OK for me using either your original or my manually edited SKM version...
Editing the contents of a SKM is a bit 'arcane'... BUT it's not so difficult after you realize that a SKM file is actually just a re-suffixed ZIP file containing the thumbnail image, perhaps a texture image and several cross-referenced XML files that contain the material's data [which are readable and editable in Notepad++.exe]... AND it helps a lot if you've previously created the SKMtool kit etc

derei

@burkhard said:

A conflict between Maxwell attributes and SuPodium. Thanks all

hmm, this should be reported... it needs a fix.

Burkhard

A conflict between Maxwell attributes and SuPodium,Sketchup Bim and Driving Dimensions.All three forces Sketchup to splat. Thanks to all

Burkhard

Yes, I reported these on SuPodium and will do it here and with Ledas too.

bigstick

I'll check out Podium and SketchUpBIM, but Maxwell I'm going to leave to NextLimit.

bigstick

Podium doesn't do anything with SKM files, I can't see how this has anything to do with us. I can't find a conflict with SketchUp BIM.

TIG

Driving Dimensons does mess with some base-class/methods ill-advisedly [groups/definitions etc] - a while a go I PM'd the author about addressing it, but no news. Perhaps it also messes with some other classes I am unaware of...
Sketchup Bim is new and hopefully the authors are less cavalier ? Why do you not PM them too...
I'd not expect the other two quoted to be an issue.
Perhaps the latest Maxwell is faulty ?

d_e_x

Can someone tell me what is Maxwell?
And where are these skm files coming from?
Who uses these files?
How do I download the package, and/or get more information on this library?

I googled "Jason Marantos RAL Librairie for Maxwell" and came up with a French website. Could someone help me understand this in English?

There is something fishy about these skm files. SketchUpBIM 1.5 does not touch / make any modifications or changes to any material data already inside SketchUp. So it beats me why and how are these skm files conflicting with the SketchUpBIM product. Also, I noticed that this bug is prevalent with the initial version of SketchUpBIM - which is just mind-boggling, as the first version of SketchUpBIM had absolutely no relation to SketchUp materials.

Dex

bigstick

Maxwell is a render engine. The RAL library is most likely a SketchUp materials library with advanced material properties for Maxwell configured in the xml file.

Personally I'm not sure you need to do anything. I seriously doubt there is a conflict with your application and the skm files. There seems to be no conflict with the SUPodium renderer.

You might want to check for conflicts with the driving dimensions plugin (a tool for parametric geometry) but in the unlikely event that there is a conflict between SketchUpBIM and the skm library, you could probably ignore it, it's not a Ruby plugin, and it may be that the way the additional properties have been added to the special skm files is broken in some way or other.

TIG

To recap.
I discovered that the 'problem RAL SKM' file that was initially posted in this thread [by Burkhard] has several extra 'Maxwell' attributes added to the material compared to similar SKM files.
It might be that the original author had Maxwell installed when exporting the SKM files so they inherited these extra hidden attributes [unnecessary unless you are a Maxwell user].
I found that I could load and use the attributed SKM without any issues at all [I don't have Maxwell OR any of the now 'earmarked' tools loading - see below...].
I then manually edited the SKM file's code to remove the attributes and re-posted it, and it then worked without error with the original poster's set up as well as my own.
It now seems that the original poster [Burkhard] is having issues with other sibling materials causing crashes.
After some detective work Burkhard has deduced a shortlist of possible 'culprits':
SuPodium, SketchupBim and DrivingDimensions
He hasn't confirmed if he has Maxwell installed.
He needs to test with all combinations of these tools enabled/disabled, manually applying these 'attributed' materials also, to see if this causes issues...
Out of the three DrivingDimensions is a potential candidate because it does ill-advisedly mess with some base-classes/methods that can cause issues with standard API calls - although why it might interfere with materials is puzzling... Because it's compiled it's impossible to tell. I'd expect SketchupBim to use the basic xxx.material=mmm API coding so how this would conflict is also a mystery; does it do anything 'exotic' to materials otherwise ?
Perhaps DD is messing with SBIM [perhaps in a group/copy context?] when one of these materials is used and producing an error that in fact has nothing to do with the material itself ??
Has anyone else tried installing the original problem SKM file on a PC which also has any/all of these potential clashing tools? If so did it crash? As I said, it works fine for me with its Maxwell attributes but I have none of the listed suspects...
Burkhard: can you confirm what else you have installed - like Maxwell ? - and the exact steps you take to get to the crash...

TIG

To add a little more confusion...
This is a typical SKM attribute set that Twilight adds

xmlns;n0="http://sketchup.google.com/schemas/1.0/types">
    <n0;AttributeDictionaries count="3">
      <n0;AttributeDictionary count="1" name="Twilight">
        <n0;Attribute key="mat_changed" type="7">1</n0;Attribute>
      </n0;AttributeDictionary>
      <n0;AttributeDictionary count="2" name="KT_Mat_c0">
        <n0;Attribute key="alpha" type="6">0.6000000238419</n0;Attribute>
        <n0;Attribute key="datatype" type="4">2</n0;Attribute>
      </n0;AttributeDictionary>
      <n0;AttributeDictionary count="5" name="KT_mat">
        <n0;Attribute key="custom" type="4">1</n0;Attribute>
        <n0;Attribute key="ior" type="6">1.100000023842</n0;Attribute>
        <n0;Attribute key="shine" type="6">168</n0;Attribute>
        <n0;Attribute key="smooth" type="6">15</n0;Attribute>
        <n0;Attribute key="wireframe_thickness" type="6">0.003000000026077</n0;Attribute>
      </n0;AttributeDictionary>
    </n0;AttributeDictionaries>

You will see that it adds three dictionaries and several separate attributes set of different 'types' [float/boolean/string/etc]
This is the attribute set in the SKM with Maxwell

xmlns;n0="http://sketchup.google.com/schemas/1.0/types">
    <n0;AttributeDictionaries count="1">
      <n0;AttributeDictionary count="1" name="maxwell">
        <n0;Attribute key="material" type="10">{"material";{"name";"Velvet_1001_Beige","alpha";1.0,"mxm";{"name";"Velvet_1001_Beige","thumb";{"dir";"C;/Documents and Settings/recording/My Documents/Maxwell/SketchUp/temp/thumbs","mtime";1282327667.0,"valid";true,"file";"Velvet_1001_Beige_1279301578.jpg"},"color";"134,124,113","file";{"dir";"C;/Program Files/Next Limit/Maxwell 2/materials database/mxm files/RAL Libraries/Velvet","mtime";1279301578.0,"valid";true,"file";"Velvet_1001_Beige.mxm"}},"textures";{"color";{"app";{"dir";"","mtime";0,"valid";false,"file";""}}},"color_mode";"app","mode";"mxm","version";"2.1.1.0","use_alpha";false,"color";"208,176,128,255","editable";true}}</n0;Attribute>
      </n0;AttributeDictionary>
    </n0;AttributeDictionaries>

Maxwell saves all of its attributes in one dictionary name 'maxwell' using the key 'material' as a string [type=10] wrapped inside {} which I assume it uses to 'eval' back into something like a hash [you can't save a hash directly as an attribute] and extracts the various attributes needed.

I fail to see how any material having a long string attribute will cause other scripts to interact...
I think this is a Maxwell issue, as I now understand that Burkhard also has Maxwell loaded when the problem appears with the other tools...

Burkhard

Sorry for beeing late. For sure, I have Maxwell installed and the Bugsplat occurs when after selecting the RAL Material I just apply it onto a face.
I had made some cross tests with these Plugins, so I'm sure that every single Plugin force Sketchup to quitt.

It is for those who could have the same problems - and me, because it is interesting to know what does skm Materials have to do with non Material Plugins.

It was mentioned in the BIM Plugin here, on SuPodium and Maxwell Forum too. For now Jason postet a part of a new RAL file, which I have to test now.
I'll keep you informed if they work.

jason_maranto

Just to be clear here this should definitely not be something that is specificity to my materials -- I didn't do anything special here... if you follow the process below you should get the same results I did:

open or create a new SketchUp material
link an MXM to that SketchUp material using the Maxwell plugin
save the modified SketchUp material to a new library

If you are getting a crash with my materials then you should also get a crash with any other material made in the same way.

For the record I do not have any issues on my systems, but I do not run the other plugins listed... and last thing I heard the reported issue was specific to localized versions of SketchUp.

Best,
Jason.

Burkhard

It was localized, Jason...after I copy my Plugin folder into the English Version it happens here also.
And...it is not you but still happens with the RAL Librarie and that's interesting enough.

d_e_x

SketchUpBIM, Ledas Driving Dimensions and SU Podium work together like a champ! No problems, or issues were found. The attached screen-shot shows all 3 plugins working on the same model inside SketchUp.

My guess (and hope) is that the Maxwell issue was limited to the "modified" file posted on this forum. The cleaned-up version provided by TIG works fine.

TIG

DrivingDimensions is still a culprit that ill-advisedly affects some of the the base class/methods for group [probably copy and definition] and thereby breaks other legitimate scripts.
Could be by redefining or poorly made observers.
It's compiled so it's not readily fixable...
I have as the author to change it ages ago - but to no avail

newyawksue

Hi. I'm just reading this conversation now because I'm having a similar problem. A material in my materials pallet is causing a crash every time I click on it. HOW DO I REMOVE THE MATERIAL FROM THE PALLET IF I CAN'T SELECT IT?? I don't want to accidentally select it at a later time and crash in the middle of this big project I'm starting.

Sue

TIG

You can try this.
Copy+Paste the lines of code in turn into the Ruby Console + <enter>
Recent versions of Sketchup only, >=v8Mi...
I've assumed that assume the troublesome Material is name 'XXX', edit n= to suit.
First let's set up some variables:

n='XXX';m=Sketchup.active_model;ms=m.materials;ma=ms[n];puts ma;

If it returns a material [not NIL] we now remove the material from everything:

m.entities.each{|e|e.material=nil if e.respond_to?(;material) && e.material==ma; e.back_material=nil if e.respond_to?(;back_material) && e.back_material==ma}; m.definitions.each{|d|d.entities.each{|e|next if d.image?; e.material=nil if e.respond_to?(;material) && e.material==ma; e.back_material=nil if e.respond_to?(;back_material) && e.back_material==ma}}

Now we remove the material:

ms.remove(ma)

The material should now be gone ?