How to get the root Model in the scene?

I see that active_model gives you the current edited model (for example when editing a component, will give you the component’s model). Also it seem the transformation of a child entity changes when the active_model is either the root or a parent. So, how can I get the root model ? Recursive down search ? Why there isnt a root_model or something.

An opened component is the root model. An opened child is also the root component. SketchUp doesn’t act like other 3d packages in this sense.

Yeah, that’s why my life is a hell right now :). Anyway, I cached the active_model when file open and using that as root. Hopefully that’s fixed in a session. Also saw that transformations are local when no component is edited, and world when I edit a component.

I don’t really understand the question. A model is not the same as a component. Are you looking for the root drawing context? In that case Sketchup.active_model.entities returns it.

If you are editing actively a component, then its not returning the root of the document, but the actual edited component :slight_smile:

Also when I am editing a component/group, the inner components report the world transform as their current transformation, because the current axis is now changed. At that moment I have no way to find the local transformation of the child components of that edited component. The API is a minimalistic mess in this regard. I’ve coded 3D for 25 years and I have never seen this sort of odd behavior on an 2D/3D engine/API :)…

1 Like

If you are asking for a way to access the context currently being edited it’s Sketchup.active_model.active_entities.

I want the root of the scene, not the actively edited model. But yeah, found it as I said above, caching the active_model ref on file open.

I can agree that the coordinate system is dumbed-down to an absurd level that makes it quite difficult to understand. When a group or component instance is opened as the active drawing context all its internal coordinates seams to be converted to model space before being returned by the API. This inconsistency makes it hard to understand how the coordinate systems work.

What do you mean by root and what do you mean by scene? Sketchup.active_model should return the active model regardless of what component in that model you are inside. A component is not a model. I can’t see any reason to cache the model.

Probably its ok for simple in-application plugins. But I am trying to export stuff and also realtime sync transforms with some game engine, and this architecture is not helping me at all, just makes me pull my hair out :).
If they would just keep a localTransform and a worldTransform for each entity, it would be so nice, you would know all the information you need without doing some crazy recursive search functions or hacks. Either way, the application’s architecture is not at all developer friendly. But I digress, ranting… :slight_smile:

1 Like

The root of all things in the scene.
active_model will return the current edited Model object, it also will return the Model in which the currently edited ComponentInstance resides in. I have debug text print this :), its all checked. You can try it and see. Also the transformations change to 0,0,0 for the components parent to other child components.
Example printing transformations for components:
Large box is parent of tall box, tall box is parent of cylinder. I am editing each component one by one and printing transformations each time:

Yes, you are right, active_model stays the same when editing other nested components. I don’t remember when it changed. Probably my brain is a mush by now :slight_smile:

When you are within a component (or group, because they are actually special components,) the coordinates and axis are the component’s local coordinates and axis.

Because you are now withinm THAT component’s coordinate system, which means it’s origin, is the origin for the local coordinate system, which is [0,0,0].

We do not really say “World” origin or axis, because SketchUp was designed (originally) to draw buildings for architecture, so we instead refer to the Model origin and/or Model Axis. Later most building or construction models are geo-located using world coordinates and height with respect to the model origin, so it can be placed in the correct spot and elevation on the globe of the world (in say Google Earth or other mapping software.)

SketchUp was not "designed (originally) to draw buildings for populating Google Earth"
SketchUp Beta was released in 2000 when I started to use it and was marketed specifically to designers and Architects like myself. See the Wikipedia article for more details.
EarthViewer 3D was developed by Keyhole inc. which was not founded until 2001 after SketchUp existed…
Google acquired Keyhole in 2004 and renamed their software Google Earth.
Google acquired SketchUp in 2006 because they thought it would be good for drawing buildings for Google earth.

Both acquisitions cost chump change for Google who probably didn’t realize what they were getting into.
(Earth is still not integrated with Maps, its interchange format is still called KML: Keyhole Markup language and they sold SketchUp to Trimble in 2012.)

Trimble seems equally baffled about how SketchUp could provide synergy to its overall business model.

1 Like

Ok fine, I’ll agree, I edited the previous comment to be more general.
(I am a victim of the “watered down” and truncated application history that floats around on some of the websites. Likely was revisionist history by Google management.)

Actually this is not how it works.

Try drawing a rectangle, select the face and edges, group it, select the group and run this code:

vertex = Sketchup.active_model.selection.first.entities.first.vertices.first

If you are in any other drawing context than the group’s internal one and run the following code you’ll see the coordinate in the groups local coordinate system:


If you open the group and run the same code the same vertex’s position is now magically returned in global coordinates.

You are right! It doesn’t. BTW both code snippets are the same. I suppose the 2nd needs to be:


Is there a good reason why things work like this? It is butt-backward to how I’d want it to work, especially as the GUI moves the visible origin and axis to group local.

1 Like

Edited the comment, thanks.

The transformation isn’t even added at the inspect layer but already when getting the point from the vertex.

Up to SU 7 the axes shown in groups being edited were the global ones. If I’m not mistaking the API was introduced in version 6 which could explain this. I found this odd behaviour years ago but at the time couldn’t express it in a way that anyone seamed to understand.

This inconsistency is really weird. This is dumbing things down to a level where it’s just harder to grasp. This is like what my elementary school teachers were doing all the time.This is just wrong.

1 Like

fun fun fun! I guess with SU, don’t go too deep into the rabbit hole :), I don’t consider myself slow, but it took me 2 months to understand how its inner architecture works, when it should have taken like 1 week or so. I now understand its abstract ideas of a perfect model-view pattern, but maybe some things should be added to alleviate the plugin development (aka functions and classes that offer more information about the scene). Also a more dynamic UI would be great, where I can change icons on buttons, delete them, reorder them, delete toolbars, etc. Also more extension containment to also hot unload them and not closing the app. I’m sure this can be done, but I’m not sure if the developers of SU really care about the extension developers… :slight_smile:

1 Like