Actually, these aren't stupid questions, and probably have nothing to do with stupid hacks. I just liked the sound of the subject line :^) <- no sunglassses today

This is simply a long list of the questions I still haven't answered myself, and was wondering if anyone already has documented expirimentation on these lines.

1. Why does Poser indent setGeomHandlerOffset? It's not inside an internal block.
2. What exactly do all those channels like xOffsetB and stuff do?
3. Is there a list of geomResource numbers?
4. Are there camera models other than poser and depth?
5. What size lens does a Poser camera have? I'm guessing 50mm so that the focal lengths make sense to SLR users.
6. Who coded those spotlights and why hasn't someone smacked them yet? Real light doesn't work like that.
7. Why does light sometimes leak through a sealed corner?
8. It seems like using a GetStringRes() in a channel name overrides the hidden 1 command. But it doesn't in the case of the zOffsetA and such. What's with that?
9. If I have a channel 'translateY up-down' it shows up in the menu as 'Up-down' But if I just leave it 'translateY ytrans' it shows up as 'Translate Y' -- What's with that?
10. Has anyone ever tried playing with sticking other numbers in for lightTypes and such? 1. 0 is an infinite light.
11. 1 is a spotlight.

Has anyone ever tried 2 to see if there's a regular omni in there that maybe was buggy so they didn't document it?

1. If, for forceLimits, 0 means don't use limits and 1 means use limits if limits are one, and 4 means use limits no matter what, what do 2 and 3 mean? Or is it only 0, 1, and 4 (0000, 0001, 0100). Seems 2 should be in there (0100). Do non-boolean numebrs work with other things too?
2. How much playing with the numbers have people done anyway?

1. So it lines up with "displayMode USEPARENT". That's the free trial answer, I also have a $10.00 answer which is better, and a $25.00 answer which is really good. 2. Good question! 3. According to Hugh Everett III 1957, whenever numerous viable posing cameras exist, the world splits into many worlds, one world for each different posing camera. This contrasts with the Copenhagen Interpretation which makes a distinction between poser and depth cameras which only exist when you're looking through them, and other types of camera that only exist when you're not looking through them. 11. 4=1. I know you won't believe me, but its true.

1. The offsetA channels are the Origin, and are reproduced in the 'origin' line at the end of the Actor. The offsetB channels are the Endpoint dimensions. But Poser seems to ignore the 'offset' versions when reading the CR2. Editing the two lines at the bottom is enough.

I'd like to add one question: Why is modelType always 1318? Where are the other 1317 types?

And one more. In the upper part of CR2, every actor has a pair of lines: storageOffset 0 0 0 geomHandlerGeom 13 RearAxle Obviously the name "RearAxle" is enough of a reference to find the part. So what's the point of a three-dimensional storage Offset? And why 13?

'2. The offsetA channels are the Origin, and are reproduced in the 'origin' line at the end of the Actor. The offsetB channels are the Endpoint dimensions. But Poser seems to ignore the 'offset' versions when reading the CR2. Editing the two lines at the bottom is enough. ' I had thought that, but if I strip them out, everything gets wonky. Les: 4=1 Really? I thought 0 was ignore limits, 1 was use if needed, and 4 was always use even if not selected. Hmm. So are 2 and 3 also 4?

Oh, yeah, and whjy don't we just use 1 then? I've been using 4 because DAZ does and just assumed they were right. scolds self Bad hacker, baaad hacker.

And allow me to add, Les, that the #3 answer, which seemd to have more to do with #4, kind of, was a veddy veddy British sounding answer L

The 2 sets of Offset channels are for the End point and Point of Origin, but you need to keep them in the cr2 for some reason. If you move the jps, the new values are entered in the End and P of O lines, plus the appropriate Offset channels. When I made the 'MATs' to restore my default JPs, I found that I only needed the End and P of O in the MAT, but, of course, the cr2 needs the channels. 'I've been using 4 because DAZ does' It's not DAZ, it's Poser. Any number that's NOT 1 is 4. If you enter any other number, limits is forced, and Poser will substitute 4 for that number when you resave the figure. Why? Well.... that's a REALLY good question... mac

There was a thread about this 4,1, thing for limits, a few months ago. I havent done the experiments myself, but it seems that after a bit of initial argument the experts agreed that 1 and 4 had exactly the same effect, and that if you put 1 in the cr2 and resaved it to the pallet, Poser would change the 1 to a 4. Apparently, someone at some stage had claimed that 1 and 4 had different effects, and everyone just accepted it as gospel. When it was tried out in practice no difference was found between 1 and 4. Really this is only hearsay on my part, but I seem to remember that the people in the thread were pretty credible characters, I think Ajax was one of them. Come to think of it, where is Ajax? I havent seen him around the forum for a long time. Ocham, thanks for the info on offsetA, thats another one of those pesky hidden channels nailed down. Now what about yTwisty or what ever its called?

I suspect any none zero value =4 for force limits, but I could be wrong.

twistY, jointY, twistX, jointX, twistZ, and jointZ are affectors. They tell the joint to affect not only the moved item, but th item it's attached to. Same with the simialrly named ones with the other part in the name (i.e. lForeArm_twistX and such). If you remove them you get inorganic behaviour. For instance, if you were making a posable door you would place the door centre along a line betwen the middles of the hinges and the endpoint out at the edge of the door in line with the centre, remove the xrot and zrot to keep it from bending except the way it's supposed to, remove all affectors (what things you asked about) from both the hinge mount and the door so that the door moving doesn't bend the hinges, remove the transes from the door part so it doesn't walk away form its parent, set the limits so that the door doesn't wrap back through its own hinges, and then set forceLimits to 4 (or I guess 1) so that the user can't screw the door up because they didn't turn limits on. Oh, and there's no real use for the weld at that point either.

heyas; okay, once and for all.... this is from the semi-official unpublished curious labs in-house cr2 documentation: the offseta and offsetb are some kind of special magcial numbers that allow poser to figure out where things are in space. no, they don't know how they work. yes, they appear to be the same as the centerpoint and endpoint, but they're not. if you mess with them, you will open a rift in the space-time continuum. speaking of which, dodger, you should read the semi-official unpublished curious labs in-house cr2 documentation. the last i heard, you had to bug anthony hernandez to get it. can anybody tell poor dodger the real secret to that? 8: getstring res overriding the hidden 1? i've never heard of such a thing. are you sure you haven't been thinking too hard lately? :) 9: the trans y and what not things are hard-coded to translate into "translate y" and whatever, just like lshldr becomes 'left shoulder.' ock: model type 1318 is a modern and/or custom figure. the other model types are such things as the p1, p2, low-res, mannequins, stick figures, skeletons, etc. 'geomhandler 13' means 'a body part.' props and non-body-part things supposedly have different numbers. so do swapped geometry. i think i was the one who was guessing that 1 was use limits, unless limits were turned off, and use 4 means use limits no matter what. but i've seen the error of my ways!

Bloodsong: on 8, it was! I swear! But only on some things. On 1 vs. 4, yup, I think I got that from you.

4 = 100 binary. If Poser booleans are 3-bit integers, it would make a microscopic amout of (but still some) sense to use 4 as TRUE and 0 FALSE, if it's big-endian, because it would stop reading after the initial bit and know true. The reason it's microscopic is because not even the processor itself could detect the speed difference, aspecially as the character string '4' has to be translated anyway. The reason it's kinda silly is because it would make more sense to just use a proper 1-bit bool. And because 3-bit integers are just plain silly. And because I don't think that Intel processors are big-endian anyway.

1. You essentially answered yourself in question 6.

P4's light algorithms aren't very precise.

1. williamsheil gave lightType 2 a try.

The result is a "local" light, a hybrid of Poser's infinite light and spotlight. It illuminates the entire scene like an infinite light, but creates shadows only within a narrowly-defined field, like a spotlight.

Here's the relevant thread:
http://www.renderosity.com/messages.ez?Form.ShowMessage=645709

Les, are you thinking what I'm thinking?

I'd sure like to read the semi-official unpublished Curious Labs in-house CR2 documentation as well. Once upon a time it was going to become the official published Curious Labs file format documentation, but... What is the situation now that Anthony has left them, anybody know?

1. Poser uses the offsetA and offsetB channels to temporarily store the origin coordinates (center point) of a body part. The offsetA and offsetB channel code is a template: When the model loads, the origin coordinates of the body part are copied to the offsetA channels, and the reverse values are copied to the offsetB channels. A zero coordinate results in a "0" value in the offsetA channel, and a "-0" value in the offsetB channel. The offset channels are only used with the rotate and scale channels, which rely on the body part origin (translations don't need the origin). If a body part doesn't use rotate and scale channels, then you can remove the offset channels. The rotate and scale channels only work properly, if they are arranged between the offsetA and the offsetB channels. The channel order must be: offsetA rotate/scale offsetB. If you place the rotate/scale channels before the offsetA or after the offsetB channels, then the body part rotates/scales around 0 0 0 (i.e. Poser can't evaluate the actual origin). 3. "geomResource" refers to geometry resources, which are stored in the Poser application file ("ACTR" resources in the resource fork of the app file on a Mac, or in the "Poser.rsr" file on a PC). The number following geomResource is the resource ID. In Poser 4, there are five internal geom resources: ID 4 "box.obj" ID 6 "ground20x20Lines.obj" ID 7 "liteIcon2.obj" ID 44 "ball.obj" ID 148 "liteIcon.obj". "box" is a common box prop. "ground20x20Lines" is the ground plane. "ball" is a sphere (used to display the spherical falloff zones). The "liteicons" are used to display the light arrows in the Poser scene. Note that the magnet/wave zones don't use the internal "ball.obj", but the "ball.obj" in the /geometries/props folder. You can store any geometry in the Poser app file, and then load it with the "geomResource" call. Of course, editing the app file is not recommended. The "geomHandlerGeom" refers to a geometry resource stored in the "figureResFile". Since one figureResFile can contain multiple geometry resources, the resources must have an ID. "13" is the default ID used in a standard figureResFile. If you add "alternateGeom", or other geometry resources to the figureResFile, you must assign unique resource ID's (and use these IDs in the "objFile" parameter of the "alternateGeom" command, or in the "geomHandlerGeom" parameter). 5. The Poser4 User Guide reads: "Posers default Cameras are set to 25mm and have all the attributes of a real-world 25mm Wide Angle Lens. You can experiment with other focal lengths such as 50mm, which resembles the human eyes view, and 100mm, a lens favored by Portrait Photographers. Each time you set the focal length, the Scale will also reset. Scaling Down from 100% to 25% zooms in, while scaling up from 100% to 1000% zooms out." 8. Never seen this effect. "GetStringRes()" tells Poser to use a string from the internal string resource list. This shouldn't affect the hidden parameter. 9. When the model loads, Poser checks, whether the internal channel names match a channel name from the string resource. This test is not case sensitive. If a matching string resource is found, Poser replaces the channel name by the proper GetStringRes() call. If you use for example the internal channel names "up-down", "bend", "turn" etc., then Poser finds a matching string resource, and stores a GetStringRes() call in the document code. For some reason, this doesn't work with the rotate channel names, although there are string resources for these names (ID 9 to 11). 11. Poser seems to store several boolean parameter values in a single binary number. You see the decimal representation of the binary in the library/document code, for example "4" for the forceLimits parameter, or "32" for the customMaterial parameter. The parameters are still boolean, so any value other than 0 means "true" or "turned on". When the model loads, Poser replaces any non-zero value by the proper decimal number, i.e. "4" or "32". You find this information in the cr2 reference of Anthony Hernandez. I don't know, whether it's still available or not, and I don't have it.

Oh, and there's no real use for the weld at that point either. In Poser 4.0.3, if I delete a part's Weld command, something does its toilet somewhere unwelcome and Poser refuses to accept morph targets for that part even if its number of vertexes is correct.

Re #5: I've read that plenty of times, but it doesn't help because it's vaguely clueless. A 25mm or 28mm focal is pretty standard on an SLR with a 50mm lens, which is why I'm guessing a 50mm lens. The focal, lens size, and exposure size are all different things. The common '35mm' associated with an SLR describes the size of its negative. These usually, but not always, have 50mm lenses. The effect of a focal length changes with the size of the lens, because with a larger lens the same focal length forms a differently shaped triangle. This is how you can adjust the depth-of-field with a manual SLR simply by changing the F-stop, which is the aperture size. By changing the aperture size, you're changing the amount of the lens that is used, which is effectively almost the same thing as changing the lens size itself. This changes the shape of the light-cone, which directly determines the depth of field. However, if a 50mm focal is supposed to and is designed to approximate the depth-of-field of a human eye, then it can be extrapolated back based on the lens aperture size and focal length of a human eye. That is, if they're right.

VK, thanks for the straight scoop. Adding my voice to the clamor for public release of the "in-house" document! Since some "out-house" people apparently have it already, why not just publish it?

Hey, just because they have it and we don't, don't call them 'outhouse people!'

Poser cameras: Just the math, untested

This is based on the idea that the lens size really is 25mm, as well as the default focal being that, and that using of this the human eye ration comes out pretty close to 50mm, as you can see, which would seem to ratify this. However, it seems to me that the 14mm focal to simulate an SLR sounds pretty low, and I'm wondering why they wouldn't go with a 50mm lens to make the focal numbers more familiar to SLR users, who are the only people besides professional photographers (motion or still) that really pay much attention to these things.

< > Lens Focal Ratio SLR: 50mm 28mm 1:0.560 Eye: 9mm 17mm 1:1.888 Poser: 25mm 25mm 1:1   Focals for: Poser as Eye: 47.222mm Poser as SLR: 14mm

This may also be thrown off by the fact that a human retina is curved (concave) on the outside, though relatively flat int the centre of the field-of-view. This is what gives us peripheral vision (and gives many animals better peripheral vision). However, I doublt there's any wayto simulate this effect short of coding an entirely new third-party renderer.

'Any number that's NOT 1 is 4' I meant, of course, Any number that's NOT 0 is 4. The semi-official unpublished Curious Labs in-house CR2 documentation is part of the Poser 5 manual, which is available from CL online (Page 352, Part 11, Appendix B). Or, if anyone has problems with the big d/l, I have Anthony's doc on disk. It's 304kb. (And he's no longer with CL, at least full-time - he's off writing sci-fi books). ockham said, 'In Poser 4.0.3, if I delete a part's Weld command, something does its toilet somewhere unwelcome and Poser refuses to accept morph targets for that part even if its number of vertexes is correct.' Is that with organic or non-organic figures, ockham? I've deleted all the weld statements in all the furniture figures I've made with no problems whatsoever. Along with the twisties, et al, In fact, I do everything dodger mentioned in post #12, (apart from removing the extra rot and trans dials - I figure some idiot somewhere will want to lean a door up against it's frame or something, so I just set zero limits on the rots). Anyway, I have morphs coming out my figures' ears, and never had a problem yet. mac

Hey dodger "3.Is there a list of geomResource numbers?" There is a list around, but don't remember who's website it was on. Might try searching this forum and see what comes up. "4.Are there camera models other than poser and depth?" There is 'real'. This is used for the Dolly camera. Played with it once way back when I was doing the "Adding New/Extra Cameras to Poser", but got side tracked on some other things (see 12. below) so never fully pursued it. "6.Who coded those spotlights and why hasn't someone smacked them yet? Real light doesn't work like that." Don't know who did it, but I think your suggested solution is why they have been so slow at implementing "reach out and 'touch' someone through the Internet" technology :) "12.How much playing with the numbers have people done anyway?" A TON! Even more fun is to get a binary file reader, and peruse the .exe for code words to try out :)

I never thought about uploading the exe to my linux box and running strings on it. Hmm...

Woah!!! That is just WAY cool! So much for the old compiler method - this is just MUCHO better. Kind of interesting how much of the indentation is included directly in the source parser. Also a bit disturbing just how much is hard-coded into the thing :) Many, many kudos dodger! So i guess you're going to be the root cause of all the evil syntax mangling that's about to happen! :) As a side note, there is also a fair amount of text/names in the .rsr :)

Actually, all it does is read the file in and look for 8-bit patterns that look like they could be characters, then it checks to see if x-1 number more exist, x being what you tell it is the minimum, default of 4. I actually cleaned out over half the file before I posted it, because there was a long chunk of non-human readable stuff that I'm pretty sure was the embedded parts of what Mac would put in the resource fork, based on the way it looked (creator codes and such), which gives me the impression that the resource fork is embedded in the EXE, and probably duplicated in the RSR with optional changes, like a binary INI file.

Something I found in here... Eveyone who's touched ERC knows 'valueOpDeltaAdd' right? The strings output file contains the following little chunk... valueOpDeltaAdd valueOpDivideInto valueOpDivideBy valueOpTimes valueOpMinus valueOpPlus What do you think the ones I put in Italics are? These don't seem familiar, but they seem like they would somehow be distinctly related both due to name and location in the file...

Right-oh dodger! I was thinking of mentioning some of that, but thought I'd wait and see how long until you posted the .rsr text :) They are all null terminated strings, but actually have the leading tab character's. Not sure it always requires the correct number of tabs, but I've heard that there are some occassions where it does, so seeing it laid out the way you did perhaps explains it. The syntax is very helpful - I was trying to see if I could sluff in some uv coordinate changes along with morph deltas, so by looking at the syntax you can see it will only read the first three floats. To bad, so sad... Back to the drawing board.

Ack! you slipped a message in there on me :) Those extra valueOp commands are something I've been eying up for a couple months now :) I never managed to get them to do much for me with morph channels, (although that may easily have been my fault, so please don't take that as an indication they wont.) So just assumed they were something that could/would be used with some of the ERC stuff. That wasn't on my agenda at the time though and so moved on, but perhaps one of the ERC experts is already into that area and can clarify a bit.

On sscanf format: if the string in the EXE has a leading tab (or other leading space) the sscanf will accept inputs either with or without tabs. So if the internal strings have tabs, the CR2 doesn't need tabs. If the sscanf is written without any leading space, only an input without space (left-justified) will be read. I also tried those "mathy" valueOp commands once, and didn't see any visible results either!

on sscanf: yupyup -- which jives with the fact that whitespace/indentation doesn't seem to matter inside a poser file anyway. Of course, even if it did matter, it wouldn't necessariyl matter, because Poser could strip leading whitespace before reading. It may be the that valueOp math has to be used in combination with valueOpDeltaAdd?

From the strings file:

                        valueOpPlus
                        valueOpMinus
                        valueOpTimes
                        valueOpDivideBy
                        valueOpDivideInto
                        deltaAddDelta %f
                        valueOpDeltaAdd

Notice the valueOp operators all fall before the deltaAddDelta %f in the list, which may well mean they need to be there (before it) to work right.

Hmm. Maybe the OpTimes and so on are meant to be "mode" commands applying to the deltaAddDelta [n] command.....

Yup. My message said 'Notice the valueOp operators all fall before the deltaAddDelta %f in the list, which may well mean they need to be there (before it) to work right.' before the endge of the page so rudely interrupted me.

You've just compiled multiple new ways for me to crash poser. And made it possible for me to get truly creative in crashing it. ;] #12: LOTS. Occassionally, I play with numbers and get Poser to do something nifty. Generally I play with numbers and come up with new and unusual ways to make Poser lock up or turn cr2's inside out. I'm going to have to spend some time reading your text files and trying various things... Thanks. ;]

L No worries! See my other message for a nice fast way -- slave a dial with ERC to itself at -1.

Trying to load, texture and pose a Vicki2 character all at one shot from a pz2 file will do it also. ;]

We really need a list of definitions for what all of those command strings do... hrmm.

Attached Link: http://home.carolina.rr.com/kattman

Hey guys,

Is it possible ...

re: the "Limits" thingy
(in a .pp2 file)

(I'm just (really) guessing here)

If "forceLimits 0" = 00000000 (binary)
and any non-zero value is used, e.g., 1,2,3,4 or other(?)
that if ... the binary has the LSB = not zero
Then Poser then "sets"
the 2nd LSB to "1"
and the LSB to "0"
... thus equaling 00000010 or "4"

If this bit___|
__________ |
__________ V
0 = 00000000
1 = 00000001
2 = 00000010
3 = 00000011
4 = 00000010

is not zero, then Poser sets ...

..this bit__ |
_________ |
_________ V
0 = 00000000
1 = 00000001
2 = 00000010
3 = 00000011
4 = 00000010

to "1"

and sets the LSB to "0"

Just a thought.

Does anyone actually know the answer?

cheers,
dr geep
;=]

"Why does light sometimes leak through a sealed corner?" Shadow bias. Since computers do not have infinite precision but are rounding their 32 bit float numbers, programs add a slight bias to the shadow map's depth information in order to avoid self-shadowing. When the bias is too high, it can happen that shadows do not start at the floor where they should. Poser 4 does not give you direct access to the shadow bias value, but Poser 5 does, and you can recude such leaking by lowering the shadow bias. In Poser 4, you could have luck by adjusting the shadow lite cams, or maybe there's a hidden parameter for the shadow bias. Stefan

Or ... if you are using Poser's GROUND ... (in Poser4) You will find that the GROUND is at yTran of (minus) -0.001 and that creates a small space between the "Floor" (at yTran = 0.000) and the GROUND. So, when you do a "Drop to Floor" for a Figure ... ... and are using Poser's GROUND ... There is a small space between the Figure and the GROUND ... and some light might, just might, leak underneath a Figure's feet. ;=] cheers, dr geep ;=]

When I did Morph Manager I talked with CL a few times about various commands. It turns out a fair amount of the script commands are legacy stuff from older trial versions of poser. Some were even hacks to get models to work right becuase they didn't want to offset the geometry again. Also some are from MAC only intended implementations.

.