I'm wondering if anyone actually knows what the values in the CR2 mean - well, there are a lot of them and many I understand but what I'm perticularly interested in is the sphereMatsRaw data.

Now in the joint editor you find innermatsphere and outtermatsphere and for each you have 10 values that you can adjust, although one of those [scale] seems to always be set to 100% so I'm not sure if that counts or not.  Anyway, that gives a maximum of 20 values between the two, but in the CR2 you find:

            sphereMatsRaw
            0.074 0 0 0
            0 0.229998 0 0
            0 0 0.149998 0
            -0.077 0.269 -0.012 1

            0.088 0 0 0
            0 -0.0627447 0.305626 0
            0 -0.195914 -0.0402209 0
            -0.085 0.271 -0.012 1

which gives you  8 sets of values with 4 numbers in each set.  Now I realize that  the first 4 lines are innermatsphere and the next set are outtermatsphere, and since the last value in each line is either a 0 or a 1 I'm assuming that they are more switches than values, but that leaves me with 24 numbers to try and match up with 20 values.  So, anyone know what these numbers mean? 

I know that each one represents a 4x4 transformation matrix (thus the "Mat" part of the name). They have to do with the blending zones for the joint parameters.

There's a really thorough breakdown of the CR2 format at Kuroyume's Development Zone, and there's a great book by BL Render (which I highly recommend) that gives a lot of really useful information on the CR2 file and other goodies inside Poser.

Captain Jack

I'll check out that link and perhaps the book too [though that will have to wait a bit] I am used to working with the joint editor but I feel that to solve some problems with figures, dealing directly with the CR2 is likely the way to go.  I already do a lot of other things with the CR2 files but my lack of information has kept me away from some parts and I'm thinking it's time to look at them [heh] especially since I'm having a real challenging time trying to get a pair of pants to conform correctly and I think I'm coming close to the end of what I can do with the mesh, grouping and joint editing in Poser and there are a couple things that just keep eluding me, which is why I'm looking at the CR2 and this area of it in particular.

I've been studying the guts of the CR2 for a while now; I got into it because I was having a ton of trouble rigging figures, and I thought, me being a programmer and all, that it would be much simpler to go "under the hood" and edit the data files directly. I have since learned that "simple" is not a word to apply to the CR2 file. It still seems odd to me the way that bones are stored in the file; I got into it expecting the bones to be their own data object, and I found the structure a little elusive.

I'm pretty sure that some of the components of the file are obsolete, and just kept in place because Poser's file parser expects them to be there, even though they no longer perform any actual function.

In fact you can strip out all of that bone stuff if the figure is

not going to be doing any 'soft bending'.  When I build furniture

and houses, I use a script to eliminate all those 'twistx'

and 'jointy' type paragraphs.  Result is considerably

shorter, much easier to edit, and slightly faster in Poser.

The CR2 parser is really rather, um, pars-imonious.

For some reason, someone decided that the joint definitions should be 'channels' on the body part.  I can understand each 'actor' containing its joint specifications, but there is little reason to do them as channels.  They are not visible dials in Poser and changing the value really wouldn't change anything - as the real controls of joints are the Rotate channels/dials.

As stated at my site (thanks jevans69), the sphereMatsRaw section gives the matrices for the innerMatSphere and outerMatSphere in right-handed matrix form.  What that means (if you need the specifics) is that the rows of each 4x4 matrix represent these:

x-axis basis, 0
y-axis basis, 0
z-axis basis, 0
translation, 1

Of course, the (0,0,0,1) column vector is the homogeneous coordinate basis (usually you can ignore this).  This is strictly for higher spacial dimension representations.

The axial bases contain scaling, rotation, and shearing information for the coordinate system applied to the unit sphere.  Because the spheres are in the world system, shearing can be ignored.  If you need to know how to convert the right-handed matrix to left-hand, that information can be provided.

jevans: Funny, that was partly my thinking as I used to be a programmer - I say used to be since I haven't done any serious programming in years so I'm rather out of touch with current systems, but I still relate to things ... I think though that the CR2 files are an example of the age old tradition amoung programmers of patching rather than re-working [heh] I would say though that obsolete code is likely still there in part because if someone is using an older version of Poser that code may be needed - it gives more backward compatability.  I know that anything I create I like to have it usable with Poser 4 and up at least - since I don't have access to Poser 3 I have no way of knowing if things work with it or not.

ockham: Yes, the files can use optumising, no doubt.  I tend to go through and make sure there is no data which was used early in developing a figure [such as materials which I may have gotten rid of]

kuroyume: I would love the info on converting right-handed matrix to left-handed, I have some idea of it but mostly I'm making educated guesses based on what I see in various CR2s I have looked at.

It works like this:

Lets give the numbers in the 4 lines some names...

x1 y1 z1 0
x2 y2 z2 0
x3 y3 z3 0
x4 y4 z4 1

The easy one is the last. x4 y4 z4 are the xTran, yTran and zTran values.
By the labelling I did, you can see that lines 1,2 and 3 are coordintes, although the correct name is "transformation matrix". This is a combination of the x /y/zRotate and x/y/zScale information on the dials.

Suppose, just to mke things easy, that all rotations are zero and all scales are 1 (100%)
The matrix will be:

1 0 0
0 1 0
0 0 1

Considering another start point at 0,0,0 and these represent the three axes of the "bounding box".
Setting the scale to 25%, 50%, and 75% respectively for x,y and z this becomes.

0.25 0 0
0 0.5 0
0 0 0.75

Things get  more difficult  with  rotations, consider an easy one, yRotate = 90%.
With 100% scale that gives:

0 0 -1
0 1 0
1 0 0

Drawing some pictures with little arrows you'll see that this fits in.

• The y axis hasn't changed - this was the rotation axis.
• The old x axis is now lying in the opposite direction of the old z axis.
• The old z axis is now where the old x axis was.

Combining scale and rotation information at the same time, things get pretty complex and that's where all those funny numbers in the CR file come from.

As for the 0,0,0,1 at the end of each line - beats me!

Well, that's how it works (and I'm pretty sure you're sorry you asked), so I'll shut up now.

Rô

Quote - kuroyume: I would love the info on converting right-handed matrix to left-handed, I have some idea of it but mostly I'm making educated guesses based on what I see in various CR2s I have looked at.

Remember that this is changing a right-handed coordinate system into a left-handed coordinate system (in my case, I do this from Poser (right) to Cinema 4D (left)).

The matrix math is pretty straight forward (post-multiplication):

Matrix lhm = reflect * transpose * rhm

In words, the right-handed matrix is transposed and then multipled by a reflection matrix (about the z-axis).

Transposing the matrix involves a sort-of diagonal flip of the 4x4 matrix:

Right-handed (row-vector representation):

v1.x, v1.y, v1.y, 0
v2.x, v2.y, v2.z, 0
v3.x, v3.y, v3.z, 0
t.x, t.y, t.z, 1

becomes Left-handed (column-vector representation):

v1.x, v2.x, v3.x, t.x
v1.y, v2.y, v3.y, ty
v1.z, v2.z, v3.z, tz
0, 0, 0, 1

The left-handed reflection matrix is then:

1, 0, 0, 0
0, 1, 0, 0
0, 0, -1, 0
0, 0, 0, 1

The -1 reflects rotations and translations from the one system to the other (about the z-axis - x-y plane).

Ah... matrices. How well I remember them in school. The delightfully skewed writing on the blackboard, the blank looks on the other student's faces, the wonderfully weird ways that people would come up with to distinguish square brackets from parentheses. Who knew then that we'd grow up and actually be using that stuff for something as entertaining (and occasionally maddening) as Poser?

Interesting about the matrices. It is my understanding that the cr2 is patched and patched again onto a base that started back with Poser 1. As far as I know there IS no documentation on what it all means. Even the DAZ programmers leave certain lines alone because they don't know what they do and haven't the time to do trial and error trying to find out. The user base is in a worse fix. Seems odd, in a way, that the heart of Poser (it's DNA, as I think of it), is not better documented by the people who make the program. The cr2 is the key to get new content into the thing. You'd think they'd be like, oh, your average Quake engine and at least document the parts that level designer...new content providers need to get to. I personally find the "everything is a channel" format fairly easy to understand. It is a bit bothersome that the coding for a channel channel and a morph channel do not have the same headers, any more than the geometry pointer for a figure or a prop are the same, but it is pretty easy to intuit what is going on with the thing. It is really at the detailed level...at the long long stacks of unknown terms and once-in-a-blue-moon functions (like the rows and rows of data that all default to zero -- couldn't Poser just save its own cr2's without creating these empty lines?) I do like that the cr2 is plain text, can be edited in anything that can handle ASCII, and is somewhat internally self-documenting. What I fear is a change to it that makes it one giant table of hex, where you have to count to the 201th term, minus the number of colors multiplied by the lights in the scene plus a checksum......

ropeypopey: Ah, now that makes a lot of sense [oooo, scary that something like that makes sense - ] So that means that the values you can work with in the joint editor are not actually in the CR2 at all but rather they are calculated by Poser from the sphere mat raw data and the values one might change are then translated back into the raw data.  It's been a while since I've dealt with anything like this - as in back in the days of the XT and the 286 [those where the systems I last did any serious programming on - past that I became a user of programs rather than a writer of them - ]  Guess it's time to brush off the cobwebs and stretch the old math muscles :biggrin:

kuroyume: Thanks, that is definitely helpful.

jevans: So true :biggrin: of course after school I spent a number of years doing simulation programming so I got lots of use out of math that one would have thought had been invented just to torture kids in school :a_grin: mind you, this was the sort of math that I always tried to avoid and a lot of work I did involved table look-ups rather than calculations because all that was needed was close approximations.

nomuse: Two things about undocumented code - first, it makes it hard for anyone else to mess with it, which is the other side of the coin for the big reason why people are taught to document - if you want anyone to be able to pick up your code and understand it, thus making yourself nothing more than an interchangeable cog in the big machine then you need to document well - on the other hand, if you'd rather have the knowledge that nobody can easily replace you, then don't document :m_laugh:

Second thing is that a lot of people who are doing creative work get caught up into it and they don't want to pause to document things so they think to themselves that they'll go back and document later ... well, we all know how often later really comes, and then by the time that they decide they are really going to go back and document stuff, they discover that they haven't got a clue what it was they had been doing and they whole thing is gibberish :m_shocked: :m_letdown:

That becomes even more true as new versions come out and they just patch the old stuff to allow it to do new things.  I suppose one should get a hold of a Poser 1 CR2 file and start by playing with that and examining it and then gradually work your way up and see what changes.  It might actually be a lot easier that way.

I do like the fact that it is plain text, as for it becoming hex, I don't think we need to worry because as I understand it that is in part what the RSR files are - I believe Poser takes the OBJ file [which is also plain text] and the CR2 file and interprets the data in the OBJ by the commands in the CR2 and generate the RSR file which is a hex file that is what Poser actually uses.  If there is no RSR file then Poser generates a new one but if the RSR exists then Poser uses that.  Now some of the data in the CR2 is not included in the RSR - I think that would be the maps such as texture, trans, bump, etc and material info, etc.

My understanding is that the geometry rsr is basically Poser's internal view of the obj file. Among other things, poser adds it's own surface normals (it won't read them out of the obj file). Which means, by the way, that how small you can make the obj FILE is not a really good guide as to how big it will be once installed! The cr2 continues to carry most of the joint and materials data. However. cr2 is READ IN, not used actively. When Poser reads a cr2 (or any of the family; pz3, pz3, whatever), it interprets the data into what it uses internally. When you later "save" a cr2, you are exporting a new file created by Poser based on what it was doing. So things like figure names (aka the figure 1 or hip:1 stuff) are not what you originally wrote. The file pointers to texture maps are truncated, the morph dial sensitivity is set to some random number, and so on and so forth. It is one of the annoyances of third-party product creation to go through the "final" cr2 of a product with a text editor and fix up everything until it is the way you had it originally. Some of this is a bit hacky...like changing the version number to maintain backwards compatibility...but stuff like restoring the complete ":Runtime:textures:Me:NewShoes.jpg" is both necessary and annoying.

I know what you mean with that - it's actually one of several reasons I want to be able to work directly with the CR2 file for a lot of things.  For example, I have found that the values I enter into the joint editor do not always remain what I entered - I gett things like setting the x-Rot of the innermatsphere to say 6.080 and when I save and then load the file again I find that it has become 6.079 - close, but sometimes you need the delicate ajustments to get the look right.  I had rather hoped that the values contained in the joint editor were to be found in the CR2 rather than values calculated from the values I enter - I really like having direct control rather than indirect "interpreted" control.  Oh well, I guess one does the best that can be done.  I have to say that creating confirming cloths is a real pain, I've had far more trouble with a silly pair of pants than I did making the figure that wears the pants - you'd think that it should be easier to make the pants than the figure.

But one way or the other, I shall push on and even if editing the CR2 directly doesn't prove a solution to my current model problems, it should help me with the next.  Always a learning experience.  Besides, I've always liked knowing how things work and I find that knowing how leads to new discoveries which are sometimes really wonderful.  After all, that's how we got JCM and several other things which as I understand it, the creators of Poser had not even known that you could do it, it was a side effect of how Poser handled certain things.

Yah. Or the fact that the cr2 is a family of similar files....leading people to make experiments in transgenic files; such as taking DNA for materials out of a cr2 and inserting it into a pz2 to make the MAT Pose we still use today.

Of course there are limits - it's just that no one really knows what those limits are.  But then, that has always been the way - one person creates something with certain intentions in mind and someone else looks at it a different way and discovers things the creator never thought of because that wasn't what they had been intending.  Sometimes  it leads to really good things.  For now, I mostly just want to figure out why my right and left thigh are behaving slightly different when they should be the same, and why the center crotch area of the hip buckles over in an odd manner rather than moving in line with the rest of the mesh - I think I've exhausted examining the mesh for reasons and have concluded that the problem is in the joints and most likely I think in the mat spheres but playing with the joint editor is not giving me the results I want because it seems I am needing vary small adjustments which I'm finding hard to make because there seems to be some sort of rounding going on so that the values I use are not always the values I end up with so I though that directly manipulating the CR2 might be the answer.

I always start with this sort of thing working visually, you know, grab the angle arms with the mouse and move them or "turn" a dial, then when I'm close I switch to typing in the values directly but I'm feeling like I need either a new inspiration or a more preceise tool for adjusting things - the CR2 seems the most preceise tool available.

Quote - ....so I though that directly manipulating the CR2 might be the answer...... the CR2 seems the most preceise tool available.

I'm quite sure that you are right, the CR2 is the best (only) way to acheive total control over the parameters.

If you change a value of a parameter dial, say, yRotate to 27 degrees. It doesn't actually use that value but comes back at you with 26.92189 degrees.

This means that all this Rotate and Scale stuff is just for us poor humans who can't seem to think in terms of a three by three matrix (shame on us) and have to be spoon-fed by Poser breaking it up into separate chunks.

This also indicates that Poser's runtime internal representation is (probably) exactly the same matrix that is written in the CR2. If that is so (and I'm not sure that it is) then yes tweaking the values in the CR2 would help you acheive total control (..tomorrow, the world! :sneaky: ).

Rô

That's sort of what I thought when I started this thread - since it had become clear that the CR2 didn't store the values entered in the joint editor I thought if I knew what it did with those values I might be able to work in Poser [giving me the advantage of seeing the changes as they are made] and then figure out what needs to be adjusted and do the fine adjustment in the CR2 and check to see how it worked.  I'm sort of thinking of it in terms of targeting - try a value and if it is too little then try increasing it and if then it is too much then average the two and keep adjusting until I hit it right.  Not the fastest approach but a lot faster than random attempts