Scaling objects for Poser Use
One thing Poser relies on is that Bodies are generally VERY small in a geometrical sense. Although most other modeling packages work in large unit sizes, Poser expects the entire body to be less than 1 unit high. Anyone familiar with importing 3DS or DXF files is likely aware that these other models are built on a much larger scale.
DMesh itself defaults to making objects 1 (one) unit high. When imported into Poser, the single object is then as big as the entire Poser person. Although you can scale the object down within Poser, there is a point where Poser can not resize it in small enough increments.
The preferred solution of course, is to re-scale the objects BEFORE bringing them into Poser. Go to the Object->Properties menu, and there is a section Scaling section. By default, the U and V scaling values are set to 1.00 By changing one or the other to 0.50, (or both,) you effectively scale the object to be half as big in that direction! No fiddling with OBJ rescaling software.
The exact meaning of U and V differs depending on the base shape you are using. Generally, u goes around the object (for things such as cones, spheres or disks,) and left to right for planar objects. V goes from the bottom to the top, except for disc-based objects, where it goes from the middle to the outer edge.
The only problem with this method of scaling objects is that it is so old, and so never-used, that the rest of the program has no idea it exists! Basically, the object will get REALLY small, and the 3D Preview doesn't have a clue!
So you have to fix the 3D viewport settings also. So click on the 3D Preview window to make it active, then right-click to bring up the context menu. From that, select the Viewport menu item so we can set the viewing properties to properly focus on the object. By default, Dmesh expects objects of unit sized or bigger - Poser however expects unit sized objects as the biggest. The first thing to change is the Near setting. A value of 0.10 works pretty good for objects with u/v scaling down to about 0.05, but below that you may have to go down as low as 0.01
Click OK and you can hopefully zoom in close enough with the mouse to see the object. The next step, and although not strictly required will sure be helpful to increase the speed (not to mention the texturing capabilities once those are activated,) is to set the Far value. Since DMesh expects the objects to be unit sized or bigger, there is a fair amount of leeway on exactly how much bigger the OpenGL camera can see. By default the Far distance is 40, which is pretty far away if you have scaled things down to one tenth.
The problem is that OpenGL will scale the lighting and everything else to fit within the distance between the hither and yon, or in this case, the near and far. What you want to do is reduce how far away the far point is, so that OpenGL can more easily focus the light on your object.
For a simple unit based cone scaled down to 10%, the farthest away it can be is... (that's unfortunately a little difficult to determine, since there is positioning optimizations in the 3D Preview code, which unfortunately forgot to compensate for this uv scaling factor!) So start by reducing the Far value by half then clicking OK and see if your object disapears. If so, then that's too far and you'll have to increase it. If it's still there though, cut it in half again. Carry on until it does dissapear, then back up one step (you know, double it.)
Truth is, this is a bit of hit and miss. Even though you see it now, once you start panning and rotating it, something may dissapear again. No biggy though, just go back and fix it so now you know how!
And the caveat? Most of the sample DMesh models were built with a MINIMUM
size of 1 unit. Most are much larger, and range in size from 2 to 12 units
in size. Once scaled down to sizes like 0.03 just to match the Poser expectations,
the OpenGL 3D Preview can get a little confused when you use too small
of values, even though they sound completely reasonable. Setting Near and
Far to 0.10 and 15 has generally given suitable results. I haven't tried
that with every case though, so feel free to inform me should actual usage
prove a little different.
More to Come...
(but feel free to suggest exactly what)