Poser corrupting scenes during saving. Can't render in Queue. Not! Happy!, Jan!

  • Ok, first, my abject apologies to everyone in the world named "Jan", and to all the frustrated middle managers whose misplaced trust in a subordinate has been betrayed

    & Still not happy, Jan!

    I appear to be alone in suffering from this particular misbehaviour from Poser Pro 11, in response to my apparently envelope-pushing techniques in wresting the best from my renders. To whit: whenever I use a base figure (V4WM, in this case, but the figure type is irrelevant) with a close-fitting, conformed figure that relies on the base figure's embedded deformers, Poser will consistently, and invalidly change the evaluation order of the deformerProp channels in the conformed figure's actors when saving the scene. This corrupts (though none of the scene files are corrupted in the sense of missing or broken syntax) the scene prior to when it is next loaded, or equally importantly, sent to QueueManager for external rendering.

    I have been using the RayTrace Preview to generate larger PNG icons for my library poses, via a Python script which invokes macOS' ScreenCapture routines (I have an equivalent, though less tested version for Windows), allowing me to replace the initial, low-resolution icon of previously saved poses and figures. It works well, though with SuperFly final render settings can take an inordinate amount of time to complete the preview, prior to being able to initiate the save. It occurred to me, now that the shenanigans with mis-matched QueueManager versions, and missing Send Render buttons have been resolved in Poser Pro, that for a whole scene of still frames whose pose icons I want to replace, I should just set the output render dimensions to 256x256, to match the RayTrace Preview, and send the lot to the Queue as a batch. No problem, think I, except that when I examine the folder full of rendered icons, there are noticeable artifacts where the base figure is poking through the clothes!

    Here's a comparison of the Queued and saved RayTrace Previews of a frame of the scene:
    0_1555380726950_Modern Kitchen Updated_0045.png 0_1555380757172_RayTracePreview 45.png
    Note the absence of pokethrough on the (second image) RayTrace Preview from within Poser.

    Why did this happen? Well, the simple answer is that in order to send any renders to QueueManager, which may be on a remote system, Poser has to save the scene out to a file, which, unfortunately, cannot currently replicate the live scene in Poser due to explicitly re-ordering the deformer channels during the save to file process.

    When, (as I imagine was) the original conception of how deformers should work, clustering them all at the very start of the channel evaluation order, meant that they could all operate on the unmorphed, and more importantly, unbent mesh of an actor. Since the deformer's zone falloff gradient determines the strength of the displacement which the deformer applies to vertices, it is important to know where the mesh vertex is within the zone. Evaluating before any morphs or bends is very simple, since you only need to refer to the vertex position in the geometry. Fair enough.

    But when a base figure is loaded from the library, Poser does no rearrangement of channel evaluation order, so having a deformer not applied until after all the morphs are calculated, could move some vertices into or out of the deformer zone, changing the effect of the deformer. Even more marked would be a deformer applied after limbs have been bent, which needs to calculate a semi-final position for vertices, including joint zones and weight map bend influences before you can even know whether a vertex will still be influenced by a deformer whose zone may or may not be parented to one of those bending actors.

    Even loading a conformed figure which relies on evaluation re-ordered deformers on the base figure, works correctly in the first instance of a scene. But it is these dependent figures, with inherited deformer channels from the base figure, which get corrupted during Poser's saving of the scene, where the save routine decides that these deformer channels from another figure must all be clustered at the start of the conformers' actors' channel evaluation order. Wrong! That stops the scene from appearing identically on reload as when it was saved, and prevents any serious use of Queue rendering due to the need to save the scene to a file for queueing.

    There is also no possible workaround with a cleanup Python script, as Poser's Python API does not expose any methods to rearrange channel evaluation orders as can be done through the UI (at least in Poser Pro, by displaying the parameters in calculation order and dragging them around). Fixing the rearranged deformers on conforming figures is possible, but mind-numbingly tedious, given the dreadfully slow scrolling speed of the Parameters Palette, when hundreds of previously hidden parameters must be exposed in order to determine the correct evaluation of inherited deformers.

  • P.S. Loud hurrahs! for whoever managed to re-enable the ability to post images in an initial thread post. I'd forgotten how much of a pain that used to be, so was overjoyed to realise that I wouldn't have to edit my post to put the images back in. Yay! X-D

    P.P.S Sombre sympathies for Parisians of all faiths and genders, and all who may be concerned throughout the world, on the catastrophe at Notre Dame de Paris. ;_;

  • No changes were made in 11.1 -- if you are seeing issues they were present in Poser 11. I do not know that anything would have changed from 10, either. Your issue report has been recorded, however.

  • @h-elwood-gilliland thanks, it's certainly not a new problem, and I have vague memories that I first noticed it in Poser Pro 2014. I spent a long time working around it, by adjusting the fit of conformed clothes until I finally arrived at the conclusion that my fitting poses weren't working because when I saved them, they applied to the correctly conformed and matched deformer evaluation order clothing figures as originally loaded in a scene. At some stage I might reload that saved scene and notice that some of the clothing fits weren't quite correct, so I'd adjust them.

    Now that I've confirmed to my own satisfaction that the reordering is only happening at the point of saving a scene, I might see if I can fix the saved scene file before I load it again and confirm whether it does what I need it to do (I fully expect this to be the case).

    My major frustration now (and the point of making this thread), is that I can't use the Queue to render out my larger icons at all (which I was really looking forward to doing, given it took 6 hours overnight to render 45 icons), because I don't get an opportunity to fix the saved scene file before QM will try to process and render it. When I look through the rendered icons, almost half of them (19/45) exhibit poke-through not evident in the scene, and are thus useless.

  • @anomalaus Hopefully someone else can come forward with helpful tips. I'm glad you have some idea of what version, as we can hope to track down what changes were made one day.