Hi Ken,
No worries, I want to make sure you understand what you're working with. There is still some clarification that will be helpful.
a "symbolic" link back to the material database (and thus the underlying .MXM file)
The highlighted part is the key misconception - a Material in the plugin is as different a thing from an .mxm file as it is from a .doc, .sldprt, or a .html file - the only thing they have in common is that to the user they look almost identical. Here is how a small part of an .mxm file looks in Notepad:
- ;>9ƒ‚‚}||~}‰ˆ‡~||{zz}|
{zyx€zyx|{zzyy{zyvut{yyzxwjihMLL:98767434)))
878<;</..666333888000424:9;989877767*/'-*
'.((1335 6 8
5697 :=:
Here is how a small part of a plugin Material looks:
- <?xml version='1.0' encoding='utf-8' standalone='yes'?>
<material>
<type>Maxwell.Materials.Material</type>
<name>AE_Red</name>
<id>9790a82a-f0af-4914-9dd9-3d90ca87c75c</id>
<mxmpath>C:\Program Files\Next Limit\Maxwell\materials database\mxm files\AE_Red.mxm</mxmpath>
<matte>False</matte>
<matteshadow>False</matteshadow>
<maxpreviewsl>8</maxpreviewsl>
<previewscene>defaultpreview</previewscene>
You can clearly see the difference - the key to how the plugin works is there in that fragment; do you see the
<id> field? This is how a plugin Material is identified - not by a file path, or a certain name, but by this ID. When the plugin is started, the db mananger tree is filled with node information read from a file - each node has an ID attached to it - the ID of a Material which was created at one time or another. When you click the node, a file is read from somewhere in your user-profile folders - that file is named by this ID. When it is read, an in-memory version of the Material is created and stored for use during the session - this may be thought of as 'resurrecting' the Material from its on-disk representation into something which you may now edit, before it is once again flushed onto the disk - when documents are saved, or when the plugin is shut down. This is how the db manager can load thousands of Materials in a fraction of a second - in fact only one file is read at startup; the one necessary to reconstruct the tree-structure. No actual Materials are read until requested - where requested means either when you click the node, or when an ID is found on a SolidWorks entity during object-selection or MXS export.
a change made to the material via MXED will be reflected the next time that...the SW file is opened... regardless of the Embedded/Referenced setting.
This would be a correct statement if the highlighted portion were changed to read
'if it uses the Referenced setting'. This is the only purpose of Referenced MXM Mode - to automatically re-load the source .mxm file when the Material is loaded, rather than just using the stored text-data. Highly unnecessary in the SolidWorks plugin, as Materials are only read from storage once during a session - using Referenced mode here is equivalent to running down the Material list after startup and giving the 'Reload Source MXM' command for a bunch of the Materials.
when using the Plugin's Material Editor, any changes made to the material will be permanent only if the Material is "Embedded"; if the material is 'Referenced", the change will be lost upon the next reload of the source.
Correct in effect, yet I think there may still be a subtle misconception: changes made using the Material Editor are always permanent - they just don't seem to be that way when a Material is immediately overwritten due to the use of Referenced MXM Mode. In fact, you will notice that Referenced mode is only available when a Material has been created by mxm-import - if it is created from scratch in the plugin, the
<mxmpath> element will not appear in the Material data.
It was not defined as to what happens, if the person receiving the SW file also has a material named the same in the path structure.
It would have to be the case that the receiving person had a Material in the database with the same ID, and this is (statistically) impossible, unless they had gotten it from someone else, namely the person who sent them the file in question. If they did have a matching Material, the one found in their database would be used. If you think this may be problematic down the road, I can add a 'last-written' date/time element to plugin Materials for handling this case - to make sure that the Material used is always actually the 'newest' one.
how can Maxwell effectively store a material that uses these texture maps in 25K? What is the point of having a HiRes map if it is completely compressed or scaled down in some way?
Nothing is scaled down at at all - in the same way as it done in .mxm files, textures are always stored as simple file paths. The actual bitmap, which may be tens of megabytes in size is not stored. That's the case for the plugin, MXED, MXST, etc. - MXS files always only contain paths to the texture maps used in them. The strange apparent practice of SolidWorks - storing an entire bitmap inside the file - I've never seen or heard of this being done in any other context, and imho, it is complete nonsense. Personally, I would consider this to be a huge bug, though it is obviously by design.
Actually, this gives me an idea. The plugin does open the textures referenced by Materials, for the purpose of creating the various thumbnails and the scaled-down preview image shown in the texture editor. It caches these versions, to avoid hitting the hard disk more often than necessary. It may be possible for me to push the reduced-size version of your hi-res maps onto the disk and point SW at these, rather than at the originals...so when it stores the bitmap data, it will be a small lower-quality file it's reading. I already do this for MXI textures and for any RGB-inverted versions, otherwise it would be impossible for SW to show them to you in the viewport.
Sorry for being so long winded
No problem - I'm afraid you've got nothing on me in that department.
JD