SketchUp C API
|
The SketchUp C API is an interface for reading and writing data to and from SketchUp models. This API interacts directly with SketchUp files (.skp). It can create new ones as well as read or modify existing ones.
The SketchUp Importer/Exporter Interface allows you to create native SketchUp importer and exporter modules that are available directly within SketchUp as an import or export option.
The documentation contains reference material for all functions, data structures, and enumerations in both the SketchUp C API and the SketchUp Importer/Exporter interface.
The online C API documentation can be found here: SketchUp C API Online Documentation
The C API library for Windows is built using Microsoft Visual Studio 2019 (v142). It includes only 64-bit binaries. Building and releasing an application using the SketchUp C API for Windows requires including SketchUpAPI.dll and SketchUpCommonPreferences.dll, which can be found in the SketchUp C SDK for Windows. Also, the following C runtime DLLs must be included: msvcp140.dll and msvcr140.dll. Due to Microsoft binary compatibility, the runtime DLLs remain named "-v140.dll"
Alternatively the Microsoft Visual C++ 2019 Redistributable Packages can be used, which can be found here:
64-bit redistributable package
SketchUp 2017, 2018, and 2019 for Windows were built using Visual Studio 2015 SP1, and so plugins should be built with the Platform Toolset set to Visual Studio 2015 (v140). Using a different Platform Toolset will likely cause the plugin to fail to load and cause SketchUp to crash.
The SketchUp C API library for macOS is built using Xcode 10.3 (targeting SDK 10.12). Building and releasing an application using the SketchUp C API for macOS requires including SketchUpAPI.framework. The framework is 64-bit, and can be found in the SketchUp C SDK for macOS.
SketchUp 2017, 2018, and 2019 for macOS were built using Xcode 7.2.1 (SDK 10.10).
SketchUp 2017 for macOS was built using libstdc++, so plugins should be built with the same library. Using libc++ will likely cause the plugin to fail to load and cause SketchUp to crash.
How you link depends on whether you are using the C API from a SketchUp extension reading from the open model or not.
This is the most typical usage for most cases:
<SDK_PATH>\headers
to the include paths.<SDK_PATH>\binaries\sketchup\x64\SketchUpAPI.lib
<SDK_PATH>
to framework search paths.SketchUpAPI.framework
It is possible to use the C API for read only access to the open model via SUApplicationGetActiveModel
.
<SDK_PATH>\headers
to the include paths.<SDK_PATH>\binaries\sketchup\x64\sketchup.lib
(Do not link against SketchUpAPI.lib
!)<SDK_PATH>
to framework search paths./Application/SketchUp 2019/SketchUp.app/Contents/MacOS/SketchUp
as the bundle loader. (Do not link against SketchUpAPI.framework
!)For more details, refer to the Live C API example project: https://github.com/SketchUp/sketchup-live-c-api
Included in the SDK package are two C++ sample projects: skp_to_xml and xml_to_skp. These projects demonstrate how the SketchUp C API can be used within the SketchUp plugin architecture to create importers and exporters meant to be hosted directly by SketchUp. The XML schema used by the samples is only for demonstration purposes.
Below are some simple code examples of how to use the SketchUp C API in a standalone C++ program.
This example demonstrates how to load a SketchUp model from a .SKP file and read some data from it.
This example demonstrates how to create a SketchUp model, add some data to it, and then save the model to a .SKP file.
The SketchUp C API does not automatically track and dispose of objects that are created. The API is a C interface, and therefore there are technical limitations to memory management.
The general rule is that after an object is created using one of the SU*Create*() functions, the object should in some way be attached to the model data hierarchy.
Some object types can be retrieved directly from an existing object without explicitly calling a create function. In this case, you should not explicitly call the matching release function, as it is already attached to an object.
An entities collection can be retrieved from a model, a component definition, or a group. Entities collections are never created explicitly–they are automatically created as part of another object. Objects that can be added to an entities collection are faces, edges, curves, groups, images and component instances, using one of the SUEntitiesAdd*() functions. These objects will be released automatically when the model is released.
The types of objects that can be added to an Entities collection are:
Example: If you create an edge using SUEdgeCreate(), the most common pattern is to then add the edge to the model or to an object's entities collection. Example code (return values ignored for brevity):
Objects that can be added to a model are materials, component definitions, layers or scenes, using one of the SUModelAdd*() functions. These objects will be released automatically when the model is released. Example code:
In this case, the created object is then owned by an existing object. For instance, a loop input can be added to a face as an inner loop. A material or layer can be added to any drawing element. These objects will be released automatically when the model is released.
This is done by calling the corresponding SU*Release() function. This is not the typical use case for an object, except for the model itself as well as SUStringRef objects. However, it is possible to create and release many different types of objects explicitly. This is not advised however, because in most cases an active model is necessary for a function to operate properly.
A transient object is one that is not actually added to the model, but helps in the process. They are always explicitly created, are then used in some operation with the active model, and then are explicitly released. Examples of transient objects are: SUGeometryInputRef, SULoopInputRef, SUMeshHelperRef and SUUVHelperRef.
SUComponentInstanceRef - Component instances are actually created from an existing component definition using SUComponentDefinitionCreateInstance(). Though it can be released using SUComponentInstanceRelease(), the common pattern is to add the component instance to an entities collection using SUEntitiesAddInstance().
SUGeometryInputRef - Geometry input is a special type designed specifically allow you to input a large amount of geometry data to the model. The lifecycle of a geometry input object is that it is created, has vertex and loop data added to it, is added to an entities collection (using SUEntitiesFill()), and then is explicitly destroyed.
SUImageRef - An image can be created from a file using SUImageCreateFromFile(), however there is no corresponding release function. An image must be added to the entities collection of a model, component definition, or group. When the parent object is released, the image will be released automatically.
SUMeshHelperRef - A mesh helper is never added to another object, so it must always be explicitly released.
SUModelRef - Since a model is a top-level object, it must always be explicitly released.
SUStringRef - A string object is always created with one of the SUStringCreate*() functions. It is used to retrieve string data, like a name or a description, from an existing object (e.g., SUComponentInstanceGetName()). It must always be released using SUStringRelease() or you will leak memory. There is no memory management concern with the API regarding string data passed to an object (e.g., SUComponentInstanceSetName()), because a const char * is passed, not a SUStringRef.