You could end up 'reading' custom attributes made by the user which you might not want to change/validate (eg. metadata/pipeline data or even unrelated data). Setting up a dictionary/set of attributes for those missing is a better and more lightweight solution.
Also note that you could still rely on reading the attributes yourself by checking the registered types of the filePathEditor, but since it allows to query the unresolved names anyway... why bother (outside of optimization)? Or was the latest blob of code I posted still not functionally what you were looking for? On Wednesday, August 12, 2015 at 1:07:22 PM UTC+2, Fredrik Averpil wrote: > > Yes, I used to parse .ma too. So that could be one way of dealing with it. > I don't believe there is such a thing called a relative path inside of the > .ma though. If I remember correctly, all paths are always absolute when you > peak inside an .ma file. > > Some old notes which may or may not be completely up to date regarding all > of this, but perhaps may be of some use for you: > http://fredrik.averpil.com/post/88067886541 > > // Fredrik > > > On Wed, Aug 12, 2015 at 12:51 PM Marcus Ottosson <konstr...@gmail.com > <javascript:>> wrote: > >> validate all filepaths before publishing. >> >> You’re absolutely right. >> >> As I’m not alone in solving it, here’s some more research. >> >> I’ve found that if I temporarily export an .ma of nodes, excluding those >> that I know won’t have one and may be heavy to export (such as mesh), I >> can parse the resulting ASCII file for /. The file ends up light, >> regardless of how “heavy” a scene is, and takes under a few milliseconds to >> export. >> >> The / in the file is used for either: >> >> 1. A file path, even on Windows >> 2. A comment >> >> Excluding comments, the rest results to all paths present in the scene. >> >> Though I haven’t tested it thoroughly, I’d expect to run into the need >> for additional parsing for: >> >> 1. Relative paths, without / >> 2. Expressions or the like that also use / >> >> >> >> On 12 August 2015 at 11:24, Fredrik Averpil <fredrik...@gmail.com >> <javascript:>> wrote: >> >>> Typing on the iPad really sucks... And with the line breaks bug in >>> Google Inbox it's just... bad. >>> >>> ons 12 aug 2015 kl. 12:23 skrev Fredrik Averpil <fredrik...@gmail.com >>> <javascript:>>: >>> >>>> Hehe, it seems to me that you are trying to achieve something we do >>>> here; validate all filepaths before publishing. >>>> Am I right? ;) >>>> We want all our filepaths to be relative to the Maya project at all >>>> times and there's no silver bullet for this, I'm afraid. You're going to >>>> have to combine several methods. I wouldn't mind sharing our dictionary >>>> but >>>> it's far from covering all filepaths from all imaginable plugins etc and >>>> obviously it won't cover Maya refs. It just consists of the node >>>> attributes >>>> which are used on a regular basis in our studio. >>>> >>>> About a a-Ray 3.0, I believe that was me asking them to make their file >>>> attributes detectable by the filepaths editor. However, in the end I have >>>> need up ditching the filepaths editor and instead made my own solution >>>> >>>> // Fredrik >>>> >>>> ons 12 aug 2015 kl. 10:59 skrev Roy Nieterau <royni...@gmail.com >>>> <javascript:>>: >>>> >>>>> And sorry for the spamming, but it seems that V-Ray 3.0 actually does >>>>> register the types for its file attributes. >>>>> In Maya 2015 it doesn't list the Alembic attributes, but I assume it >>>>> will with coming version (maybe even Maya 2016)? >>>>> Autodesk will likely push developers to register it for their custom >>>>> nodes correctly, this way archive scene also supports it correctly. >>>>> >>>>> Anyway, I just noticed that it's important to perform a refresh before >>>>> you query! >>>>> Without doing that I just had it list nothing at all. >>>>> >>>>> Also the filePathEditor command actually >>>>> *does list references!*Here's some better explaining code: >>>>> >>>>> import os >>>>> >>>>> # Refresh the file list cache (note that this is relatively slow for >>>>> large scenes) >>>>> cmds.filePathEditor(refresh=True) >>>>> >>>>> # Get the file directories >>>>> directories = cmds.filePathEditor(query=True, listDirectories='', >>>>> relativeNames=False) >>>>> >>>>> # Get the files in use >>>>> for directory in directories: >>>>> files = cmds.filePathEditor(query=True, listFiles=directory) >>>>> >>>>> # With the file attributes (also see earlier reply with >>>>> `grouper()` function to iterate over it) >>>>> # file_attr = cmds.filePathEditor(query=True, >>>>> listFiles=directory, relativeNames=True, withAttribute=True) >>>>> >>>>> # To get the full path of the files in this directory >>>>> full_paths = [os.path.join(directory, file) for file in files] >>>>> print full_paths >>>>> >>>>> By setting *relativeNames* to *True* it actually returns the >>>>> unresolved paths. Even if a fileName is in the long format in a file >>>>> attribute and is within the current workspace then this command will not >>>>> resolve it into a relative path. It will just read the value as 'raw' >>>>> from >>>>> the attribute. Do note that sometimes it adds an additional "../" in >>>>> front >>>>> of it. >>>>> >>>>> Hope this helps! >>>>> >>>>> So you should be able to just register missing types temporarily (use >>>>> the tmp flag) and remove them afterwards if you want to include >>>>> additional >>>>> nodeTypes in solely your query without messing with other settings in the >>>>> current (or next) Maya session. >>>>> >>>>> -Roy >>>>> >>>>> >>>>> >>>>> On Wednesday, August 12, 2015 at 10:07:25 AM UTC+2, Roy Nieterau wrote: >>>>>> >>>>>> For completeness sake. This is how to list unresolved filenames with >>>>>> the file command: >>>>>> >>>>>> files = cmds.file(query=True, list=True, unresolvedName=True) >>>>>> >>>>>> >>>>>> On Wednesday, August 12, 2015 at 9:12:17 AM UTC+2, Marcus Ottosson >>>>>> wrote: >>>>>>> >>>>>>> Thanks everyone for your replies! >>>>>>> >>>>>>> It certainly looks more challenging than I would have thought, the >>>>>>> cmds.file(query=True, >>>>>>> list=True) is close, and the listFiles of filePathEditor almost got >>>>>>> it, and though it looks to work with file nodes, it doesn’t seem to >>>>>>> work with reference nodes, and I wonder what else it won’t work >>>>>>> with. Alembic files probably, as you say, Roy. >>>>>>> >>>>>>> What’s more, it doesn’t look like reference nodes contain their >>>>>>> unresolved filename, maybe this is resolved by the editor itself? >>>>>>> >>>>>>> # Always returns a resolved path? >>>>>>> cmds.getAttr("ben02_RN.fileNames[0]") >>>>>>> >>>>>>> The goal of this little experiment is to be able to look at a scene >>>>>>> and determine whether there are any *absolute paths* in it. As in, >>>>>>> paths starting with either a drive letter and a colon (Windows), or a >>>>>>> forward slash (Unix). >>>>>>> >>>>>>> I’d like to look at a scene with these paths: >>>>>>> >>>>>>> $ROOT/myfile.mb >>>>>>> $OTHERROOT/myotherfile.mb >>>>>>> /server/mythirdfile.mb >>>>>>> >>>>>>> And go “aha, that’s 1 absolute path, and it belongs to node.myAttr”. >>>>>>> >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Python Programming for Autodesk Maya" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to python_inside_maya+unsubscr...@googlegroups.com >>>>> <javascript:>. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/python_inside_maya/78356830-dce9-46ce-b5f9-bda2ae2689f9%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/python_inside_maya/78356830-dce9-46ce-b5f9-bda2ae2689f9%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to python_inside_maya+unsubscr...@googlegroups.com >>> <javascript:>. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMxNTmWZO7zMw%3DBkgumcf8C5cKrJv1Vg-0Ky3VaVW2mKQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/python_inside_maya/CAD%3DwhWMxNTmWZO7zMw%3DBkgumcf8C5cKrJv1Vg-0Ky3VaVW2mKQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> *Marcus Ottosson* >> konstr...@gmail.com <javascript:> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to python_inside_maya+unsubscr...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBR%3DmaE_bcj2OLZffjfzEO-7FtUYU5VZ2%3DDAQV1SzTQGw%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBR%3DmaE_bcj2OLZffjfzEO-7FtUYU5VZ2%3DDAQV1SzTQGw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/d87a596a-532e-4dd1-ab64-826c651b4030%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
