Heyo, just like the subject heading says I've got a problem with Poser 11 Pro lagging with higher MB character figures. I was wondering if anyone else has come across this and if there is anything to be done about it. I looked around, and couldn't find any other threads on this topic.

Now, when I say lag, I mean a delay in being able to select body parts, change frames, use the morph tool or adjust morphs (by spinning the dial or manual input or using any of the tools). On an empty scene with Pauline or no morph V4, the lag is barely noticeable. On a Project Evolution figure (25mb) the lag is about 1-2 seconds. On a converted-poserized GF2 with plenty of morphs (100mb) the lag is about 3+ seconds and changing frames is about 5 seconds. Spinning the dials or using tools to move body parts at this point is impracticable, leaving only manual inputs for getting things done, slowly. Also, in this state it takes much longer to save a pzz/pz3 file.

Now, I should note that if I reboot at least twice this goes away, for a little while. This issue does not occur in PoserPro 2014 (which I still have installed). Nuking the pref files did not help. Clearing a bit of space on my hard drives did not help. All runtimes I use are on a different hd from poser itself (which is on an SSD). Changing display mode (i.e. fully textured vs wireframe) has no effect).

So, other than re-installing Poser, are there any other options here? I would hate to think there is some minor setting that is messing me up.

Any help would be appreciated, thanks for your time.

Anything doing with Genesis unless you converted to a Poser Native figure will be slow because it is running on DSON which is emulating what Studio does. A simple version is you change a dial Poser records that and sends it to DSON which does what ever it needs to do and then sends commands back to Poser after it is done. Consider that Poser 9 did not have sub-division and yet you can use DSON to Sub-D a Genesis figure in that version because DSON creates a proxy and that is always going to take longer then working directly with a mesh.

I hear you, and I certainly got that when trying to work with GF3 in Poser. That said, this is not happening to me in Poser 2012, and it happens (albeit to a slightly lesser degree) with Erogenesis' Project evolution, which is a poser figure, not DS. So... something else is going on?

Richard60 posted at 6:20PM Sat, 18 August 2018 - #4335009

Anything doing with Genesis unless you converted to a Poser Native figure will be slow because it is running on DSON which is emulating what Studio does. A simple version is you change a dial Poser records that and sends it to DSON which does what ever it needs to do and then sends commands back to Poser after it is done. Consider that Poser 9 did not have sub-division and yet you can use DSON to Sub-D a Genesis figure in that version because DSON creates a proxy and that is always going to take longer then working directly with a mesh.

Don't have an answer but when checking mesh size vs redraw speed I noticed sometimes the screen refresh would only utilise a single thread when most times it appeared to use multiple. A suggestion is to display cpu usage (eg taskmgr) to confirm all of them are being utilised and just check nothing else is hogging the other cpus. Morphs have a big impact on redraw speed (try exporting the mesh as obj and see the difference) so removing any unused morphs could have benefit. I use the hide function with multiple figures, maybe a script to hide non-selected parts of a figure might help but depends on workflow, having to run a script everytime a new body part is selected might be more pain than the current issue.

I had another look at the performance calcs I did previously

Screen refresh and multithreading - looks like OpenGL is single threaded. What I was seeing before was the effect of turning on "Parallel Compute" mode. This distributes some work between CPUs but appears only one cpu can gain access to OpenGL renderer at a time (I'm basing this on looking at the performance charts and a bit of Googling, someone who actual codes with OpenGL may know differently). It could be "Parallel Compute" mode is most effective when there are complex calculations per actor to be done. The python command "poser.EnableParallelComputeActors(1)" enables this feature.

Re calculated the morph timings and got variable results, some were quicker with morphs and others not. It may be the morphs only have an impact when used but puzzled by this since applying morph transforms against the mesh should take longer.

Had a look at enabling just the selected part, did not appear to improve perceived lag when working with complex figure. Bit puzzled by this too,

My calcs (based on 500 redraws of stationary figure) V4 (no morphs) - 30 fps, V4 with Morphs++ (30 - 22 fps), G6 with sub div off = 37 fps, G6 sub-div @ 0 = 18 fps, G6 sub-div @ 1 = 8 fps

Hmm, well that gives me some food for thought at least. At the moment I have a dressed and morphed-up GF2 animating and I stopped it to check out if I had SubD preview turned on for anything. Lo and behold one of the shoes had SubD preview jacked up to 2 for some reason. Turned that down to zero and the result was that changing the selected bodypart no longer took 3 seconds. Changing a morph value however took around 7 seconds to finish.

Also, I am still at a loss to explain why this happens on non dressed figures, and why I don't have this problem at all in Poser Pro 2012. It must be something Poser Pro 11 specific I Guess?

ironsoul posted at 9:17PM Sun, 19 August 2018 - #4335028

I had another look at the performance calcs I did previously

Screen refresh and multithreading - looks like OpenGL is single threaded. What I was seeing before was the effect of turning on "Parallel Compute" mode. This distributes some work between CPUs but appears only one cpu can gain access to OpenGL renderer at a time (I'm basing this on looking at the performance charts and a bit of Googling, someone who actual codes with OpenGL may know differently). It could be "Parallel Compute" mode is most effective when there are complex calculations per actor to be done. The python command "poser.EnableParallelComputeActors(1)" enables this feature.

Re calculated the morph timings and got variable results, some were quicker with morphs and others not. It may be the morphs only have an impact when used but puzzled by this since applying morph transforms against the mesh should take longer.

Had a look at enabling just the selected part, did not appear to improve perceived lag when working with complex figure. Bit puzzled by this too,

My calcs (based on 500 redraws of stationary figure) V4 (no morphs) - 30 fps, V4 with Morphs++ (30 - 22 fps), G6 with sub div off = 37 fps, G6 sub-div @ 0 = 18 fps, G6 sub-div @ 1 = 8 fps

7 seconds is a very long time for a cpu to be doing nothing, could you be running out of memory and the delay is caused by disk thrashing?

Hmm, I will check that angle out when I have a chance, thanks!

ironsoul posted at 8:49PM Mon, 20 August 2018 - #4335122

7 seconds is a very long time for a cpu to be doing nothing, could you be running out of memory and the delay is caused by disk thrashing?

So, I have 24 gb of physical ram. I am no where near running out of memory running poser, so no need for virtual memory, so no disk thrashing, presumably?

ironsoul posted at 11:30AM Wed, 22 August 2018 - #4335122

7 seconds is a very long time for a cpu to be doing nothing, could you be running out of memory and the delay is caused by disk thrashing?

If 24Gb seems unlikely. I still think that kind of delay involves of disk io.

I don't have enough morphs to reproduce the problem. Some final thoughts...

If you've not seen https://www.daz3d.com/forums/discussion/176/genesis-in-poser it might provide some ideas (page 3 onwards)

If not already done so might be an idea to check the locations set in "Cache Folder" and "Writable Runtime Folder" in the DSON preferences are pointing to the SSD.

Check that DSON version, I'm running 1.2.0.12 and that only reloads the the selected morph from disk.

DSON appears to create the temporary pmd by scanning all the morphs installed for figure in its runtime morph folder. The suggestion in the above discussion of creating a second runtime with fewer morphs might be a solution in that it will reduce the size of the temp pmd file. If might be necessary to delete the temp pmd file for this to be effective (DSON will rebuild this automatically)

As I understand it one of the things about Genesis is that unlike Poser which keeps all the morphs loaded in the CR2 Genesis will load each one off of disk as it is used. SO start with a Blank Genesis and activate the first morph it has to go out and load that file. Use another morph and again it goes out to disk to load a file. I assume once a particular morph is loaded it will not have to go back out again. So I would play with loading a morph and seeing how long it takes and then make a change to like half strength and see if it is fast or slow.

Check this out on how to convert Genesis to a native Poser figure...

https://www.renderosity.com/mod/forumpro/?thread_id=2874212

the hang with the parameter dials appears with anything above 2 v4 figures, especially in a scene with clothing and room decor etc, it was evident 2014, but with a lot more figures in the scene, the lag in movement is considerably bad too, takes posing figures a lot longer than it should do. I have 8 core AMD 4g Nvdia and 32ram Win7 pro resource monitor on cpu shows all 8 cores being used, so am thinking their is a memory stack problem as I don't hear the discs going into overdrive have had crash issues when firefox is loaded with renderosity marketplace in background while working in poser 2011 on 4 occasions which is weird

You could also try this. Try setting your render settings to something other than Superfly. I know it sounds silly as you aren't rendering at the time, but several people have reported issues with viewport lag when Superfly was the selected render engine. Once they changed it to something else they had an improvement in viewport response. At the very least, it may be worth a try.

raven posted at 5:42PM Thu, 06 September 2018 - #4335709

You could also try this. Try setting your render settings to something other than Superfly. I know it sounds silly as you aren't rendering at the time, but several people have reported issues with viewport lag when Superfly was the selected render engine. Once they changed it to something else they had an improvement in viewport response. At the very least, it may be worth a try.

Thanks, I never use Superfly - The lag is with the parameter dials in Poser 11 pro it was in poser 2014 but it is more in the newer version

WandW posted at 1:59AM Thu, 11 October 2018 - #4335317

Check this out on how to convert Genesis to a native Poser figure...

https://www.renderosity.com/mod/forumpro/?thread_id=2874212

Hi, I am Monika from Ukraine. I need help to create a few nude characters -- male and female Genesis for a renpy-game with erotic content for adults 18+. Is there someone who will help me to proceed in creating the game. mail: monlerina@mail.ru I don't know you, but I think you can help me, because I have only starter packages of DAZ Studio basic products and my male and female characters got no morphological elements at all, they seems to look really stupid without genitals. https://forum.unity.com/attachments/cb977d6c-9910-4008-825e-e283e30f5523_scaled-jpg.207248/ Please help me, I can make a really great game with a little help - All I need is: 30 render images of male and female characters having sex in some positions. Thank you, Monika

Hi, all.

Please, I apologise in advance if this question has been answered elsewhere in these forums although I did search for some insight to my question before adding to this thread so here goes.

Poser 11 Pro seems to take an incredibly long time now to render a scene with even one figure in it. See image below. I can tell by my CPU and system monitor that Poser is maxing out my CPU usage to what would appear to be way beyond 100% and in many cases Poser slows as it goes through the render process and ultimately can't finish a render. It would just stop.

Intel i7 3.4GHz, Windows 8.1 with all the updates, 16Gb gamer-grade RAM, nVidia 1060 graphics acceleration, solid state HDDs

What might be the remedy and solution to this?

Thanks so much.

unfortunately, rendo shrank your screenshot to "I think there's something there" size so it's hard to get much information. It's also missing a key pallet. What are your render settings? It looks like you're using Firefly, because it appears to have the subsurface pass. One thing to keep in mind with Firefly, it may render multiple buckets at once and when a core is done with one bucket, it will go on to the next, but it updates the image in order. So if that spot by the ear is taking some time due to the hair or something not seen in the last pass, the other cores will continue plugging along and render the rest (or at least part of the rest) of the image.keep an eye on your progress indicator. It should move even if you don't see progress in the scene itself.

Hi, RedPhantom.

A snapshot of my current render settings...

The 2 things I see that might be slowing down the render are the pixel samples and the DOF. 20 samples might be overkill and if I remember correctly DOF slows down renders too. Changing those might help. But chances are the render is continuing, just the progress isn't showing.

Cool tip. Thanks.

I like DOF since it adds depth to the image, as a DSLR camera would. But I can agree, the pixel sample rate is set high so as to offer crisp, photo-realistic results. However...

What would be the ideal pixel sample rate you would suggest that won't show a noticeable loss in rendered image clarity?