It seems that what is needed is a system of special comments that can be put in an .OBJ file to let it transmit a tree hierarchy of groups of groups of groups like Bryce's internal structure has. Such a format could be, e.g.:- #gbeg MAN 1 f #gend MAN 1

I heard this tip: In the pose in Poser, put a prop X high above the figures and a prop Y very low below the figures, so the distance XY is bigger than any other width or the pose. Then export each figure in the pose seprately, and with each figure the prope X and Y. Then when you import the figures into Bryce, they will be all the same scale. Move the figures ao all the copies of X and Y coincide. Delete all copies of X and Y; keep one copy of each if you want them in the scene.

I understand what DD is saying; but, for the effect that I was thinking of, I would still want completely solid 3-dimensional figures. Why can't Bryce and also Poser have an option for more than one visible 3D object to share the same geometry arrays to save memory space?

I.e. make a render of him and use it as a background tiling. That may look OK at a distance, but if I am fairly close to the rank of men, I see different men of the rank in somewhat different directions, and also one of the men or his gun/etc may cast a shadow on another of the men. I still say that Bryce needs "Instances" or whatever is called. This could be implemented by letting the Bryce menu commands "duplicate" and "replicate", when called on the object X, merely make duplicate or multiple pointers to X's geometry etc, and that geometry etc would be itself only copied (using much memory space) if (a) the user actually alters one of the multiple instances of X and also (b) the user answers "no" to a MessageBox asking him "Do you want to alter all instances of this figure?".

The end of the last message should read thus, but the messager didn't like angle brackets nested 3 deep:- ... onto the wearer's color map AND BUMP MAP.

I again tried to give a Bryce 3.1 image a pattern of bumps read from a graphics file bump map, but I could not. I found that, in the Materials Lab, if one of the columns A B C D contains a texture read from a graphic file rather than a (texure made from noise in the Deep Texture Editor), that column is only obeyed if it is selected in the top part labeled Color', rather than in the lower parts labeledValue' or Optics' orVolume'. I can use a graphic file as a color map or an ambience map or a transparency map, because they all appear in the `Color' part; but not with bump. This is a nuisance. Bump maps can be used in Poser (a *.BMP file renamed *.BUM, I think), but not in Bryce 3.1 . E.g. I have 3 Poser models of backpack devices; easier than separately posing several backpack straps as multisegment uncooperative serpents of articulated parts, I would like to make their backpack straps in a Bryce scene by painting them onto the wearer's color map <<>>. PLEASE!!!

If this idea is implemented, Bryce would have to leave the mesh exactly as it is and not divide the polygons into all triangles. E.g. I have seen real fishing net, and it does <> have a diagonal thread across each mesh square.

I just tried it, with Bryce 3.1 . I textured the ground plane and a cube with a black-and-white cartoon that I had made a while ago. With the cartoon as diffuse color texture map, each face of the cube was a copy of the cartoon, and the ground plane had an infinite tesselation of the cartoon, as expected. But with the cartoon as bump map, all that happened was a line of `black' (i.e. a bump map groove) along the +X edge of where the cartoon shound have been; on the ground plane this produced an infinite pattern of thin parallel lines. Neither had apparent depressions in the shape of the cartoon image, although the sun was at a low angle.

My Bryce 3.1 routinely read in .OBJ files OK, and I have created several objects (see the Poser Fun Stuff, or my WWW site http://www.buckrogers.demon.co.uk ) in .obj with texture maps. The trick is: in the .OBJ file only use lines starting with one of these:- # comment v vertex vt texture map coordinates vn a normal at a point as a vector, must be length 1 f face g start another group If the .OBJ file contains other sorts of lines such as usemtl', than some 3D packages may moan about version. Also, some packages need .OBJ files to start with 3 special comment lines stating how much space to allocate for vertices and faces and normals. Out-of-range numbers inf' lines may cause trouble.