Forum Moderators: Staff
Poser Technical F.A.Q (Last Updated: 2024 Dec 04 2:47 am)
Welcome to the Poser Technical Forum.
Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)
This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.
New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.
(3) What are all the channels for? A typical joint (the 2nd segment of my flamethrower model's fuel hose) has all these 23 channels which my Poser 3 put in it: twistX tube3_twistx; taperX taper; smoothScaleX tube3_smooX; smoothScaleX tube1_smooX; zOffsetA zOffset; yOffsetA yOffset; xOffsetA xOffset; scale scale; scaleX xScale; scaleY yScale; scaleZ zScale; twistX twistx; rotateX xrot; rotateY yrot; rotateZ zrot; xOffsetB xTranB; yOffsetB yTranB; zOffsetB zTranB; translateX xtran; translateY ytran; translateZ ztran; curve curve - Are all these needed? Which could I delete manually without making my Poser 3 throw a fit? - What is the difference between "translate" and "offsetA" and "offsetB"? Why are all three needed? - Do we need such repeat-in-advance channels as e.g. "tube3_twistx" which merely repeat information which is also in segment tube3's channel "twistx"? - And bulking all this is the endless repetition of such things as "max 100000" and "trackingScale 1" which could be listed as defaults once and for all at the start of the file.
Well, the reason why it is structured that way is to make the parser in poser easier to write and debug. Redundant infomation is usually provided as a sanity check for the software. You can adjust a bunch of settings that are normally at default. This can produce interesting effects. But I have been told you can cut out some of the redundant channels. I never have. It takes too much effort and may well cause major problems later on. Disk space is cheap. Don't sweat it would be my recomendaton.
sanity check for the software And an insanity check for me when I have to wade thru it all with a text editor, or find disk room for it all, or sit forever or have to read a book while a slow dialup line takes "an age and a snail" to download it all. > Disk space is cheap My laptop has only 4 Gbytes, and it is already over a half full. A meg here and a meg there, and a gigabyte is soon gone, particularly since the minimum data cluster size seems to be c.32000 bytes (hex 0x8000). And download time is not cheap. PLEASE LET POSER 5 WEED OUT ALL THIS REPETITIVE RHUBARB OUT OF CR2 FILES. And there is still a case for keeping a model short enough to zip small enough to fit on a floppy. Floppies still have their uses.
Use the find function in your editor, don't just scroll. Well, they zip at about 4 to 1, so a 1.6 mb file is 330K. The obj file only compress about 3.5 to 1, so they are maybe 450K. They fit on my floppies. In order to get a lot of compression you would have to go to a binary format. That would intoduce a whole lot of problems. It's like dealing with a corrupted registry file vs a corrupted .ini file. If you corrupt your registry you get to reinstall windows, and all your applications. That is the MS improvement over having to edit those nasty text ini files, which NOBODY could manage. It is so much more efficient to throw away a day or two reinstalling windows and 20 applications than to spend ten minutes editing a somewhat cryptic file. Not that I should complain, since this improvement by MS has really done great things for my standard of living, but still, I like text formated files. They might introduce the ability to dynamically zip and unzip files, which would be fairly painless, but I would be strongly opposed to going to something that results in a binary fomat that will be totally impossible to edit. Notice that Meta has put out ZERO documentation on poser internals. So if we can't explore it we can't work with it except directly through poser. And since you are obviously finding it necessary to directly edit the CR2 you have begun to see the limits that this may cause.
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!
(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 "{")?
The GetStringRes bit is because the RSR in not just the binary verion of the obj, as it often claimed. It is that, but it also seems to have a bunch of embedded data produced by poser processing the obj and the CR2/PHI. That is why, if you reimport a .phi, you will not see any changes if you do not delete the existing RSR first. (at least in 3.01) When you hand edit a cr2 you are not generally making horribly drastic changes, like changing the orientation of all the joints. Meta uses codewarrior to produce their cross platform code and Larry said that the calls to the resource fork (the GetStringRes) are produced automatically by Meta's tools. They are just labels, as far as I can tell. The main limit you may run into is that future versions of poser may do stuff with sections that now seem dead. Some parts of the CR2 are basically there for backwards compatibility. If a new version needs something that you have decided isn't important you are going to have to fix it. For a prop, that isn't going to be too bad. For a complete figure that could mean a whole lot of work. I don't think it's worth the possible problems. It takes something like 3-400 figures to use a GB of disk space. But it's up to you.
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
I find that, even if a .CR2 file contains no geometry or morph deltas, it can easily be as big as its model's .OBJ file. Why!? All that bulk and bloat adds to filestore usage and download time. Not everybody has a fast LAN link and/or can afford umpteen gigabyte storage. I know that info needs describing, but there are limits!? E.g.:- (1) Much of the bulk of .CR2 files seems to me to consist of lines like these which set parameters to values which are their usual default values, in each of well over a thousand "channels" (23 or more at each of say 50 articulations). Why can't they be omitted? If e.g. "hidden" is 0, or "max" is 100000, why say so every time? Why not have at the start of the .CR2 file one "global channel" which sets default values for all the parameters? Then e.g. if the channel is hidden, it can contain the line "hidden 1", and if it does not contain a "hidden" line, "hidden" defaults to 0. For each channel it may not seem much bulk, but repeated over well more than a thousand channels, it adds up to a LOT of text bulk. hidden 0 forceLimits 0 min -100000 max 100000 trackingScale 1 interpStyleLocked 0 (2) Unless the model is animated, why put this "keys" matter in every channel at every joint? In still models, it merely repeats the info which is already in the "initValue" line. keys { static 0 k 0 0 }