Entities before and after group explosion

2017
2016

#1

In sketchup 2016 entities inside of group were remaining the same after exploding it…

I mean this: #Sketchup::Edge:0x0000000aaa0500 kind of same… and even #.entityID

In 2017 they change. Entities inside of a group become difrent entities after exploding it… I noticed though there is a #.persistent_id method added in 2017 API. This PID doesn’t change…

So basicly if inside a group I saved some selection in an array (in specific order preferably) then in 2016 it would be still valid entities after explosion. In 2017 after exploding sketchup thinks I am refering to already deleted entities…
Is remembering the pid (persistent id) only way to keep truck of entities bofore and after exploding?
I can retrieve entity from pid right? I think I’ve seen that method somwhere though I can not find it now…
\t I thought PIDs were originally only ment for working with it between sessions.

\t For future? Where are details like those mentiond… Didn’t see it on https://ruby.sketchup.com/


#2

Some background: While retaining object references after explode sure was nice in many situations, it was a quite odd behavior, given how there can be multiple instances of the same definition. If there is at least one instance that isn’t exploded the contained entity objects need to remain in the definition. If more than one instance was exploded there would be duplicates of the exploded geometry and hard to tell which copy should re-use the Ruby objects from the definition. While the old behavior was useful it made sense to abandon it when refactoring, given how complex and littered with special case handling the code must have been.

I’m not an expert on PIDs but I think they are just incremental numbers unique in their own context. If I am not mistaken the same number can be used in different places, e.g. on entities in different drawing contexts or other collections (e.g. the scene list). If this is the case exploding a container doesn’t necessarily result in the entities keeping their PIDs, as these PIDs may already be in use in that context. Also exploding two instances of the same definition into the same drawing context would force at least half the PIDs to be regenerated.

In most cases the return value from explode can be used to get references to exploded entities. When I need to distinguish between different elements in the exploded container I typically assign attributes. remember that that geometry can be split and merged with other geometry when exploding! Attributes has the benefit here that they are copied to all sections when an edge is split.


#3

Btw, Model#find_entity_by_id may be the method you couldn’t find. This method belonging to the model, and some of my quick testing, suggest PIDs are, contrary to my previous belief, unique for the model as a whole.


#4

There is also Model#find_entity_by_persistent_id, added in 2017. If I read the docs correctly, the difference between this and Model#find_entity_by_id (added in 2015) is that the latter will accept an EntityID or a Persistent ID (but not a mix of both), whereas the former uses only PID.