Is it a model you could share here, so others can see if they experience similar results?

This snippet works for me, and I think its fairly safe? (We'll let one of the other Ruby folk weigh in on that if they feel they need to ).

random_classes = []
ents_to_regroup = []

a = Sketchup.active_model.selection[0].explode

a.each do |e|
  random_classes << e.class
end

random_classes.uniq!

random_classes.each do |e|
  single_class_objects = a.grep(e)
  if single_class_objects[0].respond_to?(;bounds)
    then ents_to_regroup << single_class_objects
  end
end

ents_to_regroup.flatten!
Sketchup.active_model.entities.add_group(ents_to_regroup)

This will take the selected component and explode it. It then looks at the class of every object that was returned and decides if that class can be added to a group by testing to see if an object from that class responds to the bounds method, (which is in the Drawingelement class and inherited by all valid SU geometry entities). So if an object from the given class does respond to the bounds method, then it is safe to try to add those objects back into a group. If they do not respond to that method, then they get skipped.

Hopefully the logic makes sense. That snippet worked fine for me. You do have to have an object selected to test that piece of code.

Chris

Hmm, I know its doable. Can you group the entities inside the group first, and then explode the outer group? Does that do what you need?

Oh that is sooo good! Thanks for posting it! Now if only I could afford a computer that could play their games at hi-res, hi-detail, etc.

Quick example, if you explode the "Derrick" component that is used in some of the templates, these are the classes of objects that you get back form him:

Sketchup::AttributeDictionaries
Sketchup::AttributeDictionary
Sketchup::ComponentInstance
Sketchup::Curve
Sketchup::Edge
Sketchup::EdgeUse
Sketchup::Face
Sketchup::Loop
Sketchup::Vertex

Many of those are not entities that can be added to a group. So try being careful to just add edges, faces, construction geometry, instances, groups, and....anything else?

Could you upload a component that is giving this error for us to play with?

When you explode groups/components, sometimes you get a bunch of unexpected things back. So it might require poking around to see what is being returned.

Great book! That is very typical of something that I would do, BTW. Well, I don't eat "biscuits", but cookies would be likely.

Another of my favorites, is the Electric Monk, from Dirk Gently's Holistic Detective Agency. A little long to post here, but here's a link to the bit about the Electric Monk:

(theelectricmonk.com)

It actually re-orients the model's axis. So green is up and blue is shooting straight forward, like you asked for.

You can write your own camera positioning tool and you can program it's "up" direction to be pointing any which way you want. But as soon as the user flips back to the built-in orbit tool, SU will default back to forcing the original model axis z, to be up. SU very strongly favors having the z axis not tilt left or right.

I think you can change the model axes to align how you are wanting. Try this, right click on the model axis and choose "Place". Then, to set the axis how you are looking to do, click 1st on the model origin, click 2nd on the negative red axis, click 3rd upwards on the blue axis. That should now realign the axis so that red is to the left, green is up and blue is straight ahead.

I don't think there is a way to set that via ruby. But I think you could essentially include an empty "template" model that has its axis already aligned like that. And you could load that model when the user activates your plugin? That sounds really problematic though....

I suppose you could also code your own camera view tools that disregard the z=up preference of SU? I"m not sure about that really either though.

Try setting it manually though, I'm interested to see if that is even the orientation you are looking for.

Chris

Looks like you might be able to cast your full computer monitor to the TV, not just the chrome browser.

http://www.techhive.com/article/2045755/7-browser-tricks-to-get-the-most-out-of-your-chromecast.html

See tip 4. It is listed as experimental. Looks cool

Chris

You might look into Simuterra. I'm not sure if Erez is still actively developing or not, but I believe it was working pretty well.
http://www.compuneering.com/simuterra.php

Or Chuck Vali might also have a good solution:
http://www.valiarchitects.com/sketchup_scripts/instant-road

Hi Yehonatan, sorry you're having troubles. This is not something we're hearing complaints about so far. But you're seeing it on more than one computer? If you remove all plugins does it go away? Do you have any plugins that modify your toolbars or attempt to manage them?
I would recommend removing plugins and go through the process again of adding them back. It sounds like there might be one that somehow is messing things up, but it might take a little while before it is noticeable. That is my first guess.
You could also send me a zip files of your plugins folder and I'll see if I can recreate the issue. Let me know if that sounds like a good option, I'll give you an email that you can email it to.

Thanks,

Chris

Looks like you might need to ask your question over at the rendado website.

Technical. That's very technical work. SketchyPhysics makes use of an existing free library of physics simulation software. And he just plugs it into SU. And even that is an incredible undertaking.

Hey Bowesy, did you submit the bugsplat report? If so, could you PM me you email address or name you gave on the report? I'll try to look at it and see if I can find anything.

Chris

@jojo9 said:

Would be hard to code such a plugin ?

Yes.

Could you upload the model Kris? I can't quite tell whats going on in the image.

I looked at your model and I couldn't get it to crash on intersect w/model. But that doesn't surprise me too much, that is pretty stable. It is often slow and the computer stalls, but it does not actually crash.

For drape however, that model is VERY typical of the kind of models that like to crash when using drape. For that, like I said, you just have to drape in small portions and save all the time.

Chris

I'm watching and discussing internally....

from what I can gather, the behavior is just plain ol' incorrect. We are actually looking at fixing it in a future release. But I realize that will not help with backwards compatibility. At this point, we could find no way to make it work the way you want for the classes that are broken.

Chris

Hi Mike, do you have an example that shows where you are having some accuracy issues? I'm one of those who has found SU to be easier to be accurate in, than any other 3d modeler I've worked with (admittedly only a small handful). I'm always curious to see what are other people's methodologies. Any example model, or video would be appreciated.

As for the original problem, I'm also still interested in your issue here. Like I said, that check box is turned on by default. But it turns itself off if SU thinks you might not have everything selected. So there are scenarios where it turns itself off on purpose. Arguably, that behavior is not desirable (I'd vote against it myself). But that is the functionality that the team implemented many releases ago (and haunts us to this day). BUT, it sounds like you might be having issues that start getting into what might be a bug. Perhaps you've got a model that has a glitch in it that is causing that tickbox to be turned off, even in times when it should be on by default. I'd be grateful if you found a model that showed that incorrect functionality so I could log it as a bug, or use it to make a case for changing that behavior of that check box.

So if you get a chance, any info you could offer would be greatly appreciated. Thanks Mike!

Chris