Sorry folks, My first post on this contained an error. There has been some recent debate about the size of the Poser unit, and an excellent class by Dr Geep based on his preferred choice of 1 Pose unit equals 100 inches. There is another school of thought, that prefers 1 Poser unit equals 8 feet (96 inches). I hope that the champions of both of these schools of thought will not be offended by this subject being aired again, especially so recently after Dr Geep's tutorial. You will see that I actually recommend people adopt either of the two options mentioned above, for normal use. If people disagree with my findings I welcome debate, but please don't post long messages in this thread which might disrupt the flow of the proof. Ta. So anyway... I have been doing some independant study on this question, and I believe I can state with some authority that 1 Poser Unit equals 8.6021508333333333 (recurring) feet, and I can prove it! Before anyone gets too excited let me say that this is not a very useful answer, because it means that many of the figures work out very tall. I think the situation is that most of the figures are strictly overscale for their own world. I also believe that the initial release of Poser 5, which presented a ruler indicating 8.602 feet per Poser Unit was technically more accurate that the current patched version which presents a ruler indicating 8.0 feet per Poser unit. During the course of this proof I will demonstrate a) How to read the absolute size of any model exported from Poser in inches, using a freely available shareware program. b) Confirmation that the size of 1 Poser unit has never changed (at least from Poser 2), and proof that it is still 8.602150833333333 (recurring) feet in Poser 5, whatever the 'ruler' might tell you. c) The significance of the Poser import option 'percent of standard figure size'. d) A little known feature of the .3DS file format. e) How .3DS files exported from Poser would be different if 1 Poser unit were 100 inches, or 96 inches, and how to alter a .3DS file to make 1 Poser Unit look like any distance you like. Some parts of some of the proof which will follow are complex, but the underlying demonstration is simple. As stated above, the resulting world scale is not very useful, because many figures work out very tall. I would recommend that for normal use people should adopt either 1 Poser unit equals 100 inches, or 1 Poser unit equals 8 feet (96 inches) to choice, because these convertion factors give a much more typical figure height, however, I hope that I will be able to convince you all that I have a definitive answer to this thorny question, and maybe the question can finally be put to rest. This post is long enough now. So I will pause, with the words of Pierre de Fermat (of Fermat's last theorem fame). "I have discovered a truly remarkable proof which this margin is too small to contain" To be continued ..... Cheers Ian

Excellent presentation thus far, Ian.
And ......... thank you for the compliment. ;=]

Please DO continue.

cheers,
dr geep <------------------ not offended at all ;=]
;=]

Hi dr geep :-) Okay, For much of this proof I will be using a program called GMAX, which some of you may know is written by Discreet (the people who sell 3DMAX, and who devised the .3DS file format). GMAX is a stripped down version of 3DMAX, which can only export in the proprietary .gmax format. The main difference between GMAX and 3DMAX for my purposes, is that 3DMAX is very expensive, and GMAX is free. I can't afford 3DMAX to try my proof using it, but I would welcome comment from anyone who has that program, and tries what I am about to describe. If you want to verify my results, you could download GMAX, but I hope you will trust my word that I am describing here exactly the results I see. Now having read some books from my local library, on 3Dstudio and MAX, and having looked at GMAX, they all use a default world unit of one inch. The user can change the world unit, but the books warn that if you alter the world unit, you will have no way to ensure that models you load will have their correct dimensions, without asking the person who created them what world unit he/she was using, and setting your own world unit to the same value. I need you to take a leap of faith now, and accept the premise that the world unit of the program which created the models for Poser 2 (and possibly version 1) was one inch, and was possibly a member of the 3Dstudio/MAX line. I have no way to prove that, and if you can't believe it then the rest of this proof is shaky (though there is supporting evidence for this figure later on). Enough of this waffle, let's see something interesting... Right, Open Poser, any version (I've tried version 2, version 4, and version 5, can't find my CD for version 3 just yet). Delete any figures in the scene, and bring in a cube from the props library. I hope it is generally accepted that this cube is one tenth of a Poser unit. Scale the cube up to 1000% so that it is 1 Poser unit high, and export it from Poser in 3DS format. Now run up GMAX, verify that it's world unit is set to the factory default of one inch, set the units setup (not the same as world unit, this just controls what graduations are on our ruler) to decimal feet, import the .3DS cube, and look at object properties. Note that GMAX describes this object as having X,Y and Z dimensions of 8.602 feet. You can also try that in decimal inches if you wish, and GMAX will report the cube as having X,Y and Z dimensions of 103.226 inches (which is the same as 8.602 feet). Remember this number, we will make great use of it later. So, Somehow GMAX has decided that the cube is 8.602 feet (103.226 inches) per side. A figure which, coincidentally was the size of the Poser unit in the first release of Poser 5. pause for thought...

Hmmm, Well that figure of 8.602 feet matches the figure used by the unpatched version of Poser 5, but hey that could be just a coincidence, and anyway I thought there was a well documented statement somewhere that a Poser figure was six feet tall, this Poser unit of 8.602 feet makes most of them over that height. Next demonstration, Import the cube, (or any model in any format, but cubes are easier) back into Poser, and check the box for 'percent of standard figure size' and make sure the percentage is set for 100%. This cube is roughly three quarters the size of a Poser unit, but doesn't appear too useful (but we will find it is extremely useful). Now export this model from Poser in .3DS format, and import it into GMAX, with GMAX set to a ruler in decimal feet, and world unit still set to one inch. In GMAX look at the object properties of the cube, and note that GMAX describes this cube as having dimensions of exactly 6.00 feet per side. You can also try that in decimal inches, and of course it is 72.0 inches. I put it to you then that this cube, 100% of standard figure size, is in fact the origin of the statement 'A Poser figure is six feet tall'. Or maybe that is just another coincidence ????? Note that I get the same results reported by GMAX, whether I am exporting from Poser 2, 4 or 5, and I suspect also version 3 (If only I could find that dammed CD) so whatever is going on here has not changed all through since version 2. I believe as I have said that GMAX is somehow able to read the conversion factor from it's own world unit to Poser's world unit, and that that information is hidden somewhere inside 3DS files exported from Poser. Unfortuately the 3DS file format is not in easily readable text, and there seems little information available about what it actually contains. Next I think we will need to dig down into a 3DS file and try to decipher at least some part of it.

Apologies that this section is a bit long, It would have been awkward to split. To progress from here I am going to make use of a couple more shareware programs which are available on the 'net. They are:- I3DSTEST.EXE A program which partially decodes 3DS files. and Fairdell HexCmp A hex file compare program by Fairdell software Grateful thanks to the creators of these programs, they are far cleverer that I. If you want to verify my results, then you can download these programs. If you are nervous about downloading exe files off the net, then you may just want to watch what happens next. Lets clear our Poser workspace, and bring in another cube, scale it up to 1000%, and then export it as an .OBJ file and also as a 3DS file. Since these two files describe the same object, if we can decode both files we should be able to find some common ground. First let's look at the .OBJ file. That's easy because it is ASCII format. Looking at the start of the file we see... # InternalName: box_1 # ExternalName: box_1 # Num verts: 486 # Num sets: 1536 # Num elems: 384 # Num tverts: 116 # Num tsets: 1536 # Num tElems: 384 v -0.5 1 0.5 v -0.5 1 0.375 v -0.5 0.875 0.375 v -0.5 0.875 0.5 v -0.5 1 0.25 v -0.5 0.875 0.25 v -0.5 1 0.125 v -0.5 0.875 0.125 v -0.5 1 0 etc. Okay, lets set I3DSTEST loose on our 3DS file. To do that we open a DOS box, go into a directory where we have the I3DSTEST.EXE and our 3DS file (which I am calling 1pucube.3ds), and enter the command:- I3DSTEST 1pucube.3ds the program responds with >> Everything went OK. Oh, I thought it was going to decode the 3DS file for me? Never fear, it has created a file called 3dsload.log, whic we can load up in notepad, and we see... Inquisition 3D Engine for Free Pascal - 3DS LOADER DEBUG LOG FILE Loader code by Karoly Balogh (a.k.a. Charlie/Inquisition) and others Loader version : 0.4.7 .3DS Filename : 1pucube.3ds Main chunk ID $4D4D at 0, size: 20768 bytes. Unknown chunk ID $2 at 6, size: 10 bytes. Editor chunk ID $3D3D at 16, size: 20752 bytes. Unknown chunk ID $3D3E at 22, size: 10 bytes. Unknown chunk ID $100 at 32, size: 10 bytes. Material block chunk ID $AFFF at 42, size: 190 bytes. Material name chunk ID $A000 at 48, size: 14 bytes. - Material name: Preview Material ambient color chunk ID $A010 at 62, size: 24 bytes. RGB byte color chunk ID $11 at 68, size: 9 bytes. - RGB byte color values: R:0 G:0 B:0 Unknown chunk ID $12 at 77, size: 9 bytes. Unknown chunk ID $A020 at 86, size: 24 bytes. Unknown chunk ID $A030 at 110, size: 24 bytes. Unknown chunk ID $A040 at 134, size: 14 bytes. Unknown chunk ID $A041 at 148, size: 14 bytes. Unknown chunk ID $A050 at 162, size: 14 bytes. Unknown chunk ID $A052 at 176, size: 14 bytes. Unknown chunk ID $A053 at 190, size: 14 bytes. Unknown chunk ID $A100 at 204, size: 8 bytes. Unknown chunk ID $A084 at 212, size: 14 bytes. Unknown chunk ID $A08A at 226, size: 6 bytes. Object block chunk ID $4000 at 232, size: 20536 bytes. - Object name: box_1 Object mesh chunk ID $4100 at 244, size: 20524 bytes. Vertex list chunk ID $4110 at 250, size: 5840 bytes. - Found 486 vertexes. - Vertex 0. X:-0.500 Y:1.000 Z:-0.500 - Vertex 1. X:-0.500 Y:1.000 Z:-0.375 - Vertex 2. X:-0.500 Y:0.875 Z:-0.375 - Vertex 3. X:-0.500 Y:0.875 Z:-0.500 - Vertex 4. X:-0.500 Y:1.000 Z:-0.250 - Vertex 5. X:-0.500 Y:0.875 Z:-0.250 - Vertex 6. X:-0.500 Y:1.000 Z:-0.125 - Vertex 7. X:-0.500 Y:0.875 Z:-0.125 - Vertex 8. X:-0.500 Y:1.000 Z:-0.000 Well there's quite a lot of unknown chunks there, presumably the author has only been able to unscamble part of the format, but we can see the beginning of the list of vertices and happily the number of vertices match ;-), The vertex coordinates in the 3DS file match the vertices coordinates from our OBJ file, except that the Z coordinate is negative. But there is no sign of any kind of conversion factor here, or elsewhere in the decode. The full decode of the 3DS is 131K, so forgive me for not including it here. I looked all through it, and no conversion factor could I find...

So the 3DS decode didn't reveal any conversion factor, but I think it was interesting to see 'inside' the file. I'm convinced the conversion factor has to be in the 3DS file somewhere. I need to think of another way of identifying it. Logically it has to be a constant, because I know the Poser world unit is a constant. Therefore the conversion factor is in every 3DS file exported from Poser. Other programs (such as Wings3D, Nendo, etc) will not have this same constant. So... I need to look for some byte sequence which is in every 3DS file I export from Poser, but which is never in any of the 3DS files I export from other programs. This is where I use that handy hex file compare program I mentioned in my previous post. I save two 3DS files out of Poser. One is our trusty 1 Poser unit cube, and the other is an object as different from the cube as I can get, a sphere at its default size. I open both of these files in HexCmp and start looking. Unfortunately I can't show you what I saw without doing a screen capture, which would be very large. Suffice it to say I find two sequences of several bytes which are identical and are not zeroes. One sequence is the word 'Preview' in ASCII, at 036h bytes in. And the other is a sequence '9D 73 CE 42 FF AF BE' at 026h bytes in. At this point you may be wondering why I am looking for a sequence of several bytes. Well, if the conversion factor is here it is not an integer. I know that because the Poser world unit of 8.6 feet is not any exact number of inches, and inches are GMAX's world unit, so it's got to be a floating point number, so it's got to be several bytes. Keeping this sequence of bytes at 026h in mind I open 3DS files created in other applications and look in that same place. None of them have that byte sequence... Interesting... Now better minds than mine might be able to work out the hex representation of floating point numbers, but I wouldn't know where to start. Not to worry, another search round the net reveals yet another shareware program, specifically Hex workshop by breakpoint software, which claims to be able to open a file in hex and interpret byte sequences in a whole range of number formats, just what I'm looking for.. I open one of my 3DS files exported from Poser and point Hex Workshop at that 9D hex byte 026h bytes into the file. Hex workshop shows a whole range of possible interpretations of the bytes from that point in the file, and the ninth one listed is... is.. is.. 'Float 103.22581'. At this point I treat myself to a beer.. Remember at the bottom of the second paragraph, of the second part of this proof we read the size of a 1 Poser unit cube in GMAX as (in inches) 103.226, and I asked you to remember that number? Well here in the 3DS file we have found the floating point equivalent of that exact figure (with a little rounding), and it is a constant in every 3DS file we export from Poser. I reckon we just found our conversion factor.. That floating point is four bytes by the way, so 9D 73 CE 42 is the hex representation of it. But there's more..

Sherlock Holmes, Hercule Poirot, Jules Maigret, Philippe Marlowe, and now Ian Porter.

Interesting observations Ian, but I'm sorry to say, wrong. The whole basis of your proof is the incorrect assumption that the conversion between Poser and 3DS formt is meaningful. This just isn't the case. Bear in mind that the the 3DS im/exporter were probably developed as an independent project for an individual developer and that, at the time there was no embedded scaling factors in Poser, the developer probably only took an eyeball estimate of the conversion factor that seemed OK, i.e. 1PU equals a round 100 inches and put that into the code without checking up whether there was an established "standard". When P5 was developed and a conversion factor was needed, it was likely that the 3DS conversion factor was the first or only actual embedded value the new developers could find, or they may in fact have gone through a similar process to yours to derive it from first principles via imports/exports from 3rd party apps, hence the 8.6 foot conversion in the first P5 release. However, in SR1 Curious Labs changed the conversion factors back to the 8 foot scale (1/3 DXF unit), which had long been stated and established. Implicit in that decision was the acknowledgement that the 3DS file importer/exporter conversions were (considered to be) incorrect. And that, basically is all there is to it. If Poser's (post SR1) internal scale gives 1 Poser unit = 8 foot (96 inches) then that is the standard conversion, whether you like it or not. As far as scales are concerned they are mostly arbitrary and the correctness or incorrectness any file conversions is a seperate question. Where a conflict has existed in the past, CL now seem to have decided on this, and wisely gone with the established value. And in doing so, they have effectively overridden the 100 inch rule. Interestingly, the one area where scales begin to become necessary is in areas of Physics simulations, and in P5's case, this means the Cloth room. It would be more interesting to measure the assumptions of scale (time is well defined) against a few simple gravity experiments in this area. Bill

Fascinating stuff, Ian. Go for it. I'll be glad if this scale business can finally be pinned down. It would be nice if the CL (or ex-CL) mob would chip in. mac

Okay, I can see ther are other posts in this thread, and i will read them. Clearly some of you believe I am wrong. OK, that's fine. Sine I wrote all of this offline I will post this final part. Please forgive me if I have stated as fact information which later turns out to be wrong. I will be getting some sleep in about ten mins, and then work tomorrow, so probably won't be able too reply for about 19 hours. Another trick Hex workshop has up it's sleeve is the ability to edit a hex file, and to calculate the hex representation of all of these different number representations. using its calculator I verify that 9D 73 CE 42 is the 103.22581 in Intel 32 float. Now I am able to change that decimal figure, see the hex representation of it. I quickly try 100.0 and am told the hex representation of that is 00 00 C8 42. I also try 96.0 and am told the hex representation is 00 00 C0 42. Now you may wonder why I am interested in these conversions. Well I would like to put my theory, that I have located the world unit conversion factor in the 3DS file, to the test. After all it may be another coincidence? If I am correct I should be able to overwrite the floating point conversion factor in an existing Poser 3DS file, with some other value, and if I import this into GMAX I should be able to predict the result. For our 1 Poser unit cube. If I relace the conversion float with 100, then GMAX should tell me the cube is 100 inches. If I replace the conversion float with 96, then GMAX should tell me the cube is 96 inches. If all of this works I think I will have proven my point. OK so I overwrite the four byte hex sequence at 026h into the 3DS file for a 1 Poser unit cube with 00 00 C8 42, save this file, and import into GMAX, and sure enough it now reports the cube is 100 inches exactly. I go back into Hex workshop and overwrite the four bytes with 00 00 C0 42, save this , and import it into GMAX and it reports the cube is now 96 inches exactly. In fact you can calculate any positive floating point value that will fit into an Intel 32 bit float and GMAX will apply that conversion factor to the model. And that ladies and gentelmen is where I sit down I belive. Thank you for your attention, and pleae tell me if I have left anything out. Epilogue and a little light hearted speculation. One question has me vexed, and I cannot find a satisfactory answer.. Where did that figure of 8.602 feet come from? Why is a Poser unit that size? I've check through all the units of distance I can find, and nothing is that length. So I'm sitting in the study, with my head in my hands, trying to think myself into the mind of the creator. My standard Poser figure is six feet, but what is 8.6 feet. Just then my wife comes in the study, sees me looking glum, and says "What's up?" to which I immediately answer "the ceiling." .... It's an old joke... Noo, it couldn't be surely... I get out my measuring tape and measure the height of the walls in the study. The wife looks pleased straight away, probably thinks I'm going to decorate or something... Well the walls of my study are about 7.6 feet high. I wonder how high the walls were in the offices where Poser 1 was written? Guess we'll never know...........

williamsheil, You have a valid argument. Just because I found that conversion factor in the 3DS files does not mean it is a true representation of the internal world unit of Poser. And I take your point that CL may have used that same figure erroneously in the first release of P5. It still leaves me wondering why a cube imported into Poser with the percent of standard figure height set to 100%, and then exported as a 3DS, is reported by GMAX to be exactly six feet high, and not some random size around that figure. If the conversion factor is meaningless that is rather a coincidence... Currently P5 patched reports 1 Poser Unit equals 8 feet, and that is a fact. Ian

ROTFLMAO !!!!! @ "I wonder how high the walls were in the offices where Poser 1 was written?" One never knows .......... . . . . . . . ;=] Ian, you're a genius!

• It still leaves me wondering why a cube imported into Poser with the percent of standard figure height set to 100%, and then exported as a 3DS, is reported by GMAX to be exactly six feet high* Because, by exporting it, you are subjecting it to exactly the same "incorrect" conversion factor in the exporter as you are with the figures and other props that you export and import. Just to clarify, however, there is no such thing as right and wrong so far as conversion is concerned, ever. Neither for that matter is any "proof" meaningful. Units in 3D graphics have absolutely no real "meaning". If I decide that the 1 Poser unit equals 1 Astonomical Unit (IIRC about 80,000,000 miles), I'm not "wrong", at worst I'm only defying convention. All that can really be established is "standards". Defining these, and embedding them in software is a good idea for CAD type programs, where you don't want two car designers, for example churning out a chassis and seating that vary in size by orders of magnitude. To some degree Poser, being oriented towards a specific type of representation can also benefit from this, but nevertheless, it all falls back to someone making an arbtrary decision somewhere. And, at the end of the day what makes a "standard" a standard is an open question. Generally it requires concensus. First call is of course the software creators, but if users or content developers decide to go their own way then their opinion is as valid as any. The real world is full of conflicting standards, and for for that matter full of conflicting standard making bodies, so where Poser users themselves only disagree by +/-10% we're still really in pretty good agreement. Bill

BTW I had a theory (as good as any other IMHO) that the if the first "test figures" were thrown together by developers from standard primitives, then the figure "head" could well have been a sphere based on a round 0.1 diameter. If so that would naturally have lead to a "standard" figure height of between 0.7 and 0.8 internal units - with the standard Poser scaling regularised from that measure sometime after (7.5 x 0.1 head heights for a 6 foot figure conforms exactly to the 96 inch scale). Bill

Bill,

All of you observations are good points but .....

( Just kidding ... there is NO "but" )

That is why I established a "standard" scale for Poser 4 and people are free to use it or not.

It is always the user's choice.

Standards always make for better productivity.

Can you imagine the automobile industry without any "standards" for tire size?

cheers,
dr geep
;=]

" ... could well have been a sphere based on a round 0.1 diameter."

Um, ....... and that would be 0.1 (what) diameter.?

pts
pixels
feet
inches
miles
centimeters
kilometers
footlengths per furlong
light years ...

BTW - Does anyone know the difference between a "year" and a "lightyear"?

Anyone, anyone ...

(pause)

ANSWER:

They are both the same except ...

The "lightyear" has less calories.
(nevermind, I CAN hear the "booing.")

cheers, (anyway)
dr geep
;=]

• Um, ....... and that would be 0.1 (what) diameter * 0.1 internal units (i.e. Poser Units). Regardless of any scaling/conversion factors, the internal unit representation is entirely consistent (and, of course meaningless). Bill

I don't know the first thing about US building standards, but over here in the UK, before we adopted the metric system, ceilings were 8' 6" high. :)

I can only assume that there have been multiple unsuccessful attempts to do this the easy way and simply ask the people at Curious Labs or Larry Weinberg.

After thinking about my previous post, I realised that my assertion that the 1 figure height equals 6 foot in GMax 'coincidence' could be passed off as just a result of incorrect conversion was not valid. I also realised that I had never really looked at the "Import at Figure Height" option. Now that I have, I've realised how significant it is to understand why the confusion has arisin. The import option creates (with a simple box prop) and object that has a Poser height of exactly 0.6975 units (measured and derived from the unconverted Waveform .obj exported file). This is obviously much smaller (by about 5 inches) than any of the standard Poser 3+ adult figures (which all seem to measure about 0.75 units in height). However, it is consistent with the Poser 2 figures included, and so we can only assume that there has been an effective change of "assumed" scaling between Poser 2 and Poser 3. The confusion in conversion factors is almost certainly the result of using this standard height and ASSUMING that this (still) represents six foot. It obviously doesn't in Poser 3+ world, but it is likely that the P5 developers found the (old) import scaling code and used it calibrate their scaling factors. It is also consistent with the 3DS export/import scaling, whether that was calibrated using the same assumption or possibly by the same import/export method (0.6975 equals six foot, which does give exactly Ian's scaling factor) or whether the code actually dates back to Poser 2 when it was basically correct, I cannot say. Regardless, there apparently has been a clear decision in the transition between P2 and P3 to change the average height representation with the figure height from P3 onwards being consistently half a head taller than their predecessors, and all based around the 0.75 Poser units (equals six foot) measure. Bill

(from #19 - above)

" 0.1 internal units (i.e. Poser Units). Regardless of any scaling/conversion factors, the internal unit representation is entirely consistent (and, of course meaningless)."

Bill,

I knew that, and was just being facecious, and trying to inject a little humor into the thread.

If any offense was taken, then I apologize.

cheers,
dr geep
;=]

No offsense Doc, just making sure that was understood (even though it has no meaning ;-)) Bill

(from #20 - above)

"... ceilings were 8' 6" high."

Sam,

That is an interesting observation but that would make it 8.5' as opposed to 8.6', no?

Who knows?

"Fractal Creations" (the originator of Poser (1))
(which was sold to)
"Meta Creations"
(which was sold to)
"Curios Labs"
(which was sold to)
???

Does anybody here know anybody ...
that might know anybody ...
... who worked for "Fractal Creations" when "Poser" was created, so that we might be able to put this "beast" to bed?

Just a thought. ;=]
(but probably not a very realistic one)

cheers,
dr geep
;=]

Bill, Yup. ;=]

There is no doubt in my mind that 1 Poser unit = 100 pyramid inches*. *See Pyramidology, Charles Piazzi Smyth, Egyptian Book of the Dead, Edgar Cayce

Poser scale is.... Annoying, and causes a host of problems as most modelling packages work in meters.

Jim, PERFECT !!! cheers, dr geep ;=]

Btw.. V3 is 721mm or 2' 4" in Lightwave, the program where she was created.

Which also correlates exactly with Maya's finding of her scale, and probably Max, Cinema etc.

So what you guys are saying is that size does matter after all. I knew women were just lying about that so I wouldn't feel so bad. In light of that I vote we find an equation to make the 8 foot thing work - the .675 idea is very emasculating :O Lotza luv - ramster

firt? Did you mean first? Yes, my keyboards gettin' tired - just like mois. ;=]

I could ask Larry. Since Poser is his brainchild, he'd know if anybody does what sizing he had in mind originally... and why it has changed over the years. We'll see if the crew is amenable to bribing by brownies and what kind of answers I can bring back. It won't be tomorrow, though. ;^) Carolly

Hi all, Thanks compiler. I think some would liken me more to Inspector Clouseau , except nowhere near as funny. Grey cat. I don't think it matters how big your cube started off. The important thing is it's dimensions in Autocad, just before you exported it. these were 1", 1 1/4", and 1/16" I believe 1 inch is Autocad's world unit, so when you export your cube it sides have lengths of 1.00, 1.25, and 0.0625. Each of these is the percentage of one inch that the fractional sides work out at. When you import this into Poser, it gets converted into Poser world units, whatever they may be ;-). So now you can spin the dials in Poser, and your boxes will move correspondingly. For your example it works out fine to assume that the world unit is 1 inch in Poser, because there is not other reference. It only starts to matter when you bring Poser figures into the scene (which are all less that 1 world unit tall) and you want to think of them as people of typical human height. As an aside, if you were creating a scene where the figures were supposed to represent wargaming model soldiers, then you could keep your 1 PU equals 1 inch world unit. And all your figures would be about 3/4" tall. I think this is an unusual case, but it shows you can assume 1 Poser unit is any size, if it fits your particular needs. Most of this thread is aimed at recreating 'real world' images,and interchanging models of specific dimensioned between users, hence the wish for a constant, coupled with ease of use. If I have misinterpteted your post, please let me know. Ian

williamsheil, I agree with you insofar as it is wrong to try and impose a standard world unit on anyone. Perhaps my 'proof' leans rather to much in the direction of 'I'm gonna tell you the real truth' and in retrospect I would change some of the wording. When you are shuffling pieces of a puzzle around, and suddenly they all seem to fall into place, there is a great temptation to shout 'Eureka'. Perhaps the 'proof' should be looked upon more as a technical curiosity? As I said in my first post, I am not suggesting anyone adopt 8.602, in fact just the opposite. In my reply to Grey cat above, I quote an example where a world unit which defies convention suits a particular purpose very nicely. Ian

maclean, If CL were here their input would be much appreciated, if only to tell us what this 'magic' number means. It would be nice to be able to pin this whole question down, but see my reply to williamsheil above. SamTherapy, Thanks for the info on UK standard building ceiling heights. It's interestingly close to the figure I'm looking for. Imkenzie, I can't find posts by CL or Larry Weinberg on this subject. I admit I haven't tried the simple email option. Jim, ROFL. Arcane knowledge comes to the rescue. MallenLane, Interesting info on V3. We are beset by problems. RAMNIMUS LOL. An eight foot 'thing' would probably not win you many ladies, but you could do great elephant impression by pulling the lining of your trouser pockets inside out to make the elephants ears, and then ..... Carolly That would be great. and last but certainly not least Dr geep Thanks for the support. Thanks for fielding the questions (which I sneakily avoided by sleeping). Thanks for pointing various links to this thread. 69.75 of your units is 5 feet nine and a quarter inches, I could go for that :-). Well I think you get the idea.... Hope I haven't missed anybody. Time for more sleep Ian

sleep? ................... already? ;=]

Hopefully Carolly will be able to get the straight dope from Larry and the ongoing myster can be solved. Of course, he will likely say that he has no idea what the answer is. It would be interesting just to know why Poser's "scale" is so tiny compared to just about every other major and minor 3D application. OTOH, Anne Marie Goddard is 5'9", use her as a ruler.

• I agree with you insofar as it is wrong to try and impose a standard world unit on anyone. * Which is absolutely not what I am saying. Standards are very useful, individually, and for Poser users the establishment of a standard interpretation would be a major boon. What is not useful is competing standards, at now I am seriously beginning to wonder at the metality at work here. First off, Poser (since P3) does have a standard scale: 96 inches equals one Poser unit. This was officially established by MetaCreations and Curious Labs in reverting to this scale conversion in P5 has demonstrated that it remains so. And of course the people making these decisions will have included Larry Weinberg. The conversion factors in the first relase of Poser 5 were incorrect, but we now understand (see Post 22) that this was an error, and also exactly how and why the error has recurred throughout Poser's development (i.e. the wrong assumption that the 0.6975 "average figure height" definition equated to six foot). However, in SR1 the conversion was changed to the official value, even though the fix itself is buggy (you have to reset the conversion factors in the General Preferences menu to get the correct conversions). One important point is that while so much was (apparently) untested in the initial release, when it came to making the fix an assessment and investigation would undoubtedly have been necessary to justify the effort of including the change. Therefore, we must assume that the 96 inch scale has been deemed to be the correct standard by either Larry Weinberg, or whoever was delegated the authority to make that decision. Before anyone tries the muddy the waters with examples about the mutability of the Poser universe or existentialist arguments regarding the "relative" meaning of measuring units, please understand that the whole point of establishing a "standard" system in the first instance is to establish a common language, system of metrics and understanding between users, at least within certain well defined constraints. Errors have been made in the past, and if you actually take time to read my post (22) Ian you will realise that my ephiphany was not the result of some realising some awe inspiring truth regarding the "meaning" of Poser units, but was in realising why errors (including your own) have consistently cropped up in applying the standard in peripheral areas of code. What does not serve the Poser community well is people peddling their own alternative and conflicting standards for their own purposes. And what I am beginning to sense is that pride rather than common sense is the main motive here. To reiterate, since Poser 3, the scale established by MetaCreations and retained by Curious Labs has been, and has never varied from one Poser Unit equals 96 inches. It's very, simple and easy for Poser users to understand and apply consistently. So why are Ian Porter, Dr Geep and others having so much trouble accepting it? Looking back at the initial threads for both Dr Geep and Ian Porter its clear that both were in fact unaware of the existence of an official interpretation of scale and that both believed they were performing a service to the community by calculating it through alternative means. Not withstanding the amount of time and effort that went into both of these presentations, the fact of the matter is that both were demonstrably incorrect. And to clarify that, not incorrect because of any "specific" meaning of Poser units but because both Ian and the Doctor initially presented their findings as being the "official" Poser values (see the title of this thread for an example). Now, I am being hard on Ian, because he has demonstrated a lot of willingness to acknowledge alternatives. But sadly I cannot say the same for Dr Geep. Dr Geep has recently been flooding the Forum with multiple threads "demonstrating" how complex and changeable the idea of scale in Poser is, and how much of a boon his clear tutorials are in helping novice both novice and experienced users wend their through this morass. This is all utter rubbish. Poser scale is easy and has been consistently 96 inches equals one unit since Poser 3. The sole purpose, I suspect, of Dr Geeps exercise has simply between nothing more than a childish attempt to muddy the waters and use his influence to confuse and baffle readers, rather than simply stating (which he could have done some days ago) that his initial assumption that the Poser Scale was a hundered inches per unit was wrong. Bill

Hey Bill, Do you know ronstuff? cheers, dr geep ;=]

I do have to say that Bill is right about the bug. I also remember a post in the now defunct P5 Beta forum that the incorrect conversion code was used. And, even though the standard has existed, not everyone follows it. I remember something about Blackhearted's Angelina character to be specifically scaled to be 5'2", but when I measure her in P5, she is closer to 5'7". I also remember something about Jim B. (please jump in Jim if you are reading, 'cause the cranial clutch is slipping) and his way of measuring to differing slightly from the P5 standards. It all comes down to choice. You are the only person that can choose what standard you follow. I choose to follow the 1 PNU = 96 in standard, because P5 does the measuring for me. Hence, in my world, V3 is around 5'11" tall. I do agree with Bill that an adopted standard would be great for business, but I don't see it happening..... Cheers!

Actually, all kidding aside, I do accept the 1 Poser unit = 96" rule, it also "feels" correct. Using this, as close as I can measure, Victoria 3 is 5' 10 1/4" tall.