[purCAB]

There is some sensitivity in SW 2008 (SP1) when applying Maxwell Materials that causes SW to crash. I have tested this on two different XP32 machines both running SW2007 (SP5) and SW2008 (SP1) with the 1.6.0 plugin and can report that these actions seem to be causing somewhat frequent, albeit not every time, crashes of SW2008. SW2007 does not seem to exhibit this sensitivity.

In both versions of SW however, I seem to be having difficulty in getting the materials to apply/display in any consistent manner. This is regardless the Enable/Disable Viewport Material setting; nor do other settings, (e.g. RealView, MultiMaterial) seem to have any effect.

Finally, I have one other materials related problem. I have been using the Arroway Concrete Textures and found that an SW part (just a simple single part) had grown from around 1 MB to approximately 70 MB in size after this material was applied. I tried changing the Material Editor's MXM Mode from Embedded to Referenced, but this did not change the file size. Finally, and certainly worst of all, all attempts to recover the file size by removing all materials have failed.

Any help and/or insight would be most appreciated.

Ken

[JDHill]

Hi Ken,

1. I haven't observed this, so I will need a more detailed set of circumstances to diagnose it. I realize you say it does not happen every time, and so this may be difficult to do, but I'll need something - i.e. using drag/drop assignment vs. right-click > Assign to Selected, etc. - details of this nature.

2. similar to #1, I need to know how it is or is not working for you. There are several things to consider - say you are in an assembly, if you apply material to a body, but there is some other SW appearance applied to the parent component, this will hide the appearance created at the body-level by the plugin. Etc...

3. the plugin does not ever store anything of that size anywhere. If you use different textures in the same material, does it have the same effect? I'm saying, does SolidWorks seem to have a problem with Arroway textures in particular (I haven't noticed any)? Also, you say it is a simple single part. How exactly did you apply the material? To the part-body, or to each of its faces? It's difficult to theorize without more detailed information.

JD

[JDHill]

Ok...regarding #3, it is apparently due to the size/format of the Arroway textures in conjunction with whatever SW is doing with them internally.

For example, if you:

1. create a simple filleted cube
2. save as Part1.sldprt
3. file-size = 149K
4. use SW to apply a texture (e.g. Cobble Stone 1 - 600x600 JPG)
5. save again
6. file size = 410K
7. apply a Maxwell material which uses the same texture as in step 4
8. save again
9. file size = 424K
10. replace the texture with Arroway concrete+01_b010.jpg (1024x1024)
11. save again
12. file size approx 1397k
13. replace with Arroway bricks+20_s025+g050.jpg (2048x1024)
14. save again
15. file-size = 2037K
16. remove Maxwell material
17. save again
19. file size = 1768K
20. re-apply the SW texure as in step 4
21. save again
22. file size = 1787K
23. re-apply the Maxwell material that produced the 2037K file
24. save again
25. file size = 1788K

So, you're not imagining this. Furthermore, while testing, I find the numbers are pretty inconsistent - one time saving with a SW texture might add 2K, while another, it adds 200K. But at any rate, it's apparently something SW is doing internally caching texture data. It's not the plugin, which only stores one small little string (i.e. an ID like: '41bbac5f-98ea-41ea-b8fb-d975fee6c994') on the object's data. I don't see any way I can prevent this, besides telling you to just turn off viewport materials.

JD

[purCAB]

JD, thanks for the help.

I could (almost) live with a 2 MB file or some of the "variablity" that we're seeing, but I'm winding up with a 67 MB file. This makes it impossible to keep rendering resolution textures in SolidWorks. Consider the following sequence using SW2007, Maxwell 1.6.0, and the Arroway full resolution Concrete 19 material.

1) Create a cube in SW (in my case 6x6x2)
2) Save the file. File size is 276K
3) Add the Arroway Concrete-19 material by browsing with MXM.
4) Select the solid body and copy Concrete-19 to the highlighted body.
5) Viewport Material is disabled.
6) Save again. (Size is now 295K) So far so good.
7) Now enable Viewport Material.
8) Nothing happens. Need to explicitly path the texture even though Material Editor reports no path problems, etc.
9) Add path to my "special" materials (i.e. those materials not coming as standard) to "Textures Folder(1)"
10) Reapply material (with Viewport enabled...simply enabling/disabling the Viewport Material has no effect)
11) Save file. Part is now 67.6 MB.
12) Remove the material. Part in viewport returns to previous (SW default) view.
13) Save the file. Part is now 67.5 MB
14) Disable the Viewport Material and resave. No change in file size.

At this point I have a part file that can not (apparently) be resized back down. While your point about this being an SW problem is well taken, the Maxwell plugin is responsible for removing the material (at least from a UI perspective). Certainly more investigation needs to be done to narrow the scope of the problem. It is not easy to tell what material has been applied without some sort of telltale.

Thanks,

Ken

P.S. I will attempt to clarify other issues

[JDHill]

Hi Ken,

One key that will help you understand what is/is not working is this: Enable Viewport Materials is not retroactive. This should be enabled at the time you apply a Material - I don't want to recurse over the entire document and synchronize every object/Material when you enable this, it's much too expensive. That aside, if I

- create the cube
- save: 113K
- apply Arroway concrete-19.mxm
- save: 531K
- apply Arroway concrete-09.mxm
- save: 475K
- remove Material
- save: 474K
- apply Arroway stones-sandstone-02.mxm
- save: 800K
- apply Arroway tiles-17.mxm
- save: 636K
- remove Material
- save: 846K
- apply Arroway misc-cardboard-edge-01.mxm
- save: 311K
- remove Material
- save: 310K

In short, I find no consistency with what is applied vs. saved .sldprt size. However, I have absolutely no idea where you're getting this huge multi-MB file-size from. Rest assured, the plugin does everything possible to remove a Material when you ask it to - really, things work differently in different versions of SW, and if one method fails, the next is tried, and so on. If you find a failure to remove a Material, know that it was just not possible to do so. However, in your example it is working - if it wasn't, step 12 would not have the result of showing the default SW material.

Here's how it works with viewport Materials: the plugin is not able to do anything that you are not able to do yourself, through the standard SW UI. So, if you are somehow ending up with a 67MB file, you should be able to produce the same thing using a native SW shader. Unlike PhotoWorks, I have no 'special' access to your model.

It's a shot in the dark, but I'd have to say you need to start looking into your hardware-compatiblity situation or something, what you're describing makes absolutely no sense.

JD

[purCAB]

JD, I've been able to get a better, although not complete, understanding of the file size issue. In general, here is what I think may be going on. When I add the high-res Arroway materials, the underlying maps are 20 to 68 MB in size. So that when an SW file is saved with a texture applied then this mapping has to go with it, so therefore the huge file size. Now let's remove the texture. The file size remains the same. But if instead of Saving, we do a Save As, then SW recaptures most of this space and everything is returned to normal. So the first workaround (which is clearly a SolidWorks issue) is to do a Save As instead of a Save, which will recapture this (along with other) unused and/or not needed caches.

Unfortunately, this workaround does not always appear to work. I have a file that always seems to return to its "heavy" state. I removed all of the materials and did a Save As and the file was down to 1 MB. As this file has two configurations, I switched to the parent configuration and REMOVED a standard SW (i.e. non-high res) texture that was stored at the part level. Then I saved the part and it's back to 68 MB. I cannot get this part "lean" again.

After a bit of investigation, I believe that this problem is associated with some texture or material being applied as a Real View texture or Real View Material on a machine that does not support Real View. Under SW2007 all Real View functions are blocked, so I didn't see this. But under 2008, while you cannot edit them, you can see them. So this part appears to have a Real View material set with no way (that I know of) to remove it. Removing the standard texture seems to then "expose" the Real View one, which must be a high-res map. How does Maxwell handle Real View and are there any settings related to this?

Sorry that this has taken so long to narrow down...assuming that I'm even on the right track.

Ken

[JDHill]

Well, I'm also on 2008, so at least we can work in parallel. At tens of MB per, I guess you have different Arroway maps than I do - I just have the ones I got with Maxwell. So at least that begins to make a little sense. Now let's remove some variables:

1. open SW
2. Add-Ins Manager, un-check the 'Start-up' checkbox for the plugin
3. close, restart SW

So now we're definetely just working with SW, not the plugin.

4. create a cube
5. 'Save As': the file is 94K here
6. go to Options > System Options > File Locations
7. add the Maxwell materials database\textures\Arroway folder
8. from the appearance callout for the cube, edit the Body texture
9. in 'Texture Selection', choose the Arroway folder from the drop-down
10. choose 'concrete-22_b005' (in my collection, this is a 403K 2048x1024 map); click the OK check-icon
11. 'Save': the file is now 527K. Apparently, SW has saved the entire map inside the SLDPRT
12. 'Save As' another name: the new file is 479K. I'm going to say the JPG is still in there
13. from the appearance callout, edit the Body texture again
14. click 'Remove Textures', we're back to default appearance
15. 'Save': the file is now 493K. Actually bigger now that I removed the texture
16. 'Save As' the first filename: this file is 72K, apparently the JPG is not riding around anymore

So, this (appearance callout > color & texture) is exactly the same set of functions I'm using inside the plugin to generate viewport appearance. The plugin is written for SW2007 SP3.1, and therefore accesses no RealView stuff. I don't know what more I can do for you except discourage you from trying to visualize Materials in the viewport when you're working with these immense maps.