DAZ page always takes a long time to load for me (56 Kbps modem at my end). Seems to be a lot of data. Maybe it is timing out, if there is a lot of other traffic.

Hi, It's working for me, I was able to get to my account. (from UK).

Thinking futher on how to select one side. Would it be possible to select a polygon (using vertex normal) and then have the program work through and find adjacent polygons with the a very similar normal (the other normal of a two sided poly side would be 180 degrees reversed). Let's say you accept that an adjacent poly, with a normal up to 44 degrees different from the current poly, can be considered as being on the same side. Some method of manual editing would definitely be required, as the above method would 'fail' at a 90 degree (or greater) angle betwwen two poly's on the same side. But angle > 90 can create artifacts in Poser renders anyway due to it's attempt to 'round' the model. Just a thought. Ian

If you have a mesh that has been made two sided (as per UV mapper) would it be possible to make it single sided? I reckon you would need to select which side of each polygon you wanted to keep. Looks good.

I can see that a lot of thought has gone into this. It looks like this will be both an inside, and outside caliper, like the real-world one I have. I made a crude caliper back in 2001, and have many times wished I had added extra 'jaws' for inside as well. The digital readout idea is very innovative, and I can see you are trying every imaginable approach. I reckon you will find a way :-) Ian

Doc, Thanks, ting - You have mail ;-) Ian

who3d, Are you talking about the information on page 167? 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

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

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, 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

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...........

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..

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...

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.