Gauging response to a change request

  • I'm looking for some corroboration of what I see as a bug in Poser, but before I submit a bug or feature change request, I think it's prudent to get input from other experienced users in case I'm missing a more favorable alternative.

    In any scene, whether complex or bare, when I load a combined set of figures (the mechanism involves lots of readScript calls, but the process essentially parallels importing another scene, with pre-posed and valueOperation linked slaved and conformed figures), I can work without problems, knowing and observing that the slaved or conformed figures which are affected by magnets on the base figure, will closely follow the magnet induced shape changes of the base.

    The most important figure is the second copy of the base figure, which is slaved (valueOperations drive every transform and morph), rather than conformed, due to previous versions of Poser failing to accurately conform limbs of very tight clothing figures. The only solution I found at the time, was to slave, rather than conform. Since then, additional conforming options like follow origins and follow endpoints have been implemented, but due to scaling of the figure's torso and limbs, were not completely successful at maintaining the required second skin's vertices exactly following the base figure.

    This concept of slaving vs conforming, is not, however, where the issues I'm having arise. Due to V4's long dependence on JCMs and deformers to provide realistic figure shapes, and the reasonably useful ability of the base figure's deformers to invoke the same changes in close fitting clothing, I have persevered with that method.

    The major drawback, is that this deformer shaping is absolutely subject to evaluation order. Not, just before or after bending, but before or after all of the morphs on a figure. When I first load the figure group, that works perfectly, but either at the point of saving the scene, or loading it again after the inevitable Poser crash, the save or load routines have decided to re-order the deformerPropChan parameters. Usually, but not exclusively grouping them in Reverse! evaluation order before any of the morphs! This also tends to happen with the hidden joint parameters, so saving a modified clothing figure, and then trying to merge the additions back into my figure assembly source files fails to allow simple highlighting of just the changes, because parameters have been spuriously re-ordered!

    Here's what I see on reloading a previously saved scene after a crash:
    ***=NSFW content***

    click to show

    The slaved second skin, using the reversed and pre-morph grouped deformer channels of the base V4 figure does not match the underlying shape of the base figure after a reload.
    0_1537862789384_Screen Shot 2018-09-25 at 5.47.07 pm.png
    above, the base figure's breast deformers are all grouped immediately after the empty injection channels and before the normally hidden joint parameters of the chest.
    0_1537862805720_Screen Shot 2018-09-25 at 5.47.42 pm.png
    above, the second skin chest actor has all of its inherited deformers from the base figure grouped before any other channels.
    When I re-order (probably superfluous) and move those inherited deformer channels to the corresponding order they appear on the base figure, as so:
    0_1537862823943_Screen Shot 2018-09-25 at 5.51.29 pm.png
    I get what I expected; exact conformation of the second skin (with it's helpful silhouette preview due to SuperFly shaders X-P) better preserving the base V4 figure's modesty ;-)

    [Ha ha! remembered to leave out the images until after I edit the initial topic post to add them in! Shouldn't have to be so hard!]

  • The consequence of this save/load misbehaviour, is that I spend all my time either re-ordering the deformer channels, which is remarkably tedious with heavily morphed figures, since I usually have to unhide all parameters and display them in evaluation order, and there is no acceleration of the scrolling when the cursor is above or below the palette, and the scrolling stops if I don't keep jiggling the cursor!

    It also forces me to constantly save the poses and sequences I'm working on to the library, since it's commonly significantly quicker to load the blank scene, add the figure group (7 or 8 of which have deformer dependencies from the base V4) and re-apply the pose sequences, knowing that the conformed figures will retain their correct shapes.

  • So, finally, what to do? Bundle this all up and submit a bug report (obviously). But is it a problem that others have dealt with. If I'm the only victim, it seems unlikely to get any traction to get fixed in the next release.

    The second skin paradigm was available before Poser supported material layers, and is far more flexible. The second skin figure has a modified geometry from the base V4, (same vertices, but additional material groups) allowing me to more simply retexture areas (it makes a perfect wetsuit with an oval face cutout). It also has additional morphs for inflation, giving variable thickness/offset from the underlying figure (think Michelin Man in the extreme).

    Still, I don't need to just defend a useful technique, unless there are simpler, more effective alternatives. The problem affects ordinary conformed clothing. The tighter fitting, the worse the problem, so many users may never notice, or just attribute the problem to pokethrough and fix it in the normal manner, but that should not be required, as long as the deformer channels maintain their relative evaluation order in the conformed figures.

    I suspect the developers have made some reasonable expedient decisions for valid reasons, but have not received sufficient complaint for this to be rectified. [/rant]

  • [rant#2] The worst of this, is that if the Python API existed to re-order parameters, as can be done in the GUI (at least in Poser Pro), I'd just script it into oblivion and the developers needn't be troubled by the need for core rewrites delaying introduction of new features, and vice versa!

  • Poser Ambassadors

    Bundle it all up and file a bug report.
    It avoids misunderstanding what the problem is. Various options have been introduced to control the evaluation order (GoZ, load morph target) and it looks like a bug when those are not preserved when you import a figure with those changes.
    In the past they have been willing to expose this type of functionality to python, so it is a good idea to ask for that as well.

    For wet suits, wet skin, etc, I myself use the render engine to create a mixed material (blend) where i do not run into these issues.

  • @wimvdb thanks. I'm reasonably certain that the morph/deformer evaluation order is significant, (and perhaps requires a specific 'beforeBend' placement attribute) rather than just before or after the transforms ('afterBend' attribute), because morphs will move vertices within the deformer zone. Unless the deformer zone relies on weightmaps (which would obviously have a fixed, evaluation order irrelevant strength), a vertex's position within the zone will determine what strength the deformer applies to it. Pre-apply a morph, and you may get a different deformation.

  • On conforming and slaving:
    Did anyone ever consider to 'shadow' a figure, so use callback functions to let the garment 'shadow' the lead figure?
    This would allow to let the shadow respond to movements and morps of the lead in a way tailored for the shadow. The response would be defined in a Python function so basically do whatever the maker wants and how he wants it.
    The code installing the callbacks could even throw an opacity mask on the lead figure to hide what is inside the garment, or add a displacement map to simulate depression of the skin.
    In real life tight garments deform the body, so in traditional conforming tight garments must poke-thru to look realistic unless the conformee is morphed to suit.
    That being said, the garment install script could inject a morph.

  • @fverbaas having just played with Callbacks to simulate gravity on a hair prop by transforming it's WorldMatrix into Euler angles for heading (Y), pitch (X) and roll (Z) rotations of deformers controlling various hair strands, it's a huge drain on UI performance. Everything is much slower.

    All I'm having the callback do is to set the necessary keyframes if the Euler angles have changed, due to either a keyframe or parameter change.
    Once I've stepped through all the frames I want keys set for, I can issue a scene.ClearEventCallback() to stop the script processing, whereupon the UI goes back to normal responsiveness.

    So, no, I'd say it would render Poser unusable, considering how many hundreds of morphs and transforms I already have slaved with valueOperations that don't degrade the UI performance noticeably. At least given my typical scene has ~50 figures in it, two of which are fully morphed V4.


    Rereading what you posted, I may be misunderstanding your point. I understood what you termed 'shadow' to mean what I've called 'slaving', which I do with ERC. It would certainly be possible (though I've built it directly into the figures) to have a script be told which was the master and which the shadow/slave figure, and then have valueOperations applied to essentially manually conform the slave's transforms and morphs to the masters'. Callbacks don't need to come into that at all, as the valueOperation performance is pretty good already, IMHO.

    I can't see the point of an opacity map. Ray tracing will not display anything behind an opaque surface anyway. Ambient occlusion is already build into GPU hardware and the render engines.

    The clothing deformation of skin surfaces is, I believe, an application of soft body dynamics, though unless you have a high enough subdivision level or mesh density, the effects you get might not look realistic. I've a feeling that vendors of tight fitting clothing have already taken up the challenge of clothing effect morphs on the base figure, but again, will that be to the level of detail one sees on one's own skin after removing tight fitting or elasticised clothing. Perhaps, though that would require a lot of work, such displacement could also be done through materials on the base figure, though having a clothing displacement map adjust to the possible changing position of a bikini string sounds like a bridge too far, at the moment.

  • @wimvdb submitted.

    I don't remember there being a 5k limit in the email text on previous bug reports, though (excluding attachments)! When did that happen? I know that every single time I submit a new report I'm going to be asked for detailed system information, so trying to include it in a 5k limited email leaves very little room for description of how to replicate the problem.

    Maybe they're having to feed non-English bug reports through Google translate (or vice versa), or something with a free content size limit?

  • @anomalaus said in Gauging response to a change request:

    Everything is much slower.

    Was afraid that would be the case. Thank you for trying.

    All I'm having the callback do is to set the necessary keyframes if the Euler angles have changed, due to either a keyframe or parameter change.

    I do not know the exact effort associated with setting keyframes but if it includes re-interpolation it could be computationally heavy. I was more thinking of the pretty simple things like setting the 'shadow' to follow the lead with a 'slack' in the control (say wide pants following a leg), to make a hysteresus or a multi-dimensional limit function. Basicallly do computational things with 'if' switches and multi-parameter input. (yes I know I have to be aware of recursion)

    Callbacks don't need to come into that at all, as the valueOperation performance is pretty good already, IMHO.

    As said, yes but the system does not support branching.

    I can't see the point of an opacity map. Ray tracing will not display anything behind an opaque surface anyway. Ambient occlusion is already build into GPU hardware and the render engines.

    My bad. Was both mixing things up and trying to be correct at the same time. Maybe should have used word transparency map. On conform (well slave, shadow) of garment make body surface parts of conformee/master/lead inside garment invisible by plugging a transparency map into the relevant skin shaders of the lead. Nothing to do with callbacks but addon kicking in when deleting the garment. We want to see the whole body again.
    I should have left it to be another discussion.

    The clothing deformation of skin surfaces is, I believe, an application of soft body dynamics, ...
    ... Perhaps, though that would require a lot of work, such displacement could also be done through materials on the base figure, though having a clothing displacement map adjust to the possible changing position of a bikini string sounds like a bridge too far, at the moment.

    Agreed moving strap wil not work, but skin depression due to waistbands, bra cups, and the like do not move but could be done via same principle as I painted for the visibility. In general make temporary modifications to the 'lead' on conforming/slaving/shadowing and unload in delete.

  • @f_verbaas the first problem is that callbacks don't get a look-in unless the system is idle, so the script waits until the bending calculations are done, then sets keyframes, which triggers another round of bending calculations. As I understand it, interpolation only happens for parameters that are not keyframed, and should be really quick for parameters with no subsequent keyframes. Callback scripts also should never need to handle interpolation themselves, they can just ask Poser for the current value of a parameter. What comes back will either be a keyframe plus valueOperations result, or interpolated plus valueOperations.

    Shape following with hysteresis has been done in a fashion by Ockham, with his Jiggles scripts, but requires a lot of setup and experimentation to determine appropriate morph strengths. I think that may have even been written prior to dynamic clothing, and certainly long before Bullet Physics was available, which is probably a better choice, though both of those simulators account for momentum and gravity effects.

    If by 'the system does not support branching' you mean that valueOperations cannot drive logical alternatives based on initial inputs, that is incorrect. The difficulty is that it requires additional hidden parameters to be created to store intermediate calculation results, which can then be multiplied by a zero or 1 determined by another state calculation. Using limits, and scaling inputs by large amounts, an intermediate parameter value can act as a greater-than or less than switch. It's just like doing binary arithmetic with Lego blocks. By the time you've done all of the simplest, one bit calculations, you have a huge pile of blocks. So far, the only things I've given up trying to do with valueOperations is modulo arithmetic. Too much ERC for too little return. I've even done valueOpKey interpolations for two whole cycles of Sine and Cosine to make an orbitable Dolly camera with an X-axis tiltable orbit.

    Again, with the garments occluding or shadowing the underlying figure, why bother adding complexity to materials when the RayTracer already does that with hardware acceleration. Rays stop at opaque surfaces. Hide the surface and the ray continues. You are correct in using the term opacity map, despite the reversed naming convention used on the Poser Surface root node which inverts the standard sense of white (1) being opaque (and hence the name opacity map) and black (0) being transparent. Logical naming conventions derive from the unitary case, not the null ;-). Dumbing things down for the users does everyone a disservice. Simplify by all means, don't mangle the language to suit the lowest common denominator. [Speaks the proud protector of the OED ;-) - See Mark Twain for the absurdity of unconstrained simplification for it's own sake]

    When we eventually (I hope) get micropolygon displacement in SuperFly, it is certainly worth looking into using a clothing mask with a blurred edge as a displacement map in a separate layer for the underlying figure. The mask can even be enabled or disabled (I'm not sure if material layer visibility is keyframe animatable - have to check) depending of the visibility of the clothing, provided the clothing has it visibility keyframed, which creates a referenceable parameter.

    If morphs are used on clothing to move straps, etc., those morphs can also drive UV deformations of a clothing displacement (I don't like to use the word "shadow" here, as it dilutes what shadow means) mask, depressing skin surfaces below clothing. All entirely possible now, but limited to high mesh density or subdivision to have enough vertices to respond to displacement masks accurately.

  • It's good to see a discussion before a bug report. That being said, don't let it get lost. It's OK to put things in mantis "for the greater good" .. making things easier is very important to me.

    • I want you guys to boil this down to a 1-or-2 sentence gripe so I can take note of it. What is the simplest thing that would be fixed or added to resolve these issues?

  • @h-elwood-gilliland the simplest summary of the initial posting, is that in addition to the existing afterBend flag, there is a need for an afterMorphs flag, which can be applied to deformer channels, in addition to the afterBend flag applying to deformers to force Poser to preserve calculation order when reloading a saved scene. The second part of the request is that these flags be accessible to Python, in order that scripts can re-order parameters as can currently only be done manually (and extremely tediously when scrolling hundreds of parameters) in the GUI.

    This is my suggestion for a way to preserve operational symmetry of saving and loading scenes. The save currently appears to preserve the calculation order present in the open scene, but loading the scene into Poser collects all of the deformer evaluations before the pre-transform morphs, which changes the effect and breaks working scenes on loading.