[JDHill]

Good deal. Just a couple more notes:

By the way, clicking on the texture icons in MXED do not resolve the issue.

This shows one of the differences in workflow between MXED and the plugin's Material Editor. The selected (or 'viewport') texture in MXED/MXST is not chosen in the same way as with the plugin's Material Editor; rather, there is a small button with an 'eye' icon just next to the 'refresh preview' button. This drops down with a list of textures and choosing one sets it as the selected texture. I felt this workflow could be improved, and so I made it work as you see in the plugin's Material Editor, i.e. selecting by a quick left-click. In MXED/MXST, left-clicking on texture buttons in MXED opens a dialog - this is not the case in the plugin. Rather, right-clicking a texture-button opens a built-in texture editor:





It's not perfectly clear just from the screengrab, but that's a right-click on the texture button just before the editor slides out.

adding a sizing adjustment would better allow one to go directly to render without running through Studio under more circumstances than can be dealt with by rotation alone.

Adjusting the texture's Tile X/Y may be done as shown. Note, since SW has no concept of separate X and Y tiling, the SW plugin ties them together. SW also has no analogue for Maxwell's texture-offset parameter, so Offset X/Y are not able to be visualized in the viewport.

Instead of a simple No for Has Bad Paths, consider Inactive, or Not Activated, etc.

You may be misunderstanding the purpose of this particular feature: this tells you if there are any paths (texture, .ior, .r2), anywhere in the material, which are not valid. When there are, it becomes a hyperlink which will open a dialog showing a report of what is missing from where.

Why is it necessary to select the path in this manner at all? Under what circumstances would you not want the texture to be activated? Consider having the plugin "auto-select" the texture and all of this is avoided;

That would be fine if we're talking about basically opaque woodgrain-type textures, but many times you may be working only with weight maps and still want to be able to edit the underlying appearance of the material. If it was not possible to have a 'null' texture become selected, you would have to either remove, or disable all textures before you could see this.

[purCAB]

JD, talk about really missing the boat. I definitely missed most of what's been going on, the concept is more powerful (and more subtle) than it looks at first (or second) glance.

For those like me who missed the subtleties, let me recap.
1) The Material Catalog is a separate db of materials usually derived from the MXM material files, and are maintained independently from their originating mxm. Updating the .mxm will NOT affect the material in the Catalog; 2) Each entry in the Catalog can have a set of "custom" settings (e.g. bump strength, scale, RealScale, rotation angle, image control, etc.); 3) Most importantly (IMO), there can be multiple entries of the "same" material. One can create and save multiple versions of the same material, each "the same but different". 4) For each material in the Catalog, a texture (usually the main reflectance texture) must be selected so that it can be "activated" for use by both SW and Maxwell. Strictly speaking Maxwell would see the texture correctly without this selection process, but in that case there is no "feedback" in terms of the SW model. A texture is "selected" by opening the Material Editor (not MXED) for that material and clicking on the appropriate texture.

I think that the two examples that you created here were very helpful and you should consider their inclusion in the plugin manual.

Thanks very much for the help.

Ken

[JDHill]

I'm glad this helped to straighten things out. In reference to your supplemental points...

1) correct, there is no inherent link between the plugin Material and the MXM it was created from (if there is one). A plugin Material does remember which MXM it was created from though, and you can re-import whatever state that MXM may currently have by using the 'Reload Source MXM' item from the Material Editor's Options menu. Conversely, you can push the current state of the plugin Material back out to the MXM it was derived from using the 'Update Source MXM' command if you have a need to do that.

2) the database window simply presents a heirarchical view on a directory full of plugin Materials (and BSDFs, Emitters, etc.) which you have created at one time or another. Rather than using an explicit path as is done with MXM files and the Maxwell/materials database folder, the actual location of this collection of files is created by the plugin at runtime, and is therefore a well-known location regardless of how the environment the plugin finds itself in is configured - also, this location is in a place where the logged-on user is guaranteed to have storage permissions. The way the files it contains are named is extremely un-readable, but it allows the plugin to guarantee that a certain Material used in one place is really the 'same' one as may have been used elsewhere.

A small point, in reference to texure rotation: the rotation parameter is always per-object, with the reason being that a Maxwell material has no rotation parameter. A texture's Tile/Offset parameters are per-material for the equal, but opposite reason. One of the effects of this is that it takes much longer (in processor time) to adjust a texture's Tile/Offset than it does to adjust rotation: when we adjust rotation, the target entity is already known and it is acted on directly; when we adjust Tile/Offset, the plugin must traverse the model, updating the SW texture-size for each entity which uses the texture's material.

3) yes - as mentioned in the previous point, the actual files these items are stored in are named using unique identifiers, rather than human-readable names. This allows you to have any number of Materials which may physically appear to be the same, but which maintain unique identities. This is a side-effect though; the driving force behind this design is that the plugin needs a reliable way to know the difference between two Materials used in multiple SW documents so that it can duplicate the inherently by-reference behavior of SW assemblies. That is, if all materials were stored locally to the document, there would be no way to know in the context of a .sldprt whether you had modified the material from some .sldasm. On the other hand, if the plugin just used external .mxm links, there would be no material definitions stored directly insid of SW documents - the automatic database paradigm addresses both of these issues at the same time.

4. yes, that's basically it. 'Selected' texture only has meaning in the SW and MXST viewports - it is purely an editing feature. The plugin exposes the choosing mechanism in the way it does to make switching between textures (or no texture) more convenient. If you notice in the more recent versions of MXST, that application has adopted the modeless texture-editor which has been in this plugin since the beginning. Rather than a 'click button > show dialog > edit texure > click ok/cancel' modal cycle, you just click on the desired texture and it's made available for editing without blocking the rest of the application.

I'll try to incorporate some of this conversation into the next version of the plugin manual. In that regard, I want to thank you for asking questions - naturally, I'm highly-aware of how all of this stuff works and it is oftentimes more difficult to think of the ways that people might miss some of it than it was to create it in the first place.

Cheers,

JD