Particles 3 effects take the form of figures, meaning that they can be exported just like any other Poser figure can.

How successful the transfer will be depends both on the effect's reliance on procedural materials and/or sprites, and on the host software's support of those features.

I don't have Vue to test with, so I can't make any judgment calls from firsthand knowledge, but Particles 2 users did report some success in Vue and (to a lesser extent) Bryce.

DAZ does offer a 30-day satisfaction guarantee if you want to check it out and see if Particles 3/PZ will meet your needs.

Thanks--you are correct, Particles 3/PZ is cross platform, so Mac users can now use it in addition to PC users!

You can "pass arguments" using Animation Sets, provided that you're using a CM2, MC6 or PZ3. This is how ShaderSpider's FX-MATs work.

You will run into issues with loading content off of DVDs, because paths are stored from the drive letter (ie, G:/Victoria3/Runtime/Geometries/DAZ/MilWom/blMilWom3.obj)

Unless the DVD with those necessary files on it was always in the drive, you would be unable to open scenes using content from any Runtimes off of the DVD. Poser may also throw errors when starting up if it can't find your DVD Runtime.

I would recommend using an external/portable hard drive rather than DVDs, and keeping the same drive letter mapped to the external drive.

Try the UI dots.

Since Marvel and DC are not involved in the 3D market, the use of the term "super-hero" in Poser-related product names is perfectly legal.

Delta makes water faucets. Delta is a major airline. Both are trademarked names and different companies, but, as they do not compete in the same (or similar) product market, it is a non-issue.

Message edited on: 03/27/2006 20:36

Attached Link: http://www.poseworks.com/glowworm/

1) Lower-memory renders. Breaking an image into multiple renders lessens the burden on your machine when rendering. Many users have found that they are able to render scenes that previously caused "out of memory" errors, by breaking up the render into multiple passes and then compositing them.

2) Fast changes. If you need to lighten a shadow, adjust a color or tinker with any other aspect of your image, you can make those changes very easily in Photoshop/AfterEffects/Gimp/Whatever, and not re-render. This, more than anything else, is why professionals use MPR--when the boss or the client wants a change made, you don't want to be stuck rendering; you want the fast, full quality feedback that programs like Photoshop and AfterEffects provide.

3) Special effects. MPR makes it simple to add things like glows and depth-of-field to your renders. Particularly with animations, MPR opens up all kinds of new avenues of creativity.

You can view tutorials for GlowWorm and get more info on multipass rendering from the above link.

This is likely due to a bug introduced in Poser 6 SR2. There's a post on the matter floating around the Poser Python forum somewhere. When I was building my own batch renderer, GlowWorm, I developed a work-around to the problem. Calling "poser.Scene().RevertDocument()" will correct the problem after opening a file through Python.

From what I can tell, this is the result of Poser's rather clumsy selection handling (compared to competitor DAZ Studio). The only way to insure that you have a valid material selection for an MC6 or MT5 is to be in--you guessed it--the Material Room. From a design standpoint, this was the right decision to make: It's the only way that both the program and the user will know exactly who the recepient of the material preset is, or even if it would be valid to apply a material preset. I'm not saying that I like this--it cheeses me as much as y'all--but it's better than the unpredictable alternative. The whole selection system badly needs a makeover for Poser 7. My library gripe? Hitting the delete key goes up a directory. I can't tell you how many times I've tried to delete a figure or prop and wound up traversing my content folders instead. Delete should be a shortcut for one thing: Deleting things.

Attached Link: http://www.daz3d.com/shop.php?op=itemdetails&item=3551

Message edited on: 02/16/2006 13:24

Yes, it should be affected by bump mapping and displacements.

You sadly cannot create new nodes for the Material Room. Believe me, I've tried... There are some interesting files describing the nodes lying around in your Poser directories, but alterring them doesn't seem to change anything.

Poser holds a texture in memory until next render by default. Be sure that "Keep Textures Loaded" is off, and do a quick render. Then the preview should update.

To modify shader trees in P5, you'll need to do the following in Python:

1. Save a CR2 (if you're using a figure) or a PZ3 (if a prop--since SaveLibraryProp has never worked properly)

2. Search the file to find the shader tree you want

3. Parse the shader tree to get the components that you want

4. Ponder the reason why CL never added Python support for the Material Room in P5

5. Make modifications to that data and translate it back into Poser's library code

6. Write a new PZ2 with the modified shader tree

7. Apply the PZ2 to the figure/prop

8. Cry yourself to sleep

Message edited on: 01/26/2006 03:10