Using a Parameter Dial to select which face of a PP2 die (dice) is upwards ?

  • Ouch!

    I just looked: that's 480 lines of dependencies code for the six-sided die only :O

    And, since animation w/ bullet physics was mentioned earlier:

    You can't control which side ends up top (after all, that's the intended purpose of this thread).
    But all calculations and dependencies only work properly from zero position of the prop!
    So before you're able to dial in the number, you first have to zero the prop (e.g. bring the correct default number back to the top face), meaning to make offset calculations necessary depending on the current rotation values.

    Also remember that your die won't land exactly aligned rectangular in the y axis!
    So before recalculating your x and z rotations you first must set the "y" rotation back to zero (but you first have to find out which axis of the die actually aligns with the Unverse's y axis).
    After you've dialed the right number on top you have to find out again which axis of the dial aligns with the Universe's y axis, and then rotate the die back to the original y orientation it had as it fell...

    Though I believe it still can be done for a six sided die (though probably with another 500 lines of code), I doubt that it could be done with any reasonable amount of dependency calculation on a 20 sided die because you not only encounter 90 degree rotations there, but also odd angles in between: and then hell opens up!

    While I DON'T doubt that a mathematician would be able to calculate all the rotations necessary, I definitely predict that it's far from what you can do with Poser's dependent parameters. Maybe a python script, yes.

    Finally, about the idea of doing it with morphs:

    That could be done eventually (provided you solve the problem of realigning the die properly after it's tossed and landed with a different orientation).

    --> But then, morphs work linearly:
    You can't simulate rotations with a morph, because the vertices will move to the new destination in a straight line. So "morphing" a 180 degree rotation would only mirror the prop relative to the rotation axis: Top planes will move to bottom, and bottom plane will move to top. Normals will thus be inverted too.
    The side planes would be turned upside down instead...

    B.t.w., did anybody dig into the possibility of using "altGeom" instead?
    I didn't try yet and don't want to because I only played with it a few times before, so I'm no expert.

    In the end it's all a question of "why do you need this" vs. doing it manually with Poser's "Direct Manipulation" Gizmo vs. the system load of three poor dice with 1000+ lines of code each.

    However, it's an interesting challenge; curious of what else ideas you come up with.


    I still can't figure out how a 20 sided die would look like. Anybody has a model which he can share? (Or at least a picture)
    Thank you.

  • @anomalaus - that's the sort of solution I was originally thinking of, but I just couldn't see how to get something like that to work. I'll have to look through your code a few times to make sure I'm clear, and I'll give it a try. Poser 6 runs on my system, so that'll be my test.
    And I knew I'd seen the actual rotation order displayed somewhere on the UI, but convinced myself I was thinking of DAZ Studio. So it's the Joint Editor pane.

    @karina - Regarding "why do you need to do this" - I recently did a render of a role-playing game in progress ( ) using a freebie set of RPG dice ( ). I wanted to change the up-face on each die, but realized that I'd have to manually adjust the rotations of each. As a user I thought "having a parameter dial to set the up-face would be great". Then I started looking at how to do it, and here we are!

    While a couple of thousand extra lines of code in the PP2 for a 20 sided die is a lot, if that allows me to easily select which face is up (for a single frame still image) without having to fiddle with the rotation dials individually then the overhead's acceptable for me.
    And I'm not really concerned about the die being aligned with the axes, just which face is uppermost. So that's not a concern for me either. Although if I wanted to rotate the die around the y-axis once I'd selected the face that's uppermost, then that does become a concern.
    Animation and bullet physics was introduced in bagginsbill's comment - it hadn't even crossed my mind (I never do animation). I like bagginsbills animated material parameter solution for this, although as pointed out earlier the face numbering changes dependant on the up-face selected.

    A separate PZ2 file for each number is also a good option, but if the user wanted to y rotate (in world axes) the die then they still have to manually fiddle with the three rotations.

    Considering morphs or altgeom I guess (even though I know nothing about it) that both of those should work with bullet physics animation. To me altgeom (if it's possible) would make more sense than morphs. I haven't tried eitheryet.

  • @karina A 20 sided die would probably be somethng like an icosphere.

  • Yep that's it - real world icospheres/icosahedra ! They have a wonderful feel to them.

  • @karina Yes, it's a lot simpler with valueOpKey.

    I would suggest that any physics animation be done with a render-invisible wireframe object of the desired shape and then interpose a grouping object (in P11) or other dummy prop (pre P11) between that and the final render object as child actors to de-couple the rotations and eliminate gimbal lock entirely. If the middle rotation is done on the grouping object/dummy prop (and can be driven by valueOperations from a dial on the visible die) then the other two axes can never coalesce and will always be orthogonal.

    Fully agree about the morphs. Linear interpolation can never substitute for actual rotations.

    AltGeom, unfortunately, is absolutely nicht und verboten on unimesh figures. Replace parent with prop is the way to do that with unimesh, though I've not tried. I usually just animate the visibility of the parts I want replaced and drive those parameters with valueOpKey.

    Thanks @3dcheapskate for the links.

  • @anomalaus said in Using a Parameter Dial to select which face of a PP2 die (dice) is upwards ?:

    I would suggest that any physics animation be done with a render-invisible wireframe object of the desired shape and then interpose a grouping object (in P11) or other dummy prop (pre P11) between that and the final render object as child actors to de-couple the rotations and eliminate gimbal lock entirely. If the middle rotation is done on the grouping object/dummy prop (and can be driven by valueOperations from a dial on the visible die) then the other two axes can never coalesce and will always be orthogonal.

    This sounds a good approach. I recall having problems saving (or deleting) a 'parent prop + child prop' combination - only one of the two props was saved/deleted. I think there was a certain technique required to get it to work (maybe involving manually editing the PP2) ?

    ...AltGeom, unfortunately, is absolutely nicht und verboten on unimesh figures...

    But the dice aren't unimesh figures - they're props. I had a look at Kuroyume's CR2 spec again and it seems to indicate that altgeom works on props (edited extract below). So altgeom definitely seems to still be an option - not necessarily a good one though.

    actor|prop|hairProp <part name>:<character number> 
    	name <name|GetStringRes(1024,<int>)> <on|off> 
    	[alternateGeom <name> 
    	... more alternateGeom sections 
    	defaultGeomName GetStringRes(1037,N)]

  • @3dcheapskate you are absolutely correct about the irrelevance of unimesh to props. I was only mentioning it as when I finally got to the point of deciding to just subdivide all the figures and clothing I was using, I ran across the necessity to convert them all to unimesh as a prerequisite for subdivision (again only relevant to figures) which A) immediately broke every piece of altGeom I was using on those figures, and B) even broke one of the figures whose geometry was so disconnected in places its UV mapping broke if subdivided at all.

    IIRC, Kuroyume's document came out before unimesh became an option in Poser and hasn't been updated since. Poser certainly deprecates and purges all of the GetStringRes() references when saving to the library. Pity SMS don't publish a specification of the file formats the way DAZ at least attempted to do with DSON. At least then one could compare the specs and see what won't be supported in older versions of Poser.

  • Had an hour to while away today so I made the pose files for the D6 die.
    A nice extra is that the die will keep it's rotation around the y axis because it sets the orientation according to the rotations.
    The pose files for other die types would look exactly the same, just different rotation values of course.

    For the poses to work correctly the original geometry must have the "3" facing upwards and the "6" on the front (z+) side. If your prop has a different orientation, change it with the Joint Editor.

    [0_1507387166300_Roll Dice](Uploading 100%)

    I can't get the file to upload; any ideas?
    Is it allowed to link to external hosting?

  • @karina yes, external links are the way to go. I use, which is free, but others will work as well.

  • Thank you anomalaus!

    I just returned from the weekend at *** and try to catch up.

    I'll upload the dice to "Zippyshare" which IMO is the best (and works with TOR too).

    However I still have a few questions to be answered.
    The main problem is about "animated" bump and displacement nodes, which shall follow the die's scale in order to keep relative values:
    "Bump/Disp values coupled to actual scale of die".
    So if you scale the die the default value will be adjusted according to the set scale automatically.
    It woks as intended as long as you load the original prop.

    But as soon as you try to apply a different texture (no matter whether it's .pz2, .mt5, .mc6 : It just discards the dependencies (PP2014 SR3)

    I found a workaround, but it's still acting strange (sometimes you'll have to click the MAT file TWICE to make the dependencies work!).
    Still fiddling with it.

    I'll be more specific once you have my version of the dice for download, so, laters.

    I'm a tad tired tonight ...


  • @karina yes, in PPro2014 the first application of an animated material clears the dependencies and the second re-applies them. Weird. I also notice that dependencies tend not to get saved or apply properly from .mt5, while they do save and work better from material collections, at least in P11. There are other features which require double application to work properly, like workspace layout dots when one has dual monitors. It takes a second click on the dot to move things like the Raytrace Render Preview window back to the second monitor.

    Scale is an especially problematic property in Poser. I had to resort to creating my own, hidden UnitScale parameter which I set appropriately with a python script by reading Poser's own preferences file. In that way, I can have non-translation parameter dials (which automatically display in the preferred units) containing measurements like depth of field or focus distance for cameras by dividing their internal value by the UnitScale (1 for PNU, 2.62128 for metres, etc), so when they're saved to the library, they are forced into PNU as happens with the translations. Oh, that reminds me, I need to request that feature from SMS: a way to define parameter dials as using display units.

  • 0_1507569782600_Die 6-sided (render).png

    Thank you for the insights anomalaus.

    In fact I've encountered some of the same problems (and others), but gladly I could solve most, or at least figure out a workaround.

    In this example I've got the problem of the dice's yRotation solved by just realigning the xyz orientation after "tossing the dice".
    So now the procedure is straightforward:
    Load the die, make it show your desired number on top with the injection, and you have a die without gimbal lock, and all axes reset as they should be.

    However one thing still makes me lose my hair:

    Scaling with bump/displacement values automatically adjusted by shaderNodeParms!
    With just one prop in the scene it works fine.

    The problems start when you change the texture (per .mc6 injection)
    and it gets worse when you load a second die into the scene:
    "Posing" the numbers works fine, as well as applying a different texture.
    Unfortunately the shaderNodeParms now go totally bonkers (also see below in the copy of the ReadMe file).

    This is definitely something that SM must work on!


    ReadMe file follows (included in download):



    THIS IS NOT FOR REDISTRIBUTION, only testing purposes!

    For easier testing I kept all necessary files in one folder structure;
    put this folder where you like.


    A simple prop made from a primitive because the die in the link
    has a crazy polycount (10.000something).

    The die comes with improved textures for the dots and displacement map.
    The UV layout is the same as in the other dice so that you can swap
    texture maps to your liking.

    After loading the die is exactly one metre large, to facilitate
    finding it at all, and for quick testing purposes.

    If you want a die of 1.5 cm, set the Scale(xyz) to 1.5 per cent.
    The bump and displacement values will be scaled accordingly when you
    change the Scale(xyz) dial.
    This was achieved by "animating" the dials in the Material Room.

    There's a set of poses included to bring the clicked die face on top while
    preserving the current orientation and rotation of the y axis.
    This is achieved by realigning the prop's orientation.

    Use the RESET GEOM pose to zero all rotations and restore
    the original orientation.


    You can choose from six different colours for the die.
    However, there's a problem with Poser when injecting these any of these:
    The "animated" dials for Bump and Displacement behave very strange.
    Sometimes you have to click the texture twice to restore the dependency.

    Another Poser weirdness:
    When I have more than one die in the scene, Poser always reads the scale
    value of the first die loaded and propagates it to the "shaderNodeParm"s
    of the other dice loaded later.

    I think the problem is in the code of the shaderNodeParms:
    Die 6-sided:1

    I suppose Poser doesn't recognize and upcount the :1 counter in line #3.

    I really wish Poser would adjust such critical values like Bump and
    Displacement automatically with the scale of the figure or prop.
    Could save people a lot of headaches and bad surprises.