Bug Splat Constantly in Win 7

valerostudio

This bug is plaguing a few plugins. I found that SKMs that have additional information attached to them, like MXM links for Maxwell or other information of other rendering plug-ins seems to be causing these Bugsplats. I found that disabling V-Ray and BuildEdge Plan seems to fix these crashes. The bug has been reported to all of these developers. I find that it started with the latest maintenance of SketchUp started these issues for me. Please contact Trimble and let them know of your crashes as well.

crowdad

Thanks for the responses.

I have disabled Vray while working in all of my models and then enable it when I am wanting to render out a scene. This seems to minimize the number of Bugsplats.

Having to open and close it to work with materials and environment/scenes gets pretty old after a while though. My IT department is in communication with both Vray and Trimble.

For some reason it seems like a lot of these issues have occurred after trimble took over sketchup...is this a possibility at all?

Thanks everyone.

valerostudio

I think something happened in a recent update that affects the way materials are handled. It has something to do with materials that have additional information attached to them. Some of your materials may have bump files or settings from other engines and you don't even know it.

I would suggest using ThomThoms V-Ray Toys to disable VRay and enable as you need. Incredibly useful plugin for any VR4SU user.

tibet

hi,

i´ve encountered a similar problem, crashing with SU8 when apply dimensions to a simple

model.( + with 1001bit plugin too )

i fixed by reinstalling sketchup, vray, and updating graphic driver.

cheers!

JD Hill

Hi all, Maxwell guy posting in the V-Ray forum. Matthew and I have been discussing this issue over email for a couple of months now, with respect to BuildEdge PLAN, and this morning he sent me a link to this forum thread, so I thought I'd post what I know about it.

@valerostudio said:

I think something happened in a recent update that affects the way materials are handled.

That's not the case, I just tested here with BuildEdge PLAN 2.0 (I don't have V-Ray) and Google SketchUp 8.0.3117, which is the initial SU8 release, and it crashes there too. However, I tried it in SketchUp 7, and was not able to reproduce the crash.

@valerostudio said:

It has something to do with materials that have additional information attached to them. Some of your materials may have bump files or settings from other engines and you don't even know it.

To be accurate, my tests have indicated that it specifically has to do with applying a SKM which is not contained in the model, and whose attribute data contains a string with a forward slash. That is why it affects SKMs written with render plugins active -- commonly, the data you need to store includes file paths with forward slashes. There could be other problem scenarios, this is just the one I've identified.

If you want to reproduce the issue, here are steps by which you should be able to do it, with as many variables removed as possible. You should perform these with all plugins uninstalled, except for the one you think is triggering the crash, apparently meaning V-Ray or BuildEdge PLAN:

Open SketchUp, open the Ruby Console, and run this one-liner:

Sketchup.active_model.materials.add('m').set_attribute('d','k','/')

Drag the new "m" material out into a library to create a SKM.
Select the new "m" SKM and attempt to apply it to an entity.
Upon executing step 3, SketchUp should immediately crash. Note that you should not drag the SKM into the model materials before applying it, otherwise you will not trigger the issue -- just select the SKM in the material browser, then try to apply it to an entity. My guess is that the affected plugins are not doing anything wrong, and that this rather points to a bug in SketchUp. Plugins may be able to work around it by changing some code, though.

Seeing as how I have only personally reproduced this with BuildEdge PLAN, I have not reported it to the SketchUp people as a potential bug yet, and have rather reported it to the BuildEdge people, since they have the code capable of triggering it. I would have reported it to SketchUp, but I have not been successful in writing a test plugin that shows similar behavior.

TIG

This BuildingEdge toolset is known to add some ill-considered observers to the model that run even when it is not activated, that can cause crashes for innocent legit scripts that follow API protocols.
I had to rewrite part of my 2dFillet tool because of this very reason... when others are changing the model's data-base quite legitimately with API methods their tool can cause crashes. In my case I had to NOT erase a temporary group within my model.start..commit_operation block, but rather use group.entities.clear! so the Garbage Collection deleted it at the commit, because otherwise my quite legitimate erasing of the group mid-process led to BuildingEdge's entities-observer crashing everything...
They haven't fixed it as far as I know - it's a dangerous thing to do because now we never know when someone has innocently done a legit operation in their tool that the BuildingEdge observers might take a dislike to and crash out...
Perhaps they also have a materials-observer etc that is equally uncouth with this setup...

andybot

@jd hill said:

... my tests have indicated that it specifically has to do with applying a SKM which is not contained in the model, and whose attribute data contains a string with a forward slash. That is why it affects SKMs written with render plugins active -- commonly, the data you need to store includes file paths with forward slashes. There could be other problem scenarios, this is just the one I've identified.

That's very interesting JD. The Vray developers may want to look into this. I've never seen this crash in vray 1.49.01, but then again, I also haven't upgraded beyond SU8 M3, so it could be something even more recent than just the SU7 - SU8 upgrade.

JD Hill

I'll just mention that doing some more testing here, it appears that the forward slash is actually not required -- SKMs with any attribute data at all will trigger the crash. I would've sworn I had proved that was required, but I guess not.

Anyway, prompted by TIG's comments on entities observers, I have been finally able to reproduce the crash at will by writing this plugin:

     # This is an example of an observer that watches the entities collection
     # new added elements and shows a messagbox.
     class MyEntitiesObserver < Sketchup;;EntitiesObserver
       def onElementAdded(entities, entity)
         UI.messagebox("onElementAdded; " + entity.to_s)
       end
     end

     # Attach the observer
     Sketchup.active_model.entities.add_observer(MyEntitiesObserver.new)

If this looks familiar, that's because it is a direct copy/paste from the Ruby API docs.

andybot

So is this a problem just in SU8? Was it not a problem in SU7?

JD Hill

I have reproduced it in clean SU8 installations from the initial release up through 8.0.16846. I am not able to reproduce it using my SU6 or SU7 installations.

bugra

Hi guys,

I am an engineer at SketchUp and wanted to let you know that we confirmed this as a bug. It is high on our list to fix. The workaround for now is to make sure the material (if it has attributes) is in the model before applying it to an entity. Sorry about the inconvenience.

Thanks!
Bugra

andybot

So JD, how is Maxwell able to avoid this issue. I see that when running Maxwell, there is material information stored in the skm file, and I can load it with no problem into SU and all the Maxwell properties are there. Does your particular setup not use the observer somehow? There must be some specific trigger that some plugins effect but others don't. I am way out of my depth on this one, but it's really peculiar to me that some plugins would be affected and others aren't.

JD Hill

Your intuition is correct -- by luck, I just happen not to have used this particular observer yet. And to follow up a bit, I'll mention, since I have been able to reproduce it independent of any 3rd-party plugin, that I've made a report for it on the SketchUp beta tester bug tracker. The upshot is: until this is no longer an issue, you should be able to work around it simply by making sure to import SKMs into your model before trying to apply them to entities. Naturally I can't give any guarantee on that, but from what I can tell, it appears to circumvent the problem.

dkendig

I can confirm everything JD Hill has said, V-Ray is using the Sketchup::Entities observer to track scene changes for RT updates, which is why we are having this headache. You can temporarily disable the observer by running this:

entsList = [Sketchup.active_model.active_entities];Sketchup.active_model.definitions.each{|deff| entsList.push deff.entities};entsList.each{|ents| ents.remove_observer VRayForSketchUp.entity_observer}

Then if you decide to enable it again, run this:

entsList = [Sketchup.active_model.active_entities];Sketchup.active_model.definitions.each{|deff| entsList.push deff.entities};entsList.each{|ents| ents.add_observer VRayForSketchUp.entity_observer}

Restarting SketchUp will result in restoring the observer as well.

thomthom

@bugra said:

The workaround for now is to make sure the material (if it has attributes) is in the model before applying it to an entity. Sorry about the inconvenience.

If it has attributes? I find that the material needs to be in the model regardless.
See: http://www.thomthom.net/thoughts/2012/03/the-secrets-of-sketchups-materials/#current-material-bugsplat-warning

Or, when you say "in the model" - do you mean it should be applied to an entity in the model, or simply that it's in the list of materials for that model (regardless if it's applied or not).

andybot

@thomthom said:

@bugra said:

The workaround for now is to make sure the material (if it has attributes) is in the model before applying it to an entity. Sorry about the inconvenience.

If it has attributes? I find that the material needs to be in the model regardless.
See: http://www.thomthom.net/thoughts/2012/03/the-secrets-of-sketchups-materials/#current-material-bugsplat-warning

Or, when you say "in the model" - do you mean it should be applied to an entity in the model, or simply that it's in the list of materials for that model (regardless if it's applied or not).

Does he mean this:

@jd hill said:

you should be able to work around it simply by making sure to import SKMs into your model before trying to apply them to entities. Naturally I can't give any guarantee on that, but from what I can tell, it appears to circumvent the problem.

If you select the material in the SU material library, and select the "add to model" option, it doesn't seem to trigger the crash. Only if you use the paintbucket to apply the new skm (that's not already in the model) directly to geometry.

thomthom

That's the bug I knew about. I've not noticed that attributes made any difference. Curious if it's the same bug or some similar variation.

bugra

Hi guys,
Yeah the crash I was able to reproduce happens only when the material has attributes, it's not in the model's list of materials yet, and there is at least one EntitiesObserver listening.
Thomthom: if there's another crash that triggers without attributes, let us know and I'll get it in the list (if it's not already).
Thanks guys.
Bugra

thomthom

@bugra said:

Thomthom: if there's another crash that triggers without attributes, let us know and I'll get it in the list (if it's not already).

I was under the impression that using materials.current - when that material came from the Component Browser library (not in model) and then applied would cause a BugSplat regardless because applying the material from the Ruby API didn't add it to the In Model material list. That eventually caused a crash. (See video in my previous link.) That is a bug I've reported earlier I believe.

Though I'm not sure if there was any observers or attributes around. I'd have to go back and double check.

bugra

@thomthom said:

I was under the impression that using materials.current - when that material came from the Component Browser library (not in model) and then applied would cause a BugSplat regardless because applying the material from the Ruby API didn't add it to the In Model material list. That eventually caused a crash. (See video in my previous link.) That is a bug I've reported earlier I believe.

Though I'm not sure if there was any observers or attributes around. I'd have to go back and double check.

Ok, I will try to reproduce that when I get a chance and see if it's already captured in our issue tracker.