I just this minute had a thought. Can you inject geometry? YOU CAN! Try this; load a figure, load a p4 box, parent the box to the figure. Now apply this pose file: { version { number } prop box_1 { storageOffset 0 0.3487 0 objFileGeom 0 0 :Runtime:Geometries:props:cone.obj } figure { } }

Sooo... you need geometry in the scene already? Boo. I wanted to find a way to add a prop to a figure, and pose the figure in the right way to hold the prop, all with one file; but without success so far.

I thought this was interesting news. Oh well!

It WAS interesting news, Les. I forgot to say so. But, tell this bear of little brain, what could I do with it? Is this an easy route to geometry switching?

its very interesting to us lurkers les! lol

les- count me as another lurker who finds this quite interesting!

E-Bob - Looks like pose file can only change attributes of existing parts/props. Conversely, figure and prop files create entirely new figures (or overwrite existing figures). If correct, then there is no way to accomplish that (add prop and pose figure + prop) in a single file. Simplest solution I can see is TWO files: * file #1 is a smart prop, so that it adds itself to a figure. E.g., it contains a line like: smartparent hip * file #2 is a pose file, which can pose both a human figure, and a prop of a known name ALREADY attached to that figure, such as file #1. The prop posing can include switching which body part is parent. As pointed out, the prop posing can also switch geometry. This does lead to one interesting possibility: a prop or figure file that loads and attaches multiple "default" props to a person. These props could even come in "invisible". For example, one might "invent" standard names for smart props, such as "LBracelet", "Necklace", "LHandHeld" etc. - each attached to the appropriate body part. Select a figure. Load the multi-smart-prop file (which will parent these props to the SELECTED figure). Now, can have pose files that do things like: * Over the "LHandHeld" prop with a particular item, and pose the hand to hold that item. * Replace the "Necklace" with a particular necklace, and make it visible.

Interesting Idea ToolmakerSteve, I like the way you think. But I'm still hoping, like Bob, that it could all be achieved via one file. An lt2 is essentially a pose file but it can load the "spotLite.obj", it's not clear whether it can load an object that is not called "spotLite.obj", it seems not, but perhaps this has not been investigated enough (see the "objFile in spotlights... why?" thread). One question now seems to me; can we load the "spotLite.obj" from an lt2, then inject or swap in another geometry at the same time from within the same file? Perhaps. Perhaps not, in which case you suggestion will be the best way forward. If you try your idea out please let us know how you get on.

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=967170

I know this thread is ancient, but in case anyone searching hits it, here is some clarification: 1. Attached link is the "objFile in spotlights" discussion. 2. As I point out there, les is incorrect when he says "an lt2 is essentially a pose file". Truth is that it is essentially a prop file - and like any props, a light can be set to a given pose when it is brought in. Les' confusion probably arose because lights differ in one way from props: if you load multiple prop files, you end up with lots of props; if you load a new light file, it REPLACES the existing lights. It appeared that the EXISTING lights were being posed; but that's not really what is going on. 3. Dodger was incorrect (in the linked thread), when he says any ".*2" file can add an object. True - EXCEPT for a pose file. Truth is that, while pose file ".pz2" LOOKS just like any other Poser file, it is handled differently by Poser: try as you like, it WILL NOT add new objects. 4. Conversely, all non-pose files WILL NOT change ("pose") an existing object; they will only ADD new objects. BOY, am I a "KNOW-IT-ALL" today ;-)

"if you load multiple prop files, you end up with lots of props; if you load a new light file, it REPLACES the existing lights." So it's like a hair file, in a way? I smell hard coding, Poser style. That might limit the possibilities of doing anything useful with it. :-(

Yes, that's how I see it. Speaking as a programmer, this was an appropriate way to program it. Yes, we're disappointed we can't trick Poser into doing what we want, but it would have risked strange bugs if it hadn't been hard-coded this way. But now I've been thinking: "readScripts". Except I haven't found any way that gets around the "hard-coded" distinction between "posing" and "adding objects". Hmm. Okay, now I understand what is "unfortunate" about how Larry hacked this out (as a lone programmer, with stone age tools, way, way back). Pose information should NOT have a format identical to non-pose information. Instead, each pose description should be wrapped in something, anything, that says "this is a CHANGE to the object I'm about to talk about". Then, there could safely be a single file format, that describes both objects, and changes to objects. Noted (for future posing and animation tools).

Similarly, file types that REPLACE an object, could SAY SO. A hair file could explicitly say "The following object REPLACES the hair object on the currently selected figure". A lighting file could explicitly say "discard all existing lights, before reading the rest of the file". The advantage of such explicitness, is that it would be easy for add-ons to compose new functionality. * A light file, that ADDS lights to the existing set. * A "REPLACES " file, that replaces something other than hair.

In effect, there would no longer be a plethora of file types, that look the same, but are treated differently. These commands in the files could be mixed and matched at will; a single file could do anything desired; using readscripts one could compose smaller files into complex functionality; eventually, one could even have PARAMETERIZED readscripts, that could accomplish tasks we haven't even thought of yet. Or wait, at this level of functionality, maybe we're talking Python. Hmm. Even a mixture of Python commands with figure data.

I was thinking along the same lines myself. If the library items were self contained in this way, you wouldn't need to make any of the distinctions that currently apply; you would just have a generalised library object which would contain all the instructions about what to do with it. The library heirarchy could then be organised solely to suit the user (i.e. total chaos in many cases, I suspect). Keep this in mind for when you write your own character posing application, Steve. :D

:D

is there a tutorial for make it ? example: i want save as pz2 (pose) a prop (star.obj) in parent with the left hand. thx for feedback ;-)

The finest Poser minds seem to agree: you can't do this. :(

Your post disappeared before I could try it out, and I lost my copy. Did it not work?

I have "found" the way for save the parent of props to a figure ;-) read my tutorial (link fix): http://www.renderosity.com/messages.ez?Form.ShowMessage=1756687 Best Regards; Andygraph