materials library error

Started by cognition, February 04, 2011, 07:23:09 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


  I spent an entire day applying textures and materials to a rendering file.  Each part took at least 5-10 solid minutes of solid thinking per material - even hiding parts took this long.  I've got the real time render settings as low as they'll go with a window barely large enough to see the working part.  The BIP file is 241 MB, which seems huge to me.  After getting all the parts painted, I showed all parts, only to find that half of the materials had gone black.  Refreshing the materials library only turns all the spheres in the library black.  The library refreshes fine if this BIP file is not open.  The CPU should not be to blame on this, since I'm running Windows 7, 64 bit with an Intel Core2 Quad @ 2.66ghz with 8GBs of RAM.
  1) How do i get these materials to show back up?
  2) How can i minimize file size / improve performance so that the program is actually usable?


When you imported the file, did you have the "keep individual parts" option enabled?

That setting, applied to the wrong file types will give you thousands too many parts which can really affect performance and cause issues.

We have addressed this in 2.2 which is available as a beta now in the members only section, and the full release is expected version soon.


I did have the individual parts option on.  I also noticed that I ended up with 3 sets of parts after importing native SolidWorks files.  I've deleted those since, but performance has not significantly improved.  I discovered that I had inadvertently put the ray bounces at zero, and that was the cause of the blacked out materials.  However, that certainly doesn't help the lag time associated with painting this part. 


As a test, can you import, into a new scene, the solidworks files and turn off the "keep individual parts".

How is the performance then?


I went back into SolidWorks to clean up a lot of unnecessary detail that wasn't critical, and that helped cut the file size down to almost a third of its original.  Should have been working from a rendering model instead of the development model the whole time.