I'm running into problems with one new model. Mostly the fact that the foot is moving parts of a thigh (Grouping and joints appear correct) and only on the Y and Z bends/rotations, not the X. Looking through to OBJ I found this entry: vn -1.#IND0000 -1.#IND0000 -1.#IND0000 vn -1.#IND0000 -1.#IND0000 -1.#IND0000 What do these lines do?

Are you sure the problem is in the obj? It sounds more like a pp2/cr2 thing to me.

Is this a cr2 or a pp2? Just off the top of my head I would sujest this If it's a cr2. Try making a copy, then deleting; all the channels except translation, rotation, and scale. In the figure section delete the weld statments and any inkyChain statments. If that works add things back selectivly, if not check your addChild statments.

No, that's an OBJ

If you import an object into Poser it will not bend, it will be rigid. To bend an object must either have a library file (cr2 or pp2), or a morph target.

Thank you, However this is the source OBJ for a figure. That entry is from an OBJ, not a CR2 or any other Poser Native file type. The OBJ had those entries and that's what I was curiuos about. Thanks anyway.

Sorry if I missunderstud you, I thought you were asking about a joint rotation issue, which would most likly relate to a cr2 and joint paramiters, not a Wavefront Object. I can't help much with the code in your original post, I think the "vn" stands for vertex normal, and somhow defines a vector for the normal (the way light appears to be reflected from the surface). As to what the specific lines in your example mean I don't know, but the hash "#" symbol represents a comment line in obj files.

I've had something like this when I had an error in my OBJ file, but can't remember the details any more. Sorry. However this is unlikely to affect Poser, since it ignores normals and these are normal definition lines. You could probably get rid of them by opening your OBJ in UVmapper and saving it out again without doing anything. Your actual problem sounds like a joint parameters thing...

I see you have the JPs sorted, scratch that...

"vn" lines in the obj are vertex normals. Your vn's seem to be corrupt (IND could be "indefinable"). What program wrote the obj? Poser doesn't use the vn's, but it needs to know the proper vn data, to rewrite the "f" lines. The corrupt vn's could cause problems. You could rewrite the vn lines with text editor, like vn 1 1 1 and save a new obj. Then, import the new obj in UVMapper, and export without normals, to make the obj more Poser-friendly.

Cross-post with EnglishBob, sorry.

English Bob and VK thanks for the input. Yeah the joints are sorted, you'd think that it would switch the related neighbor body parts with the section you just switched.. but it's poser, should have expected it not to work at the same time. VK, okay that makes sense. Wings3D wrote the original OBJ file. I'll try what you suggested. Thanks, Tom

Yes... I've come accross these bad lines in the obj files which ship with Poser. While experimenting with the PBooost 1.4 obj viewer, I found a whole bunch of files with these erroneous lines. I had to re-code the mesh loader to ignore these lines... by reading them as vn -1.0000 -1.0000 -1.0000. This works... the files load in, and there are no incorrect facets I can see. Looks like Poser ignores these lines... or corrects them when it reads. So I suppose the only thing to remember to do is remove the #IND bits prior to trying to manipulate the mesh in another application. H:)

Thanks H. So I can redo those lines in (Insert favorite editor) to vn -1.0000 -1.000 etc. That should fix some normal problems.. thanks. Tom

A bit late but the -1.#IND probably indicates an ill defined result, for example if you were to try to calculate 1/0, this is ill-defined and often produces a division by zero error. The upshot is that these normals cannot be calculated (effectively the result is nonsense).