I'll keep you posted here unless I get too frustrated...

"at share CG they have the whole character

http://www.sharecg.com/v/33043/browse/11/Poser/Cyberman-PC"

That's the old cyberman version, OP is looking for the more recent design, as in "2013 cyberman upgrade"; the title of the thread and attached images.

as a prop? fit to what figure?

"If ya using V4 .just turn it in to cloths."

The OP is building the figure by generating the ivy within the V4 mesh interior rather than on the surface, similar to the generation 4 conforming internal organ and anatomy sets from Daz. By using the Donor rig, the OP has already done what you have suggested in a sense, I imagine.

keeping track of all of the various figure types (animals, toons, humans, humanoids, objects, tentacles, monsters, and so on/so forth) would probably be an impossible task. Consider all of the figures being created internationally and within subcultures or subgenres of Poser use.

I use ReadMe also: title of content ReadMe. Within the Runtime folder. Depending on the need, complexity, and content of the Runtime frequently with categorized by content type subfolders.

I was playing around with Ivy Generator the other night and found that sometimes I had to flip normals and other times didn't... It really was a sort of hit and miss process, requiring a lot of tweaking. Another issue I discovered was that the diffuse image map imported properly into Poser with the model but without the trans maps, this being very problematic if flipping normals or U/V texture coordinates as the trans maps need to be flipped to match the diffuse. Very confusing, and most easily remedied with an image editor, or perhaps can be done nodally within the material room itself. Yet another thing to look into. I would say that giving the exported object some going over in a modeler and perhaps UVMapper before use in Poser would be a good course of action.

Anyway, Ivy generator certainly is a clever, useful little app if one has the patience to iron out the idiosyncrasies in relation to Poser. I'd love to experiment further and offer more input but all of my spare time is absorbed by a project at the moment. That being said, I must admit that if I were attempting to create the kind of figure that you have conceived I would probably go a different route, as I feel that Ivy Generator's results are best reserved for static object creation. Your perseverance and progress thus far is admirable, I can see it being a hair-pulling experience.

Good luck, and keep us posted on your progress. :)

Ali's (mankahoo) Angela is not the same figure as BVH's Angela (as linked by imagination304), although Ali's Angela is a truly wonderful free figure and well worth the download. Ali's Angela figure can be found directly here_ http://www.mankahoo.com/index.php?l=page_view&p=freestuff and you can find a nice dynamic dress and some texture expansions for Ali's Angela on shareCG (in particular the things created by LaurieA or AllenArt)_ http://www.sharecg.com/pf/full_uploads.php?pf_user_name=allenart&division_id=0&s=dd&pn=1

BVH's Angela, the figure that you seek, seems to be no longer available at bvh3d.com... Perhaps being supplanted by his more recent figure, Cynthia.

The artifact in the foot looks like the spherical fall off zone needs to be widened, some of the polys are not being included.

You've already figured out the the import/ export process for the standalone Ivy Generator (or as a plug for various apps), it's just a matter of ironing out the bugs. The Ivy Generator requires an object composed of tri's as a support so from the get go I would say that V4 is a pretty unwieldy subject to convert to tri's for a support mannikin, essentially doubling the poly count (tried triangulating the blMilWom_v4b.obj in Carrara and it caused serious lag and a force quit, in wings triangulation increased the poly count from 68k to 149k). I would use a low poly blank .cr2 as a mannikin and donor. Using the default V4 .cr2 as donor has all kinds of magnets, morph channels, etc. that make it unsuitable as a donor rig (I'm assuming this is what you are doing).

You need to have a dedicated nuts & bolts modeler in your arsenal... like wings, hex, silo, etc. In wings if you select all objects composing your Ivy Figure and do an export selected of all as one .obj the object will appear in poser as a single object which can be dissected via materials or groups (I would leave all import settings unchecked). Upon import into Poser I can't see any reason why you would be losing the UV's on the .obj, if in fact the UV's are actually being lost. If so it has something to do with your export settings from the Ivy Generator.

Example: in a modeler I create a simple .obj and uv map it, assign a single material, and create a texture. I duplicate the uv'd object 10 times and export as a single object. I import this object into Poser, enter the material room and find my originally assigned material on the object, apply the texture and the texture is duplicated multiple times applied correctly to its composite parts. If I had assigned an individual material to all the parts in the modeler before exporting as a single object the Poser result would be a single object with multiple material regions.

As far as the disappearing planes that have the leaf materials, try flipping normals.

Hope these shots in the dark have been somewhat helpful.

ps. another method of object gluing would be to import all into poser and then re-export, selecting all parts from the hierarchy list (click the universe to uncheck all, tick the comprising parts), export as wavefront. Upon reimport your object will be consolidated.

correction, just checked... the material lines within the object file start after the vertex normal (vn) lines at the head of the face definitions and continue as group per material within these definitions (easiest way would be a find 'usemtl "name"' with the text editor).

Also, just to double check opened an .obj file in a text editor, deleted the material definitions and loaded the associated .cr2. The result was that the material names were still present within the material room but since these materials were no longer associated with faces of the geometry were rendered functionless... Essentially phantom debris loaded from the .cr2. Conversely I did the same process with the .cr2 file and when the figure was loaded in Poser, as earlier stated, the material regions and their functionality were still intact but the material qualities were no longer intact.

The only sure way to completely delete unwanted material regions and the corresponding material names within a figure via text editing is to edit both files. Be careful within the .cr2 to leave the preview material intact and to only delete the usemtl 'name' line within the object. Don't delete the G line and the group assignations (numbered f lines) or you'll lose your groupings.

...from the .cr2 and the object file it references. I've found that editing out either by itself will result in the unwanted material assignations still loading with the figure. delete the unwanted material lines near the bottom of the .cr2 file, within the object file delete the unwanted materials by locating them after the face definitions (F lines) and coupled with the groups definitions. Materials within the .obj will be identified by "usemtl (material name)".

AFAIK the material definitions within the .cr2 simply direct poser what material qualities to apply to the material region, it's the assignations within the object file which establishes how the material regions will be grouped to the faces. Simply deleting the material definitions within the .cr2 will result in the figure loading with all the same material groups but with a default material applied.

http://www.daz3d.com/fog-tool-deluxe-iii

nope in all instances. I would elaborate but I've found that elaborating is a distinctly unpleasant experience here at the Poser forum, I'm sure that an expert will be along to help you shortly. Waitaminute , I hear the creaking of crutches... Here comes one now!

Python script "snap to" by Ockham, moves selected object to clicked location. Not sure if it's Poser 9/pro usable though...

http://ockhamsbungalow.com/Python/

Results are variable.

"Edit_ ahhh, nevermind he wants to put the object in front of the camera rather than have the camera point at the object. Hmmm, that's a good one. An objects origin is at zero xyz when it loads even if those coordinates aren't matching the zero coordinates of the poser work space. I think, stumped on this one."

Yeah, it's not the traditional point at anyway... They must have added the little ball with brackets in Pro, Laurie. I'm not seeing it.

_ solved, Poser 9 feature.