SuperFly volumetric breath/water vapour shader (Not clouds)?

  • Here's the prop (grouping object for placement, direction and scaling, and morphing sphere with animating volumetric scatter material). It requires the Poser 11 grouping object and primitive ball, as well as SuperFly materials. Just animate the Breath parameter linearly from 0 to 1 for each breath cycle.

    an0malaus Breath Prop

  • @anomalaus Thank you so much for this, I doubt I woill make animations, though you never know, but I'm sure the shader will be used, boiling pan / kettle etc!


  • I'm giving some thought to applying these props to an animation sequence, and while it's absolutely obvious how to deal with an essentially static figure, with only expression and minor limb movements animated, I'm not really sure how to go about major figure movement or orientation changes, in terms of prop placement. Does anyone have experience with a series of constraints in animation?

    Given the possibility that a single breath cloud may not evaporate before a subsequent exhalation, multiple instances of the breath props would be needed. In my current scene, I'm not parenting the grouping object to the figure's head, though it's placement is initially dependent, as I realised a turn of the head should not have any influence on the vector the breath prop continues to follow (using the obviously invalid, yet expedient assumption that the entire breath is emitted instantaneously). If it were parented, turning the head during the breath cycle would illogically move the breath prop to follow the head and would just look blatantly wrong.

    Yet I would want subsequent breaths to commence from the appropriate world location relative to the figure's head at that frame, so I'm thinking about how to achieve that with constraints. I suppose I could just have one set of breath props for each breath, but that seems completely wasteful of resources, when an individual breath prop would only be visible for a single, or small number of breath cycles, and then never be used again, whereas relocating and recycling a few breath props seems the obvious solution.

    So, each grouping object for a breath cycle needs to constrain itself to the figure's head's position at the current frame, and then hold that world position for the remainder of that breath cycle, rather than continuing to follow the constrained, head-relative position in subsequent frames. Unless I'm mistaken (and happy to be advised if so), this implies to me that I would need a constraint object parented to the figure's head, which can be constrained to at the first frame of each breath cycle. What I'm having difficulty working out is how to release that constraint and have the grouping object remain in place.

    How can I acquire the current frame position of an object and then transfer that position to another, static object which will maintain that position throughout subsequent frames, without resorting to Python scripting? I know that I can use a parent, zero relative position, unparent workflow to acquire a parent object's position on a temporary child object, but that process will kill or corrupt all previously set keyframed positions during the parenting and unparenting. It feels like I should be able to do this with constraints, but I'm not sure if that will work.

    Comments or advice would be most welcome, please.

    0_1520768175601_Screen Shot 2018-03-11 at 10.00.15 pm.png

  • Poser Ambassadors

    My first thought would be a particle emitter parented to her mouth.
    To deal with a previous breath still visible when it's time for another breath, I think it would be easiest to use a second particle figure/emitter.

  • @seachnasaigh okay, so that means a python script then, since I'm not aware of any particle emission system bundled with Poser. Any you'd care to recommend, before I just bite the bullet and write one to make use of the single particle per breath system I'm using, with SF Volumetric Scatter replacing a myriad of infinitesimal water vapour droplets?

  • Poser Ambassadors

    @anomalaus Bite that tasty bullet! P11 could use a current particle system.0_1520773283429_giggle.gif

    The last time I had need of particles in P11Pro, I ran Particles 3 in P7, saved the simmed particle figure as a PZ3 (scene), then opened that scene in P11Pro. It worked. I was able to render the particle effect in Superfly with. However, you can't re-simulate the Particles 3 figure in P11.

  • @anomalaus What you want is a constraint object at the mouth and another one for each breath object you want to animate. So lets say you want 4 breaths. You would need 5 constraint objects (Targets), Mouth, B1, B2, B3 and B4. So the Constraint at the mouth will move with the head and you start a breath object (say #1) with a constraint set to 1 at the mouth and the other constraint for that breath B1 set to 0. As the animation plays along the time line you make the mouth constraint move towards 0 and B1 move towards 1. This will cause the breath object to move between these two points. The only issue you will run into is as the mouth constraint moves it will change the path of the breath object. You can get rid of this problem by making a total of 8 constraints, M1 & B1, M2 & B2 etc. Make your figure animated and place a Mouth constraint at the location the mouth is on the frame you want to start a breath. Do the same at each location and you will have 4 breaths that will move along their own paths without changing the tracking because the mouth moves. Downside to this is you have to plan out your action ahead of time, or be prepared to move the Mouth constraints if you change the animation.

  • @seachnasaigh unfortunately, nothing older that P8 (PPro2010) will even run on macOS Sierra 10.12.6, since Apple orphaned hybrid Motorola/Intel architecture binaries, so I can no longer run Particles 3 or Wierd Juice's Drops.

    @richard60 I like the idea of constraints. I just need to verify that my theory of how to acquire the current frame position of a parent object and apply it to a child before unparenting that child will preserve the parent's position on the child, and a one constriaint per breath cycle plus another for the animated mouth position should work and be calculable by a python script, which can then be re-executed if the animation is changed.

  • @anomalaus Would the new 3D paths in P11.1 help at all with this?

  • @amethystpendant mmmmaybe...? Looking at the manual still leaves the question of how an object binds to the path and interpolates between waypoints. It's the same situation with constraints. I want the grouping object the breath is parented to, to be constrained to the mouth until the frame in which the breath animation starts, and then I need the grouping object to be unconstrained, but maintain the exact position and orientation (and scale) it was last constrained to. Then it needs to remain fixed until that breath cycle completes, so the vector isn't changed by continued movement of the head. As soon as the breath cycle completes, the grouping object can be constrained to the new mouth position until the next breath cycle begins (which may be only a single frame).

    I can't (yet) see anything in 3D path or constraint documentation, which can do the copying of position and orientation that's necessary. I may still have to resort to a simple python script to be run at the frames where the breath cycles start, to copy the world position and orientation of the constraint object to the grouping object and then zero the constraint parameter. (If Poser's Python API allows).

  • @anomalaus said in SuperFly volumetric breath/water vapour shader (Not clouds)?:
    (If Poser's Python API allows).

    Probably a no then

  • @seachnasaigh I've found @Snarlygribbly 's Particles3+ particle system which does appear to still work in Poser Pro 11.1, so I'll have a go with that and see if I can constrain it's particle emitter to the figure's mouth and use my material with it's PRT3_Life node as the driver for the Scatter Volume Density via some math transformations to match my valueOperation Key profile. I'll probably also see if the source code is amenable to taking into account Poser UI units setting so it's a bit less impenetrable.

    @amethystpendant unfortunately, there doesn't appear to be any way to identify either the constraint parameters or the constraint target actor or client from within Poser Python, as yet. (Attention @Poser-Team we need full Python exposure and operability for new features when they are released, not decades to never!)