In the Ruby API, we have texture.filename:
The filename method retrieves the entire path, including the file, for a texture object.
In the C API, we have SUTextureGetFileName():
A full path may be stored with the texture, but this method will always return a file name string with no path.
Why is that?
Is there a way to retrieve the full path of a texture in the C API?
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".)
SUImageRepRef also 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.)
Should I file a bug report for the current method, or a feature request for a new separate method? eg SUTextureGetFilePath()
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ā¦
john
Because the SUTextureGetFileName() function has specific varying behavior (purposely designed,) ā¦ it is likely best to file FRs for new functions:
SUTextureGetFilePath()Logged Issue:
and
SUImageRepGetFilePath()Logged Issue:
Logged Issue:
Ca you elaborate? Example?
the most recent one was from misbehaving model [on the users mac] and one ātexture.filenameā ended .php.jpg
I didnāt investigate, what may have or not been inside, I just exacted the pixel data, and the stats and created a new skmā¦
it was one of about 50 materials in the model with only three or four had the userās local pathsā¦
the file was reduced from 126 to 90 MB after I cleaned and optimised the skmāsā¦
john
I still donāt understand what the issue isā¦ ? What is the damaging behaviour?
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 ?
Oh ā¦ FYI, Ruby is implemented in C so it itself has a C API.
For a āliveā C extension running within SketchUpās process, you can call Ruby API functionality.
In my Ruby Learning Resources Book list, see the downloadable PDF for:
There are several C functions for calling Ruby methods.
You can use one of these to get the path string by calling the method on the texture object.
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.
Yes this is also a direction that I was looking into. That PDF will be helpful. Thank You very much.
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:
SUMaterialWriteToFile()SUMaterialGetTexture()
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.
Whatever your extension requires.
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.