An odd day when one can't decide if something is a feature or a bug



  • Poser Pro 11, default settings, default scene with Andy.

    Add Hair / Poser 7 / Ben Hair - that's a dynamic hair; it will be parented to the head by default.

    Add Prop / Primitives / Square Hi Res, then parent it to Andy's body. Go to Cloth Room, new simulation, clothify the square hi res; Collide Against / check Ignore head, hands and feet, add Andy's chest. Close Collide Against.

    Open Collide Against again; it added the hair as a collision target by itself, without you selecting anything. Uncheck all hair elements, close and reopen again... there it go, it re-added the hair again, all on its own.

    It seems to do that all the time, for some specific kinds of props (it doesn't do that with say glasses, but I've seen it dong the same with other cloth props). I can't come to a conclusion if that's a feature in the product or a bug, although it seems very unhelpful to me as a feature, because I don't want the cloth to collide with the hair, but because it does that whenever my cloth simulation goes awry I always check first if Poser ninja-added a collision target behind my back...



  • Also I can't get the point of the thing always adding "Goal Center of Mass" and "Center Of Mass" as collision targets in dynamic cloth simulation.

    It's not like these things are a mesh, so I have no clue why they show in the cloth collision target list, to begin with, and then why it keeps defaulting these as selected, and when they are selected (or not) what does that do for the cloth simulation...

    Another thing I can't decide if it's an odd feature or a bug...



  • Parented items can get weirdly added to things, for some reason, especially parented hair items. I don't know if it's leftover functionality or some weird hierarchy thing.



  • Another thing I can't decide if it's a bug or a feature:

    Default document, delete Andy, add a Ball Hi-Res from Poser Pro 2016 library, change the ball to Display / Object / Wireframe so you can see it.

    You see the "north pole" of the mesh is up, and the "south pole" of the mesh is down. Nice. Now try to rotate Y to rotate around the north pole - it instead rotates around the Z axies. Strange! Now rotate Z, you get exactly the same thing. More strange!

    Then you notice the thing loads with default X axis = 90 degrees (so that "north" is up down "south" is down)... so it already comes Gimball-locked from the library, that's why you can't rotate around Y axis!

    So I set X = 0 in order to be able to rotate on Y. Now add a Tile texture; you'll notice the uv map follows the grid, which is, with zero rotations there's no north or south pole, but an ... err... "east" and "west" pole. So setting X = 0 will not do!

    But I won't give up! I want my sphere to rotate as planets do, around their poles, so i set rotX=90, rotY=0,rotZ=0 at frame 0, and rotX=0,rotY=90,rotZ=-90 at frame 30 (don't forget the Z is minus 90, not 90). That gets me out of gimbal lock, and it rotates, but it wobbles a lot - the wobbling is due to the fact that compound rotations are a complicated formula which will not under linear or spline interpolation.

    Of course this is easy to fix - I can either add a magnet with a constant zone around the whole ball and rotate the magnet, or I can export/import as OBJ to get rid of the original orientation of the mesh and get my own orientation with well-behaves poles.

    But yet I can't decide if SM's decision to deliver me a ball that by default is gimball locked, which I can't make it rotate like planets happily do, is a bug or a feature.



  • Oh, another solution is to set rotX=0, add another prop, make that prop invisible, parent the ball to the other prop, then rotate THAT prop with rotX=90. Now the ball will happily rotate its pole. But may be one of those things that may look complicated to a new user.



  • Another solution which I use a lot with messed-up props is to align the prop the way I want it to be, then go to the Grouping Editor, (create a new group called "All" when multiple groups exist) and then add ALL vertices to that group.

    Click "Create New Prop" et voilà: a new prop with the UV mapping unscathed, but the xyz axes zeroed and in compliance with the "Universe".
    For some props you now might wish to modify the centre to a different point because Poser invariably places the centre in newly created props in the centre. So if it's a door you need to realign the centre with the hinges.

    I use this technique frequently when props were created in angled positions and I want them to be aligned properly, but you can use it also to get rid of gimbal lock.

    Don't forget to save your fixed prop!

    Karina



  • @karina said in An odd day when one can't decide if something is a feature or a bug:

    Another solution which I use a lot with messed-up props is to align the prop the way I want it to be, then go to the Grouping Editor, (create a new group called "All" when multiple groups exist) and then add ALL vertices to that group.

    Click "Create New Prop" et voilà: a new prop with the UV mapping unscathed, but the xyz axes zeroed and in compliance with the "Universe".
    For some props you now might wish to modify the centre to a different point because Poser invariably places the centre in newly created props in the centre. So if it's a door you need to realign the centre with the hinges.

    I use this technique frequently when props were created in angled positions and I want them to be aligned properly, but you can use it also to get rid of gimbal lock.

    Don't forget to save your fixed prop!

    Karina

    Good idea; appreciate the tip!



  • @fbs7 as you're using Poser 11, instead of just using another ordinary prop, try creating a Grouping object. I use one as a parent for a square prop with a paraboloid morph which acts as a light focusing mirror, much like outdoor glamour/sportswear photographers would use to illuminate the shadowed side of the model. I create master valueParms on the square to control the Y rotation of the grouping object through valueOperations, leaving the square to rotate about X and Z axes with no risk of gimbal lock. I believe that gimbal lock avoidance is also a compelling reason for figures to have separate Body and Hip actors.



  • If you look in the hierarchy editor, you will notice that when you parent something to a figure, it becomes part of the figure. It will be listed as a child to whatever part of the figure you parented it to. So when you do a cloth sim you have to check each part of the figure separately, and you will have to go through and uncheck the hair. It's a pain in the butt, I know.



  • @rokketman said in An odd day when one can't decide if something is a feature or a bug:

    If you look in the hierarchy editor, you will notice that when you parent something to a figure, it becomes part of the figure. It will be listed as a child to whatever part of the figure you parented it to. So when you do a cloth sim you have to check each part of the figure separately, and you will have to go through and uncheck the hair. It's a pain in the butt, I know.

    Correct, but why it keeps re-selecting the hair as collision target, and not say a hat or a ring? I would understand the rationale for that behavior if you selected or unselected once, and then it would leave it alone, but for hair the thing has a tendency of selecting it again on its own based in some action that I don't understand.

    Now, here's a similar action that I kind understand (although not much); set Ignore Head / Hands / Feet collision, then unselect all body parts and select only the chest.

    Now close that, reopen, it still shows only Chest as collision target. Nice. Now unselect "Ignore Head collision s", and reopen the collision targets... it added the Head as collision target on its own. I kinda get this behavior, but for the life of me I don't understand why it does a similar thing with hair.



  • If I've understood correctly, we're talking about prop hair here, not conforming?

    If so, maybe the strange handling comes from some internal Poser procedures about prop hair:
    Remember that the files for prop hair vs. ordinary props only differ in one distinctive line in the file:

    Instead of
    "prop SoAndSo"
    it invariably states
    "prop figureHair"

    You may also have noticed that if you load a new hair prop, the present one gets replaced with the new one - you can't load two "figureHair" props at the same time!
    So this must be some sort of internal Poser code which triggers a special behaviour.

    Try this:

    • Option #1: (in case you want to terminally convert all the prop hairs in the "Hair" folder)
      Replace all "prop figureHair" occurrences in the .hr2 files with "prop chooseAnyName".
    • Option #2: (works well for converting "on the fly", and quick testing)
      Go to the Grouping Editor with the prop hair selected, create a new group "all", the "add all" polygons and "Create New Prop".
      You now have a new hair prop.
      Parent it to the head and save it to the "Props" library as "smart prop".

    In both cases you'll get a normal prop and you can load as many of them as you like without them getting replaced by the next one.

    Maybe this "special treatment" of "prop figureHair" is also the culprit for the strange collisions?
    Maybe Poser considers "prop figureHair" as a body part?

    Try to convert a hair prop to a regular prop as described above, load it and see whether the problems still persist. (My guess: They won't!)

    Sorry for getting a bit long-winded :/

    Karina



  • @fbs7 Had this problem a time or three. A workaround I've used is to hide the props or other items I don't want included in simulation, during simulation, invisible items are ignored even if they're included in the collisions list.