Got this door, and moving the pivot point seems to be impossible.

The Origin dials move the whole door, and the EndPoint moves the red cross. What am I missing?

I have the feeling that you will have to use the "Setup room"

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️

The setup room it is then.

It's swingin' now! Thanks for the tip Phil.

Looks like there is something goofy with this door (an OBJ exported from Maya), because the pivot can be moved just fine on a native Poser prop.

Yes! cool... ?

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️

Got a tip from a fellow Poser-ino:

The center-point can be adjusted right after importing the obj and before moving, scaling, or rotating it.

It's mui bueno now!

Thank you for that tip, now I better understand how to rotate some props that seemed to to a have a rather weird logic.... ?

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️

Sure thing Phil. With a program as complex as Poser, we learn something new every day.

Eronik posted at 11:23AM Tue, 08 June 2021 - #4420871

Sure thing Phil. With a program as complex as Poser, we learn something new every day.

Absolutely ?

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️

Normally I'd open set the view to wireframe or outline then set the camera to top view then open the joint editor. You can drag the green cross with the translate tool to the position you want it. Sometimes the red crosshair is right over the green, but if you drag on it, it usually grabs the green one.

Often the problem is that the geometry center of a prop is displaced (the center of the OBJ is not at coordinate (0, 0, 0)). You don't always notice this because the prop may have been moved to the center of the image with the dials.

This can lead to problems when processing such props further. Among other things, it can cause the prop to rotate around its parent in a strange way.

The following small Python script based on "NumThe script changes the vertices of a prop or actor, not just the poser coordinates.

If you start the script as is, the currently selected Poser Actor will be changed.py" remedies this. Here is the core:

    verts = NP.array([[v.X(), v.Y(), v.Z()] for v in geom.Vertices()])
    v_min = NP.array([NP.min(verts[:, X]), NP.min(verts[:, Y]), NP.min(verts[:, Z])])
    v_max = NP.array([NP.max(verts[:, X]), NP.max(verts[:, Y]), NP.max(verts[:, Z])])
    center = v_min + (v_max - v_min) / 2.0
    for pv, new_verts in zip(geom.Vertices(), verts - center):
        pv.SetX(new_verts[X])
        pv.SetY(new_verts[Y])
        pv.SetZ(new_verts[Z])

And here is a working script (save it under any filename ending with ".py"):

from __future__ import print_function  # Python 3 print function in Python 2
import poser
import numpy as NP

X, Y, Z = range(3)

def geom_ok(geom):
    return isinstance(geom, poser.GeomType) \
           and geom.NumVertices() > 0


def actor_has_geom(ac):
    return isinstance(ac, poser.ActorType) \
           and hasattr(ac, "Geometry") \
           and geom_ok(ac.Geometry())


def set_geom2center(actor):
    if isinstance(actor, poser.GeomType) and geom_ok(actor):
        geom = actor
    elif isinstance(actor, poser.ActorType) and actor_has_geom(actor):
        geom = actor.Geometry()
    else:
        raise AttributeError("Call this function with a Poser actor or geometry.")

    verts = NP.array([[v.X(), v.Y(), v.Z()] for v in geom.Vertices()])
    v_min = NP.array([NP.min(verts[:, X]), NP.min(verts[:, Y]), NP.min(verts[:, Z])])
    v_max = NP.array([NP.max(verts[:, X]), NP.max(verts[:, Y]), NP.max(verts[:, Z])])
    center = v_min + (v_max - v_min) / 2.0
    for pv, new_verts in zip(geom.Vertices(), verts - center):
        pv.SetX(new_verts[X])
        pv.SetY(new_verts[Y])
        pv.SetZ(new_verts[Z])


if __name__ == "__main__":
    set_geom2center(poser.Scene().CurrentActor())
    print("Done.")

The script changes the vertices of a prop or actor, not just the poser coordinates.

If you start the script as is, the currently selected Poser Actor will be changed.

---

Ups! Something messed up my post :)

Here is the top part again:

Often the problem is that the geometry center of a prop is shifted (the center of the OBJ is not at coordinate (0, 0, 0)). You don't always notice this because the prop has been moved to the center of the image with the dials.

This can lead to problems when processing such props further. Among other things it can cause the prop to rotate around its parent in a strange way.

The following small Python script based on "Numpy" remedies this. Here is the core:

---

adp001 posted at 1:30AM Wed, 09 June 2021 - #4420895

Ups! Something messed up my post :)

Here is the top part again:

Often the problem is that the geometry center of a prop is shifted (the center of the OBJ is not at coordinate (0, 0, 0)). You don't always notice this because the prop has been moved to the center of the image with the dials.

This can lead to problems when processing such props further. Among other things it can cause the prop to rotate around its parent in a strange way.

The following small Python script based on "Numpy" remedies this. Here is the core:

Thank you so much ?

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️

I wouldn't mind chiming in on a few things I've noticed with the joint editor.

Sometimes when you have the joint editor open and you're trying to translate the object center to a new position you'll find that for some reason you can't get the little bullseye cursor to appear when hovering over either the center or end point. The cursor will just stay stuck in whatever tool mode you had currently active before that point. An easy way to remedy this is to either click on or select another object and than reselect the the intended object. That usually clears it up and you'll have the bullseye cursor.

Also let's say you imported an object from some external modeler or you import a file not specifically intended for Poser's relatively tiny scale. Generally you want to import with one of poser's scaling options or prep externally with Poser's scale in mind. Scaling an object after the fact within Poser will invariably screw up any attempts to change it's origin with the joint editor as this will cause the entire object to translate in the workspace rather than just translating it's origin. You'll be wondering why your object is flying around when this happens...

Here's a sphere prop loaded from primitives; front camera, outline preview, joint editor open, default scale...

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

I change the center point by translating it to -0.049 in the Y axis...

It behaves as expected.

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

Ok. Let's try something different. I load the same sphere again but this time I scale it up to 200%

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

I then open the joint editor and try translating the center point in a like manner as the first sphere. Something different happens this time, the sphere object itself translating while I move the center point. Note the camera has not changed...

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

Here's an overlay of the before and after of the editing attempt...

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

One way to scale an object after import with the intention of adjusting it's origin after is to bake it's scale before even touching the joint editor. Scale the object to it's desired scale in Poser and then immediately export it as obj (all options unchecked) and reimport likewise, this will bake the scale as default and you can edit it's origin without that behavior.

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

I had a different idea. Changing (changing) the objects vertices instead of just doing a Poser scale. With the following script this is as simple as the standard way.

The following script creates a new parameter inside the currently selected prop/actor. This prop contains the height of the prop measured in centimeters. If you dial it, the prop will scale (or if you type in a value in cm).

Note: Poser scale dials are not affected! The geometry changes, not the dials. The prop/actor is flagged as changed, so Poser can take actions accordingly.

And now the fun part:

from __future__ import print_function  # Python 3 print function in Python 2

import sys
import numpy as NP

def actor_has_geom(ac):
    return isinstance(ac, poser.ActorType) 
           and hasattr(ac, "Geometry") 
           and geom_ok(ac.Geometry())

def get_props_height_pnu(actor):
    if isinstance(actor, poser.ActorType) and actor_has_geom(actor):
        geom = actor.Geometry()
        verts = NP.array([[v.X(), v.Y(), v.Z()] for v in geom.Vertices()])
        return NP.max(verts[:, Y]) - NP.min(verts[:, Y])


def get_props_height_cm(actor):
    return get_props_height_pnu(actor) / 0.0038145


def change_props_size(actor, scale):
    if isinstance(actor, poser.ActorType) and actor_has_geom(actor):
        geom = actor.Geometry()
        for pv in geom.Vertices():
            pv.SetX(pv.X() * scale)
            pv.SetY(pv.Y() * scale)
            pv.SetZ(pv.Z() * scale)
        actor.MarkGeomChanged()

__lastsizes = dict()  # storage to remember scales

def dynamic_height_prop(actor):
    global __lastsizes

    def cb_func(parm, value):
        ac = parm.Actor()
        iname = ac.InternalName()
        old = __lastsizes[iname]
        if old != value:
            scale = 1.0 / old * value
            change_props_size(ac, scale)
            __lastsizes[iname] = value
        return value

    if isinstance(actor, poser.ActorType) and actor_has_geom(actor):
        parmname = "Dyn Height cm"
        parm = actor.Parameter(parmname)
        if parm is None:
            parm = actor.CreateValueParameter(parmname)
        last_value = __lastsizes[actor.InternalName()] = get_props_height_cm(actor)
        parm.SetValue(last_value)
        poser.Scene().DrawAll()
        parm.SetUpdateCallback(cb_func)


if __name__ == "__main__":
    dynamic_height_prop(poser.Scene().CurrentActor())
    print("Activated.")

---

Forgott to copy the declarion of X, Y and Z. Put the line

X, Y, Z = range(3)

just before the fist line starting with "def"

---

This editor removed some important things nd I missed to copy something to.

Click here to download the tested script from my webpage.

---

What witchcraft is this?!

Just kidding adp... maybe I'm totally not getting this right but why does this feel like 'match centers to morph' sorta.

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

I see what it is now. It's a scale change but the scale dials are uneffected? So your changing the vert coordinates so wouldn't that be... a morph?

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

EldritchCellar posted at 3:19AM Thu, 10 June 2021 - #4420958

I see what it is now. It's a scale change but the scale dials are uneffected? So your changing the vert coordinates so wouldn't that be... a morph?

The objects vertices are changed. So it is not a morph. All further operations on the object are affected by the change. A morph is a set of additional data used to change the appearance while displaying it.

The script can be useful while developing something. After that the standard scales should be used.

I use something like that in the process of making dyn cloth (it's part of a bigger script with mutch more other things I made over time).

---

By the way: What I forgot to add to the script here is correcting the origin and the endpoint according to the new computed size.

---

Got it. Hope it doesn't "change" the winding order, wouldn't that be a surprise.

---

W10 Pro, HP Envy X360 Laptop, Intel Core i7-10510U, NVIDIA GeForce MX250, Intel UHD, 16 GB DDR4-2400 SDRAM, 1 TB PCIe NVMe M.2 SSD

Mudbox 2022, Adobe PS CC, Poser Pro 11.3, Blender 2.9, Wings3D 2.2.5

My Freestuff and Gallery at ShareCG

EldritchCellar posted at 2:11PM Thu, 10 June 2021 - #4420977

Got it. Hope it doesn't "change" the winding order, wouldn't that be a surprise.

It does not.

---

adp001 posted at 2:11PM Thu, 10 June 2021 - #4420951

Forgott to copy the declarion of X, Y and Z. Put the line

X, Y, Z = range(3)

just before the fist line starting with "def"

Thank you ?

𝒫𝒽𝓎𝓁

---

(っ◔◡◔)っ

👿 Win11 on i9-13900K@5GHz, 64GB, RoG Strix B760F Gamng, Asus Tuf Gaming RTX 4070 OC Edition, 1 TB SSD, 6+4+8TB HD
👿 Mac Mini M2, Sonoma 14.6.1, 16GB, 500GB SSD
👿 Nas 10TB
👿 Poser 13 and soon 14 ❤️