I’m in the process of upgrading my extension to support SU2025 PBR materials.
I successfully updated my extension, and it works fine in SU2025. I noticed I’m having issues loading my extension in older SketchUp versions (SU 2024 and SU 2023). Is the latest SDK supposed to work with older SketchUp versions ( SketchUp API 13.0, SketchUp 2025.0). I could not find it in the release notes: SketchUp C API: SketchUp C API Release Notes
The previous SDK was compatible with older versions because I could support SU2024, SU2023, and SU2022 with a single build.
And looking at dependency walker, it seems that the DLL is not missing any downstream dependencies (except for Ruby, which I assume is loaded when running SU?):
This error message usually means that the entry point function in the compiled so, dll, dylib or bundle cannot be found by Ruby. If you are using Ruby’s require method, then there must be an entry point function named Init_SUEX_Rayscaper(), (i.e., the prefix Init_ followed by the library filename minus the extension.)
The plugin works just fine with SU2025; it fails when I try it on SU2024. It worked before the upgrade to the latest SDK on SU2022, SU2023, SU2024 and SU2025.
My next suggestion would be to look at the targeted toolkit setting in MSVS.
However, it appears that the C SDK documentation intro page has not been updated for 2024 and 2025 releases in this regard.
Ruby DLL’s name is different in SU 2023, which would explain why a build for 2025 won’t work there. But I’m not sure why it doesn’t work in 2024 (which has the same Ruby DLL I believe)
To clarify on the Ruby versions, I’m building two DLLs of my C extensions. One targeting Ruby 2.7 (x64-msvcrt-ruby270.lib - SU 2023/2022) and the other one targeting Ruby 3.2 (x64-ucrt-ruby320.lib - SU2024/SU2025). Based on the SketchUp version, I’m copying the correct dll in my plugin directory and load it from there.
There is a system flag we can enable that will cause the kernel to log the diagnostic information created by a failed loadlibrary call. The flag is referred to as Show Loader Snaps (SLS) Show Loader Snaps - Windows drivers | Microsoft Learn. The SLS flag is enabled by a tool called gflags.exe GFlags - Windows drivers | Microsoft Learn which is part of the Debugging Tools for Windows and would have been installed on you computer as part of Visual Studio.
Summarizing the comments from a short discussion of using gflags.exe on this Stackoverflow page.
The Microsoft gflags tool will always tell you exactly what dependency is failing to load and why.
Run gflags -i your_application.exe +sls. After that execute the application under the debugger to capture the loader traces.
.
. debug you application
.
Run gflags -i your_application.exe -sls afterwards to disable the loader traces.
Below are the steps to use gflags to diagnose problems with your SUEX_rayscraper.so file.
Disable Rayscraper in SU2024
To Enable the Show Loader Snaps flag
Open a Command Prompt
cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
gflags -i sketchup.exe +sls
Start windbg.exe
File>Open Executable
Navigate to Sketchup.exe
The debugger will load Sketchup and stop at the entry point
Press F5 to complete loading Sketchup.
At this point you can either enable the Rayscraper extension or
require ‘path/path/SUEX_Rayscraper.so’ in the Ruby Console
The loader failure information will be logged to the windbg console.
Disable the Show Loader Snaps flag
gflags -i sketchup.exe -sls
Thanks for the suggestions @sWilliams ! That helps.
Let’s say I use new SU2025 functions (e.g. SU_RESULT SUMaterialGetMetallicTexture(SUMaterialRef material, SUTextureRef* texture)) in my extension. How are these symbols resolved when I run my extension in SU2024 for example?
I upgraded to the latest SDK (2025-0-575) and still have the same issue. My extension works in SU2025, but when loading in SU2024 I’m getting the following error:
[2025-03-31 15:07:15.523] [error] [16276] Failed to load library 'C:\Users\Thomas\dev\RayscaperBuilds\Release\rayscaper\installed\Windows\3.2.2\0.9.45 Beta\resources\SUEX_Rayscaper.so': [127] The specified procedure could not be found.
Could it be that my plugin is no longer compatible with older versions of SketchUp because I’m using symbols relevant only to the SU2025 (like SUMaterialGetMetallicTexture)?
I assume that since the SDK is a file SDK and since the 2021 release that SketchUp can open model files from newer version, that it is necessary to code defensively with respect to features that may not be present in the file that is opened with the C API.
So, you have four possible scenarios for the SKP file ↔ SDK version.
The file was created in an older version and lacks the PBR material properties:
… and is opened in a pre-PBR version of SketchUp.
… and is opened in a PBR aware version of SketchUp.
The file was created in a newer PBR aware version and possibly contains the PBR material properties:
… and is opened in a pre-PBR version of SketchUp.
… and is opened in a PBR aware version of SketchUp.
I think the first check that you need to do is use SUMaterialGetWorkflow() to determine whether the file is even using PBR materials.
(It is a bit weird that this is defined needing a material argument. In Ruby this would be either a method of the model object’s materials collection or an attribute of the model options hash. But this is C. What happens if the model has no materials? Do ya’ need to create one in order to ask if the workflow is set to classic or PBR?)
Anyway, I wonder if an older model is opened, does this set the 2nd argument to the SUMaterialWorkflow_Classic enumeration value or does it return SU_ERROR_NULL_POINTER_OUTPUT?
Then before attempting to get any PBR texture, use the query functions:
Same question when a pre-PBR file is opened or a PBR-aware file is open in a older version, does this set the bool argument returning SU_ERROR_NONE, or does it return SU_ERROR_NULL_POINTER_OUTPUT?
Here’s a link to my extension’s RBZ: Rayscaper_Win_0.9.45_Beta.rbz - Google Drive. Internally, it packs the DLLs required to run Rayscaper. You will notice that it works in SU2025 but fails in SU2024.
Internally, I use two DLLs:
SUEX_Rayscaper_LoadDlls.so: The purpose of this DLL is to simply load the dependencies of my main DLL, and load the DLL itself. This is to make sure I’m using the correct version of dependencies and don’t fallback to some dll installed on the user’s system.
SUEX_Rayscaper.so: This is my main dll.
I can successfully load the first DLL, but that one fails as soon as I try to load SUEX_Rayscaper.so in SU2024.
So I assume that the new SDK provides some stubbing when the code detects that it’s running in a version of SketchUp that doesn’t support a particular API.
I assume that since the SDK is a file SDK and since the 2021 release that SketchUp can
open model files from newer version, that it is necessary to code defensively with respect
to features that may not be present in the file that is opened with the C API.
I’m using the live C API to query things (not modifying anything). So I assume it’s not querying from a file representation of the scene, but from an in-memory data structure representing the scene? But I’m only guessing here.
Anyway, I wonder if an older model is opened, does this set the 2nd argument to the SUMaterialWorkflow_Classic enumeration value or does it return SU_ERROR_NULL_POINTER_OUTPUT?
That’s a good question. I haven’t been able to verify that by running in an older SU version (because see my original issue ). I have coded this defensively, assuming anything that indicates not PBR or an error means classic workflow:
I do not believe there is a difference to the SDK. I.e., with the “live” API the model is preloaded for you. In standalone mode you must explicitly load the model into memory from a file path.
I confirmed that a C extension using the live C-API, compiled using the latest SU 2025 SDK, can be loaded in SU2024 and SU2023, but not in SU2022.(edit: It’s not entirely compatible, as soon as I use environment functions, it fails to load in older SketchUp versions, see my next post).
It seems that the SU2025 SDK is not fully compatible with older versions.
I updated the example C extension to use the new environments API. I can load this extension fine in the SU2025 but fails in the SU2024 API. This is the same issue I’m seeing with my extension. Note that a new function like SUMaterialGetWorkflow does work in older version of SketchUp.
I see you only have two DLLs. I’m not sure what the versions of SketchUp you intend of supporting, but if only Ruby 3.2 and 2.7, then you only go back to SketchUp 2021. (Which was the start of the new file “versionless” format.)
Somewhere I noted (perhaps not in this thread) that this section of the SDK main page does not specifically mention SketchUp 2024 and 2025 releases, re: the toolset.
I think that it implies that SketchUp 2024 and 2025 are built using MSVS 2022 to platform toolset v143.
SketchUp 2020, 2021, 2022, and 2023 built using MSVS 2019 to platform toolset v142.
SketchUp 2017, 2018, and 2019 for Windows were built using MSVS 2015 SP1, to platform toolset v140.
As a tabular reference:
SketchUp
Ruby
MSVS
Toolset
2024, 2025
3.2
2022
v143
2021, 2022, 2023
2.7
2019
v142
2020
2.5
2019
v142
2019
2.5
2015SP1
v140
2017, 2018
2.2
2015SP1
v140
For “Live” use I would think that the correct VC runtime DLLs in SketchUp’s binary directory are those used.