I just got feedback from a beta tester and this is one thing he said that I don't understand. - "There are the geometry file in right folder, but prop file includes geometry too. Need to make as extended geometry." Whats that mean, and how do I fix it? Thanks.

Look at the *.pp2 file in the libraries/prop directory. Maybe the external reference is missing there and the geometry is included. In this case the external geometry is never used.

It sounds like your prop has the geometry embedded in it. I don`t know how to fix it, but someone else will know.

Possibly trying to suggest making an imbedded geometry into an external geometry?

Some professionals like to save the prop out of Poser as an obj file, then replace the geom co-ordinates in the pp2 file with a line that refers to the obj file. However, there's no advantage to it IMVHO, unless one plans to allow redistribution of modified pp2 files, or to create multiple props based on the same obj file.

Making a prop use external geometry: - load the prop, set all scaling to 100%, set all translations and rotations to zero - export the prop as Wavefront .OBJ file - move the .OBJ file to the correct geometry folder replace the lines prop [yourpropname]:1 { geomCustom { numbVerts 9869 numbTVerts 9986 numbTSets 38764 numbElems 9692 numbSets 38764 v -0.075841 0.337970 -0.009842 v -0.075799 0.345500 -0.009542 ... } } with prop [yourpropname]:1 { storageOffset 0 0.3487 0 objFileGeom 0 0 :Runtime:Geometries:[yourfolder]:[yourOBJfilename.obj] } That's it.

There are several reasons to do this. One is that DAZ, and possibly other brokers, requires it! I find an external .obj easier to do last-minute edits on, particularly cleaning up of UVmaps. An external .obj can be imported directly into applications other than Poser, without having to go through Poser first. And lastly, an external .obj can save on the total file size. In my last outfit, I had the same .obj referenced by two different smart-props; one smart-propped to sword belt, the other smart-propped to right hand. In the case of something like a colonade of Doric columns the saving in file size could be huge.

"...or to create multiple props based on the same obj file."

Miss Nancy and Nomuse are right. To elaborate, Miss Nancy means several copies of the same prop appearing in the same scene. For example, if you have a scene with 10 identical telephone poles in, why load the geometry same geometry (that is, vertex and polygon data) ten times? As nomuse says, same idea is true for distributing props which use the same geometry.

Also as nomuse says, some people are sticklers for external geometry in all props; I believe that the Poser Pros' guideline for submitting props also demands external geometry in all. But I agree with Miss Nancy, if only one of the prop (for example, a sky-dome) will appear in any scene or you are distributing two props which include the same geometry, which doesn't happen too often, then externalizing geometry saves nothing and so is pointless.

Pointless, except for the thing that nomuse mentions: It's far easier to change mapping and make other minor edits in something that has external obj's. Besides, as svdl clearly showed, there's nothing difficult in doing it (or for people even more lazy, such as myself, there's PWizard who, among other things, has a built in obj-ripper to do the dirty work G)

There's another advantage that no one's mentioned yet. If props have embedded geometry, every time you save a figure complete with it's parented props, you're saving huge quantities of vertice information, instead of a single reference line. The same applies to saving .pz3s with props in them. Embedded geometry has NO advantages whatsoever. Not one. mac

It does have the advantage of being one file and not spread between two.

Thanks for everyones input, i just bought Pwizard, in hopes to make things less complicated. Thanks again!

"It does have the advantage of being one file and not spread between two." I'd agree with that - no chance of the reference getting broken. If you simply must have the .obj file, there's no need for text editors or purchased software. Just fire up UVMapper and drag that sucker (.pp2) onto it. Yes, UVMapper will read the embedded geometry in prop and hair files. It may even grab an .obj out of the middle of a html file for all I know. Once loaded, just do Save Model and voila, you got your .obj and you can map it too - Neat!

I preferred the old poser 4 cr2 file that had the object embedded in it. I didn`t know that pp2 uvmapper thing.

I can see scenarios where you save on disk file size, but is Poser actually going to use less memory by "instancing" a single external .obj - or are those 10 telephone poles going to use the same memory either way? I've never cared for Poser's way of scattering files to hell and gone for a single item so I usually prefer every bit of consolidation. It make sense that some common geometry like the (human) figure .objs should be external because they're used by many characters. OTOH, props are nearly always unique. As long as I can access it the geometry if I need to, I'm happier with a single file.

It is highly unlikely that any version of poser does instancing whatever way the object is loaded.

Yeah, it was pretty much a rehtorical question. External, internal, File->Import->Wavefront... I think it's all the same hardware load, otherwise, Poser should load copies 2-n just about instantly.

Yah. Even given an extreme case -- such as a brick wall built from one source object -- the only savings are in the cr2/pz3 file size, and the size of the download and the final Runtime folder. The actual scene opened in Poser will be the same RAM either way. My main reason for making the obj external (besides external pressures from brokerages), is consistency. All my cr2's reference external obj, and same for hr2 (which is allowed int or ext in the same fashion as the pp2). It just strikes my simplistic mind as "cleaner" to put all the geometry in one place and to have the format of all the library files as similar as possible.

One reason for using external geometry in props would be that you can then have several prop files which reference the same geometry, but load different texture combinations, neatly getting round the problem of applying MAT poses to figureless props.

18 - There is an order to that way. For me, I'd like to able to delete something without looking at notes, using a utility or opening a Poser file to track down references - just delete one file or folder. 19 - Not a scenario I've run across but certainly valid one for saving disk space. Otherwise, internal functions the same way, simply using different texture references.