Has anyone used this?
I’m thinking I can use it instead of summaryinfo or fileproperties but I can’t figure out what the hell the docs are going on about, it’s very verbose and unclear.
I want to add some strings as custom assets, much in the way summaryinfo works. My reason? I want to access information without opening a maxfile. I know you can do this with dotnet by using structured storage but was looking if there was another way.
Edit: just noted that you talked explicitely about the asset meta data, so my post below somehow misses the point completely
Why not dotnet? In mxs you got fileproperties #custom, but that requires opening the file
You could use one of the existing structured storage managing assemblies, which work quite good
Eg. McLellans library is great and works via mxs and does’nt depend on max, so you can base max independent tools on it
http://calummclellan.com/code.aspx
Yeah… I have asked custom string asset data stream to dev.
You should joint the force.
Regarding the getMAXFileAssetMetadata/setMAXFileAssetMetadata/AssetMetadata_StructDef
Whats unclear about them ? Besides that you are limited to inside 3ds Max they work as you’d expect.
Here’s a detailed investigation of that topic
http://blog.duber.cz/3ds-max/repathing-your-assets-in-max-files-without-3ds-max
I used the MXS AssetMetadata access for a MXS project to manage assets of 3ds Maxfiles without opening them. Until i decided that i want a tool which can do this without 3ds Max. So i started to code my own assembly for full Max structured storage access without 3ds Max. That’s the project i’m currently working on …
This is the dialog for the MXS based approach
Also worth mentioning that the source for the MaxFind utility which does access 3dsmax metadata is available in the SDK samples.
Maxfind does not support the Asset meta datastream (FileAssetMetaData3 ,only the OLE based structured storage via SummaryInformationStorage or DocsummaryinformationStorage and user properties storage). The Asset meta datastream is still an additional undocumented binary data stream, which you only can decipher using 3ds Max tools ( or hack something together, the chunks do’not look too complicated )
A great tool to decipher the structured storage of max files / and others ) is Mitec’s Structured Storage Viewer http://www.mitec.cz/ssv.html
BTW: here’s a Testapp ( C# ) which uses the MaxFileInfo assembly i currently develop
Works completly 3ds Max independent and will be used to develop Shell Extensions for 3ds Max files which support advanced Tooltips, Property page, thumbnail, Preview and Windows search integration ( to search/index Max file’s internal scene properties via Windows search )
I think you can only set file path for MXS AssetMetadata.
Can u set any string like xml?
Hi chaps,
I’m well up with the COM and OLE methods, and have been using them for years. And thanks to Denis I’ve been happily using the structured storage via dotnet (something I’d previously used dsofile.dll and and interop class for)
It was more that I was flagging something that I feel is poorly documented, that would potentially be useful if you could customise the scene metadata in a way like Changsoo mentioned. I know the ways we do this now, but its clear that although thought has gone into this system and it could be made into something really useful. We dont always need to be outside max, but we don’t want to open files the whole time!
Customizing assetmetdata, is possible outside max, but you can’t add custom metadata :(. I did wrote a tool for my company to do asset repath without opening max at all, using the OpenMcdf for getting the data from the OLE container. Its pretty useful, since i can repath entire projects without the need to open max, all in one go.
Why is’nt it possible to add to the asset stream using OpenMcdf ? As i understand OpenMcdf is more lowlevel and capable than McLellan’s structured storage assembly, but lacks the property handling functionality which make the latter so easy to work with . Is the problem the unknown/undocumented asset stream’s chunk format and you are only able to hack/change existing strings in there ?
@LoneRobot:
Was’nt aware that one can’t add new AssetMetadata_StructDef’S to the assetstream via the built in MXS command ( setMAXFileAssetMetadata ) . Docs says the following and testing it clearly shows that you can’t generate new entries/assetid’s, you can’t even change the type of existing entries, only change the paths . This sucks for certain…
setMAXFileAssetMetadata <filename> <array of AssetMetadata_StructDef instances>
Updates the asset metadata defined in the specified.MAXfile.
If the asset ID for an existing asset is not found in the AssetMetadata_StructDef struct instances, the asset is unchanged.
If an asset ID match is found, the asset types must be the same, otherwise a runtime error will be generated.
It should be possible, with openMcdf, it was a bit of hack’n slash to get the right streams (look for CFItem name either FileAssetMetaData2 or FileAssetMetaData3, using the VisitEntries on the CompoundFile.RootStorage), but after that, you can write whatever you want to the CFStream, of course it must be valid FileAssetStreamData. The only rule is to keep the Guid’s for the existing ones, so you don’t mess up the assets.
BTW: the source for setMAXFileAssetMetadata() and getMAXFileAssetMetadata() is in the SDK code of mxsagni.dlx (avg_dlx.cpp ). Checking those two functions you will recognize that they directly read/write from/to the binary datastream storage and doing the validity checks in there too.
So it would be not too much of an effort to remove those asset validity checks and implement an extended setMAXFileAssetMetadataEx() which simply writes into the FileAssetMetaData2/FileAssetMetaData3 streams without those checks (allowing for type changes and adding of entries).
When i tested this with a manually hacked FileAssetMetaData3 stream with manually added entries, this all seemed to work. Of course it might be dangerous to miss-use that stream to transport own arbitrary data like strings etc… with the max file. One never knows what things might be implemented in the future, which might later on lead to crashes on load or at least stripping/overriding of that data in future max versions…
As long the existing GUID’s are left untouched, I don’t think adding custom elements to the stream with freshly generated GUID’s messes up anything on the existing assets. GUID’s are by definition globally unique, so i can’t see adding them interfering with existing assets. It’s more a problem of what to do with those custom entries, as Max itself does nothing with them. But one can manipulate them with get/getMAXFileAssetMetadata() once the entries exist. This i tested and the changes persist, once such a custom entry is in the stream. Hence my idea to base an extended set/getMAXFileAssetMetadataEx() function on the code in the SDK samples.
Of course nobody can say what changes in the future ( stricter Assetstream validation etc… ) could lead the added entries to be stripped or Max getting confused. Technically it would be possible to transport some custom filepath data via such custom assetstream entry ATM…