Instantiation Via (Poser) Geometry Swapping ?

[Ken1171]

I am trying to replicate Object -> Duplicate in Poser Python. I am duplicating the prop by calling:

newProp = scene.CreatePropFromGeom(geom, instanceName)

I provide the geometry for the new copy, and it has a Materials() property, but the materials are not copied. Maybe there is another way to duplicate a prop that already preserves the materials? Or is this the only way?

Where I am now, I have the root nodes from both source and destiny materials, and I will have to write code to reproduce everything from one tree to the other. I wish I could just make an assignment. Can we assign a material from one object to another?

 

[Ken1171]

Here some results from my prop scattering. Placed 200 copies of the grass patch over this morphed ground plane. Each includes random scaling and rotations. The one at the center is the source one with materials. Only need to copy the materials to the copies, and fine-tune the positions.

 

[Karina]

I think it's just another case of Poser not being open enough for Python code.
It's time to finally enable all Poser options for Python too!
SM (back then) made a good start with publishing the "poser.ProcessCommand()" codes.
Why can't this be expanded to ALL of'em?

K

 

[3dcheapskate]

Re copying the materials Ken, ironsoul's script (not yet published on the thread) uses this:

def Duplicate( oActor):
scene.SelectActor(oActor)
poser.ProcessCommand( 1568 )
return scene.CurrentActor()

Over on my new Renderosity "Does Anybody Recall SM Claiming That Poser Supported Instancing ?" thread willyb53 replied that:

"Instancing in poser is limited to .obj and textures. Poser does not reload either of these if there is already one cached with the same name. That is why most stores require props to have external geometry, otherwise each copy in a scene would create a new obj in memory.
So if I load 2 V4's in a scene with the same texture, there is only one copy of the obj and the textures in memory. What can not currently be instanced is all of the other information, location, morphs, scale etc. A fully loaded V4 with external geometry still will take up 100's of megabytes of memory for each copy"

 

[3dcheapskate]

...so the geometry-swapping grass figure I'm messing around with is actually using Poser .obj/texture instancing. The location/rotation and scale of each instance is handled by the individual bones. So it's only morphs (which I'm not yet using) that would add any real extra memory load.

I think that (a) using a geometry-swapping figure and (b) using Python to multiply duplicate a prop are interesting alternative ways to do this, and I think it's worth continuing with both.

 

[3dcheapskate]

Oh, I see what you mean. No, I read your statements through, but I thought you were saying that SMS were just lying and obfuscating in the middle post. That your opening sentence meant your personal opinion differed, and their lack of clarity on it was proof of deception, not that you were working from their statement, not opinion. I apologize for misunderstanding you.

My point about the "when" part is simply that it wasn't relevant to the debate I had before. I get (and already got) that you've been going over that aspect. It's an interesting topic, but it's kind of beside my issue, which is simply, "Do instances have a benefit in Poser?"

Logically, I'd think that if you load something from a preset that points at an OBJ rather than embed geometry in a preset, the software is aware of the loaded OBJ file. But that's just an assumption. I can say that the duplicating you can do by scripting and that you can do with the interface are one and the same. You have to use the ProcessCommand method.

I think Bill's comment over on the Renderosity thread (quoted in my previous-but-one post) indicates that your assumption was correct. Hopefully what we've (re?)discovered here will inspire you to get back to work on your idea ?

 

[3dcheapskate]

Re my using Translucence and Alt Diffuse in that shader - it was in the SM "We need a hair shader like this for Poser ... Shader gurus?" thread that bagginsbill posted the non-intuitive FF setup that I used ( We need a hair shader like this for Poser ... Shader gurus? ), and also stated in the next post that it's different in SF.

 

[3dcheapskate]

Hang on...

If what Bill said about "...Instancing in poser is limited to .obj and textures. Poser does not reload either of these if there is already one cached with the same name. " is correct, then the results I got when I exported an OBJ, restarted, imported the OBJ and then did Edit>Duplicate don't make any sense - 2nd and 3rd 'instances' each required around 80% of the memory of the 1st ?

 

[Ken1171]

SM (back then) made a good start with publishing the "poser.ProcessCommand()" codes.

Ohh I must have missed that. Big stuff! ^^

Re copying the materials Ken, ironsoul's script (not yet published on the thread) uses this:

Heeey, that does exactly what I needed, thanks! Where do we get these command IDs from? They are not listed in the official documentation.

then the results I got when I exported an OBJ, restarted, imported the OBJ and then did Edit>Duplicate don't make any sense

I know, these results seem to vary a lot depending on who runs the test. At least it has been consistent in my personal tests. I will do some more testing with the scattering script. Should be easy when I am adding objects by the hundreds.

Here's the new script with the updated code. Scattered 200 instances with random sizes and rotations. It will not place an instance at the same place twice, so nothing is wasted.

* 425MB Loaded 1 prop
* 483MB Scattered 200 instances +58MB

Not bad! ^___^

 

[3dcheapskate]

Renderosity thread - The poser.ProcessCommand() calls
PhilC said "If you open Runtime/ui/Poser.xrc in a text editor you'll get them all. "

 

[KageRyu]

Will this script follow contours of a ground object/figure?

 

[3dcheapskate]

Regarding the higher-than-expected memory increments for the 2nd/3rd/etc figures, Richard60 made this comment -"Look at the size of a CR2 compared to the object file it points to. The data for the obj is small compared to all the channels of data needed to keep track of where the arm is and the hand etc. So you don't have the data that defines the mesh, but you do have it for how the mesh will be formed." Does Anybody Recall SM Claiming That Poser Supported Instancing ?

 

[phdubrov]

I wish I could just make an assignment.

To close this question: 8.17. copy — Shallow and deep copy operations — Python 2.7.17 documentation - why assignment wouldn't work.
As far as I remember, someone reported deepcopy problems in Poser. Not 100%sure.

 

[Ken1171]

Will this script follow contours of a ground object/figure?

Yes, it will follow the shape of the surface you are scattering over, even if you transform it (scale, translations, rotations). However, I am not sure if it will work if the mesh is morphed. I have to check that. If not, I will have to find out how to get the morph deltas in world coordinates, and account for that.

Regarding the higher-than-expected memory increments for the 2nd/3rd/etc figures, Richard60 made this comment -"Look at the size of a CR2 compared to the object file it points to. The data for the obj is small compared to all the channels of data needed to keep track of where the arm is and the hand etc. So you don't have the data that defines the mesh, but you do have it for how the mesh will be formed." Does Anybody Recall SM Claiming That Poser Supported Instancing ?

This makes a lot of sense. That would explain why props with embedded geometry are less memory efficient than linked geometry.

To close this question: 8.17. copy — Shallow and deep copy operations — Python 2.7.17 documentation - why assignment wouldn't work.
As far as I remember, someone reported deepcopy problems in Poser. Not 100%sure.

My point is that the Poser Python API does not seem to be data-driven. For example, it exposes many data structures, like all the materials from a given Actor, but we cannot use that to copy or assign the data to another object. It appears that ALL that data is read-only in the form of function calls. The API provides means to access the data, but never to assign it. That can be frustrating when working with data you can see, but not assign to anything.

 

[KageRyu]

If it works when morphed, that script would by a huge time saver for me. I am very worn out on placing grass, trees, flowers, weeds, rocks, and debris by hand all of the time.

 

[Ken1171]

I have checked, and it does seem to work with morphs, but the items have an odd offset that I have to look into. I think I might have to calculate the total transformations Poser does to geometry first. There is also the normal angle from the surface. I want to align the objects to it, so they remain aligned. No idea how to do that - I will have to learn it first.

 

[3dcheapskate]

Over at Renderosity ironsoul asked "If its possible to modify the geometry via Poser API it would be interesting to see if modifying the source prop used in the geometry swap also modifies all the instances."
Although you're not using geometry swapping you're using python, so maybe you could check this ? E.g. try geometry.addPolygon() on the geometry after instancing is done...

 

[3dcheapskate]

P.S. Bagginsbill pointed out that using File >Import > Wavefront OBJ is like opening a PP2 with embedded geometry. I.e. Using Edit > Duplicate will also duplicate the geometry.

So I tried converting my OBJ to aPP2 with external geometry and retried my test. Still got large memory usage increases for the 2nd/3rd/4th 'instances'. But (accidentally) closing task manager and reopening it gave me a very different number. I no longer trust what task managersays about Poser's memory use !

 

[Ken1171]

"If its possible to modify the geometry via Poser API it would be interesting to see if modifying the source prop used in the geometry swap also modifies all the instances."

The current code adds random rotations and scale to each prop, and they each retain these individual properties. I know transforms don't actually modify the geometry, but this part works. All that is missing now is to align each instance to the surface normal, and adjust their offset when the surface is morphed (props ends up off the surface).

But (accidentally) closing task manager and reopening it gave me a very different number. I no longer trust what task managersays about Poser's memory use !

Oh that would explain why were getting such different results in our tests.

 

[Ken1171]

Why does the Tkinter listbox looses its selection when we TAB out of it? I can't seem to avoid that.