I've got a light fixture that needs to be rigged as a figure,
and also needs to stay fastened to the ceiling of the house 
when the house moves.  Smartpropping is obviously the 
right concept, but I can't make the 'smartParent' line work 
on the BODY of the light fixture.  Is there a way to do 
this, besides just making it a PP2?

This kind of evades the smartparenting question, but is the house a figure?  If so, could the light be conformed to the house?

i ran into this on some wingfigures & ended up adding a parenting pose, because if i added parenting into the cr2 poser liked to crash mightily.  but cage's conforming idea is probably the better way to go...

{

actor BODY
 {
 smartparent chest
 
 }
figure
 {
 }
}

Hmm.  Conforming is interesting, but it still requires a separate
step by the user, which means it's six of one/ half dozen of other
compared to the parenting pose.  Goal is to let the user position 
things correctly and easily in the house no matter where the 
house stands in the scene.  Smartpropping is so nice and 
easy, but most of the furnishings are figs.

Thinking aloud ... Probably Python is best toward this goal.  
A script with a list of the available furnishings,  you pick from the list, 
and they get installed in the currently selected house.  Install
the whole standard set is the main choice.

The figures on my site use a Python assembly method, running the Python script from a stripped-down .cr2.  Perhaps something like that would be convenient?  (I'm always trying to get other people to use this method, in spite of the fact that it's arguably over-complicated).  The trouble with assembling characters using Python is mainly that the figures and props need to be placed correctly for Python to find them.  I keep getting e-mails from confused users who've mis-placed a few things.... 

i like those python-call cr2s too but also suffer from the moved-files problem.  & the smart-pose has its own problems--the right figure has to be selected (unless you could customize it to the specific name?) & it may cause problems if the parented figure is resaved.  

if the loading script is non-location-sensitive, i bet that's the simplest solution.  P4 users can't use that though.

Smart parenting a figures BODY actor (only) has always worked for me (only tested in P4 & P5). Works just the same as in a prop, eg:

actor BODY:1
 {
 [etc etc]
 smartparent chest

The PROBLEM comes when I delete either the parent or child figure. Poser tends to hang or crash when either figure is deleted. because of this I sometimes use smartparent in my own figures, but strongly recomend you don't use it in any distributed files, no one will appreciate a file that can crash Poser.

@Les: I tried exactly that method, but the light didn't seem to stick 
with the house when I moved it.  Maybe I mistyped something.

Thanks for the warning about crashing!  This is going to be a product
for sale, so I don't want it to cause trouble when Murphy's Law inevitably operates.

So I'll do the Python thing, with some parenting poses for the 4.0 people.

"smartparent" has worked for me on numerous occasions. Perhaps you are setting smartparent as BODY, then moving the house by the "hip" actor, or perhaps you are typing "smartParent". I think you should leave the actor number (:#) off the end of the smartparent line.

Why does the light fixture need to be a figure? What is its hierachy? Perhaps there is some workround.

You're right, I did type smartParent!  Dumbly following the example of other
words in the CR2 like smoothPolys.  When I changed it to smartparent, it worked.

The light fixture only needs to be a figure so it can receive the LightOn
and LightOff poses, but most of the furniture has moving parts, so
unquestionably needs to be rigged as figures.

"The light fixture only needs to be a figure so it can receive the LightOn and LightOff poses..."

Anything parented to a figure, or in a parenting chain where a figure is part of the chain should take a pose, just so long as any part of the figure, or an item parented to the figure is selected.

Eg a box parented to a ball parented to the head will take a pose. Even when a box is parented to a ball and a figure is parented to the ball, the box will still accept a pose.

With lights it's even better, a light will take a pose (pz2 or lt2) even if the light is not parented to anything, just so long as there is a figure in the document.

Notes:

If you need to keep files together in one folder, a pp2 (prop) can live in, and work from a character folder, so long as you change its extension to cr2.

When you pose lights via a pz2 you should include an empty figure block in the pz2. I forget why, but I remember that you should.

Using a pz2 on a light instead of a lt2 has the advantage that lights not referenced in the pz2 will not be turned off when the pose is applied, as would happen with a lt2.

If you use a pose on a prop, remember that Poser increments the prop name with a number, a pose for "box_1" will not work on "box_2".

If you add lights to a scene via a cr2 or pp2, the lights and shadow cams should have unique internal names, so as not to conflict with lights that may already exist in the scene.

As an alternative to implementing the light fixture as pp2, or as a smart parented figure, you could inject the actors for the light fixture into the house figure (assuming the house is a figure). Actor injection would seem to have some advantages in this situation, as it is not subject to the hanging problems associated with smart parented figures, or the name incermentation associated with props.

Not many people realize that you can inject new actors into an existing figure, but it's quite simple, though there are some limitations.

The limitations stem from the fact that the file to inject the new ators can't contain a 'figure' section. The main limitations are:

1). Actor injecion can't add welds, so the new actors won't be welded when they load.

2). If the new actors are to use materials that are not defined in the target figure, then you will have to put them in the individual actors and use 'customMaterial 32' to tell Poser to look for them there. This will have consequences for how they are accessed in the Materials Room.

3).  Actor injection can't add IK chains.

All the above things could be fixed by the later application of a pose, but that's adding another step.

One last limitation. 

5). Sometimes (eg when injecting body handles) it is desirable to place new joint paramiter channels in the target figure, actor injecion can't do that (perhaps it could call a py script to add the channels).

If you are interested in trying actor injection, I will post details of how to do it.

This is great stuff!

Les - at risk of veering OT, what have you tested with regard to injecting actor geometry?  I've found that Poser will only accept a pose which adds a new geometry path for an actor under certain circumstances, but I haven't been able to determine the parameters.

For instance:

actor hair:3
{
storageOffset 0 0 0
objFileGeom 0 0 :Runtime:Geometries:Cagedrei:hair:WWhair3.obj
}

can be inserted (I think I left out the indentation here), but only one actor can be injected per pose, and some actors won't work without creating errors in Poser.  Have you ever tested this area?

Several of those notes are highly informative and new to me, especially
the details about what works with lights and what doesn't.

At this point I'll let Cage and Les carry on with injection ... my
main purpose is to make the furniture easy to place in the house
and* *easy to use separately if the user wants it that way.

@Cage,

First thing to remember when applying a pose to a prop (or light, or camera) is that there must be a figure in the document.

With respect to 'objFileGeom' in props, you should be able to inject multiple geometry references (paths) from one pz2. At least I have never run into problems myself. The most I have ever injected is three. I tend to leave  actor numbers out of poses, so in your example I would have used "actor hair" not "actor hair:3", not sure if it make a diffrence here though.

If you have an example of something that does not work, I would be interested to have a look.

Try this. Load two Poser square props(not onesided), and one cone prop. Load a figure, then try these two poses:

{
//swapped.pz2
version
 {
 number 4.01
 }
actor cone_1
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:square.obj
 }
actor square_1
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:cone.obj
 }
actor square_2
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:cone.obj
 }

figure
 {

 }
}

{
//restored.pz2
version
 {
 number 4.01
 }
actor cone_1
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:cone.obj
 }
actor square_1
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:square.obj
 }
actor square_2
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:square.obj
 }

figure
 {

 }
}

Note that I use "actor propName" not "prop propName" in the poses, this allows me to apply the poses to the props even if the props are not parented to a figure. If the props are paerented to a figure "prop propname" should work fine.

As I said in a previous post, remember that Poser increments the prop name with a number in each new instance. A pose for "square_2" will not work on "square_1". If this becomes a problem, remember that in P5 and up you can use 'actor $CURRENT' to apply a pose to the currently selected item.

Geometry injection also works with 'geomCustom'. If I remember right, you can mix and match  'geomCustom' and 'objFileGeom', applying a 'objFileGeom' pose to a prop that uses 'geomCustom' and vis versa. An empty 'geomCustom' will clear the geometry from a prop.

I can't advise on geom injection with 'figureResFile', perhaps I will have a look at that in the nex few days.

Ah, apologies to Ockham. 

@lesbentley - Actually, I hadn't even tried this process with props.  I've been using it for body parts, seeking an alternative to using geom switching.  

{
version
 {
 number 5
 }
actor hip:1
 {
 storageOffset 0 0 0
 objFileGeom 0 0 :Runtime:Geometries:Cagedrei:Vicky:femina_high3.obj
 }
}

{
version
 {
 number 5
 }
figureResFile :Runtime:Geometries:ZygotePeople:blMilWom.obj
actor hip:1
 {
 storageOffset 0 0 0
 geomHandlerGeom 13 hip
 }
}

The upper pose inserts a genswap hip.  The lower pose restores the original.  Using the same trick to try to alter the buttocks locks up Poser.  I've only managed to get this to work with one actor at a time.  And the restoration pose seems to confuse Poser about the cached geometry referenced in the figureResFile line.  After applying such a pose, a figure which loads that geometry will load only the part present in the restoration pose, even with a fresh Poser document applied.  (One wonders if adding an empty figure section might remedy any of the troubles....)

So there are complications to the approach.  I just wondered if you'd ever tinkered with the idea for figures.

@Cage.

Quote: "I've only managed to get this to work with one actor at a time."

This file worked for me to replace both thighs with Poser box props in Victoria 3 RR and Posette. I can't think of any reason why it wouldn't with any actors in any figure, except that perhaps P6 binary files might confuse things if they are enabled. I turned 'bend' off just so it looks better, but it still works with 'bend' left on. I recomend that you don't use actor numbers (:1) in the pz2, don't know if it helps, but it can't hurt.

{

version
 {
 number 4.01
 }

actor rThigh
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:box.obj
 bend 0
 }

actor lThigh
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:props:box.obj
 bend 0
 }

figure
 {
 }
}

I haven't tried a restoration pose yet.

Hmm.  I wonder if your inclusion of the figure section is making a difference.  I'll try that.  I think a good test would involve replacement with a geometry which needs to be welded.  When I try to insert intensified buttock geometries, which will be welded, as alternates, Poser gets mixed up.

BTW, what's the difference between 

storageOffset 0 0 0

and 

storageOffset 0 0.3487 0

?

Could that make a difference when applying one of these poses?

Interesting.

Q: BTW, what's the difference between 'storageOffset 0 0 0' and 'storageOffset 0 0.3487 0' ?

A: NAFC (not a f.....g clue.

Q: Could that make a difference when applying one of these poses?

A: Perhaps, perhaps not!

I tried a few restoration poses based on trying to restore the 'figureResFile', and similar to your example, but with some modifications. Nothing worked for me so far.

Now this is interesting. I have made some slight progress.

My original tests of my restore poses were done in P4, they did nothing. I tried one of the restore poses in P6 and it worked fine. Here is the pz2:

{
version
 {
 number 4.01
 }

figureResFile :Runtime:Geometries:DAZPeople:blMilWom_v3Lo.obj

actor lThigh
 {
 storageOffset 0 0 0
 geomHandlerGeom  13 lThigh
 bend 1 
 }

actor rThigh
 {
 storageOffset 0 0 0
 geomHandlerGeom 13 rThigh
 bend 1
 }

figure
 {

 }
}

Although the restore pose workes in P6, my pose to replace the thighs with boxes crashes P6 if I load the boxes with 'bend' on. That pose did not crash P4. Diffrent Poser versions seem to handle this stuff diffrently :(

With so many versions and service releases out there, things could get complicated.

Does the pose work in Poser 6 with bend on if only one body part is being changed?  The result you're reporting sounds like I've encountered in P5 when trying to do more than one body part.  Or, for that matter, two body parts, one after the other, using separate poses.

Kind of looks like the approach may only have very limited utility.  :(

Q: Does the pose work in Poser 6 with bend on if only one body part is being changed?

A: No! Even when the pose is applied to only one actor, if 'bend' is on Poser hangs. Even if I apply the pose to one thigh with bend off, then turn bend on later, P6 hangs.

Perhaps it is the welding that is confusing Poser, or some issue with the joint paramiters. Guess I should try it with real thigh geonetry, instead of box props, I just didn't want to go to all that trouble.

Good News!

I exported morphed thigh objects from V3RR, and used these in my geometry injection pose. IT WORKED!

I can now inject and restore both  thighs at once  in P6 with 'bend' turned on.

There are still some outstanding issues. Why can't I inject the box geometry without hanging? If I inject P4 thighs into V3RR Poser goes a bit crazy, kind of a partial hang. I can inject V3RR thighs into V2 and again Poser goes a bit crazy, but not quite so bad. All this is with 'bend' left on of course.

There is also the issue of not being able to restore from the 'figureResFile' in P4. I wonder how this stuff plays in P5, I don't have P5 installed at the moment.

Here are the inject and restore poses that are working on V3RR:

{
//thighs V3RR New.pz2
version
 {
 number 4.01
 }

actor rThigh
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:VrThigh.obj
 }

actor lThigh
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:VlThigh.obj
 }
figure
 {
 }
}

{
//thighs V3RR Restore.pz2
version
 {
 number 4.01
 }

figureResFile :Runtime:Geometries:DAZPeople:blMilWom_v3Lo.obj

actor lThigh
 {
 storageOffset 0 0 0
 geomHandlerGeom  13 lThigh
 }

actor rThigh
 {
 storageOffset 0 0 0
 geomHandlerGeom 13 rThigh
 }

figure
 {

 }
}

Seems like the more the injected geom differs from the default geom, the more Poser struggles, eventually hanging completely. Sugessts that too much memory or processing power is being used to do something.

Quote - Seems like the more the injected geom differs from the default geom, the more Poser struggles, eventually hanging completely. Sugessts that too much memory or processing power is being used to do something.

As the geometries are different, perhaps this is related to the morphs for the original geometry no longer working when the number of vertices changes.

*"As the geometries are different, perhaps this is related to the morphs for the original geometry no longer working when the number of vertices changes."

*When I've been using this for the genswap hip I've been replacing the hip with a geometry which differs a great deal from the original, with bend on, in Poser 5.  I've been combining the swap pose with an INJ pose, so the deltas and geometry change at the same time.  So far it works nicely (in P5), but only for the hip.   I'll hopefully have these files up on my site in a few days. 

THe MultiHair on my site uses this swap method, with bend on and very different geometries.  It also uses combined INJ in the poses.  None of the geometry elements would be welded to another body part, however, so the bend settings may not be impacting anything in this instance.

@nruddock

The problem seems to have been the welding, as I suspected. I stripped the weld statements out of the target figure, and now it seems to  work ok no mater what geometry I inject.

So the problem seems to be Poser struggling to weld things that were never meant to welded together. When I used morphed obj files for the thighs spawned from the the figures obj file, Poser handled it ok, even though the edge vertices where the weld happens had been moved. When I used box props that came in at a totally diffrent position (on the ground) and had a totally difrent shape Poser threw a fit. When I used thighs from diffrent figures that matched the shape and position more closely I got intermediate results, Poser did not like it, but still worked to some degree.

So in conclusion, it seems to be ok to use a morphed version of the original geometry, even if its edges do not meet the other parts of the figure, but a totally forign object causes problems (unless 'bend' is turned off).

@Cage.

I guess the next question is the more specific one "What's wrong with Cage's buttocks?". 

Where the new butocks made from the original geometry? Where any vertices added or deleted? Are the edges where the buttocks weld moved a long way from their original position?

Cage's buttocks may have some slight issues from sitting at a computer so much.  Hmm.

The buttocks I've tried to insert were derived from the orignal V1 geometries.  I pulled the parts into Wings 3D, selected the edge vertices, inverted the selection, switched from vertex to polygon mode, and used smooth once on the geometry to intensify it.  Then I triangulated all of the unsmoothed verts.  The edges were preserved.

I used TDMT to port all the buttock morphs to the new geometries, then put these intensified deltas into an INJ pose.  The INJ pose was set up to swap the geom, as well.  The main difference between what I did and what you've tested, as far as I can tell, is your inclusion of a figure section.

So the geometries were derivative and the edges were unchanged and the deltas shouldn't have been the problem.

I'll test a few things with the files later tonight.

Hmm.  I managed to inject everything, but Poser's preview screen grayed out on me and the cursor vanished.  I was able to save the altered figure to the libraries palette (without a visible cursor), but the scene file would not save - doing so resulted in a .pzz of 0 bytes.  So the process works, but it doesn't work, in this case.  Yet I receive no such errors with the hip.

I'll try another test with bend off.  Perhaps bend can be turned back on using a second pose and the problems can be circumvented....

From my experience so far I think that turning bend back on will bring back the problem, but it's worth a try.

It's interesting to note that that when we use Poseres 'Replace Body Part with Prop' functrion, Poser is doing what we are trying to do, injecting new geometry, but this method has none of the problems we seem to be getting when injecting from a pz2.

'Replace Body Part with Prop' injects 'geomCustom', but 'geomCustom' is not the answer, I have tried that. Poser is obviously doing somthing extra when using  'Replace Body Part with Prop'. My fear it that this might be something internal to Poser, and not capable of being done through a pz2.

Ha ha!  :woot:  I got it to work, I think.  The weld statements have to be inserted along with the new geometry references.  So the pose builds on the basic structure of the weld insertion poses lesbentley outlined in an earlier thread.  The pose has to include a blank reference to the welded parent as well as the lines to weld to that parent.

I haven't tested this with the restoration poses yet, but I assume it will work out, leaving only the geometry cacheing problem I mentioned earlier.  

New delta INJ data can be added into the actor sections for the affected parts.

And it looks like the reason this worked for the hip (and the MultiHair) already was that the affected actors were not welded to their parents.

Interesting.  Maybe these can be useful, after all.... 

{

version
 {
 number 5
 }
actor rButtock
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:Cagedrei:Vicky:rbutt.obj
 }
actor lButtock
 {
 storageOffset 0 0.3487 0
 objFileGeom 0 0 :Runtime:Geometries:Cagedrei:Vicky:lbutt.obj
 }

actor hip
 {

 }

actor rButtock
 {

 }

actor lButtock
 {

 }

figure
 {
 weld    rButtock
 hip
 weld    lButtock
 hip
 }
}

@lesbentley - turning bend back on did lead to trouble, as you predict above.

I was thinking about the Replace Body Part with Prop function before I decided to try inserting the weld lines.  That made me think about trying to use PoserPython for the process.  Hopefully testing the process used in the above pose won't reveal too many ugly side effects.  I'd rather not drag Python into this....

Sounds like you cracked it. Great work Cage! I think you have really made a big contribution to our understanding of Poser, and how to wring themost out of it.  :thumbupboth:

Just remember, when injecting welds: weld child to parent!  If you put the welds in backwards, the parts weld inside-out, sort of.  :-P

Just for closure, I've tested the restoration poses with welds, and it works without trouble.  Moreover, I can't seem to duplicate the "geometry cache" bug that I encountered earlier.  So far the process looks effective and seems to be without errors, at least in Poser 5.

Here's an example restoration pose.

{

version
 {
 number 5
 }
figureResFile :Runtime:Geometries:ZygotePeople:blMilWom.obj
actor rButtock
 {
 storageOffset 0 0 0
 geomHandlerGeom 13 rButtock
 }
actor lButtock
 {
 storageOffset 0 0 0
 geomHandlerGeom 13 lButtock
 }

actor hip
 {

 }

actor rButtock
 {

 }

actor lButtock
 {

 }

figure
 {
 weld    rButtock
 hip
 weld    lButtock
 hip
 }
}

Seems to work in P6 too!

With the benifit of hindsight, refreshing the welds makes sense. I assume that poser is keeping some data relating to the original welds cached, and trying to apply it to the new geometry. Redoing the welds forces poser to refresh the cache with data relating to the new geometry. This explination is of course just a guess, and may be wrong. The one thing that surprises me a little, is that this data seems to relate to the whole butock geom not just the touching edge vertices.

Some quick tests I did on V3RR in P6, seem to confirm that your method works, though I am a bit surprised that you don't seem to need to re-weld the child (thighs) of the injected part. The testes I did  injected box prop geometry via 'objFileGeom' and P4 thighs via 'geomCustom'.

Welds in the restore poses have not seemed necessary in my tests in P6, but perhaps it is best to include them just to be on the safe side.

Woops! I was wrong on that last point, at least. The restore pose does need welds.

Hmm.  This doesn't seem to be a problem with the poses, but it is a puzzle.  In the above examples, I use "storageOffset 0 0.3487 0" for the swap pose and "storageOffset 0 0 0" for the restore pose.  But when I check a resored cr2 in cr2Builder, I find that the objFileGeom reference is still using "storageOffset 0 0.3487 0".  This makes the restored parts inconsistent with the normal actor listings.  I haven't detected any errors as a result, but I, personally, would prefer to retain consistency.  So it looks like it may be best to use "storageOffset 0 0 0" for both the swap poses and the restore poses, just to be on the safe side.

Poser is a puzzle.  Does no one understand the difference represented by the variances in storageOffset values?  Kuroyume's cr2 file specs note that the reason for the difference is unknown.  Does anyone from eFrontier read these forums?  Stewer?  Anyone?

 The Vicky 1 genswap hip which uses this geometry insertion pose method is now available at the "Cage Page 2007 Poser Freebies" link in my sigline.