-
Organizing Emitter libraries
Hello,
I had one of or Production Assistants organize all the libraries that we have to make it easier to find an emitter we want based on what type it was (fire, debris, magic, etc.)
What he did was made one library that had folders that housed the different types. This made the library file size over 100 megs and it looked like it dragged down PI’s performance. So what I did was have him separate out each of the folders into it’s own library. And breaking down that library into smaller libraries so there would only be about 10 to a library. So we would have a Fire01 library, Fire02 library etc.
But we’re seeing that the size of the library hasn’t really changed much since we made the first master library that housed ALL the emitters.
Are we organizing this in the wrong way?
We love that we get free emitters each month but they’re so varied in what they are that just by going by month and year makes it hard to track down a specific one.
Ernest
-
8 Replies
-
As you’ve seen, one huge library will kill your performance, so breaking it into smaller libs is important.
You need to go into each library and delete the unused particle shape images in each one to reduce the filesize.
Also, you’re aware of particleView’s search function, right?
Alan.
-
I just looked into the search function. That is pretty cool.
We’ll work on cleaning up our libraries.
Thx!
-
Maybe in the next major release, “importing” new emitters into a master library sorted by category would be possible and not a performance burden.
I find it a lot easier to resort the libraries into the same type of categories as well.
-
So clearing out the unused image maps is working.
It would be nice if there was a “Clear all unused” button.
Our work around cheat is to make a new folder and then drag the unused ones into that folder and then delete that folder. It’s nice that before it deletes the folder it’ll give you a warning dialog that says if they’re being used in an emitter.
E
-
In the process of clearing out the unused images I’m finding that the emitter library will sometimes get corrupted. Which is frustrating because there are a lot of images to clear out making us have to start over.
What I’m doing is making a folder called used and unused. I put the used images into the used folder and the unused ones into the unused ones. Then after awhile I delete the unused folder, wait for PI to rewrite the emitter library, close PI and relaunch it. If it relaunches then great. When it doesn’t I get the “Realtime runtime C++ error”.
I’ve modified the work flow so that every time I leave off with a good library that reopens I copy it. So if it get corrupted when I save out the updated one I just delete the corrupted one and restore the most recent copy.
What would cause PI to corrupt a library? I have a window up with the libraries so I’m watching the file size changes as it writes to it so it’s not like I’m closing PI too early.
-
I suggest moving the images to the “unused” folder, closing the props dialog, loading a different library (or closing pIllusion), then loading the lib you’re modifying again and then deleting the “unused” folder. Don’t move the images and delete the folder all at one time.
This is an issue that I’ve never been able to duplicate when testing, although I know it’s happened to me before.
Alan.
-
I just tried your steps and the library still got corrupted.
-Open Properties dialog
-Moved some images to an unused folder. A used folder already existed with some images in there.
-Closed Properties dialog
-Switched to one of the ProEmitters, dragged it around, played with it, etc.
-Closed out of PI
-Relaunched PI
-Swithed to the library I’m trying to clean up (it opened properly)
-Deleted the unused folder
-Closed Properties dialog
-Switched to one of the ProEmitters, dragged it around, played with it, etc.
-Closed out of PI
-Relaunched PI
-Switched to the library I’m tring to clean up and now it says “Unexpected argument” and wants to crash
-Force quit PI
-Relaunch PI
-It tries to open the library that’s corrupt and gives me the C++ error -
Ok, please email me directly at support at wondertouch dotcom.
Sounds like I may finally be able to track this bug down!
Alan.
Reply to this Discussion! Login or Sign Up