Hi, I have made a prop with several morphs. I used the load morph target option in poser to load all of my morphs then saved the file as a PP2. Doing this also creates a PMD file which holds the morph data(I presume)

Now when I strip the geometry from the PP2 and replace it with a link to the .obj the morphs no longer load with the PP2.

Does anybody know why this is and how I may be able to fix it so that my PP2 references the .obj but still contains data for the morphs?

Thanks

John

I think pp2s are supposed to contain geometry. You can take an obj. and edit the extension to make it become an pp2. or edit a pp2 extension to become an obj. Stripping out the geometry is pointless and is possibly harmful.

Paloth, I am no expert, but things I have read indicate my understanding is different than yours. Perhaps you're right, but...

The point of referencing the external obj file is so that loading multiple copies of the prop does not load multiple copies of the geometry. Only one copy gets loaded. Same deal with morphs.

This was told to me by Larry Weinberg, creator of Poser, but maybe I misunderstood.

Quote - The point of referencing the external obj file is so that loading multiple copies of the prop does not load multiple copies of the geometry. Only one copy gets loaded. Same deal with morphs.

This was told to me by Larry Weinberg, creator of Poser, but maybe I misunderstood.

 ...are you hinting that Poser hides inside it support for instancing ?

Thank for your input.

I would prefer if I could refernce the .obj for the reason BagginsBill gave.. it would (I presume) save resources/memory to use the obj.

The point of referencing the external obj file is so that loading multiple copies of the prop does not load multiple copies of the geometry. Only one copy gets loaded. Same deal with morphs.

I didn't know that Poser could do instancing. Is that actually what happens?

If pointing multiple pp2 files to one obj. doesn't actually save memory it would be pointless*,* but supposing it does?... This might open up a world of possibilities. I shall experiment.*

Quote - ...are you hinting that Poser hides inside it support for instancing ?

No I don't think it does. There is a copy of every actor in its morphed/posed/translated/rotated/scaled state.

What I was referring to was that the information (about the base OBJ and base morph deltas) is kept once per OBJ or PMD file - in a lookup table for each such file. When props or figures are instantiated these referenced files are reused.

Not so when the geometry is buried in a prop file - then Poser makes the assumption that each time you load the prop, it needs a fresh copy of the base geometry. I don't know why. Seems a filename and timestamp would work about the same as a referenced OBJ file.

Paloth - I am sure every time I clone a V4 figure, 20MB of RAM is added. But the base OBJ is not loaded again. In other words, 1 V4 is 20 MB for base OBJ, and 20 MB for the posed figure that derives from it. 2 V4 is not 80 MB, but just 60 MB - 20 MB for base OBJ, 20MB x 2 for two instanced and posed figures. 10 V4 is 220 MB - 20 MB for base OBJ, 20MB x 10 for instances.

In most cases a prop is just an obj and a texture. I'm wondering how significant the memory savings would for an average prop to reference an external obj.

you can edit General Preferences, so that it doesn't make a .pmd file.  the morphs will save in the prop file.

pmd files influence my buying decisions,  it's a pita file path to maintain when organizing my library.

@MistyLaraPrincess.. You mean you would prefer to buy a product without the PMD file? I guess to turn PMD off you uncheck external binary morph targets in preferences??

I will give that a try and see if I can then reference the obj.

Quote - In most cases a prop is just an obj and a texture. I'm wondering how significant the memory savings would for an average prop to reference an external obj.

That's an important question, for the effort involved in saving the memory of something trivial is probably unjustified. Your typical prop is pretty small - and almost never loaded twice, let alone dozens of times.

But - still. If it were a bar glass, or something similar, that gets replicated even in a real life setting, then maybe it's worth it.

Blades of grass - absolutely worth it. Which is why it's so important in general, but not so much to the NVIATWAS crowd.

the external binary morph won't make an obj file.

! i think i saw a script to extract embedded object.  doh, where was it ..

not sure if it was a python script or the editor from D3.

Quote - In most cases a prop is just an obj and a texture. I'm wondering how significant the memory savings would for an average prop to reference an external obj.

Very minimal.

External geometry for props is mostly something people do because it makes development easier (OBJ can be replaced without disturbing the PP2) and was particularly useful when making a set of PP2s for material variations (back in the P4 days when this was the easiest way to change the materials on a standalone, unparented prop).
It's also a (notional) requirement of most Poser brokerages.

I understand..I have a script that strips the Obj from the PP2 so i will try that :)

@nruddock.. is it a requirement of Renderosity Marketplace to have the PP2 reference an obj?

Quote - Stripping out the geometry is pointless and is possibly harmful.

..harmful? what your computer explodes? you get a case of the weeping bueboes....?

.harmful? what your computer explodes? you get a case of the weeping bueboes....?

Maybe morph linkage will break?

It's also a (notional) requirement of most Poser brokerages.

Not at Renderosity*.

"

.harmful? what your computer explodes? you get a case of the weeping bueboes....?

Maybe morph linkage will break?"

annoying.. but hardly "harmful"

annoying.. but hardly "harmful"

Not in your book maybe. For me, nothing destroys a good mood like something annoying. *

Quote - I think pp2s are supposed to contain geometry. You can take an obj. and edit the extension to make it become an pp2. or edit a pp2 extension to become an obj. Stripping out the geometry is pointless and is possibly harmful.

Haven't had time to read the whole thread, but felt that I must comment on the above  before someone takes it seriously. Absolutely none of it is true!

Quote - If pointing multiple pp2 files to one obj. doesn't actually save memory it would be pointless, but supposing it does?... This might open up a world of possibilities. I shall experiment.

Perhaps a whole world, but certainly not a whole new world, this has been standard practice since at least P4, and probably right from the first Poser version.

"Stripping out the geometry is pointless and is possibly harmful."

"..harmful? what your computer explodes? you get a case of the weeping bueboes....?"

Stripping out the geometry is not pointless, for reasons BB explained, and it is never harmful, and as nruddock said, many brokerages insist that you do strip out internal geomCustom and use an external obj file. I strongly disagree with this total ban on geomCustom and think it is very stupid, but it is certainly not harmful. In props neither internal geomCustom nor external obj files are harmful, except for the extra memory burden associated with multiple instances of internal geometry. Figures are a diffrent story, and it is almost never a good idea to use internal geomCustom in figures, except in the developement stage.

Attached Link: http://www.renderosity.com/news.php?viewStory=13759#4

It is according to the "MARKETPLACE QUALITY STANDARDS AND GUIDELINES", as per the attached link (but they don't always enforce it according to kawecki).

My guess would be that if the morphs broke when you externalised the geometry, you made an error.
The way to check is to compare the number of vertices in the OBJ with the delta count in the PP2.

Quote - (but they don't always enforce it according to kawecki).

I would take that as confirmation that they always enforce it.

Ok thanks for all of your help everyone :D

I have it working now by using MistyLaraPrincess's Idea of using internal morph Data.

I will still look into making it with external as well as I am now curious as to what I was doing wrong.

What is everyones view on external Vs internal morph data? is there a clear advantage of either? I have read that using external means you can use the morphs on other figures e.g. A3 and V3(but they dont usually look right) If that is the only advantage then that is not worth it for this item.

"... edit a pp2 extension to become an obj ..."

More of a curiousity than anything else - I knew that UVMapper would read the embedded geometry in a .pp2 or .hr2 file, so I tried renaming a .pp2 with embedded geometry to .obj. 3DExploration, Art of Illusion and Carrara 6 Pro imported it just fine while Vue 6 refused. So, depending on the application, the 'trick' might work. It probably depends on how lenient the Wavefront (.obj) format import routine is. I suppose it might be a minor convenience in some rare cases. I don't see any advantage if you're only using Poser though.

Quote - "(but they don't always enforce it according to kawecki)."

I would take that as confirmation that they always enforce it.

Lest anyone think I'm just making stuff up, here is the file hierarchy from an available product at Renderosity.

*Dragon of Plenty_readme
License.txt

RuntimeGeometriesPaloth
Dragon of Plenty5.obj
saddle.obj.

RuntimeTexturesPalothDragon of Plenty

Body and TentaclesMppedJoined2_3.jpg
fruitBump.jpg
fruitColor.jpg
gearBump.jpg
gearColor.jpg
Gold.jpg
GreenBlue.jpg
GreenPearl.jpg
linearLight.jpg
pinkishOrange.jpg

RuntimeLibrariesCharacterPalothDragon of Plenty
Dragon of Plenty.cr2
Saddle and Basket.cr2

RuntimeLibrariesMaterialsPalothDragon Skin
Blue Green.mc6
Gold.mc6
Green Brown.mc6
Green.mc6
Pink Orange.mc6

RuntimeLibrariesPosesPalothDragon MAT Poses
Blue Green.pz2
Gold.pz2
Green Brown.pz2
Green.pz2
Pink Orange.pz2

RuntimeLibrariesPropsPalothFruit and Fruit Basket
Apple Basket.pp2
Apple.pp2
Banana Basket.pp2
Banana.pp2
Grape Basket.pp2
grapes.pp2
Melon Basket.pp2
Melon.pp2
Mushroom Basket.pp2
Mushroom.pp2
Mystery Fruit Basket.pp2
Mystery Fruit.pp2
Orange Basket.pp2
Orange.pp2
Pineapple.pp2*

Notice that the fruit props do not reference anything in the geometry file.

More of a curiousity than anything else - I knew that UVMapper would read the embedded geometry in a .pp2 or .hr2 file, so I tried renaming a .pp2 with embedded geometry to .obj. 3DExploration, Art of Illusion and Carrara 6 Pro imported it just fine while Vue 6 refused. So, depending on the application, the 'trick' might work. It probably depends on how lenient the Wavefront (.obj) format import routine is. I suppose it might be a minor convenience in some rare cases. I don't see any advantage if you're only using Poser though.

Yes, provided that the geometry is embedded, renaming the .pp2 extension to .obj will create an obj. I didn't know about Vue's difficulties. I read about this in an old thread and when I tried it, it worked. It is mainly useful for extracting objs from pp2s with embedded geometry (and not at all useful for pp2s with links to the geometry folder*,* of course*.)

Quote - "I think pp2s are supposed to contain geometry. You can take an obj. and edit the extension to make it become an pp2. or edit a pp2 extension to become an obj. Stripping out the geometry is pointless and is possibly harmful."

Haven't had time to read the whole thread, but felt that I must comment on the above  before someone takes it seriously. Absolutely none of it is true!

Actually, it's true that I thought this. **
**

**
**

"Yes, provided that the geometry is embedded, renaming the .pp2 extension to .obj will create an obj"

I'd say that strictly speaking, you're not creating an .obj. It's more a matter of luck that some applications ignore the Poser code and read the valid vertex and face entities. Vue apparently doesn't (for the one file I tried) and DS3 appears to read it but I couldn't see the object as anything but a tiny cube and then only when selected. OTOH, I could see the same file after saving it as an .obj out of UVMapper. That may have had to do with scaling or something, I didn't play with it very long. I'm assuming that for the apps where it does work, it would work equally well with a .hr2 with embedded geometry. The moral being, it's not a valid .obj file that you can just use in anything. And pity the person who renamed their prop, modified & saved it, expecting to rename it back and get a valid .pp2 :-)

Quote - > Quote - (but they don't always enforce it according to kawecki).

I would take that as confirmation that they always enforce it.

I have more than a thousand products sold and most of them haven't external geometry and my customers are very happy with mine products.

As for memory use I made some tests, I used neraida hair because it has a relative big obj file and a small cr2 with no morphs.

Neraida Hair
obj = 9M  cr2 = 100k no morphs

0 - 700M
1 - 741M + 41
2 - 784M + 43
3 - 817M + 33
4 - 848M + 31
5 - 884M + 40

Loaded the same hair as a prop

0 - 700M
1 - 740M + 40
2 - 780M + 40
3 - 822M + 42
4 - 864M + 44
5 - 905M + 41

Loading 0ne or two copies gave the same result, loading 3 and 4 copies gave less memory usage in the external geometry version and then loading more that 4 returned to be the same thing external or internal

iffn anyone is interested, just bought the Greenpots set in the Prime products,

and it is all embedded geometry.

I think the memory saving would be more benificial where you use the prop many times in a scene. Say an auditorium with a 100 or more chairs.

I seem to remember using that trick back when I was using Poser 4. The saved PZ3 file was also much smaller and faster loading.

Quote - Yes, provided that the geometry is embedded, renaming the .pp2 extension to .obj will create an obj.

No it won't! What you have created is a corrupt file that contains elements of the obj file specification, plus a lot of junk that should not be in an obj file.

This needs to be understood. You can't convert a pp2 file to an obj file, or vice versa, by changing the file extension. It will just be what it originally was, but with the wrong file extension. An obj file renamed as a pp2 just won't work. With a pp2 renamed as obj, you may be able to import the geometry into Poser, if, and only if the file uses geomCustom. Although you may be able to import the geometry from such a file, it has NOT been converted to a true obj file, because it contains a lot of useless junk that does not belong in an obj file, and if the file uses an external obj reference it just won't work art all. Try saving a the Poser box.pp2 as "box.obj", you might try saving a jpg file as obj as well, you have just as much chance of it working.

The reason saving a pp2 as a corrupted obj file may work, is that if (and only if) the file contains a geomCustom section, that section will be the same as an uncorrupted obj file. If you are lucky poser will ignore the corrupt part of the file, but there is no guarantee that the corruptions will not cause problems in some cases. The obj format can be considered as a subset of the pp2 format, but a pp2 file is never the same as an obj file. If you don't believe me, try looking inside the files and see for yourself.

LB, I agree with you from a semantic point of view. They are not the same. Same means identical.

However, we lack a spec for OBJ. It would seem based on how things have been written that lines of text in a file that do not appear to follow the OBJ object syntax are simply ignored. It may be that the original authors of OBJ format actually said "Anything that does not begin with v, t, f, etc. is a comment."

In which case, the rest of the pp2 file is considered a comment. If that's the rule (and we'll never be able to prove it - I think the people who would know are dead) then it would be technically accurate to say that any file that contains geometry in OBJ style is an OBJ file, even if it contains a million lines of other stuff.

Certainly that's how I wrote my OBJ parser.

Quote - However, we lack a spec for OBJ.

The spec exists as extracts from Alias|Wavefront, Inc. manuals (OBJ -> http://paulbourke.net/dataformats/obj/ MTL -> http://paulbourke.net/dataformats/mtl/) Because the format is line based, you don't have to do anything sophisticated (or even bother worrying at all about rubbish) when parsing to effectively filter out just about anything that isn't a "real" part of the geometry.

P.S. I'm very much still alive :tt2:

If you want to convert obj into pp2 or pp2 (with internal geometry) into obj you can use PropViewer3.

You can also convert from 3ds and ply

Renaming a pp2 extension into obj extension with a multi-prop pp2 into obj will fail because in each internal prop the vertices count start from one, so the second prop faces will be referecing the vertices of the first prop.

Apparently, even AutoDesk (as far as I can tell, the closest thing to a descendent of the primordial Alias-Wavefront now extant) uses a 3rd party .obj import module. The developer has some opinions on some apps formatting.

http://www.guruware.at/main/ 

From a practical standpoint, for me, I'd say Animal Farm rules. Some .objs are more equal than others.  If it doesn't work in some of the most widely used 3D apps, then whether the format is, in theory, valid is academic IMO. I could probably use Base64 to include thumbnails in an .obj file for my own use, but I'd be sure to preface that data with the apparently de facto standard # comment.

bagginsbill,

Quote - However, we lack a spec for OBJ.

Perhaps we do lack an official specification, but there are certainly plenty of unofficial ones, and it seems to be generally accepted in those that "#" should be used to start comment lines in obj files. Lines that do not comprise part of the geometry or actions to be performed on it, and do not start with "#" are by common consensus, outside of the specification, and do not belong in a compliment obj file. Granted, it is the Poser parser that really matters here, not the spec, but who knows how it works? Not me.  

Quote - "Anything that does not begin with v, t, f, etc. is a comment."

Perhaps that is so, but the "etc" comprises quite a long list, including at least a couple of words used in common language.

Quote - ... then it would be technically accurate to say that any file that contains geometry in OBJ style is an OBJ file, even if it contains a million lines of other stuff.

You make a good point... but. If I take a Microsoft Word document (.doc) version of War and Peace, paste the geometry from an obj file into it, and rename it with an obj file extension, then try to import it into Poser, Poser may well be able to load the geometry, but I think it is stretching the point a very long way to say that you can convert Word documents into obj files by changing their file extension to obj.

I guess just about any file type can be made "to become an obj" by that logic, but personally I still think that War and Peace, even with a bit of geometry code added, and the file extension changed, is still a novel, not a Wavefront object file, and that an "obj" file with all the contents of a pp2 inside it is just a pp2 with the wrong file extension, not a Wavefront object file.

I have said it before on a number of occasions but it does not seem to sink in. I think it is very important that this misinformation is stamped out before it starts to cause problems, so I will say it again.

You can not convert a pp2 file into a valid obj file by changing its file extension. Attempting to use the corrupt obj files resulting from such a renaming operation, as if they were valid obj files, is dangerous and can trash your scene.

I already know that you can't can't turn a pp2 file into a valid obj by changing the extension. That would be logically impossible as a normal fully functioning pp2 could never be a member of the class "Wavefront  Object file", as to be a functional pp2 it would by necessity have to break compliance with the Wavefront Object file specification.

So in light of the logical impossibility of the claim, it irks me considerably that I have had to do the legwork to prove it in an operational sense.

Never the less, when someone obviously intelligent, and well regarded as bagginsbill, makes the suggestion that it may be "technically accurate to say that any file that contains geometry in OBJ style is an OBJ file" (and to be fair, note that bagginsbill stated this as a hypothesis not a fact). Then I feel obliged to take the suggestion seriously and put it to the test.

I have done that, and can now state categorically that pp2 files renamed as obj, even if they contain embedded obj geometry, do not function as valid obj files in P6 (and probably not in any other Poser version). I have proved this. And if you like you can follow the proof, and prove it for yourself.

Attached above is the text of a pp2 "CUBE.pp2". This is a perfectly normal pp2 file, produced by importing a cube geometry into Poser, then saving it to the Props palette, but if you prefer you can use one of your own pp2 files for the experiment.

Save the CUBE.pp2 under the libraries/Props folder. Make a copy of the CUBE.pp2 and save it to the Geometries folder, then rename the file extension so it becomes "CUBE.obj".

Open the original CUBE.pp2 (the one under the props folder) in a text editor and delete the entire geomCustom code block. Replace it with an objFileGeom call to the "CUBE.obj":

prop cube
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Geometries:CUBE.obj
    }

We now have a valid pp2 file that calls an corrupt obj file. We can load the pp2 in poser and see if the corrupt obj file will function as if it were a valid obj file. Before we do that let's be absolutely clear on what we are testing here. It is this assertion:

"If you change the file extension of a pp2 file that contains embedded geometry to "obj", it will function in Poser as if it were a valid obj file."

Now load the pp2 file from the Props palette. What happened? Did the cube load as a functioning Poser item? Do you even see the cube in the scene?

I performed the experiment five times, closing and restarting P6 on each occasion. The cube did not load as a visible item in any test. On each iteration, loading the pp2 that referenced the corrupt obj file trashed the Poser scene, causing all other loaded items to disappear from the scene, and it was no longer possible to load any visible items into the scene.

I really do hope I don't have to say this again. Changing the file extension of a pp2 file to obj does not convert it into a valid obj file, or a file that will function in Poser as if it were a valid obj file. The resulting corrupt file does not function in the same way as a valid obj file, and in many cases won't function at all, and causes the scent to be trashed.

We knew from the start that a pp2 could not logically be a valid obj file, but now we have proof that it does not function as if it were a valid obj file in praxis. Not only are such corrupt obj files invalid, calling then from a pp2 is dangerous and can trash your scene.

**
**

Delete the txt extension and leave is as pp2. Import the pp2 into Poser or put the pp2 in some prop library and load it. You will have a ball and a cube because it is a valid pp2 file.

Now take again the CubeBall file and rename to CubeBall.obj. Import it in Poser or any other application. Do you see now a nice cube and ball or something strange ? Depending on the application you use to import this fake obj even can make your app crash. Poser at least doesn't crash.

I couldn't test in Poser ATM so I'm glad to see this, though the results don't surprise me. I would have simply tried to import the pseudo-obj as an .obj rather than going through the indirection of using the reference in a .pp2, i.e. to test Poser's .obj import function directly. I assume it's the same code though and would have a similar result. I'm not sure why anyone would 'change' a prop to an .obj and then in effect use it as another .pp2, but it could happen.

As I said before, I see little or no use for the 'trick' in Poser anyway even if it worked. The only (limited) utility I see would be in saving an extraction step if you aim is to get the geometry into another application for modeling, rendering etc. Whether that was a design intention in the case of UVMapper, for instance, or just a happy coincidence, I don't know.

This is the first time I've heard of the idea so I wasn't aware that it was a popular one. I thought maybe it was some odd thing based on the somewhat mutability of Poser file types e.g.  pz2 > cm2.  I guess again, it just seems an odd thing to do for use only within Poser. Nevertheless, it is important to illustrate as you did, why it's not a good idea.

Kawecki's example illustrates another hazard of the 'fake' .obj. There's probably no application other than Poser (when reading a .pp2) that's going to be able to properly distinguish multiple sub objects in Poser's embedded .obj format. Since there's no way to tell beforehand whether a .pp2 contains even one embedded geometry, much less multiple, ones without opening it in a text editor, the renaming has even less utility. It's a quick and dirty way to get some prop's geometry into some applications without using an editor or utility to save it out, and that's about it. Even then, you probably need to remember to make a copy first.

I suspect BB's musings on the semantic limits of what constitutes an .obj were meant more as a thought provoker than a suggestion for practice. At any rate, when it comes to what one can put into an .obj, one should follow the old joke (ladies avert your eyes)  - 'Confucius say that woman who ride astride is stretching a good thing too far.'

Now, having lowered the tone of the discussion to a sufficiently low level, I'll slink out :-) 

You need to look for the program Geometry Stripper...

here is the link....http://www.vanishingpoint.biz/freestuff.asp?StartNo=421

Very simple... save your prop to the library, morphs and all.

Open the prop in GeometryStirpper. Process it. It will remove the OBJ file and point it to the obj in the same folder.

You are done. Poser will now refrence the obj. Take things one step further and cut/paste your obj to a geometries folder... edit the .pp2 file to point to the obj you've just moved.

Someone told me about this program (probably pjz) a few years ago and I've been using it ever since. Very simple to use.

and of course, the reason to do it is...

1. For making morphs later

2. For exporting to another app like lmckenzie says

3. For cutting down on memory usage when using it more than once in a scene. It might not sound like much, but image you make a chair. Then you want to use that chair 12 times in an office setting..... you can see how that might slow down ou scene. Now in front of those 12 chairs each one has a cup, a pencil, etc, etc, etc................................

Good utility - I've used it a few times. Phionix, now that you've changed your avatar, I can admit that I had a crush on the last one :-) Edit: Oops, she's still there at the bottom of your posts :-)

I'm probably going to change her back, don't worry!