[b-kandor]

Hi Jd,

Once I tested last night and learned that applying materials at the part level nicely propagates up to the main assembly, including with read only toolbox fasteners, I realized that I could be doing this whole project in solidworks with just the plugin. As far as I understand, the only feature I'm missing is the ability to manipulate UV's, add uv channels and apply decals. So thanks! I'm going to start over in solidworks - it's so much easier to manage. I was in the habit of using only studio since beta 0.5 but I think that habit has finally died!

[b-kandor]

One thing I've discover, if I refresh the preview of an mxm in the plugin mxed, the sphere turns pure bright yellow, even if I havn't editing the material. Strange?

[JDHill]

I've seen similar things, but just rarely and intermittently. It seems that it may have to do with having older MXS files in your Maxwell 2/preview folder. The defaultpreview scene uses an MXI, and I do know that I've seen problems rendering MXIs from older versions. Sorry I can't give you more precise info, but I have never found a consistent pattern to it.

[b-kandor]

Ok, I'll check on that.

Here is a good question(s): I would like to have the same mxm's show up in the materials window with each and every part / assembly I open as I am applying materials. If I make a library in one assembly, then open a sub assm. and import the library, then apply those materials, when I go back to the main assembly I have duplicates. Makes it untidy, and if I need to edit a material property it's confusing.

Also, I can't see a way to append to an mxl file? It overwrites.

I remember in an older plugin there was a sort of 'built in' library so that as you built it, the material remained constant.

[JDHill]

The way to accomplish this is to use the "Linked MXM" workflow, in which you link materials to MXM files and edit them using MXED, rather than with the plugin's material editor. You link to an MXM file using the "Link MXM" controls in the plugin material editor's top-level Material page, and there are some items in the Options page which govern behavior related to this workflow. The main one is Material Defaults > MXM Mode, which determines whether materials created from MXM files are initially set as being linked or not. In Options > Behavior, there are two others, Ignore Linked Mxm Mode, which would rarely be used (it prevents the plugin re-reading the current state of the MXM when opening a SW document), and Auto-update Linked Materials, which determines whether the plugin actively listens to your disk for changes being made to linked MXM files.

There is more discussion of this workflow on p. 48 of the plugin manual. What it will not do is reduce the number of materials showing up in an assembly, since materials in part files are local to those files. You are correct that it used to work differently, with a central 'database' of materials, but that went away, in favor of using the file system, and MXM files, to accomplish a similar goal. Regarding .mxl files, those are just an entirely different thing; they are meant to make it easier to grab all the materials being used in a document, and send them to somebody else, or use them again in another document; importing the same .mxl twice will result in two copies of each material it contains being added to the document.

[b-kandor]

Ok, that sounds good! I read the manual pages on it and will implement that next time. Meanwhile fyi a cosmetic thread feature applied to a cut revolve causes a 'invalid U something' failed to write MXS. I will try to recreate it in a simpler form and send to you.

[JDHill]

Probably no need, if that happens, it just means that SW wasn't able to create a valid mesh. It may help to use Document Properties > Image Quality (in the part file) to try and convince it to make something we can work with.

[b-kandor]

Ok, I wonder if its possible to have the export process skip that body rather than continue processing until the end. Reason is, with instances it take 29 min. to export. The body error occured about half way (I could see it in the log). If it was possible to skip bad bodies and just report at the end "These bodies were skipped: <name of body>" Then I could correct the geometry and fix up the existing mxs later.

[JDHill]

Unfortunately, the plugin already catches and notifies of every class of error that it understands (it has a reporting dialog similar to what you suggest, which gives a lot of details about the error, and allows you to stop the export, or continue). All I can recommend, if you are not seeing this, and if it is not possible to force SW to create a better mesh, is to hide or suppress the feature.

[hatts]

Does SW actually mesh cosmetic threads at export time? I don't think it does...
Maybe that's why the MXS exporter is getting tripped up, because it's pseudo-geometry that doesn't have usable 3D data?

Avoid cosmetic threads...just do a helical sweep cut

[JDHill]

I don't suspect that would be a factor; as far as I know, cosmetic threads (as far as being able to view them in the 3D view) are just a sort of virtual texture applied to faces in the viewport.