say like this:

targetGeom 24box02
            {
            name 24box02
            initValue 0
            hidden 0
            forceLimits 1
            min -100000
            max 100000
            trackingScale 0.02
            keys
                {
                static  0
                k  0  0.72
                }
            interpStyleLocked 0
            indexes 8
            numbDeltas 26
            deltas
                {
                d 10 0.05835599 0 -0.05835599
                d 12 0.05835599 0 0.05835599
                d 14 -0.05835599 0 0.05835599
                d 15 -0.05835599 0 -0.05835599
                d 22 0.05835599 0 0
                d 23 0 0 0.05835599
                d 24 -0.05835599 0 0
                d 25 0 0 -0.05835599
                }
            blendType 0
            }

i understand the rest of the code, but "indexes" is something i don't get.  i've looked at it in different files i've set up.  if i change that number it throws a fault and poser closes, just on importing the file. 

this particular file is just a morphing box i was toying with that has 27 verts.  it's really just a square subdivided once.  the top and bottom morph inwards in x and z and the middle remains the same as well as the center top and bottom verts.

I have no idea. Probably just a coincidence but there are 8 d(elta) lines :-) 

Indexes is the number of elements in the delta table, in this case 8, you can count them.

NumbDeltas is the total number of vertices of this body part.

In theory there should be 26 deltas in the table (the same number as the vertices number), but as 18 morphed vertices have the value d 0 0 0 it are supressed remaining 8 deltas that are not d 0 0 0. This is done to reduce the table length removing useless information.

The value of indexes must match the number of delta entries. If you change to 9 in your case, Poser will read { as a number and { is not a number and who knows what Poser will do.

If you change indexes to 7 Poser will read d 25 0 0 -0.05835599 when was expecting to read { and again, who knows what Poser will do.

Waddya know, I was right :-)

The structure of the vertices tables is:

d n x y z

Where d is d, I don't know if some other letter is allowed or what it will do

n is the vertex umber and cannot be greater than numDeltas, if it is, terrible things can happen.

x y z is the difference between the morphed x yx z coordinates and x y z of the original mesh of vertex n

I think part of the confusion arises from the name 'numbDeltas', which is just a wrong word.  They should have used something like 'numbVerts'.  The vertices are NOT deltas; only the values listed in the MT are deltas.

On this topic, does anyone know whether 'blendType' has any function?  The internal code of Poser.exe seems to indicate that it can be 0 or 1.  But when I change it to 1, the morphs don't seem to behave differently.

thanks guys

lol i missed the 27 verts corresponds to 26 since the table always starts at 0.

so what happens i can tell you when that index number doesn't match you crash.

i've never messed with blend type.  would be cool if we could find a new toy in this file : )

Terrible things can happen when something is wrong with the delta table. Poser can crash, but there are worst thing that can happen.

You have a figure with one faulty morph, when the morph dial has a value 0 nothing happens and appear to be normal. You change the dial to 1 and strange things can happen, Poser crash or nothing happens, the figure is morphed and all is ok. You apply other morphs, pose your figure, move it and in some moment the figure has no more head or the eyes get out of orbit or who knows what else can happen. Or you save the scene that looked ok and when you load the pz3 again tragedy!

How do you find what/who is responsible for all the malfunctions?

As for the blend parameter I have no idea, the same for the joint dials !

I think the deltas section actually may be fairly tolerant of oddities.  I posted an actor subdivision script in the Python forum, over a year ago.  It preserves morphs, when subdividing a mesh, by adding all new vertices (and corresponding deltas) at the end of the existing vertex/delta listings.  I found that even when the actor had subdivided morphs, I could change the base geometry back to the original and just make the morph numbDeltas lines consistent with the current number of actor vertices, and the morphs would still work.  All of the extra deltas would be ignored.

Something similar seems to be true with the new weight mapping representation within the cr2.  The format is similar to the delta format.  I've encountered weight map listings with three times as many indices as there are vertices in the actor.  I don't know how that happened, but Poser seems to keep carrying around any extra listings above the numbVerts listing, simply ignoring them within Poser itself but saving them back out to the file with each save.

Quote - On this topic, does anyone know whether 'blendType' has any function?  The internal code of Poser.exe seems to indicate that it can be 0 or 1.  But when I change it to 1, the morphs don't seem to behave differently.

Maybe it's some old legacy listing which is deactivated?  They never seem to remove anything from the cr2 format.  :unsure:  Does anyone have a working copy of Poser 2, in which they could test toggling the values for blendType? 

The problem that I found was when the number of deltas was smaller than the value of "indexes" (some deltas were missing) and this produced an erratic behaviour of the body part.

The problem is how to fix it. To fix it you must count the number of deltas and then change the indexes value. For large morphs it only can be done by software. A morph checking-fixing program ?

Quote - > Quote - On this topic, does anyone know whether 'blendType' has any function?  The internal code of Poser.exe seems to indicate that it can be 0 or 1.  But when I change it to 1, the morphs don't seem to behave differently.

Maybe it's some old legacy listing which is deactivated?  They never seem to remove anything from the cr2 format.  :unsure:  Does anyone have a working copy of Poser 2, in which they could test toggling the values for blendType? 

It is not so old, Poser 4 had no blend parameter

Quote - The problem is how to fix it. To fix it you must count the number of deltas and then change the indexes value. For large morphs it only can be done by software. A morph checking-fixing program ?

A fairly simple script could scan a cr2 file and correct the indexes listing to match the deltas count in each morph.

Quote - It is not so old, Poser 4 had no blend parameter

Well, huh.  I'm out of guesses, then.    But I'm very curious about the matter.  Bloodsong's book makes no mention of it.  Kuroyume's cr2 file spec makes no mention of it.  I wonder what it is.  :unsure:

Quote - A fairly simple script could scan a cr2 file and correct the indexes listing to match the deltas count in each morph.

And remove all the useless deltas like d xxx 0 0 1e-12. Your morph the breast and get a foot morph with trash deltas as bonus

One day I shall do one....

Another mystery is the curve channel. I thought that it could be useful for bendings and it never worked and never produced any result.

I thought that is was a relic of some ancient Poser and in Poser 4 it didn't work anymore. Until a day with a downloaded prop the "curve" channel it was working!!!

So, it means that curve works in Poser 4, but why it works in one prop and doesn't work in many others ???

Quote - So, it means that curve works in Poser 4, but why it works in one prop and doesn't work in many others ???

I thought the curve parameter only worked in body part actors, where it modified the bending or weld handling, adding extra averaging and smoothing between welded actors. Does it actually work on props? 

Sort of makes me wonder how curve handles now on a weight-mapped figure.  Hmm.  :unsure:

Well, it were figures, it doesn't matter props can behave in the same way as figures.

Many very old props/figures have the curve dial, but no matter how much I moved the dial it never had any effect until I found one.

And it works fine, if the mesh has enough segments it produce a smooth curve. Curiously again, the curve only worked in some body parts.

In resume, curve works, but I don't know the rules and tricks when it works or do not.

Other mystery are the joint and twist channel dials, normally hidden. For what do they exist ? Changing the value I never observed any effect, but it would be very nice if it worked in some way and I could modulate the effect or magnitude of the joints by some variable controlled by something.

Quote - Other mystery are the joint and twist channel dials, normally hidden. For what do they exist ?

The actual dials (keys values) of joint and twist channels don't do anything. However the joint twist and smoothScale channels do a lot, they are the "Joint Parameters" and control how the mesh deforms (bends) in response to joint rotation.

Quote - > Quote - Other mystery are the joint and twist channel dials, normally hidden. For what do they exist ?

The actual dials (keys values) of joint and twist channels don't do anything. However the joint twist and smoothScale channels do a lot, they are the "Joint Parameters" and control how the mesh deforms (bends) in response to joint rotation.

That is the problem, the key value do nothing, but why do they exist?

Imagine if it would be possible to control the center of rotation !!!

Quote - That is the problem, the key value do nothing, but why do they exist?
Imagine if it would be possible to control the center of rotation !!!

It just seems to be a peculiarity of the .cr2 format that all internal features of an actor are represented as dials, whether those dials have any user-level functionality or not.  We'd have to ask Larry W or someone from way back, developers of the cr2 format, why it works that way.  But based on how you can hack a cr2 using the OffsetA and OffsetB channels, these listings are necessary and the values do something.  These are really instructions for Poser on how to handle the math behind any modifications to the actor in question.  Check out some of the posts by VK, in the Poser Technical forum, from several years ago.  People really did some digging into these things back then, but the posts are now buried deeply (they should be stickied, IMO :laugh:).

"It just seems to be a peculiarity of the .cr2 format that all internal features of an actor are represented as dials, whether those dials have any user-level functionality or not."

From a programming standpoint, it makes sense to reuse the functionality of the dial 'object' internally if you already have the code working and the only difference seems to be whether the changes are generated internally as opposed to coming from a UI control. Of course, you can stretch that reuse too far - been there done that :-)

Having Poser's data files be, in effect, a kind of scripting language has enabled people to do a lot of interesting and useful stuff. I wonder if the designers were designing it from a clean slate they'd use the same strategy. 

Quote - Imagine if it would be possible to control the center of rotation !!!

Ah, but you can control the center of rotation, though not via the joint or offset channels. You need to use extra translate channels, and some ERC helps. Give me an hour or two and I'll post an example.

Quote - You need to use extra translate channels

A fake body part ?

Quote - A fake body part ?

No, just extra channels.  This trick is really cool.  Les is quite clever.  :thumbupboth:  He used it with the cr2 base for the chain_maker script.

Quote - > Quote - You need to use extra translate channels

A fake body part ?

In Poser 9 / Pro2012 you have "Animatable Origin" as an option for each prop / body part...
Combine that with dependent parameters...  

I do not know, if any of this works in previous versions of Poser... Dependent parameters should work in Poser 7 ( maybe even 6 ) 

Quote - In Poser 9 / Pro2012 you have "Animatable Origin" as an option for each prop / body part...

The origin is not the center of rotation of a joint

Quote - > Quote - A fake body part ?

No, just extra channels.  This trick is really cool.  Les is quite clever.  :thumbupboth:  He used it with the cr2 base for the chain_maker script.

So, where is it ?

Sorry about the delay, I'm having internet problems.

Attached above is the text of a cr2 to demonstrate a variable joint center "CenterTest.cr2". This works in any version of poser from at least P4 up. It does not rely on extra body parts. The figure has 5 actors including BODY. You can ignore the hidden actors CenterIconA and CenterIconB, as they are only there as a visual representation of where the joint center is, they play no active part in what is happening, and could have been left out. PartA and PartB each have a dial "CenterY" that you can use to adjust the center of rotation for the respective parts. To keep things simple, the center is only adjustable on the y axis, though it could be done for all axes if desired. By default the joint centers of each part are in the center of the respective part, and the figure uses Wireframe Display Style.

PartA and PartB each have two extra translateY channels named yTranA and yTranB. ERC is used to link the extra translate channels to the "CenterY" channel-dial in such a way that when one translate channel goes positive the other goes negative. The main trick to the whole system relies on the fact that one translate channel comes before the rotate channels, and the other translate channel comes after the rotate channels. In essence, the actor is translated, then rotated round its new position, then translated back to its original position. This system, or something very like it was first brought to light by VK.

Thank you, I shall experiment it.

I should add that I have only used this system in mechanical type figures, I have not tried it in human figures.

Quote - I should add that I have only used this system in mechanical type figures, I have not tried it in human figures.

Shvrdavid has been doing some interesting things with animatable origins in human joints, while developing weight-mapping for Sydney G2.  Possibly this approach could be used to bring similar benefits to figures in Poser versions earlier than P9.  :unsure:

My concern with human figures is that the joint parameters will not "know" that the location of the rotation center has changed, and I fear that fact might lead to problems. One would hope that the P9 JPs are "aware" of the Animatable Origin.

I have looked at it, but it is not what I wanted, the figure has no joints. What I want is move the center of the joint.

For moving the pivot point I can use some of the the "offsetN" k values. The interesting thing is that I can have more duplicated channels and this is very useful, for example I can have two rotation dials, one that rotates the object around itself and the other dial that rotates around the center of the scene (of course the object is not in the center).

To explain what I want, for example I have a tube with enough segments to have a good mesh definition, not body parts, each body part can have a lot of segments.

I can set the joint center in any place of a body part, not necessarly at the junction with the other body part, the center can be outside the mesh. This center will define the point of bending of the mesh.

If the tube is along the Y axis, normally the joint X,Z center is set at the center of the tube. When I bend the tube to the right as the bending angle increases the result become not good, I can use buldges to improve the bended shape.

Now, if I can move the joint center to the right, the bended mesh becomes much better and I can achieve greater angles (90 degrees or more) and the mesh still continue to look good. If I want to bend the tube to the left I move the joint center to the left. In either case the translation is proportional or some function of the bending angle.

As I can have duplicated channels, I have a curious question:

"A bending figure/prop with only one body part?"

Quote - "A bending figure/prop with only one body part?"

Poser bends are an interaction between two actors (body parts). So I don't see how it would be possible to have a one actor figure or prop that would bend via joint parameters. Of course it is possible bend an actor via morphs or magnets, and ERC could be set up so that bend happened in response to a rotation.  

P.S.

An actor does not need to have geometry associated with it, so invisible "ghost" actors can be used to cause bends in normal actors.

Another thing, Someone did or has an idea how can be done:

valueParm1 = sin(valueParm2)

It doesn't necessarly need to be exactly a sinus function, any periodical function with a similar shape can work. With a sinus and cosinus I can make a centipede walk with only one dial.

Quote - Another thing, Someone did or has an idea how can be done:

valueParm1 = sin(valueParm2)

It doesn't necessarly need to be exactly a sinus function, any periodical function with a similar shape can work. With a sinus and cosinus I can make a centipede walk with only one dial.

Check out old posts by VK in the Poser Technical forum.  You can apply sine and cosine to joints and ERC, but you need to use a series of dials to arduously hand-code every mathematical step in the process.  It's not easy stuff, but it can work, apparently.

Edit:  Maybe it isn't a series of dials, but a series of ERC blocks.  See, I need to re-read the VK stuff myself.  :lol: