[mtripoli]

Once materials (MXM) are applied to an object are they attached (or embedded) to the actual object file such that if you open the part and go to object properties and select a feature (body, etc.) you can open that material in MXED?

This could be useful if you send someone a SLDPRT (and they have Maxwell) they can render the same part? Would this speed up rendering if Maxwell doesn't have to go "looking" for all the materials? Am I talking out my rear end (butt, arse)?

[JDHill]

Yes and no - technically, the only time the plugin deals with an MXM (an actual .mxm file) is when you import one from the file system, usually using the MXM Browser. After import, the Material is no longer an MXM, but a plugin 'Material' - it has all the same properties (and a few more) as an MXM, but it is not a binary file, and it may be stored directly in a document. If you open a .sldprt on another machine, you should find the Materials contained in it are immediately added to the database on that machine - no MXM files are necessary.

As far as speed, the time spent locating the actual materials is negligible - far greater time may be spent searching through every face/feature of a body to find whether or not it uses a material different than that of the body. That's why it is important to only set the 'enable multi-material' flag for SW bodies when necessary - if not enabled, then this per-face/feature check can be skipped entirely.

[mtripoli]

Thanks for the explanation!

[mtripoli]

If the material gets stored directly, what happens when you update the material? If I make changes to the original MXM file do they propagate to the part? It appears that I have to manually update the part. Is this the case?

[JDHill]

The key is in understanding the difference between using an MXM file, and using a plugin Material - they purposefully look very much the same, but underneath, they really aren't the same thing at all. Plugin Materials may be created from MXMs, or they may be saved out to MXMs, but they're completely independent things. Because of this, plugin Materials have two modes: Embedded and Referenced. What that means is this:

• Embedded: the default - once the Material is created from an MXM, any changes to either the Material or to the source MXM are completely independent
  
  Referenced: really, the same as Embedded, except that the Material will re-read itself from its source MXM, if that file still exists. This is a one-way process, and it happens when the Material is first referenced (loaded) during a session. Mechanically, it is the same as giving the 'Reload Source MXM' command from the Material Editor's Options menu

Editing a Material in the plugin never modifies the MXM file it may have been sourced from (of course there isn't one for a Material you've created from scratch inside the plugin). You can change the MXM Mode for a Material in the Material Editor's main Material page, and there is a global override in Plugin Options (Ignore Referenced MXM Mode) which can be used to temporarily disable the function on a global basis. This stuff is really more of a hold-over from the Rhino plugin, where there is no global 'Material Database', so it may seem a little strange to use. What I mean is, if (as in Rhino) there's no database, then the time where a Material might be re-loaded is clear, i.e. when you open a document. But in SW, this time corresponds either to when you first load a Material by clicking on its node in the Database Manager, or when you render - the Material must be 're-hydrated' from the database during export.

The idea of using a fully-abstracted database for materials was created specifically for the SW plugin, since the concept of referenced documents is so central to the application - it turned out to be almost impossible to keep materials synchronized from a .sldprt to a .sldasm if a unique copy was stored in both (or maybe only in the .sldasm). So I felt it best to create this database, where no matter what level of document-nesting was encountered, there would only be one authoritative place to get a Material that was referenced in the document (this is also a very SW-style way of working with materiasl). It would work similarly if one just used file-based references, as was done in the previous plugin, but I wanted to do this a way where no matter what machine a document might be opened, there would be one central place that Materials could be expected to be found. The [Program Files]\Next Limit\Maxwell\materials database is not such a suitable place to do this - depending on the OS and how you're logged in, the plugin might not even have permission to write data there. Furthermore, though the database is currently a file-based system (by default, these files are stored somewhere under your user-account) abstracting this fact keeps the future open to any other way of handling stored materials.

In reference to your last question, if you choose to change an MXM (an .mxm file), and you wish those changes to take effect in places where a Material derived from that MXM are already assigned, you would want to open the Material in the plugin's Material Editor, and choose 'Reload Source MXM' from the Options menu - this will overwrite the Material with whatever is currently contained in that MXM file. Note that the 'Reload Source MXM' option will only be available if the source MXM still exists. I think this would rarely be used though, when you can just edit the Material directly and leave the MXM alone - that's generally what people have been asking for all along, to be able to have materials saved and edited directly in plugins and not have to use an external program like MXED.

I hope this helps, and I hope you skipped anything you don't find useful...if I get long-winded, it's because over time I intend to gather this stuff up into the plugin help - it's much easier for me to go into detail based on some actual question than it is to sit here trying to figure out what parts of the plugin need an explanation.

Cheers,

JD

[purCAB]

One caution I would raise regarding the use of embedded materials: When you have a material with large texture maps (e.g the full resolution Arroway files), the size of the SolidWorks part/assm file can very get quickly out of hand. I have had single part files in excess of 70 MB.

Regardless of the material file's size, I would advocate exclusively using materials by reference, unless one needs to share the SolidWorks file with another location. In addition to minimizing the SW file size, this ensures that parts that utilize the same material will remain in synch, etc.

Ken

[JDHill]

Hi Ken,

Actually, if you recall, this assessment is not correct: we positively established that the large file size you experienced is not related to the use of Maxwell Materials at all - the problem will be the exactly the same if you assign those maps through the regular SW texture interface. The fact that SW is (somewhat randomly) storing entire bitmaps inside the file is something that the plugin is neither requesting, nor causing. I really do not understand how SW is handling bitmaps at all - the plugin loads the same files in a fraction of the time it takes SW to load them, even with this strange cache mechanism they seem to be using.

In fact, a Maxwell Material in the plugin generally requires only about 25k of plain text to store, and the largest part of that is the preview image bitmap. This data will be stored in the SW file regardless if you have it set as Embedded or Referenced - it's just that if it is Referenced, it will re-load itself from the source .mxm file each time it's used in a session, as I described in the previous post. In all cases, at export-time a Material is retreived from the database, so synchronization between documents is assured.

JD

[mtripoli]

If I follow correctly I agree with Ken; I tend to change or make updates to materials. I'm going to use "referenced" from now on. Given that I don't share parts for rendering I think this will work out better for me.

[JDHill]

From the comments, I can see that I'm not explaining this well enough. I'll try to emphasize the important key points.

Referenced MXM Mode is really only valuable in the Rhino plugin, where separate and discrete copies of each Material are contained in each individual document. In the SW plugin, all usage of Materials comes from the Database - all usage is by definition of a reference type - it is just not referenced to to any .mxm file on the file system. Using Referenced mode in the SW plugin only guarantees that you will need to use MXED to edit your materials, and therefore to use the 'Reload Source MXM' command alot. Furthermore, any edits you make using the plugin's Material Editor will be overwritten with whatever is in the source .mxm file every time you start up SW.

To put this as simply as I can, regardless if a Material in the SW plugin is using Referenced or Embedded mode:

a) if you assign it in a .sldprt, you will get the same Material later when you use that .sldprt in a .sldasm
b) if you change it in the database (i.e. double click its node, edit in the Material Editor) that change will apply in every place where this Material is used

It had not occured to me to do so, but I probably should have just removed this choice from the SW plugin's UI because it has no real value in this context. In Rhino where copies are embedded in each document, it has value - users can edit things in MXED, and by using this mode, they can have the changes automatically take effect the next time they open a document. This is completely unnecessary here due to the database paradigm.

It has nothing to do with sharing documents or whether or not copies of these Materials are stored there - they always are. But...the stored copies are immediately thrown away if existing versions of them are already found in the database. The stored copies are used as a) backups, and b) for implementing document portability.

[purCAB]

JD, I had assumed that Embedded meant kept with the SW file and Referenced meant that there was some sort of symbolic link made to the material. Thank you for the clarification. To make sure that I understand the nuance here, let me restate this:

In SolidWorks, a material is always, in effect, a "symbolic" link back to the material database (and thus the underlying .MXM file) regardless of the Embedded/Referenced setting. As such, a change made to the material via MXED will be reflected the next time that either the SW file is opened or Reload Source MXM is executed, again regardless of the Embedded/Referenced setting. Additionally, 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. Finally, in all cases a copy of the material is stored in the SW file so that if the file is sent to someone without that material, those material(s) will be available. 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.

You are correct that the file size problem that I raised earlier is with the application of textures (and is not a plugin issue) and once a texture is applied, the SW file size doesn't seem to go back down even if you remove the texture.

One final question then, the HiRes Arroway textures are multiple megabytes in size, 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?

Sorry for being so long winded, but I really had this upside down and wanted to make sure that I understood that now I really don't have to worry about any of this because the materials are all referenced anyway.

Ken

[JDHill]

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