-
New versions of PI: Alan ?
Hello,
Here’s my 2 cents worth of what I would think to be fantastic in future versions.
1. The ability to import 3d objects such as 3ds, obj, lwo etc etc. Nothing would be more fantastic to be playing around with, say, planets, robots, figures, etc etc.
2. Windows-style library management, where a library is a directory, and the actual emmitters are files. Easy for creating your own directories, and copying individual files to them.Hey, Alan, I know you can’t reveal any secrets, yet, but this is my 2 cents worth. Don’t know what other people would like to see ?
Regards -
3 Replies
-
[beast666] “1. The ability to import 3d objects”
Not to be too negative, but I don’t see this ever happening. It would require a 3D rendering engine, with texturing, etc. That’s beyond the scope of pIllusion. Why not just render the objects and then import the images?
[beast666] “2. Windows-style library management, where a library is a directory, and the actual emmitters are files. Easy for creating your own directories, and copying individual files to them.”
But not very cross-platform, is it? Also, where do the particle shape images (which are shared by all of the emitters in a library) go?
Glad you’re thinking though. Don’t stop making suggestions.
Alan.
wondertouch -
Regarding the window-style file management issue:
Have to disagree with you here Alan: A windows style file management system would be very beneficial to PI, and would hardly be non-cross-platform. Folders and files are pretty universal as far as file management is concerned. As to where to place emitters images…perhaps a bit of redundancy can help with the organization here: If each emitter was assigned a folder as such…
EmitterFolder
EmitterFile.il3 (actual emitter)
EmitterImagesFolder (Contains images/sequences for these emitters.
image
image
imageGranted, this creates some extra folders in the hierarchy, and emitter images MUST be contained within the actual EmitterFolderName/EmitterImagesFolder itself, but this has several advantages:
1-Altered emitters/images for one emitter have no chance of altering those of other emitters (example being someone alters an image that is shared between two emitters as a source).
2-Creation of a new/modified version of an existing emitter is as simple as selecting an EmitterFolder and creating a copy and modifying the copy.
I believe that emitter management would benefit immensely from this ability.
-
I’ll think about this, and appreciate the input.
There are a couple of problems that I see with this method. First, it will multiply the size of the libraries, possibly many, many times. The duplication of particle shape images (one copy for each emitter) can really add up to some big HD space. Right now, all of the free libraries total up to about 200 MB. Suppose that the new “folder for each emitter” (FFEE) approach results in a tripling of library size (which I think is a conservative estimate). That’s 600 MB, not including all of the overhead of over 1500 emitter folders, and image subfolders. Then add in library backups if you do any editing of libraries at all, and you’re talking a couple of GB of space. Maybe not a lot when you can get a 250GB HD for $100, but I think it’s still a lot.
The second issue is that using the FFEE method you now enable people to corrupt and change emitter libraries, and even emitters themselves from outside of particleIllusion. I really do not want to do that. Does it let the power user do some things that would be harder within pIllusion? Maybe. But the potential for problems far outweighs this in my opinion.
Keep thinking though. A redo of the library system is on the “to do” list.
FYI, Apple Motion keeps all particle images in a specific folder, and they are then accessed by all particle emitters, whether in library or in a project. There are advantages to this, and it may be the solution to the problems with your FFEE method. As I said, I’ll keep thinking.
Alan.
wondertouch
Reply to this Discussion! Login or Sign Up