The idea of persistent IDs in SU2017 is very welcome indeed. However, I think there is a big problem with it that prevents developers taking advantage of it.
Whereas the native tools in SketchUp allow you to manipulate and change existing geometry, the Ruby API (and indeed the C API) is limited to erasing and creating new geometry. This means that persistent IDs for extensions that “manipulate” geometry will be useless to them.
For example, the dimensions on a model in LayOut, will always break if I were to use Fredo’s Joint Push Pull tool on it for example. More disappointingly for me, the Skalp sections I use in LayOut, which has dimensions all over will break every time that the section is updated. And I know that due to the limitations of the API, Skalp will not be able to fix this.
I think a Ruby API / C API method to SET a persistent ID is much needed now. That would allow extension developers to work with persistent IDs. I know that SketchUp don’t normally add something like this to the API outside of a major release, but I would like them to consider it. Not doing so means we lose a full year of extension development in leveraging persistent IDs.
We don’t need this for Skalp. If just SketchUp keep the association with his own sectionplane then the problem was solved. Because the Skalp section is a little behind the real section. LayOut snaps to the intersection of the sectionplane and the faces. But it doesn’t keep this association after updating.
I see what you are saying, Guy. However, I don’t like to have Section Planes visible in my views, which means that the intersection will not be there to snap to. Section Planes give a greyish tinge to the overall colour of a drawing which is not attractive. I have been using Skalp section’s endpoints to snap to until now.
In the case of Skalp, I guess if LayOut’s dimension tool keeps the association to an intersection between two entities, then, the problem is almost solved (plus give user ability to change a section plane’s colour/transparency). I think for other extensions, the inability to set persistent IDs are still a problem.
So the main objective here is to be able to allow LayOut to retain associated dimensions between mesh-regeneration? Setting persistent ID is a proposed solution to this? But not necessarily a must if there are other alternatives?
Just want to make sure what the core of this discussion is - as setting IDs on entities open up a can of worms in terms of ensuring IDs are all unique. If objective is to retain associated dimensions then I’d want to focus on that.
My desire for being able to set persistent IDs come from my misconception that geometry (edges, faces) cannot be manipulated with the API. Having studied it further, I discovered that all geometry can be manipulated using the entities.transform_entities(ent, transform) method in Ruby API. I hadn’t been aware of this - am I right in thinking that developers were advised in the past to create geometry afresh rather than manipulating existing geometry? I seem to remember talk of bugsplats if you tried manipulating existing geometry (I might be wrong).
The C API is more limited; the SUVertexSetPosition function is the only function that suggests existing geometry can be manipulated (instances and groups can be transformed quite easily too). The major problem with the C API in taking the “manipulating” geometry approach is that there is no function to erase an entity from the model. So if one wants to delete an entity in the model through the C API, you would have to copy across the entire model except the items that you want to delete, to a new model and then save.
I know the C API was originally intended for import/export purposes, but because of the performance gains and multi-thread possibilities, it is a good place for some tools to be built (extensions like Skalp). If I scrap the desire to set persistent IDs, then I’d like my Christmas wish to be:
new SUEntitiesEraseEntities(size_t len, SUEntitiesRef* ent[]) C function
new SUModelEraseComponentDefinitions(size_t len, SUComponentDefinitionRef* def[]) C function
new SUModelEraseLayers(size_t len, SULayerRef* layers[]) C function
new SUAttributeDictionaryEraseValue(SUAttributeDictionaryRef dictionary, const char * key) C function
That should open up new possibilities with the C API to manipulate geometry.
Not that I am aware of. At least not in Ruby API. The C API is currently missing methods to transform existing entities - this is coming though.
Not that you can also transform vertices, I often use transform_by_vectors to move a set of vertices to new positions. Class: Sketchup::Entities — SketchUp Ruby API Documentation
That’s how I do the live preview of SUbD when the user crease the mesh. I then avoid the expensive operation of re-creating the mesh - just push vertices around.
Yes - the C API is still in active development to become feature complete. The ability of the Ruby API is in large part the target for the C API. Each new SU release will move closer to that target.
