I've come across many forum posts that suggest that V4's poly count can slow Poser down, esp. if a scene has multiple V4s (and/or M4s). But when I figured out how to check poly counts, I was surprised to discover how many other items have a much higher poly count than V4, including some clothing, hair, jewelry and props. Since then I've been kind of obsessive about using only items with relatively low poly counts, which means I'm not using a lot of the content I have available.

So here's my question: does the poly count of a posable figure like V4 have a greater impact on Poser's performance than the poly count of static items?

By "performance" I'm referring to using the Pose room in Preview mode, NOT to rendering. I know about tricks like making items visible only when rendered, setting items to wireframe or flat-shaded, and so on (see Relevant Info below), and I typically run Poser with only one other app open (Notes) and after a restart, so it has plenty of memory. But still it gets laggy fairly frequently and actually crashes at least once a day, often before I've even added a V4 or M4 to the scene!

I'm creating sets to use for a graphic novel, so they're more complex than a backdrop for a single render. The sets and props also contribute a lot to the storytelling, so I don't want to skimp on detail. But of course that's all for nothing if I add a few V4/M4 characters to the scene and can barely pose them b/c Poser has slowed to a crawl.

I guess what I'm really trying to figure out is what role poly count plays in causing Poser's performance to decline while setting things up in the Pose room, so that I can try and optimize my figures, sets, and props accordingly. I will continue to use V4 and M4 (for a variety of reasons), but I don't need them to wear 100k poly earrings or sit in 80k poly chairs if that's the sort of thing that will slow Poser down! On the other hand, if the poly count of props doesn't really impact performance in Preview mode, then I'd love to use some of the beautiful furniture and jewelry in my runtime.

Any input would be appreciated!

RELEVANT INFO & CURRENT SETTINGS

• Poser Pro 11.0.8
• 2017 MacBook Pro 2.9GHz i7 16GB RAM Intel HD Graphics 630
• Display modes: wireframe or flat shaded as needed
• Typical Lights: one IBL and a few low-intensity point or infinite lights
• Ground/Hardware Shadows: off
• Hardware AO: off
• Preview texture resolution: 512
• OpenGL mipmaps: off
• Enable hardware antialiasing: off for full sets
• Enable hardware shading: off for full sets
• Texture cache: 500mb
• Main Figures: M4 and the SASHA-16 WM V4 (and occasionally HW Horse)
• Background Figures: rigged LOD versions of M4 & V4

My system isn't nearly as robust as yours and I have had up to 10+ V4/M4/K4 figures in the scene as well as a major collection of props (scene props, clothing, hair ... etc.) Another major contributor is the size and complexity of the texture maps and the shaders.

I've made huge scenes that used a variety of figures, but plenty of Vickys and Mikes. I don't know how a mac compares to a pc as far as cpu and video card we have the same memory. I do get plenty of slow down. I've had hair also slow down my scene, though it was a figure too. I think that figures need more memory in that they have rigging and morphs and Sasha has plenty of morphs. It sounds like you're using most of the tricks I know, except don't have 'enhance multilayer transparency' checked.

Another thing you can do for a crowd is to pose small groups of people in separate scenes and then parent them to a grouping prop or a primitive and import them all into your background scene. Use box tracking to position them in the new scene. Basically, with my last story, I said I didn't care. If I wanted 40 people in a scene, I was going to do it and suffer the delays.

I find that I need more polys in dynamic cloth simulations, cannot compromise on that. I also find that managing background props and figures to have lower polygons, more texture filtering (Poser Pro 11 can reduce polygons in-the-fly), will help in bigger scenes. I render on a Windows system, so we may be comparing apples and oranges. I have 32 GB installed RAM, an Intel i7-6700 running at 3.4GHz, and an nVidia GTX 1080 graphics accelerator card.

Had a look at this from the point of redraw time, results were not expected with there being a big overhead with the figure, maybe a problem with the test.

##Method

Load scene (basic P11 + BBs environment sphere)
Load V4.2 figure and ran timer
Export to obj, delete v4.2 figure and import obj
Re-ran test

##Results

#Victoria as a Figure
Average redraw time with Parallel Compute Actors Off = 0.051s
Average redraw time with Parallel Compute Actors Enabled = 0.039s
Improvement with Parallel Compute Actors enabled = 23.1%

#Victoria as an Object
Average redraw time with Parallel Compute Actors Off = 0.015s
Average redraw time with Parallel Compute Actors Enabled = 0.028s
Improvement with Parallel Compute Actors enabled = -84.9%

##Code

import time
import poser

scene = poser.Scene()

poser.EnableParallelComputeActors(0)
start = time.clock()
for x in xrange(1, 11):
scene.DrawAll()

AvgRedrawTimeNoParallel = (time.clock() - start)/10

poser.EnableParallelComputeActors(1)
start = time.clock()
for x in xrange(1, 11):
scene.DrawAll()

AvgRedrawTimeParallel = (time.clock() - start)/10

print "Average redraw time with Parallel Compute Actors Off = {:0.3f}s".format(AvgRedrawTimeNoParallel)
print "Average redraw time with Parallel Compute Actors Enabled = {:0.3f}s".format(AvgRedrawTimeParallel)
print "Improvement with Parallel Compute Actors enabled = {:0.1f}%".format(100*(AvgRedrawTimeNoParallel-AvgRedrawTimeParallel)/AvgRedrawTimeNoParallel)

Couple of variations. A figure has much more functionaility (eg morphs) and hidden effects like callbacks that explain the much higher time, but wasn't expecting it to have as much as an impacted as the numbers show. It may be I have something installed that is using callbacks or someother function adding to the figure redraw.

4 V4 figures vs 4 V4 Obj

Figures
Average redraw time with Parallel Compute Actors Off = 0.197s
Average redraw time with Parallel Compute Actors Enabled = 0.198s
Improvement with Parallel Compute Actors enabled = -0.7%

Objs
Average redraw time with Parallel Compute Actors Off = 0.032s
Average redraw time with Parallel Compute Actors Enabled = 0.020s
Improvement with Parallel Compute Actors enabled = 35.3%

Increased polygon count - skin to unimesh then sub div by 2

Figure
Average redraw time with Parallel Compute Actors Off = 0.454s
Average redraw time with Parallel Compute Actors Enabled = 0.395s
Improvement with Parallel Compute Actors enabled = 13.0%

Obj
Average redraw time with Parallel Compute Actors Off = 0.097s
Average redraw time with Parallel Compute Actors Enabled = 0.096s
Improvement with Parallel Compute Actors enabled = 1.2%

Haven't done any in depth tests as those above so this is just based on what I have experienced my self. But at least for me conforming figures with a lot of polygons seems to have a huge impact on the viewport, if the "When conforming.." check boxes are turned on. Especially when you pose a character, my guess is that Poser have to constantly adjust the conforming figure to fit the character which make posing lag. However this is only the case if the conforming figure is visible, if its hidden it doesn't seem to have any impact. Unfortunately Poser doesn't have an option for hiding objects, while still making them visible during rendering. At least to me it seems that you can get away with a lot more polygons when using dynamic cloth since they don't have to conform. The down side is obviously if you have a lot of characters you will have to do a lot of cloth simulations.

What you could try if you haven't already is to use the reduce polygons (Havent tried it my self, so might not work on figures).

Thanks to everyone for the replies and esp. to ironsoul for running those tests of V4 as a figure vs. an object.

It makes sense that several aspects of figures might slow down Poser in ways that aren't applicable to props--such as morphs and conformers. I only have what I consider the "core" morph packages installed (Morphs++ and Aiko/Hiro), plus a few individual Faerime face morphs depending on the character, and I removed all of Sasha's KV stuff. So I don't think I can trim down any further there. As for conformers, I need way too many different poses (and I fiddle with poses too often) to use dynamic clothes, but I can experiment with making conforming items invisible until I'm mostly finished with posing to see if that helps.

Yesterday I was working on a scene with two V4 characters, each riding a HW Horse along a trail in 2nd World's Park and Nature Scene. I set up each horse/rider pair in their own scene file, parented each rider's hip to their horse's abdomen, and saved each group to the figures library. My thinking was that by the time I added them to the scene file, they'd already be posed and I would only need to translate the horses a bit to get them to the right spot.

But after I loaded them, I saw that both V4s had weird poke-through in their shirts, their feet had moved out of place in the stirrups, and their hands were no longer holding the reins but hovering above them. In other words, much of the work that had gone into posing them in separate files (and using the morph brush on spots of poke-through) had been for naught, as I had a lot more work to do. And the posing was incredibly tedious b/c by then Poser was barely responding to turns of the dials (even though the only items visible in the scene were those necessary for posing). It was maddening!!

I understand that textures and shaders can also slow down Poser's performance in Preview mode, but I had Hardware Shading turned off, Preview Texture Size set to 512, and items with transparency (hair, manes, tails) set to wireframe display. So shouldn't that make textures less of a factor while in Preview mode?

I bought a new top-of-the-line MacBook Pro specifically to make it easier to work with Poser, but other than Firefly renders being much faster, there's no real improvement over my 2013 MacBook Pro, which is certainly disappointing. I use Cheetah3D for modeling and texturing, and it can handle WAY more stuff than Poser before there's any impact on performance, so I wonder there's something about Poser that's just not optimized for Macs?

Odd there is a problem with just four figures.

You mentioned problems with Poser becoming laggy even before V4/M4 are added (first post), could the slow response with the new scene be related to that issue?

When Poser is performing badly have you looked at the CPU, memory utilization and disk performance to see if they are much higher than expected (ie near 100%)?

I've never used a Mac so don't know the correct name, but are there system and application logs, do they show an increase in error messages when Poser starts to slow down? Is there an error message associated with the Poser crash you mentioned in the first post?

A grasping at straws type question in case its an OpenGL problem - if availabled on the Mac have you tried changing to the preview render engine to Sreed?

Since you have a scene you can do testing with, have you tried turning each figure invisible/visible one at the time or deleting them to see if its a specific figure. I don't only mean V4 or the horses. But also hair, cloth etc.Maybe test it with only one V4 and one horse, maybe that way you can isolate what is causing it.

These are the preview settings I use, you can try to copy them and see if it gets better or whether it makes any difference at all.

@3D-Mobster: Thanks for the tips. When I work with more than two figures at a time, I turn off hardware antialiasing, hardware shading, and mipmaps, on the theory that that should help with performance. But now that I think about it, those settings only apply to textures, not to other aspects of the figures, and I don't think textures are the cause of my issues. I delete all bump/disp maps and use simple procedural shaders whenever possible, and I keep items with transparency in wireframe mode. I suspect the performance issues have more to do with how Poser is handling poly count, morphs, and rigging. (FYI: I never use subdivision on anything.)

@ironsoul: Thanks for your reply. Yes, Poser will start to lag when I'm setting up a scene with lots of props, but it takes a lot longer to get to "unusable" (or a crash) compared to when I'm working with figures. Over the past two weeks I've been building my main character's bedroom, using a room I created in Cheetah3D as well as a variety of props I modified and/or re-mapped and textured in Cheetah. Cheetah has no problem handling the room with all props visible AND all texture maps applied in .PSD format, for as long as I want to have it open -- and I can even open and work in other Cheetah files at the same time. So I try to do as much setup as I can there, but of course the lighting and texture display aren't exactly the same. When I'm ready to see how things look in Poser, I export the props as OBJs and the textures as JPGs and load everything into a new Poser scene file. But Poser can only handle them for about an hour before it stops responding to my dial turns.

Macs have an Activity Monitor that shows real-time CPU, RAM and disk usage, but the only time I've noticed Poser using close to 100% of the CPU is when I'm rendering, which makes sense. Macs also have a Console tool that displays a variety of system and app logs as well as crash reports, but I'm not a programmer, so I don't know how to interpret those. I'm enough of a techie "fiddler" that I often study Poser crash reports, hoping I can somehow make sense of them, but apparently my glasses don't have "Magic Decoder Ring" technology :-)

I will fiddle around some more tomorrow to see if I can activate some kind of logging that will give me some insight into what's happening as I work with a file like the one with two V4s, two horses, and a park.

Here's an aspect of the scenario I described above that I still don't understand: why didn't the horse/rider pairs I'd so painstakingly posed and saved to the figure library load into the new scene file in precisely the same poses?

It took me forever to get each rider's hands positioned on the reins in a way that resembled the way my friends and I hold reins when trail riding, but when I loaded the horse/rider pairs into the new scene, neither rider's hands were actually touching the reins. Their feet were also no longer properly placed the stirrups but a few inches below or to the side of them. And one of the horses had her mane sticking straight up, instead of split to the right as I'd saved her with.

I swear if I didn't already have so much time, money, and effort invested in creating my graphic novel with Poser, I'd just ditch the graphic part and write the dang thing in words!

check to see if the original scenes and see if they are still correct there. if they are, try importing the scene rather than loading and saving the figure.

@perpetualrevision - thanks for your reply. From your description it is not clear if this a problem with Poser or some kind of resource leak or in driver/library issue but I don't know enough about how Macs work to know where to look. Regarding posing multiple horse/riders - in the past I just used one rider/horse but setup the different poses as animation key frames. Once all the poses had been setup the figure was duplicated and I used the pose dots to copy the key frame to frame one. This also had the benefit of being able use the animation interpolation to create additional poses if there are many horse/riders to setup - the process probably works best when the figures are very similar.

perpetualrevision posted at 5:13PM Sun, 19 November 2017 - #4318239

Here's an aspect of the scenario I described above that I still don't understand: why didn't the horse/rider pairs I'd so painstakingly posed and saved to the figure library load into the new scene file in precisely the same poses?

It took me forever to get each rider's hands positioned on the reins in a way that resembled the way my friends and I hold reins when trail riding, but when I loaded the horse/rider pairs into the new scene, neither rider's hands were actually touching the reins. Their feet were also no longer properly placed the stirrups but a few inches below or to the side of them. And one of the horses had her mane sticking straight up, instead of split to the right as I'd saved her with.

I swear if I didn't already have so much time, money, and effort invested in creating my graphic novel with Poser, I'd just ditch the graphic part and write the dang thing in words!

A possible cause to this can be due to you having saved the poses with IK turned on or your characters having IK turned on when applying the pose. All poses in my experience should be saved with IK turned off and applied to characters with it turned off as well. You should only have IK enabled while posing if you need to do some quick posing or need the feet or hands to stay locked. Once the pose is done you turn it off again. If you look closely on the character as you turn them off, you can actually see that the body parts (Hands, Feet) move a little, so after you have turned IK off, you should always check and fine tune hands and feet to make sure they are correct. After that you can save the pose.

I think I've identified a possible reason why the rider/horse pairs came into the new scene slightly out of position. It has to do with the dreaded "keyframe drift."

I always leave everything in its default location/pose on Frame 1 and do all my posing on Frames 2 and up (depending on how many shots I need per scene). After I set up the Parks & Trails set in a new scene file, I loaded one rider/horse pair from the figures library, which came into Frame 1 already posed. Then I loaded the other pair via Import/Poser Document (b/c I hadn't saved them to the library), and they came into Frame 1 in default poses, with the riding pose on Frame 2.

I used Frame 2 to translate the rider/horse pairs to the right spot on the trail, and then I think I must've advanced to Frame 3 to fine-tune poses. What I forgot to do was to copy Frame 2's keyframes to a point further down the timeline (like Frame 5) and to set the keyframes to Constant. So the reason their hands were no longer properly gripping the reins on Frame 3 was most likely that their bodies were starting to drift along a Spline path back to their default poses. (And I started fixing that before I thought to check hand positions one earlier frames.)

I'm pretty far off of my original question by now, but since it's just come up: is there a way to make Constant the default type of interpolation for all new files? I've gotten myself into more than one crazy posing mess due to the way Spline interpolation works!

PS to 3D-Mobster: I never use IK for anything and always have it off, both b/c I prefer to pose w/o it and b/c it messes up how poses get saved. I did try using it to keep the riders' hands connected to the horses' reins, but it didn't work as intended. Neither did using "add constraint" or parenting, probably b/c the reins are part of the bridle figure rather than being a separate prop. (And I'd lose all the helpful morph dials if I converted them to a prop.)

@ironsoul: Yes, I think you're right that I'm experiencing some kind of performance problem that has to do with using Poser on a Mac. I've tried all the solutions I could find online, so I may just need to contact Smith Micro support.

For the benefit of future readers of this thread, I want to recap what I think was the answer to my original question: does the poly count of a posable figure like V4 have a greater impact on Poser's performance (in Preview/posing mode) than the poly count of static objects?

The answer appears to be "yes" b/c posable figures have other elements that impact performance in addition to poly count, such as morphs and rigging. So that's likely why some people complain about V4's "high" poly count, despite the fact that so many accessories and props have even higher poly counts.

But here's the question that remains for me: how much of an impact does the poly count of non-rigged props have on performance in Preview mode?

I understand that large textures impact performance, but that's easy enough to deal with through various Preview settings that don't reduce the quality of an actual render. It's much harder to reduce the poly count of items like earrings, handbags, or furniture without reducing their quality in a render, so it's not even worth trying unless the poly count of those items really does slow down Poser's performance. Or maybe it's not poly count that's the issue so much as how those objects were modeled? That's the part I don't yet understand.

Many thanks to all who've contributed to this thread thus far! I appreciate your help.

In document display style ,you don't have to use shaded texture.

You could render in .png .tif or what ever has a clear back ground n peace a big scene together in a 2D app.

Don't know about Poser Decimate but maybe.

Shaders/maps play a big role in this also.

if your 3D card or open GL or what ever is trying real time.

FYI, it's not always simple polycounts that make or break a scene's usability. If a mesh is mostly quads (square/4-sided polys), or mostly tris (3-sided ones), it will load and behave a lot faster than a mesh that is riddled with nGons (an nGon is technically a polygon with 5 or more sides, but usually denotes a poly with a zillion sides to it). The Vickies are almost always clean in this regard, so I don't think it's that, but I wanted to bring it up anyway, just in case. :)

Your best bet I think is to look at the texture/shader rigging - a crap texture (or worse, a really crap shader) can suck down CPU and GPU cycles faster than a dachshund can eat raw meat.

Also, although you're using multiple V4/M4 figures, what kind of hair are they using? What kind of clothing? Those meshes may be sucking down the power as well.

Totally agree with pengy

Tried an experiment once. 10 v4s in one scene... Poser broke. Crash city.

But, 5 million(!) polygon tree covered in ivy? No problems.

The difference? The tree had no rigging or scripts, etc.

Ive always suspected that is where the main issues lie in Poser and ds, with all figures...

@Penguinisto: Thanks for your reply. I suspected that the way an item was modeled (tris, quads, n-gons, etc.) might have an impact on how it performs in Poser, and you've confirmed that it does. I just wish I understood exactly how those factors impact performance, so that it's less of a trial and error process with various props and sets.

I'm willing to modify props and sets in my 3D modeler to get rid of n-gons and otherwise optimize the mesh (including deleting unnecessary polys). But to make good use of my time and efforts, I need a better understanding of what's causing an issue. Like why Poser would start to slow down b/c a model has n-gons or whatever. (I understand why those are problematic for sub-division, rendering, and smooth shading, but not why they might make Poser's parameter dials cease to function!)

So the next time I'm trying to choose between several props of the same type (say, desks or chairs), I should check the poly count AND the type of polys used. Anything else?

Is there a way inside Poser to check for n-gons, or would I need to bring the item into my modeler for that?

I'm deliberately not mentioning textures b/c I'm certain that's not what's causing the slow-downs I've been getting. I always optimize textures in the Advanced Material Room shortly after loading an item, I keep "hardware shading" disabled in Preview mode, and in scenes with more than a few items, I put many of them (like hair) in wireframe or flat shaded display mode.

Re: reducing polygons: I've had mixed results using Poser's "Reduce Polygons" tool on various props and sets, and I suspect that's generally easier to deal with in a modeling app.

Vicky will load with all the morphs n all that's a lot .strip all that way will make the file a lot smaller,conforming cloths ,hair might load with morphs also.

Never tried my self but A while back use to see Some Artist used Vue for large scenes.