Hey there i am facing an issue in Dynamo for Revit in 2023 and 2025 when reading a materials texture path it will only return the file name rather then the full path.
I have written my own cpython3 node and also get returned withe same issue.
I have used Genius Locis Find Texture Path node to do this and i am returned with same issue.
Please see the image below.
Heres the code.
import clr
clr.AddReference('RevitAPI')
from Autodesk.Revit.DB import *
clr.AddReference('RevitServices')
import RevitServices
from RevitServices.Persistence import DocumentManager
doc = DocumentManager.Instance.CurrentDBDocument
materials_input = UnwrapElement(IN[0])
materials = materials_input if isinstance(materials_input, list) else [materials_input]
def get_material_texture_paths(material):
paths = []
# Check if material has appearance asset
if hasattr(material, 'AppearanceAssetId'):
assetElem = doc.GetElement(material.AppearanceAssetId)
if assetElem:
# Use the appearance asset edit scope
with Visual.AppearanceAssetEditScope(doc) as editScope:
asset = editScope.Start(assetElem.Id)
# Iterate through all properties in the asset
for idx in range(0, asset.Size):
property = asset.Get(idx)
connectedAsset = property.GetSingleConnectedAsset()
# Check if there is a connected asset
if connectedAsset:
# Extract paths based on schema type
if connectedAsset.Name == "UnifiedBitmapSchema":
bitmap_property = connectedAsset.FindByName("unifiedbitmap_Bitmap")
if bitmap_property:
paths.append(bitmap_property.Value)
elif connectedAsset.Name == "BumpMapSchema":
bitmap_property = connectedAsset.FindByName("bumpmap_Bitmap")
if bitmap_property:
paths.append(bitmap_property.Value)
paths = list(filter(None, paths))
return paths[0] if len(paths) == 1 else paths if paths else None
all_results = []
for mat in materials:
result = get_material_texture_paths(mat)
all_results.append(result)
OUT = all_results
The OOTB dynamo node AppearanceAssetElement.GetRenderingAssetTextureImages doesnt work either
Does anyone have any insight on how to read the full path rather then just the file name.
If you hover over the materials image in the Material menu in revit it shows the full path of the image so revit has to be storing it somewhere right?
Material asset paths are relative - so the default path is C:\Program Files\Common Files\Autodesk Shared\Materials\Textures
If you have custom textures it will most likely include the full path - see example below
Thanks for a response these materials texture paths are currently living in a different directory than the default autodesk material directory. Which is why i’d expect a response similar to the node you are showing. Which node do you happen to be using to get that response?
There isn’t a path to it as your system has been told where it lives, so Revit, you, and anyone else in your environment (such as your co workers) should know what that directory is.
The source code could be modified to search all material directories + the file name until it is returned, but that would slow stuff down quite a bit for 99% of the use cases where this step isn’t needed. Since you’ve got a unique case, you’ll have to write the code solution yourself.
I believe there is a method to read the relative path directories available - I recommend you start with.this method: Revit API 2026 Documentation
So I’ve attempted getting the relative path directories via your recommended method. However it returns a path that doesn’t exist on my machine when viewing it in windows explorer i have admin rights to check it as well.
I’m curious there must be a property/field that i can access as hovering over the path in the material editor reveals the full path.
Looks like you may have to read your Revit ini directly (info), or find mother method for accessing those directories.
I was able to parse the ini for the paths but then you need to break them apart and form them into some useful paths because they truncate those as well (C:\ = ..\..\..\) then you will need to seperate the known paths with the relative paths do a check and then reconcile the list.
additionally it looks as if the API is giving a file prefix of 1\Mats\ even though in the material editor it is pathed to the 3\Mats. its not reporting the true path ugh.
The full material editor doesn’t have a real API. I can’t fix anything about it, but I can continue to lobby for a change that gets it included. One big obstruction is that there hasn’t been a clearly communicated value in having such.
So in the hopes that you’ve got one - what is the reason you need this path?
There is a performance slow down in Revit when it is searching for custom materials.Additionally missing materials can cause problems when rendering. I have a script that collects the paths and identifies if they are missing. This used to work before they changed the pathing in the API. It would give the full path to the material. now it gives a truncated ‘relative’ path but its not actually giving the real path…even truncated.
That is a good answer and I’ll pass it on.
But before I do I’m going to play devil’s advocate for a second. Please don’t shoot the messenger or get frustrated with me for asking this - I’m only trying to solidify the case before I surface it.
Why are materials and texture paths not being managed as a library to keep them from getting lost?
No worries, I appreciate the inquiry. Content can move from company to company, server to server. Sometimes there are materials for projects in restricted locations (more so as companies and projects are moving to zero-trust) sometimes its just poor user practice and the add materials from their own desktop. As support, usually the question we get is where are our materials? why cant i see this material in rendering. and you need to go track it down one by one. Other workflows could be to collect the relavent materials and move them to a unified library, or to repath to a common library.
I have wanted to make a Material Manager tool for sometime but i am not a good coder. yet.
I have yet to meet anyone who considers themself a good coder and actually is one, but I can confirm this is quite ambitious. Remember that for managing material libraries there isn’t an API at all so you’re poking blindly and that is apt to corrupt things.
Don’t let any of that stop you though - but do look into some lower hanging fruit first. A C# based Dynamo package to transfer materials int a project would be viable first step to enable that journey. Pursuing it with Python can work, but is apt to get into engine issues very quickly. Nodes also work to some extent, but those are just different wrappers of C# and/or Python anyway. One path is to take nodes transition to Python and then jump into C#. Just don’t let the knowledge hold you back - the only way to get the know how is to build.
I am fairly certain that symbolic links are an ‘easy’ button to prevent loss in files moving between companies, transferring servers, or dealing with restricted locations (in which case the only fix is to move things out of the restricted location anyway). This amazing blog post from @Aaron_Maller of Parallax Team shows a great example of using symbolic links to manage materials stored on desktop connector, and the process can be applied for any of the use cases you mentioned above except one.
Sadly the one thing we can’t manage to build a system to account for is the rouge user practices. You can idiot proof hole in the floor today and universe will provide a bigger idiot tomorrow, who somehow will fall in the hole. Instead I always recommend such cases are identified (well the missing texture shows a path to Jacob’s desktop in the UI so no more work need happen here) and the idiot asked to fix the issue (hey Jacob - we need you to move all your textures from your local disc to the server where textures are supposed to live as per our standard, which has to happen before this date which is a day before our presentation).
You no longer need that Symbolic Link. Materials can now be stored in Forma/ACC and accessed directly through Desktop Connector, as long as your Hub Name and Project Name and Folder Name dont have any special characters in them… Because Desktop Connector doesnt handle those well, like, at all.
But for Jacob- There currently ISNT a good way to manage Materials, inter-company. Hell, the only ways to manage them WITHIN one company are if you are totally LOCKED IN on the deployment and install routine, because the ARAP path is set in the INI, so it deals with UserDataCache and the Revit.ini in AppData. So managing it company wide is a nightmare, especially if people want things “project specific.”
The folders shown above (1, 2, 3, 4, 5) are the OOTB locations, for OOTB render assets. Most materials use those until someone paths them to somewhere custom.
You totally CAN get the paths, though. If you see the folder with the 1, 2, 3, 4, or 5, you can basically replace those numbers with the OOTB locations (which moved, some years ago, from x86 to the new location, LOL). But the paths dont change.
My thought here was the textures could be copied from company A server to company B server and a symbolic link set up by company B to assure the paths match. Not easy for long term maintenance and never intended for more than a one off transfer, but I don’t see why that wouldn’t work.
- You would have to add the Symbolic Link path to the ARAP dialogue… as staff members jump on and off the project, which would get frustrating.
- Also, your IT group would have to be “better than mediocre” to make sure that Symbolic Link was set up appropriately, project by project.
- Would that “new directory” be job specific, or all shared projects? That gets REAL interesting with naming Material Assets (images). Sure, prefix with a Project Number works (which is the icky way we recommend it), but most folks dont like one big folder.
- Its hard to make it sustainable, since you have to make the path so ambiguous that it can work in any companies server setup. That (basically) means a single Drive Letter. Which, of course, are limited in count.
- When people edit textures, having to constantly ship them back and forth gets old, really quickly.
- Still doesnt work when people are on the go / traveling / outside the office (admittedly, Desktop Connector DOES solve this, because VPN is a fast way to make the Material Editor crash Revit, hardcore).
Not saying all of this to be argumentative, btw. Materials shared across project teams in multiple companies is exhausting.
Oh it is miserable, tooling should exist to make it easier, and I would avoid this other than the ‘one time handoff’ where firm B steps in as firm A steps out. But IMO for the semi-competent IT team (most should clear that bar) all of the above on a competent IT team is certainly easier more doable than ‘find all the images, relocate them, then repath all the materials in all of the models’ which usually feels like you’re trying to bail out a submarine with a sieve.
Most of the time when we are having these discussions with firms, its because there isnt a “one time hand of.” More and more, firms are partnering long term (as silly as some of the arrangements are). They are in the same Project Hub, same model or same group of models, and they are rendering each others stuff on the regular.
We have one client right now where there are multiple models by multiple parties, and they expect to remain that way through CD’s. Materials changing day to day, and both firms expect to be able to render.
(Im not saying i endorsed this setup, nor agreed with the expectation, but this is AEC in 2026).
Wouldn’t the desktop connector integration solve this? Or am I missing something?
As always, asking as a way to get the feedback to development and help find work-arounds where I can. 
Oh, it does.
Sorry, i thought we were still just discussing “inter-company Material management, as a composite, and not a project by project thing.”
Yeah, Desktop Connector solves it for the Project Teams, now. I still dont love it, as the ARAP dialogue still needs to be mitigated project team by project team, but whatever. It works.
