I have no idea why that function return the basename. Itās easy enough to extract that from the full path, so it would have been better to return that.
Iām not seeing any other way to obtain the full path either.
And itās even worse if the texture was created from an SUImageRepRef as then the filename contains only the file extension (ie, ".png".)
SUImageRepRefalso lacks a file path getter function (which should return a full path once an image file is loaded to or saved from the SUImageRepRef object.)
Iād be cautious of doing this as I recently found some potentially damaging ālinksā imbedded as texture paths [including php paths] in skm files from one of the āfree texture repositoriesāā¦
I use the returned name to check for a local file and write on out if it doesnāt existā¦
This is an old thread but the issue still remains. I have just recently come upon this limitation in the C API. I have done quite well migrating my export application from Ruby to the C API, actually using C# expanding on the C# wrapper that was made available in the forum. The only exception is the texture full path name. I am having no luck with a work around, for instance storing the path as some sort of metadata in the model. The only solution I have is to build an object library reference list to be included in my export application.
I would think that you could (in Ruby) attach an attribute dictionary to the material object(s) that has the texture path and then retrieve this on the C-side.
You will need to upcast the SUMaterialRef to a SUEntityRef and then use SUEntityGetAttributeDictionary.
Are you still using or (targeting) SketchUp 2017 or is this exporter for latest versions ?
Hi Dan. I am using the latest version. Is there a way of attaching the attribute directory in the model itself? That is a good solution for my exporters that work within the SketchUp process. I am also building exporters and modifiers that need to work outside the SketchUp process for exporting and updating multiple models. For this I have decided to build a texture reference application that creates a list of all valid texture types and their locations.
Of course there is. Any model object that is a subclass of Sketchup::Entity inherits attribute dictionary access methods.
I would suggest attaching the dictionaries to the Material objects.
Make sure to create a unique dictionary name so as not to clash with dictionaries other extensions might be attaching. (It is common to prefix your dictionaries with your top-level namespace module identifier and the extension submodule identifier.)
Okay, your profile still says 2017.
If however, the model is shared (perhaps via the 3DW) the external paths to file locations will be invalid. (Theyāll point at a disk location on the model authorās machine, not actually to valid locations on the machine that opened the model.)
So, youāll need to check for file existence with some C# library.
If not, then you may need to locally write out resource files with:
Dan your help was greatly appreciated. I was able to use dictionary and attribute for materials. I ran a few tests, and this is a great way to attach metadata. My only question is whether or not that metadata (the dictionary and keys as well as their values) are accessible in the IDE or must it be only accessed via Ruby code or even the C API.
What IDE? SketchUp does not come with an IDE, nor it impose the use of any particular IDE.
Attribute dictionaries are model data objects and must be accessed via some API methods / functions.
If (for some reason) you find it necessary for some IDE to access model data, then you would need to write a plugin for that IDE which uses (I guess) the C API. (You might need to wrap the C API calls into some coding language that the chosen IDE understands.)
But getting into IDE integration is off-topic for this thread.
Itās my bad, I called the SketchUp 2023 application (model builder) an IDE. Too much Visual Studio for me. Sorry for the confusion. Probably need to build an extension to get the dictionary info and keys to perform user edit functions for keys and their values as well as adding or deleting dictionaries.
There are existing extensions that do this. The Dynamic Components extension keeps data in dictionaries named "dynamic_attributes". The Classfications are also kept in special custom dictionaries.
There are also generic utilities for inspecting dictionaries. I most often use the one by Aerilius.