JKeller wrote "Actually, when Poser exports to Bryce, each Poser usemtl area becomes its own group for the purposes of applying materials in Bryce.". That doesn't happen in my Poser 3. If I export as .OBJ, I get a dialog box "Do you want to export each body part as a group?". "Yes" gets each body segment as a group. "No" gets an exported .OBJ file which contains no "g" lines and no "usemtl" lines anywhere.

I just tried to look at the other Poser Forum and I got this:- > Forbidden > You don't have permission to access /main.shtml on this server.

Horse harness is another example of something which is partly a conforming garment and partly not, for the reins do not follow the horse's neck and chest but hang in a loop between the horse's nose and the rider's hand. Posing the reins seems to be another example of wanting to be able to pose a long thinnish object by having it as one segment with the curve property and letting the user specify its position and attitude at various places along its length, rather than by dividing it into long uncooperative serpents of many jointed segments, after the temper-trying times I have had with my flamethrower's backpack harness which I had to make as long "tails" of many segments with the "curve" property. And the reins are a closed loop, and the "I want to make a circular IK chain" matter surfaces again. How to pose the harness (both the reins and the parts that conform to the horse) when it is not on the horse but is in the harness room spread on a table or hanging from a hook?

(1) I have now got http://www.buckrogers.demon.co.uk/shortcr2.txt down to 115475 bytes, not much more than a third of the original length! (2) Why the "name GetStringRes(1028,5)" type of format for channel names? I was told that they refer to position in the .RSR file; but if so, how do .CR2 files that call GetStringRes work when I alter the .CR2 file and delete the .RSR file and expect Poser to make another .RSR file? Why not put the channel name literally every time? And why put a "name" command in at all if the name is the same as the second arg in the channel info header line the line before the "{")?

I am extremely sorry to Kevin if I seemed to be aggressive to him. I sympathize with him about text versus binary for convenience in editing, e.g. .ini files versus the registry. But he misunderstood me. I was not wanting .CR2's to be in binary. As an example of shortening .CR2 files in some future version of Poser, compare:- - my flamethrower model's CR2 file, zipped nto http://www.buckrogers.demon.co.uk/3d/fl.zip : it is 305744 bytes. - a version of it with my suggested "channel defaults" paragraph (starting at its line 254, next after declaring the actor names), at http://www.buckrogers.demon.co.uk/shortcr2.txt : it is 159943 bytes By removing these repeated settings, and removing the keys{..} sub-blocks (which in an unanimated model seem to only serve to repeat things), I thinned out nearly half its bulk!

Also, having each strap or hose or whatever as one segment rather than one would make the model's .CR2 and .RSR files much shorter and much lessen the load on Poser of having to keep track of at least eleven settable parameters (some hidden) at each articulation.

Someone suggested that in Poser 4 the flamethrower's hose and nozzle can be treated as a "conforming garment". But the wearer's hands and arms must conform to the flamethrower's handheld part, not the other way round. Also, in life the hose would not follow his arm but would hang in a long loop.

P.S. With two of those devices I had the same bout of python-wrestling trying to pose a hose that runs from the backpack part to the handheld part.

It would also be useful in more common objects with several long "tails" of "curve"-d segments, e.g. anything with backpack straps such 3 devices that I put in the Poser Funb Stuff (text search for "appleyard"); and I am planning a scuba set, where the same problem may arise. So far in posing backpack straps I must wrestle with a long serpent of many jointed segments and find that it has many of the properties of a large uncooperative python.

Possible algorithm: = Hereininder for "R" read whichever of x y z is the part's rotation axis at its proximal joint. = F0 is the part's proximal joint center point. = The user chooses fix points F1 F2 F3 etc. = Each of those points contains x y z (position) and xrot yrot zrot. = The part's length along its rotation axis is L, as set by its geometry and rits current scaleR setting. Poser 5 could do this:- = At each point, find from xrot yrot zrot: vector P = {Px Py Pz} = direction of the part's R-axis at that point; angle T = how much to twist the part about its R-axis there to get its desired attitude there completely correct. = Leastsquares fit a curved path from F0 through F1 F2 etc, using each point's x y z and P. = Lay the part with its R-axis along that path as far as its current length L will allow. = Twist the object to fit the T values at all the points that it runs through.

I have known cases in a prop imported into my oser 3 and then it was in an exported .OBJ file, that some of the vt numbers in its f lines came out as 0 and a few as VERY BIG NEGATIVE NUMBERS, and I had to clean them out with a text editor before my Bryce 3.1 would accept the .OBJ file.

Do we need such lines as "name GetStringRes(1028,1)"? ... > [Kevin replied to this, above] - Uhh, resource forks, those Mac arcana. Most people use PC's, not Macs. Sounds fiddly, poking about in a binary file with a special editor. And, if I edit the .CR2 file to change something, I must delete the .RSR file and let Poser recreate it, and all the carefully REPLACEed foreign language info in it goes down the /dev/null and must be reREPLACEed by hand. Surely something like this would be easier for humans to understand and edit? languages French Latin Spanish .... actor head:2 { langname French "tete" Latin "caput" Spanish "cabeza" storageOffset 0 0 0 geomHandlerGeom 13 head } .... rotateY yrot { langname French "tourner-en-Y" Latin "rotare-Y" ...

I wrote and Wiz replied, about removing need for particular types of line:- > > (1) ... keys { static 0 k 0 0 } > ... store animated figures ... add animation ... - When it is needed to describe animation, put it in. When it does nothing except repeat the InitValue value, leave it out? > > (2) ... lines which explicitly set quantities to values which are their defaults anyway, e.g. "min -10000" and "max 10000". > better to properly set ranges, than eliminate them. - I was not talking specifically about limits. CR2 files contain hundreds of lines that serve only to set many parameters to values which are their defaults anyway, e.g. "hidden 0" and very many others. All that adds to file bulk, multiplied across all the actors in a figure, multiplied by all the Poser figures in the computer, becomes a LOT of space used. >> [actor Hip's "twistY genital_twisty" info repeats actor genital's "twistY twisty", and likewise with several twists and translates etc at each of over 50 joints in the body] > because every joint really does articulate on the LAST joint in the hierarchy. You're just misinterpreting the relationships. - Erh? I still see no need for all that repeating of twist and translate etc info in both of a pair of parts that articulate with each other. And, (c. 30 lines per repetition) * (6 or more) (for twistX/Y/Z translateX/Y/Z and perhaps others) * c.50 (articulations), = up to c.10000 extra lines of CR2 language text that could be removed per Cr2 file!

It would also help if I could issue along with the flamethrower model a pose-type file mentioning BOTH the nozzle AND its user's hands and finger parts. In that file there would be a new special cr2 language command DragToRelative" with coordinates (x y z) and orientation angles (xrot yrot zrot) relative to a specified other part, e.g.:- actor nozzle:1 { channels { ... DragToRelative lHand .012 .034 .065 123.5 32.6 33.87 DragToRelative rHand .053 .023 .056 321.8 34.6 45.84 ... where the six nunbers are x y z xrot yrot zrot in that order; the fingers are posed relative to the hands by their ordinary "rotateX" etc cr2 commands. Then the user could do this:- - Put the flamethrower on a man's back. - Parent its tank to his chest part. - Apply this pose-type file. If applied it tries to attract its wearer's hands to the place of operation, and then as above.

P>S. Also, my total allowed WWW space is only 20 MBytes, and that much is soon gone, even if to save space in each model I e.g. omit the file qwertyuiop.rsr if its geometry file is qwertyuiop.obj .