Thanx ron... I thought I had done all that, but I'll check again..

The light I set to "reflect" the target in the mirror was set on that side of the figure that showed up in the reflection. If I rotate the camera, it shows clearly. And, as you said and as I expect, when I go back to the desired camera position, the effect of the light is not visible. But the REFLECTION in the mirror in front of the fiture shows the same area of the figure that was properly lighted when I rotated the camera. I'll now check my lights and see if I can find the suggested box to click to get the lights used in reflections. If not, the problem remains unsolved. If it IS a problem, I would think that the folks at Curious had better relook at the way they use lights in the scene.

Danke Schoen. DankuVell. Efkharisto! Toda Raba! Gracias. Grazie, Merci Beaucoup. and even thank you... And that's BEFORE I even try it out!

Now say I want to move a limb on the body. Using IK with Poser, the x/z/z coordinates are in reference to the orientation of the BODY (i.e., NOT the set). So I know, for example, that moving a foot in the "z" axis moves it forward or aft with respect to the direction in which the body points. This is a nice feature.

As a pilot, I KNOW roll, pitch, and yaw... at least from a global coordinate perspective (my own rolling, pitching, or yawing while seated is something else).

Now I want to roll a character I imported from Poser into Vue. What is the roll axis? One would think that yaw is rotation about the axis along the length of the body (say, for argument, a line between the center of the hip and the center of the head in a human); pitch uses an axis parallel to a line between the hips, so roll is like a sailor's walk.. rotation about an axis perpendicular to the yaw and pitch axes.

Well... I spent a bit of frustrated time trying to figure out how to position my Poser character in a Vue scene. It seems (I'm NOT sure of this) that using the little windows at the upper right of the screen MIGHT be relative to the model, somehow (OH HOW I WISH I COULD CONFIRM THIS AND USE IT WITH PRECISION!), whereas I KNOW that using the four view panel object orientation controls refers to global coordinates.

Either way, everything in the windows disappears when I try to rotate an object. So I can't see what I'm doing. Trial and error, with more error than patience.

Vue 5 SEEMS to address this issue. Can anybody vouch for the fact that it does? Because right now, I LOVE the render engine in VUE, and am learning to use its materials and foliage, but actually building a total scene is a pain in the nether parts. I've attached a thumbnail image of one result I was able to FINALLY get.

After I get myself a bit educated on VUE, I will consider upgrading to Vue 5 (alot of it's features seem rather excellent). Can't decide on 5PRO because have no specs. As for mover... well Vue basic's internal animation is simple, but it can't easily do things like make tires rotate when autos move (see, however, the EXCELLENT video on Vue 5 on the e-on website). Do I do my final animation in Lightwave? Will I be able to import my scenes (including foilage... but without the fractal procedural textures of Vue 5)? I think not... but I keep hoping and waiting.

The ideal would be an e-on product that worked hand-in-glove BIDIRECTIONALLY with other 3D products. POSER excels in animating creatures; Vue excells in fly-through animation and procedural terrain textures, and has an excellent renderer. And lightwave (modeler) is the way models can be built and textured, and it's animation capabilities (except for fractal and scale-based procedural textures)are better, IMHO, than the others.

NO product I know of (include that I can afford) does it all. How can we get the manufacturers of 3D software to make interoperability a priority?

Thanks for listening to this diatribe. I'm still stumbling around in the dark looking for an answer that allows be to be ARTISTICALLY (not programatically) productive.

Is it OK if I summarize? Although visualization, per se, doesn't NEED absolute units (meters or feet), if all 3D apps used units that had a well known relationship to a single set of units (e.g., meters or feet) it would be MUCH simpler to use models from various sources into the final scene (wherever THAT one is being built). IF ONLY ALL THE SOFTWARE VENDORS WOULD ALLOW EXPORTS IN STANDARD COORDINATES! Then, I wouldn't have to punch in all the conversion factors every time I move a mesh from one place to another. FOR SOME ENTERPRISING SOFTWARE GURU OUT THERE: Maybe this world needs a simple-to-use program that would read at least a few common formats (3ds, lwo, obj, etc.) and, by letting the user click a source of the model (max, lightwave, poser, vue, etc.), convert the mesh into the appropriate numbers for the target (destination) program.

Have just spent several days playing with my new Vue 4. I tend to agree that, if vegetation is where you're going, it far exceeds Terragen. But I'll have to see if the sky/terrain capabilities of Vue can do some of the astounding things I've seen done with Terragen. As for the interface... well... I have Poser, Terragen, Blender, Lightwave 7.5, and have played with Anim8tor and a few other lightweights. I think it's a very nice interface, theoretically, but with the following observed problems: 1) Vue distance inits have no relationship with reality that I know of. Kinda like Poser that way. Why can't folks trying to do 3D modeling software understand the foot or the meter? 2) I run a 3 gig CPU with 3/4Gig of RAM and a display board that supports Open GL. I STILL have to wait up to ten seconds to get my display updated after a trial-and-error attempt to rotate an imported Poser model. And then the display sure as heck doesn't look like Open GL, even though I clicked the box on the appropriate options page. Anybody have any ideas why this might be happening? Despite not being able to figure out x/y/z in Vue (no sweat in Poser or Lightwave) nor understanding just how Vue sets its rotation axes (roll, pitch, yaw) it IS possible to import a Poser figure and even innovate a way to fit it into a Vue terrain/veggie environment. T'aint simple, and very time consuming. Can anybody say if Vue 5 or Vue Pro would help me out? Thanx for listening...

Thanx for the reply, Joe. I pretty much discarded the first approach for the reasons stated, and will play with the second idea. But working with IK is still bad news for Poser Animation - even when working with the package's built-in walk designer. On too many occasions, the knee angle of the model "snaps" from a non zero value (slightly bent) to a zero value so that a jarring discontinuity occurs in the animation... or the knee joint snaps from vertical to one side, or something else that COMPLETELY ruins the continuity of the animation. As the feet are being locked from skating, this means having to search through many other parameters, hopefully (haven't always been succesful) to find where I can tweak a parameter so that it won't be noticeable, but so that the knee joint won't snap around without control. Has anybody else seen this phenomenon?

Yeah... that's what I meant about "turning up empty." Anybody know if the mesh is still available anywhere?

1. Poser 5 already handles zipped files (e.g., pzz, crz, etc.) It helps keep the disk space from climbing too rapidly, but it doesn't help the organization problem. P.S. Maybe I'm a packrat, but I find that I can do some things more quickly (maybe better sometimes?) in P4 than in P5. Render differences, yes... but also P4 has a memory of which textures have already been used in a scene. P5 does not... so if the same texture image is used for several parts of a mesh, you have to manually enter the same information over and over and over.... Anyway... this means that I keep everything in its uncompressed form so that both P4 and P5 can read it. Which also means.... it's ALL under the "Runtime" directory where P4 resides. YECCCCHHHH 2) If/when I finally decide that P5 is really doing what it was supposed to do when released (stability being a critical element, and the most recent version -SR4 - is actually not bad)... I MAY give up P4. Then comes the real question of this topic string. Where to from here? a) Remember the textures already used and make it easier to remove an entry from the list. As I may have many textures called "wood" (in different directories)... how bout giving me a better way of id'ing which "wood" it is? Has anybody ever heard of image previewing? b) Allow me to group morphs dynamically rather than having to use a word processor to enter the grouping command. Then let me delete all the morph targets in any selected group. This alone, when applied to V3 and similar models with huge libraries of morph targets, will do wonders to minimize the disk space. Once I have defined the shape of a character's head and most of it's features, I will probably never change or modify those morphs again. (I can always re-inject them if I intend derivative characters, or even save them off-line somewhere before the morphs are removed). Yes, I know I can use morph manager and a Python script which lists all the morphs with zero values, but these are time consuming because they are done with general purpose programs. And just think about how much faster it will be to find the particular morph targets you want (i.e., expressions, phonemes, etc.) b) Poser should keep separate "most recently used" directories for render output, scene input, image textures, etc. Right now, it actually only keeps the information necessary to save the scene or the render. As I like to keep my textures in a type-catalogued structure separated from the run time programs, I end up clicking many mouse buttons to get from deep within a D drive to deep within the subdirectories of "Runtime" on the C drive. c) Make it easier to maintain the list of "Runtime" directory tree roots(e.g., to "remove" one) that exists only for archiveal reasons) d) This message is already too long.... sooo.... If anybody wants to continue on this subject, let me know at bmoritz@exis.net.

I'm no newcomer to Poser. But I feel for the originator of this string, as I've been fighting a curious "feature" of Poser since Poser 4 was a baby (and into SR4 of Poser 5). Has anybody figured out how to switch between IK and non-IK for segments of an animation without screwing up previous hard work? Works fine for static images, but have yet to find it useful for animation. I sometimes use IK to first approximate the position of a limb target. It is also good to have on when playing with limb params further down tree (like subtly changing the collar without moving the hand). But it does TERRIBLE things to the rotation/bend/twist params of the hand! So, if I've used IK to help me establish a rough pose, I turn it off and fix the hand params. It'd be nice to use the strengths of IK/non-IK modes when posing key frames in an animation..... but, like I said above, Poser won't let me limit the number of frames that gets affected whenever I change modes.... so things REALLY screw up! When using IK continuously in an animation, I find limb angles "jumping" from frame to frame. So even staying in the IK mode, which would SIGNIFICANTLY HELP TO PREVENT SKATING (if it worked properly), isn't terribly helpful. I've e-mailed Curious a while back now, with thoughts of what might be looked at to fix the problem (including increasing the precision of the IK algorithms). But they've never offered me the courtesy of a reply. (ARE YOU LISTENING, CURIOUS LABS, THE FOLKS WHO CLAIM POSER IS A SUPERB ANIMATION PACKAGE?)

It's nice to see that y'all have such favorites, and I can even figure out what some of them might do from their names. But where do I find them?

Jeez! To have to take stitch together pictures! Wouldn't it be easier to use one of the new hires digital cameras and crop it to the proper aspect ratio?

It may not be as simple as a reversed normal. I recently built a simple model of a picture in a frame in Ligthwave. It was exported as an obj and picked up by UVmapper.

I used UVmapper's "box" mapping to find out that the "picture" insert actually had TWO normals... and that each side of the picture had it's own texture map. Interestingly enough, Poser picks up BOTH sides of the pic and tries to render them too. Results.... interesting to say the least.

Solution. Assign each side of the pic a different material name (e.g., "front" and "back"). Make the "back" material transparent with no colors. voila!

Hope this helps... or maybe all you pros out there already knew this...

Is there a reason to go Vue 4 instead of Corel Bryce?