An annoyance

Can someone explain why, if you have an object at 0,0,0 and you create a group while it is selected so that the group will contain it, why does the group end up with a location of x,y,z and the object ends up inside it at -x,-y,-z. Why don't they both just have 0,0,0 as their coordinates?

I usually remember to select the group and object and clear their transforms. It's just seems weird.

Comments

  • felisfelis Posts: 6,460

    I have never seen that happen. What is your process?

  • WendyLuvsCatzWendyLuvsCatz Posts: 41,366

    it happens to me too

    especially with clothed haired characters

    so usually create the group first then add the object

  • barbultbarbult Posts: 27,311

    Oh, Yes, this happens a lot.

    This is what I think DS is doing: The original item loaded has it's origin where ever the creator placed it. For example, a tree might have the origin set to the X-Z center of the trunk at ground level, or even above ground level, to embed the roots under ground. The Group that is created would be centered around the whole tree mesh. Then the Group coordinates are changed to keep the tree in the original position in the viewport. Then since the tree is parented to the Group, the tree coordinates are relative to the Group coordinates. The tree coordinates have to be adjusted to get the absolute coordinates back to 0,0,0, keeping the tree in the same place in the viewport. So, if the Group is created by Daz at 15, -10, 2, the tree coordinates are changed to -15,10,-2 to get the absolute tree position back to 0,0,0.

  • jmucchiellojmucchiello Posts: 1,901

    0. New Scene

    1. Create figure

    2. Select figure and create a group with it selected

    3. Check Transform parameters

    At the top of my image is the figure already loaded and showing it is located at 0,0,0

    The middle row is steps 1, 2, and 3.

    The bottom row shows the Group (left) and the figure (right) still at 0,0,0 but the transform parameters are complementary values (0.0048, -0.36, 0.80) and (-0.0048, 0.36, -0.80).

     

     

    Untitled.png
    949 x 1043 - 221K
  • garrett_3dgarrett_3d Posts: 754
    edited August 6

    Run a quick test as I've noticed this happen before. I think I've found a solution (in DS4 at least).

     

    Create new scene.

    Load character and zero translation (assuming you want it zeroed).

    Create Group and zero translation.

    Right click character and change parent.

    On parenting dialogue box, tick "parent in place" then OK.

     

    For some reason a new group doesn't create at absolute zero, it's a few cm off on Y and Z axis.

     

    Post edited by garrett_3d on
  • jmucchiellojmucchiello Posts: 1,901

    Fixing it isn't an issue. I know how to fix it. I want to know why it happens in the first place. The post title is "An annoyance" for a reason.

    Changing parent takes a lot of motion and scrolling. I usually select the group and the figure, select all in parameters. And then zero x, y, and z with alt-click.

  • WendyLuvsCatzWendyLuvsCatz Posts: 41,366

    probably the only ones who know why it happens is the developers 

  • exastrisexastris Posts: 10

    i have been awake for a very long time because of work so while i want to share what i've noticed, i am sorry if i do not make sense and ramble.

    origin points and bounding box size and what barbult said: the group has its own origin point so to keep it in relation to where the figure is in the scene when you place it within the group, there has to be some sort of calculation made.

    load a figure at 0,0,0. put it in a group. the group must encompass everything about that figure, so it is a slightly bigger space than the figure itself and the group's origin point loads in directly under the figure's origin point. the coordinates are now not at 0,0,0 for either but within the entire scene, your figure is still technically at 0,0,0. it hasn't actually moved but the world center it now must consider for coordinates is the group's, not the scene's.

    load 2 figures, move one far away from the 1st, put them both within a group. the group's origin is centered between them but they have not actually moved around in the scene. if you moved that 2nd figure on only one axis, put that at zero and it doesn't move to the scene's world origin but the group's.

    if you have one figure within a group but another not and change to solid bounding box view, the group is one big box. a figure not within a group is all the little itty bitty boxes that make the figure.

    this is why i like to pose characters together and then put them in a group because if everything about the pose is perfect except for where they're located, all i have to move around is the group, not each individual character, if i need to move their location from, say, the floor to the bed or one side of a room to the other.

  • This is simple to explain, 0,0,0, is relational, not absolute in this case, and the group's origin is based on the bounding box and not object origin.

    Load a primitive, and then apply a group to it, you'll see no change in the xyz translations. This is because the object loads at absolute zero and the bounding box is equal distance in every direction.

    Now, load Ally 9, then CTRL+D(Move to floor). She should move in a -Y Translation. In my case it was -0.29, which equates to the 0.29 of the group when applied without Move to floor.

    Basically, she loads hovering above the floor.

    I say it's in relation to the bounding box, as rotating her legs 90 degrees(Bend= -90) and then apply a group to her, the Y translation now equates to where the backs of her calfs are, and the "bottom" of  the bounding box.

    In my case that was 75.63, and ally showed -75.63, as her origin didn't move. The "gizmo" was stil at 0,0,0.

     

    Now, is it possible to "fix" this issue, yes.

    You'll simply have to go through each base figure and character preset, load them, determine their offset, then reset the values to actual 0 and overwrite the DSF files with the new definitions.

    This will wind up breaking stuff and i highly recommend against it.

     

    I'm now going to ask the "dumb" question, Why are you creating a group for a single figure?

  • WendyLuvsCatzWendyLuvsCatz Posts: 41,366

    ah yes,

    hairs especially are not symmetrical 

    at least not well made realistic ones

    outfits often are not either due to styles and things like scabbards, bags on one hip etc

    so the group will always be slightly of centre with such hairs and outfits on a figure 

  • jmucchiellojmucchiello Posts: 1,901

    The reason i care about groups is I only learned about ctrl-clicking the "eye" icon to hide all of a figure a few months ago. Since I work in G9, hiding the figure leaves hair, eyes, and a mouth floating in space if you don't ctrl-click. Putting the figure in a group means it's easy to hide the entire figure. My brain hasn't adjusted to the ctrl-click paradigm.

     

  • jmucchiello said:

    The reason i care about groups is I only learned about ctrl-clicking the "eye" icon to hide all of a figure a few months ago. Since I work in G9, hiding the figure leaves hair, eyes, and a mouth floating in space if you don't ctrl-click. Putting the figure in a group means it's easy to hide the entire figure. My brain hasn't adjusted to the ctrl-click paradigm.

     

    Don't feel too bad, i've been working with DS for ~15 years or so, and had no clue about CTRL+Click till you mentioned it.

     Just thinking about it, i so rarely need to hide stuff in such a way that this would be a consideration.

     

  • WendyLuvsCatzWendyLuvsCatz Posts: 41,366

    I use both ctrl click eye icon AND grouping to hide stuff

  • jmucchiellojmucchiello Posts: 1,901

    DrunkMonkeyProductions said:

    jmucchiello said:

    The reason i care about groups is I only learned about ctrl-clicking the "eye" icon to hide all of a figure a few months ago. Since I work in G9, hiding the figure leaves hair, eyes, and a mouth floating in space if you don't ctrl-click. Putting the figure in a group means it's easy to hide the entire figure. My brain hasn't adjusted to the ctrl-click paradigm.

     

    Don't feel too bad, i've been working with DS for ~15 years or so, and had no clue about CTRL+Click till you mentioned it.

     Just thinking about it, i so rarely need to hide stuff in such a way that this would be a consideration.

    That's basically how I found out. Someone mentioned it in passing and I was like Whhhaaaattttt???? G9 requires it (or the group trick). First time I hid a G3 figure I was shocked the entire thing went away without a group. :)

  • crosswindcrosswind Posts: 10,094
    edited 1:54AM

    A Group's transform values are calculated based on the holistic bounding box of all of its 1st level children nodes, i.e. the exact center of the lowest position of the "whole bounding box".  If just Grouping a G9,  the data is only calculated based on that G9's bounding box.

    However, a bounding box per se is calculated based on the node's geometry, i.e. the vertex positions. So better not touch any DSF / DUF by modifying the related XYZ values (actually they're all 0...) ~

    So, if you DO want to "fix the issue" from an experimental perspective, a simple way is to set XYZ values on Ally 9 (in OP's case) by adopting the negative values from the Group's XYZ, export Ally 9 to OBJ, zero Ally 9's XYZ, import OBJ as a delta morph with Morph Loader Pro, ARtS.  Then group her again, Group's XYZ will be all 0 ~~

    Edit: Ctrl to Hide is already a good way on a single figure with children nodes, IMO ~ 

     

     

    SNAG-2026-8-7 0000.png
    2017 x 1297 - 238K
    Post edited by crosswind at
  • jmucchiellojmucchiello Posts: 1,901

    The real question is why isn't the bounding box for the figure 0,0,0. This is also why sometimes drop to floor doesn't quite work on some figures.

    And old dogs and tricks is the issue with ctrl-click hide.

  • WendyLuvsCatzWendyLuvsCatz Posts: 41,366

    the real question is why is moving the pivot point of anything such a song and dance requiring the bone editor, a script or some other duckery instead of just a key hold combination freeing the gizmo like other softwares

  • jmucchiellojmucchiello Posts: 1,901

    WendyLuvsCatz said:

    the real question is why is moving the pivot point of anything such a song and dance requiring the bone editor, a script or some other duckery instead of just a key hold combination freeing the gizmo like other softwares

    I can promote this to real status. Sure.

  • crosswindcrosswind Posts: 10,094

    jmucchiello said:

    The real question is why isn't the bounding box for the figure 0,0,0. This is also why sometimes drop to floor doesn't quite work on some figures.

    And old dogs and tricks is the issue with ctrl-click hide.

    I don't know~ Maybe Daz can answer the question since all the Base figures have this issue.

Sign In or Register to comment.