Wouldn't it just plain rock to have a script where you could point Poser to a directory full of obj's for, let's say a head, and have it load all those as morphs? -Les

That would be flippin' awesome ;o).

Laurie

Select tha actor you want to morphs to be loaded.
Run the script (File-Run python scripts) or save it in your ScriptsMenu.
It will ask you for a folder... select the one containing the obj.

And wait... do NOT touch Poser until you have the final message.

Basil

Thanks! Gave it a shot just now and got this error:

Traceback (most recent call last):
  File "S:ModelsPythonScriptsimportMultipleObj.py", line 53, in ?
    actor.SpawnTargetFromGeometry(geom, objsName[i])
NameError: name 'objsName' is not defined

This could be a really handy script, so if you can help debug this, it would rock! -Les

very nice semidieu, mines not so elegant. :) 

Hey there... looking further into that error, it seems like maybe there needs to be a function defined that gets the name of the obj and passes it to Poser when the morph is created. Maybe something like that is in there and I'm just not catching it, but that seems to be the kind of thing the error is related to. FYI: I'm no programmer so I'm just spitballing from my effort to trouble shoot this. I really, really want to get this script working because I know it will become invaluable for me. -Les

This one should work...

Dude! Brilliant! Love it! This is great stuff. Just made my life a lot easier. -Les

Glad you will find it useful :)

Many, many thanks sir ;o).

Laurie

You're welcome :)

semidieu: Nice work! I have just one tiny question. Lines 46 and following read like this:

   
            for a in
poser.Scene().Actors():<br></br>
           
        if not a.Name() in
curList:<br></br>
           
            prop =
poser.Scene().CurrentActor()

           
    if prop != None:<br></br>
           
        # GET THE GEOMETRY<br></br>
           
        geom = prop.Geometry()<br></br>
           
        # LOAD MORPH TARGET<br></br>
           
        name =
os.path.splitext(os.path.split(fp)[1])[0]<br></br>
           
       
actor.SpawnTargetFromGeometry(geom, name)<br></br>
           
       
prop.Delete()<br></br>

That's confusing me. Why not just write:

   
            prop =
poser.Scene().CurrentActor()

   
            if not
prop.Name() in curList:<br></br>
    
           
    # GET THE GEOMETRY<br></br>
           
        geom = prop.Geometry()<br></br>
           
        # LOAD MORPH TARGET<br></br>
           
        name =
os.path.splitext(os.path.split(fp)[1])[0]<br></br>
           
       
actor.SpawnTargetFromGeometry(geom, name)<br></br>
           
       
prop.Delete()<br></br>

Also, is there a reason one has to fill curList each time the loop is executed?

Sorry if these are dumb questions. I have no experience with the Poser API and I'm trying to learn.

The relevant cod is thls:

for a in poser.Scene().Actors():
        curList.append(a.Name())
imExObject.Import('obj', 'File Format Wavefront', fp, imoptions)
prop = None
for a in poser.Scene().Actors():
        if not a.Name() in curList:
                   prop = poser.Scene().CurrentActor()
this appears to do:
  build list of actors in scene
  import the obj file
  loop through actors looking for the new one thats not in the list
  allocate it to prop variable

I do wonder about that code if my interpretation is right
I would have expected to see prop = a     rather than prop=poser.Scene.CurrentActor()

The curlist needs to be refreshed before the next import if you are using it to identify the imported obj.

Please correct this if I am reading it wrong.

you need to test existance before referring to a value
prop.Name() will throw an error if prop is None.

If the import fails, won't "currentActor" just be whatever it was before? In that case, wouldn't it suffice to compare its value before the import with the one after the import? If on the other hand it is set to None after a failed import, that's even easier.

But maybe the code was written the way it is because it's possible to have a successful import that doesn't change the current actor. In that case, the line that now reads "prop = poser.Scene().CurrentActor()" should indeed be "prop = a".

I feel a bit weird asking questions like that, but since the API is so badly documented, I figure picking people's brain is the most effective way to understand those details.

I thought about this and realized he is simply testing for a successful load.
The last loaded item IS the current actor .

**semidieu certainly knows what he is doing when writing scripts. Its certainly worth asking if you dont understand something, its how you learn. Different people have different styles to their code so you need to work out your own.

It might be possible to put a try:   import  except:  display error   on the import. I dont remember if you get a trappable error.
**

You are right... there is a little error.

prop = poser.Scene().CurrentActor()

should be:

prop = a

In fact, why I'm doing that: In 99.99% of the case, the last loaded prop become the currently select prop. So doing the loop to check which actor is the new one is only for some special case (I don't know how to reproduce it, but it happens once...): if I recall well, if you click somewhere exactly after the OBJ has been loaded, the selected prop won't be the correct one...

Notice that I could optimize the code (not resetting the CurList for example):

markshum: thanks for what you said... :)

you need to keep updating curlist as each morph geometry is loaded (unless it gets removed as part of the morph creation) 

Its nit a major overhead in this case.  It is the sort of thing to look for when your program is running really slowly.

Thanks, semidieu! That explains it.

markschum: Agreed! Updating curlist after each import isn't a big performance hit in this case, and makes the code potentially more robust. But since the loop is so very simple and the newly imported prop is removed each time, I'd personally be inclined to keep it out of the loop in order to make the logical structure clearer. So I guess my question was whether there was some compelling reason not to that.

It happened to me more than once that I looked at old code of mine, wondered  why I had done a simple thing in such a complicated way, simplified the code, ran into errors, and then realized why I had done it the way I did. :laugh: