Hi,
as far as I understood Poser manages each body part as an own geometry. When one exports it unwelded, then each body part is a seperate group with its own vertices.
In the preview and during rendering, I think Poser is working on a welded version( otherwise there would be splits on scaling, but the figure stays together even if you scale a single body part).
But how does it handle morph targets at the places where body parts come together. Each body part can define a movement for a border vertex, but as each body part has its own geometry, these movement do not collide. But for preview and rendering - which body parts wins to define the x,y,z coordinates of the point that is used by the rendering engine?
My assumption was only one body part can define the morphed geometry. But maybe Poser is smoothing them, or doing something else?
Thanks and best regards,
cc

Poser uses morphs for each body part. The seams however may be identicle and are welded. For morphs crossing body part boundaries you can link the morphs so altering one changes the other , or create a FBM, full body morph which does the same sort of thing. i.e one control dial that alters many parts.

The joint zones control the mesh deformation during joint movement.

and yes, Poser will do smoothing.

Hi, yes. I am talking only about the effects of the morphs. FBM/JCM etc. is another topic.
For a morph to be smooth, it must have identical move deltas on the vertices that are involved in a seam? I am speculating that the figures are welded in the UI, and some vertices are not taking part in the surface any more because of the welding. But I have no idea how to make sure :)

I'm glad to see someone tackle this. I would contact stewer who sometimes looks in here and writes code for Poser dev team. He might have insight or at least a name you could use to help solve this longtime issue.

My initial assumption was, that for body parts, the child part inherits the (x,y,z) coordinates from the parent for the vertexes that they share. however, unfortunately, this seems to be true only in 99,97% of the cases. A few figures have 1 or 2 single vertices for those this rule doesnt apply. Doh :/

mmmh, appearently there are ways to access the welding information through PoserPython.
there is a WeldGoals() function on the actors. this might be the key to this mystery.
yay ;)

Quote - Each body part can define a movement for a border vertex, but as each body part has its own geometry, these movement do not collide. But for preview and rendering - which body parts wins to define the x,y,z coordinates of the point that is used by the rendering engine?
My assumption was only one body part can define the morphed geometry.

This is what I have always assumed happens, though I have no special knowledge here, and may be wrong. The deformations (bending) at the joints is controlled by the join parameters (JPs). In the cr2 the JPs are the channels labelled "joint", "twist", and "smoothScale". I don't think Poser does specifically do anything to prevent the vertices from colliding. Rather the fact that they don't usually collide is a consequence of the sort of deformations, and restrictions on movement, introduced by the JPs, but the vertices can and sometimes do collide.

Quote - I am speculating that the figures are welded in the UI, and some vertices are not taking part in the surface any more because of the welding. But I have no idea how to make sure :)

At a welded seam, the vertices in the child will respect the position of the vertices in the parent, so that if the parent is morphed, the vertex positions in the child will be identical with those in the parent at the seam. A morph in the child will not affect the shape of the parent, or the position of it's own vertices at the welded seam.

Hi les,
thanks a ton for your 2cents. I think we have the same opinion about it.
With actor.WeldGoals(), I think I can query from python which verts are having a welded nature. I use this information to copy the morph delta from the parent to the child. As you said, the verts wont move for the child if they are welded to the parent.
BUT: I think the normals move still, and this can cause shading bugs.

You are correct on most accounts.  For the normal figures in Poser, each body part is a group of self contained polys and their associated vertexes.  Within the OBJ files, they are separate poly groups but are the same mesh.  When the OBJ is loaded in Poser, it breaks apart the mesh and duplicates the vertexes at the seam boundries.  It then re-welds the seams.

PhilC has a demonstration python script to demonstrate this:
http://www.philc.net/forum/viewtopic.php?t=3021

As for the morph questions, morphs move vertexes not polygons.  If you have a morph that moves a vertex in Part 1 to 0,0,1 and  a morph that moves it to 0,0,2 in Part 2, I believe that Poser will average the two positions for the vertex.  This will result in seam distortion.

For morphs that involve border vertexes, its best to weld the mesh and do the morph.  This will insure smooth seams.  You will then need to break apart the mesh and load each obj as a MT for the corresponding body part in poser.

For linking morphs, its simple as adding a few lines to the CR2:
            valueOpDeltaAdd
                Figure 1
                hip:1
                Thin
            deltaAddDelta 1.000000
In this case, this is from a bikini I made for K4.  This comes from the Thin morph on the thigh.  In this case, its linked to the Thin morph in the hip using a 1 to 1 ratio of movement.  The deltaAddDelta line defines the connection ratio.  For normal morphs you will typically use the 1:1 scenario so in the example above, the Thin morph is applied equally to both the thigh and the hip.  This is known as ERC or EasyPose.

If you want to form a curve in a tail or rope, each morph links to its parent using deltaAddDelta 2.00000 ratio, or a 2 to 1 movement. For each ONE increment of the parent, the child is applied at TWO increments.  Since each is a daisy chain from the prior, it will form a curl.  This would likely be applied to a twist, bend or scale parameter dial.

You can use the Poser 7 morph tool to morph vertices of a child actor away from those of the parent, at the weld seam.  The result can be ugly rendering artifacts, where this has happened.  It doesn't look like Poser averages the positions, in such cases or, if it does, the results are unpleasant.  It looks like the parent vertex at a weld is dominant, setting the position.  But the child vertex's position apparently contributes somehow to normals calculations at render time.

You can sort of test the parent-child morph behavior at welds by welding two identical geometries, so they overlap completely and end up with welds for every vertex.  In such a case, both actors will respond to deformations only of the parent actor.  Morphs in the child will be deactivated unless "Bend" is turned off for that child.  This seems to verify that the parent vertex at a weld will dominate.

I'm not sure how things might sort out in the case of "illegal" welds, between two actors which don't have a parent-child relationship....  :unsure:

Edit:

Thinking about this, it probably relates less to the actual actor-level parent-child relationship, than the way the "weld" listings are set up in the .cr2.  There's an implicit parent-child relationship set up there, regardless of where the actual actors may fall within the figure hierarchy.

Its all crazy.
But what is the "correct" way for a morph target to look like at these welded vertices.
What must be done so that the morph is really "smooth".
I noted assigning the same morph target delta to the welded vertices in the different actors seem to OFTEN make a smooth morph, but somehow, not always :(
I really wonder how they compute those normals :(

Are you sending the two vertices to the same location, then calculating the deltas separately for each, or are you calculating the deltas for one and then applying those to both vertices?  How are you setting it up?  If you're assuming both weld vertices will be in the same place when the calculations are handled, maybe that assumption is the problem? 

Actually, first i was doing the first.
Because it was not good enough on some occasions, Then I added code to do the second.
It seems in some situtations the first brings the best results, in other situations the second.
The sort of feeling I have if the morph is local and small then applying same delta to both vertices is best. If its a full blown deformation of the whole body then the first approach is better. But maybe my example of a FBM is too extreme (i morph a pose into another pose). If I look at the morphed figure in the zero pose that is really looking odd.

I had hoped there is kind of a theory that clearly determines what has to be done.

You could still try simply not setting any deltas at all for the weld child vertices, at the weld seam.  If the parent sets the position, any child vertex deltas should be unnecessary, only running the risk of complicating matters.  Maybe. 

Poser has the gremlins, as I've stated many times.  :lol:

Thats also worth a trial. I had assumed if the delta is the same, then the normal would be.
But I did not try with 0.0, that could be interesting.

Hmm unfortunately this seems to not be it. It creates very beautiful artifacts at the seams, though :-).
Goddamned, there must be a solution for this :D

You might try calculating both parent and child deltas separately, then averaging the two and setting the same for both vertices, perhaps. 

I don't know if this might help show somehow what Poser is doing with welds at render-time, but maybe.  Apologies if I'm veering OT and emphasizing the abstract question with this.

The cape in the attached image is an unusual figure, which has the inner cape (front) welded to the outer cape (back).  In the full figure render at the left, the dark lines showing up on the cape are places where the front and back have been welded, to create the effect of seams.  Some unusual things happen here, as shown by the various renders on the right.  The back is the weld parent here, the front is the weld child.

In the full image on the left, there is no back-lighting and the cape back is in shadow, creating the dark lines on the front.  When a back light is added, the top-left image of the four on the right shows that the new lighting on the back actor bleeds through to the front at these weld locations.  The lighting for the weld parent vertex is dominant.

The top-right image shows what happens when the "Remove backfacing polys" render option is used on the figure.  The cape front polygons at the weld seams disappear.  Poser considers those to be back-facing polygons.  The weld parent has dominated fully in terms of how the normals are determined for rendering.

The bottom left image shows the cape back hidden.  The weld seams are completely relaxed and now they render properly as facing forward.  This is similar to the effect seen in the bottom right image, where "Bend" has been turned off for the front actor, the weld child.  The seams vanish completely.

Apologies again if this trends off topic.    I thought it might help present some new, potentially useful  information about how Poser handles welds.  :unsure:

Hm... I made a checking script and let it eat some FBM's contained in DAZ's M4.
Tried with "FBMHeavy" and "FBMBeerbelly".
And indeed, the children have exactly the same morph delta values on the shared vertices than their parents. Unless my check code is wrong, but I hope not.
So my conclusion for today is that this is the way to go, and there are limits I have to accept and situations where bad shading has to occur because the morph is so extreme.
Ah well.

P.S.  I am thankful for every input you give cage. Your post came while I was writing ;). You did many things that are pretty much impressive :D

Quote - P.S.  I am thankful for every input you give cage. Your post came while I was writing ;). You did many things that are pretty much impressive :D

Just as long as I'm not taking your thread too OT.  :lol:

It's rotten that there's no evident solution.  Poser's handling of welds  can be immensely frustrating.  :cursing:

The behavior will depend if the figure mesh is welded or not. If the mesh in geometry folder is welded then a vertex shared by two body parts is exactly the same and so any morph, deformer or bending applied to one body part common vertex will be tracked by the other body part just because it is the same vertex.
If the mesh is not welded each shared vertex are two vertices and deforming only one body part will break easily the mesh.

PoserPython provides access to welding information. By evaluating it, I hope the path is clear.
BTW.
Does anybody now whether one can store python modules somewhere in the library, so scripts in ScriptsMenu can find them?

Hm... back to the original topic:

It seems to me that while welded child vertexes respect the parents position, they still have their own normal vector.

My assumption is, if the parent and childs normal vector are different, there are shading artefacts created.

Can one create joints that affect only one of two connected body parts? If the original mesh is welded, and poser splits the weld internally, is it possible to make joints that move just the vertex that is belonging to either the parent/child? I thought for scaling this might be possible, wasnt sure though.

Quote -
Can one create joints that affect only one of two connected body parts? If the original mesh is welded, and poser splits the weld internally, is it possible to make joints that move just the vertex that is belonging to either the parent/child? I thought for scaling this might be possible, wasnt sure though.

If you remove the child's joint affectors from the parent's listing, in the .cr2, you can prevent the child from deforming the parent at a joint.  I've never examined such a case specifically to see how the weld seam is affected. 

You could also set up a joint using the falloff zones, then position the zones in a way that prevents one of the actors from being affected by the joint. 

Yea, I thought with the zones, if the original mesh was welded, the effect of the joint would be "in harmony" ;-) an everything affected the same way.

In the meanwhile, I checked the morphs the P8 morph brush creates: And they also seem to maintain identical values at the welded verts.

The funny thing is, I often have situations where letting my program move each vertex on its own, welded or not, makes morphs that are not "in harmony" at welding points but produce a much better shading. However, in other situations, the contrary is true.

Also, I have trouble telling the poser support what my problem is.
I assume, the "default" way is to have a morph that has identical values for welded verts, and the shading errors that seem to occur in extreme poses are, well, bad luck. But they seem to not want to tell me a clear statement.

Quote - Yea, I thought with the zones, if the original mesh was welded, the effect of the joint would be "in harmony" ;-) an everything affected the same way.

I'm not sure what you mean, with this.  Is there a special case you're working with, as an example?  I was addressing your earlier question rather abstractly....

Quote - Also, I have trouble telling the poser support what my problem is.
I assume, the "default" way is to have a morph that has identical values for welded verts, and the shading errors that seem to occur in extreme poses are, well, bad luck. But they seem to not want to tell me a clear statement.

I doubt this counts as a bug, but as long-standing normal behavior for Poser, which just happens to be a bit screwy.  :lol:  My experience when reporting such things to Smith Micro is that Customer Support doesn't necessarily seem receptive, but they will pass the information on to the development team (or so they tell me) if you can explain why there's a problem, how to recreate it, and what the benefits of fixing it might be.  Whether the programming team will actually address something like this, which may go back to the earliest core code of Poser, is uncertain.  But it's worth a try!  :laugh:

With "in harmony", i meant that both vertices that are joined in the weld have the same morph target delta. I tried a bit more with the Poser-8 smooth-morph-brush, and I managed to let it set different values at the involved vertices. So there seems to not be a best solution. I guess its pose-dependent, and one has to find settings that work good in most cases.

And yes I agree, this will hardly count as a bug in the eyes of the support ;).

I will try another experiment. Maybe WorldNormals() can be used to study the effect of morph target deltas on the normals. With lots of luck I can apply my algorithm to the normals in a similar way as to the vertex movement in the morph. If that work, I could develop a script that generates a smoothing morph, which does not move any vertex taking activly part in the geometry deformation but contains just the morph deltas required to repair the shading dependend on the current pose.