Thanks for the help, folks. This is disappointing that subdiv is so limited. I wanted to subdivide so I could have more highly resolved lines of polygons on the figure where it intersects with clothing. That would allow cleaner bulges in figure bodies where, for example, tight clothing is constraining it and making it bulge. The descriptions of subdivision might be considered somewhat misleading.

In Poser10, dynamic cloth simulations don't obey the settings for collision objects.  Example: a forearm brushes against a hip and it grabs the dynamic cloth of a pair of shorts parented to the hip even though forearm is not one of the collision objects for the shorts.  The dynamic cloth simulation then blows up.  Seems to happen when I've already run a bullet physics simulation on the figure, though I haven't tested the simulation without a bullet physics run.  Cloth sim fails even if prior bullet physics simulation is cleared. 

This is a major disappointment since I would like to be able to run a bullet simulation of a figure's body then run dynamic cloth sims for clothing.

Thanks to everyone who provided advice.  I finished my upgrade to Win7 64-bit and reinstalled Poser 10.  So far, all renders have completed without crashing (yay!) but I haven't taxed it with more than a single subdivided V2 figure yet.  I'll keep the suggested strategies in mind and pursue as needed... including a potential upgrade to Pro2014 some day.

Quote - Sorry. I meant do you have the "separate process" box checked under your Render Preferences?

Sorry I misunderstood.  I didn't realize there was a separate process option, but have now checked the box.  I'll see if that helps.  I usually open task manager before rendering and minimize the window for the Poser app.  That bumps the memory load down considerably --though of course it starts surging upward again once rendering starts ... but not as high.  That's the only method I had found to reduce the chances of the dreaded "you are out of memory" crash.  

I'm also about to move the computer I use from WinXP to Win7.  I was goin to install the 32 bit flavor of Win7, but maybe I'll go with 64 bit.  I know Poser 10 is 32 bit (disappointing) but maybe it'll help at least a bit, and perhaps I'll also upgrade to Pro2014 if that's the only way to make it all work... but then only if the upgrade price falls to something reasonable for a hobbyist like me.

Thanks for the insights and advice.

Quote - Are you rendering as a separate process?

Rendering using FireFly within P10.  I used to export to Vue but it was too much hassle since I focus on animations.

Bought Poser10 as a sidegrade from Poser8.  Subdivision of V2 worked fine.  Unfortunately, it crashes on most renders now even with a single subdivided V2 figure. 

I may have wasted my money, though the renders that did work looked fantastic.

Quote - Attached is screencap of V2 side-by-side, the right subdivision of 1 in preview, the left unsubdivided.

Excellent.  Thanks very much for the helpful demo, which gives convincing proof it works for V2 exactly as I hoped it would.  Much appreciated...

Now off to choose between Poser10 and PP2014... hmmm

Quote - Texture maps should only be altered if the material zones were somehow changed, which i don't believe subdivision would affect.

Thanks.  That makes sense.

Thanks to both for the helpful replies. 

A follow up question, if I may:

If I take the plunge and get PP2014 --and then apply subdivision to all or part of the V2 mesh-- what happens to the texture mapping?  Does the post-subdivision mesh still take the original texture map for the figure, or do you have to re-do the texture map somehow? 

Thanks for any replies...

I'm with MistyLaraPrincess...  I'm interested in upgrading from P8 to the newest Pro version (esp for 64-bit, subdivision, network rendering) but 279 was too much.  Now 349 is even worse. 

If they ever drop the price below 200 I'll bite.

I bought P4, P4 Pro Pack, P5, P6, P7, and P8, so I think it's fair to say I'm a loyal customer... but until now none of the post-P8 upgrades were worthwhile for me.  And this one isn't either unless and until they price it for hobbyists.

I rigged up a dual PC monitor system with a front surface mirror between them.  The equipment is positioned so I can look past the front edge of the mirror to see the right monitor directly.  My left eye sees the left monitor in the reflection of the mirror.  I generate two images in Poser, each one rendered with the Poser camera in left eye then right eye position.  You have to flip the left monitor image and position the monitors and mirror fairly precisely.  But if you do it right, you see a perfect full screen 3D image with no anaglyph false colors, no size constraints imposed by spllit screen stereoscopic images on one screen, and no expensive 3D TV or monitor equipment.  All you need is a second monitor identical to the first and a graphics card which will run two monitors (unless you want to put the images on twin PCs with separate monitors).  I've generated animated 3D clips this way and the results are amazing.  I had all the equipment around except the front surface mirror, which cost about $35.

Here's a link to the concept with instructions: 

http://www.crystalcanyons.net/abouts/3dc9_DualMonitorComplete.shtm

This is the kind of thread which reminds me why I don't come here much anymore.

I remember the days in years past when people like lesbentley, Stewer, Dr. Geep, EnglishBob, Little Dragon, nruddock, ockham and others would share their knowledge and help people better understand Poser and how it could be used to achieve whatever people wanted to achieve, using whatever models or tools might help them meet their Poser-related ambitions.  

I've been dismayed to see the rise in sanctimony and the deterioration in civility and comity in recent years, so now I just stop by a few times a year to see if there are any new and interesting developments in the Poser world.... and to search for the rare pearls of wisdom and helpfulness which may still be cast by the true paragons of Poser talent and virtue.

And also to keep an eye out to see if anyone ever makes any dynamic hair I can actually use.  :)

This may be a dead thread, but I'll throw in my 2 cents anyway since I've been dealing with this issue for a long time. 

Over the years I've tried a number of solutions, including the ones suggested above in this thread.  Nothing works as a generally applicable strategy (i.e., for a wide range of animated poses) except one:

1.  go to the frame where the IK target gets fixed (e.g., frame 30 if that's when the feet finally arrive at the spots you want them to stay)... hereafter referred to as the "anchor keyframe"

2.  make the keyframe for the IK target constant (i.e., the gray one, not the green for spline or orange for interpolated)

3.  in the animation palette, delete all position and rotation keyframes for all body parts in the chain for the IK target from the anchor keyframe onward

4.  delete all position and rotation keyframes for the IK target which occur after the anchor keyframe 

The IK target will now stay in its fixed location for the remainder of animation (or until it hits a keyframe where new position or rotation parameters are defined).

Thinking through this, I believe there would be a much easier and faster solution which could be achieved using a python script ... but I'm not facile enough with Poser python scripting to do it.  Here are two options, the first of which is a scripted implementation of the above strategy:

Script A:  the script asks you to define the number for the anchor frame (or just starts from the frame you're currently on) ... the script asks which IK target you want to process ... the script then deletes all position and rotation keyframes for all body parts in the IK chain for that IK target from the anchor frame onward.

Script B:  the script asks you to define the number for the anchor frame ... the script then COPIES the position and rotation parameters for the IK target from the anchor frame to all subsequent frames

The second script would probably be improved by also having the position and rotation parameters deleted for the body parts in the IK chain from the anchor frame onward so the IK solver establishes a fresh IK solution for each post-anchor frame keyframe

The principles here should also work in heddhelds' situation where the body part you want to plant is parented to what I call an "IK proxy prop" (which I often use because I can then animate the prop to allow, say, the feet to slide on the floor or the hands to move along a surface)

If anyone is interested in a group effort to create such a script, I'd love to participate.

@ OP... I use Vue6 Infinite with 5 rendercows to render P8 animations.  Works great for me, giving me what I personally need in terms of speed versus quality.

BTW, I don't subscribe to these general statements about which renderer is faster.  These programs have too many setting variables to make general conclusions.  For example, just yesterday I was working with Vue6Inf, made one tweak to an atmospheric setting and changed the render time from 57 min to 12 min.  In my experience, there's no substitute for trying each candidate renderer to see how long it takes to render scenes which meet your personal aesthetic objectives.  Thank God for demo versions.

BTW#2: I just noticed that I joined this place just days before Little Dragon did, way back in 2001.  If only I could have accumulated as much knowledge since then as he has. 

Quote - The "single good reason" I can think of is that I open a zip file and drag the Runtime folder wherever, and it merges everything automatically.

Otherwise I'd have to drag Geometries, Textures, and Libraries, and sometimes Python - four drags instead of one.

Or, if the zip file had a top-level folder with some arbitrary name, like V4CoolStuff, and I wanted to install it in my V4 external runtime called V4 Runtime, I'd have to drag V4CoolStuff to some temporary place, change the name to V4 Runtime, and then drag it onto my existing V4 Runtime.

Either way, it's extra work. I know people say you shouldn't just drag a zip contents somewhere without examining it, but I have no trouble examining it while it is still in the zip. Then I drag it.

My main runtime is the product of six or seven years of accumulating stuff.  It would be entirely unmanageable if I let merchants choose how their geometries and textures and poses and lights and such get embedded in my runtime... so I always drag stuff where I want it and relink.  It is more work, but I can keep all textures and geometries and poses and such organized in "file cabinets" through an intervening directory level (e.g., textureseye textures...etc).  This approach includes using a "to be tested" cabinet where products can be tested before being promoted to my main runtime.  But again, I know my situation is probably unique, especially since these habits and workflows were formed way back when you could only have a single runtime (having started with Poser 4).  In any case, I like to keep as tidy and lean a runtime as possible, dumping unused geometries and textures and such to external holding bins.  This approach would itself be unworkable if not for CRPro, which not everyone has. 

But that leads to a thought... maybe P9 could have a CRPro type utility built-in to help people manage their inevitably bloating runtimes.