I’m working on a SketchUp extension and need to retrieve shadow information using the C++ SDK. In Ruby, there’s a ShadowInfo class that lets you get shadow details, but I can’t find something similar in the C++ API documentation.
My main goal is to get the sun’s direction vector based on the current shadow settings that users configure in SketchUp. I need this data to calculate lighting in my plugin.
Does anyone know if there’s a direct way to access this through the C++ SDK? If not, are there alternative methods to get the same information, maybe through date and time parameters or other shadow-related functions?
Any help or code examples would be really appreciated. I’ve been searching through the SDK docs but haven’t found anything obvious yet.
hey there, i ran into this same issue last year. the c++ sdk doesn’t expose shadowinfo directly like ruby does unfortunately. what worked for me was getting the model’s options manager and looking for shadow-related settings there. you might need to dig into the model’s rendering options or time/date attributes. not as clean as ruby but it’s doable with some extra work.
I hit this same issue building a daylighting plugin two years back. SketchUp’s lack of direct shadow API access in C++ is super frustrating. Here’s what worked for me: SketchUp stores shadow config in the model’s rendering options through SUModelGetRenderingOptions. You can pull shadow display state, time values, and coordinates from there. Converting those parameters into sun direction vectors is where it gets tricky. I’d go with the NREL Solar Position Algorithm - it’s well-documented and handles all the astronomy math. Feed it the lat/long, timezone, date, and time from SketchUp’s shadow settings. It spits out solar azimuth and elevation angles that you can convert to direction vectors. Watch out for SketchUp’s coordinate system though. Your calculated sun vector needs proper transformation to match how SketchUp handles lighting directions internally. I spent weeks debugging bad shadow casting because of coordinate mismatches. It’s way more work than Ruby’s convenience methods, but you get exact control over the calculations.
I’ve hit this wall countless times. Manual shadow calculations and Ruby bridges? Way too much work for something this basic.
Skip all that - just build a workflow that watches SketchUp’s shadow settings and pulls the data automatically. No SDK wrestling required.
Set up automation to monitor your SketchUp files. Shadow parameters change? It grabs rendering options, coordinates, time data, then runs solar calculations automatically. No messing with attribute dictionaries or bridge code.
Built something like this for lighting analysis last year. Everything ran in the background - data extraction, sun vectors, the works. Beat the hell out of debugging coordinate transforms or coding SPA algorithms by hand.
Bonus: extends easily to sync with other tools. Push vectors to lighting sims, update dashboards live, whatever you need.
This beats fighting SDK limitations and gives you something way more solid than hardcoded hacks.
The gap between Ruby and C++ shadow access is super annoying. I’ve found SUModelGetOptionsManager works way better than digging through attribute dictionaries - you can grab the ShadowInfo options directly. The shadow options come back as typed values you can pull with SUTypedValueRef functions.
Here’s the tricky bit: SketchUp stores shadow time as minutes from midnight. You’ve got to combine that with shadow date, UTC offset, and location data to get actual sun positions. I built a simple solar calculator using basic geometry equations instead of the full SPA algorithm - much lighter and works fine for most lighting stuff.
Watch out though - SketchUp’s internal sun direction doesn’t always match theoretical calculations because of how they handle daylight saving transitions. I cache the shadow state now and only recalculate when settings actually change. Saves a ton on performance.
Yeah, I’ve hit this wall several times. The C++ SDK sucks for shadow data compared to Ruby.
I ended up pulling shadow parameters manually from the model’s attribute dictionaries. Use SUModelGetAttributeDictionary and hunt for keys like “ShadowTime”, “ShadowDate”, “Latitude”, “Longitude”.
Once you’ve got those values, you’ll have to calculate the sun vector yourself with solar position algorithms. I used the SPA algorithm on one project - worked great. The math isn’t crazy hard but it’s definitely more work than just grabbing a ready vector.
Or you could create a small Ruby bridge script that exposes the ShadowInfo data and call it from your C++ extension. Pretty hacky but beats implementing solar calculations from scratch.
This video covers the lighting calculation basics if you go the manual route:
Frustrating that Trimble still hasn’t exposed this properly in the C++ API. I’ve been asking for this feature for years.
