This is the supporting topic for my "Proof Of Principle - Poser ERC Opening Book" freebie in the Renderosity Free Stuff.

The opening book was originally created around three years ago as part of my books project in the Smith Micro Poser forum and posted to ShareCG to test the viability of doing moderately complex maths using just valueOp parameters. 

Please feel free to post comments (good or bad*), suggestions for improvement, and/or questions about this freebie here.

Link to item in Renderosity Free Stuff: Proof Of Principle - Poser ERC Opening Book

Alternative link to item at ShareCG: Proof Of Principle - Poser ERC Opening Book

Since the Smith Micro Poser forum vanished a couple of years ago all that background information has gone, although I'm fairly sure that I have backups of it somewhere. I did create parallel topics for my books project on a few other forums, but they each contain far less information and nothing specifically related to this opening book test. I'll include links here for completeness.

My rather infrequent, and possibly apocryphal, 'books project'. on the Hivewire3D 3D Content Development forum
Books For Those Empty Virtual Bookshelves on the DAZ Freebies forum

* if bad then constructive criticism is preferred :)

This is the maths involved.

That's mostly trigonometry so I had to get creative to do it in valueOps.

I ended up using Bhaskara I's sine approximation to get the sines and cosines using just +, -, ×, and ÷ operators, and I used a key/value lookup table for the arctangent

This was the next step from that scribbled concept - coding it into the valueOps within a CR2.

The most difficult thing was coming up for meaningful but short names for each valueParm.

And editing the CR2 without errors (I did it all manually). That was the most difficult thing too.

Here's an example of a complete valueParm statement explaining how I'm coding my maths into these things.

This is the last additional picture I attached to the original ShareCG upload.

It shows how the zRotate of each of the bones making up the book is determined from the valueParms.

One key point to note is that the BackJoint and Spine bodyparts are not physically connected - it is just the maths that keeps them together. In my early attempts it kept breaking apart because I'd made mistakes in the maths !

If you look at the Hierarchy Editor you'll see that the Book bodypart (which has no physical mesh attached to it - it's just a dummy) has three direct children: PageBlock4; BackCover; and BackJoint. The rest of the PageBlocks, the FrontCover, FrontJoint, and Spine are in a chain under PageBlock4

(I'm not sure why the FrontCover bone doesn't show up in the image above - I think it's similar to the BackCover bone)

This shows in principle how it's possible, using just valueOps, to create a skeleton where the last bone joins back to the first, i.e. a loop. Of course this example only has one degree of freedom, zRotation, and 2 or 3 degrees of freedom would make it far more complex. But in principle it's possible.

(I also played with the idea of doing trigonometry with valueOps for a millipede's legs )

I've just realized that the backup in which I found the OBJ that was missing from the original ShareCG upload also contained a slightly later version of this which had a spine that bends too. 

I've uploaded that to my HiveWire3D book stuff topic, post #53.

There's also a short video of the book opening on my Youtube channel Proof of principle - Poser ERC opening book - YouTube

Thanks for sharing. I have returned to poser after 3 years of computer downtime…

That's a long time to be without a computer !

Something I forgot to mention - the trig functions were down using valueOpKey lookup tables which I calculated in a spreadsheet.

For the sine and cosine I found 5 degree steps from 0 to 180 were enough (interpolation is linear).

For the arcsine and arctangent I arranged the key/value pairs so that the keys would give values of 1, 2, 3, 4, etc through to 87, 88, and 89 (and 90 for arcsine) - I stopped at 89 for arctangent because tangent(a) tends to infinity as a tends to 90.

For other projects different ranges and/or step sizes may be required.