Python Question: Object dimensions

[StudioMartillo]

 

[StudioMartillo]

 

[Miss B]

A morphing toilet??? How . . . erm . . . unique.

 

[StudioMartillo]

Magnetized. An OBJ duplicated twice and Magnets added to the dupes.
How can that work?

 

[StudioMartillo]

Morphing the duplicate:

How is this possible?

 

[StudioMartillo]

Recommended reading:
(1) The Poser Manual
(2) Barrons Review Series: Let's Review Geometry

 

[kobaltkween]

StudioMartillo- I'm not sure what you're trying to show us? Yes, instances in Poser can have their own hierarchies. I'm pretty sure that's true of all 3D apps. Deformers are just another set of actors parented to the actors they affect. And if you look at the code, you can see that an instance includes materials, dials, their settings, etc. So yes, each instance can have a lot more specifics than just scale, rotation, and position. That's all my tool will work with, because dials can be absolutely anything after that, but it's really amazing what you can do with individual instance properties in Poser.

Another good example of how different instances can appear is a single dynamic dress fitted to different figures who all have different poses. They'll have entirely specific shapes. But it's still all the same source mesh.

I could do all of that with instances in Blender, too. Actually, Blender can have instance specific mesh modifiers. So I'm guessing this is pretty much standard for instance behavior. Pretty cool to demonstrate, though.

That said, if you haven't externalized your geometry, and the geometry is embedded in the scene file or presets, then those are clones. But even Poser primitives have externalized geometry.

To all- So I've been doing a lot of testing, and I've found an issue I don't think I can get around. So I think the best solution is to ask people how likely they think this is to come up. Basically, Poser acts a bit screwy in different ways when you start parenting figures to other things. Especially other figures. I get it- the designers were, as always thinking of figures as being humanoid (or at least animal). Which is understandable. They were also obviously thinking that people would mostly use their own content, and therefore create edit figures to add and subtract as fit their needs. Which is annoying and incorrect, but there it is.

I've managed to get around the major issues I've encountered so far, but I just found that if you have an item conformed to a figure and then that conformed figure has a figure (not a prop) as a child, the child figure doesn't get copied with everything else. It's not a problem when figures are children (or children of children) of the main figure. It's not an issue when there are conformers of conformers. Just main figure | conformer > child figure. I'm thinking that this set up is rare enough, especially in items you'd want arrayed, that I can just let it go. But I thought I'd ask first.

 

[phdubrov]

The primary goal is architecture/landscape, right? I think conformers are pretty rare here.
Something mechanical, probably, but I haven't seen something made in this style.
Poseable crane - cable and hook as conformers - some figure as the child... But I haven't seen real examples.

 

[kobaltkween]

The primary goal is architecture/landscape, right? I think conformers are pretty rare here.
Something mechanical, probably, but I haven't seen something made in this style.
Poseable crane - cable and hook as conformers - some figure as the child... But I haven't seen real examples.

That's what I was thinking, but I figured it would be better to ask than assume. I mean, it works on Dawn just fine in general, but I can't think of much use for identical looking Dawns in row beyond depicting clones or robots. Maybe statues, too, but that's three awfully specific uses. And customizing Dawns (or any other human figure full of morphs) would be both involved and specific.

But I don't want to make the same mistake as Poser's developers. For years I assumed they knew what they were doing and there was a larger professional community they were designing for that was outside of the content community. This year's events indicate that wasn't true. That means for _years_ they were designing primarily for professionals who mostly animate their own content, and ignoring the fact that their tool was mostly used by hobbyists who mostly render stills of content they buy. Just because I'm thinking rows and rings of columns, walls, windows, etc. doesn't mean that there aren't better uses I haven't thought of.

 

[phdubrov]

From technical POV - how does this problem arise? I.e. how do you make a copy? Recursive copy or fixed depth copy? Or do you use "duplicate" command?

 

[kobaltkween]

From technical POV - how does this problem arise? I.e. how do you make a copy? Recursive copy or fixed depth copy? Or do you use "duplicate" command?

As far as I can tell, the only way to make copies is with the duplicate command. I haven't seen any other way to create or duplicate actors or figures, except for some particular actors (CreateLight, CreateGrouping, etc.). Everything else involves creating geometry, and I honestly don't know how I'd copy rigging without using a command. I _might_ be able to create presets and apply them repeatedly, but that doesn't make a whole lot of sense.

That said, I control the copying with Python so that it goes from the selected item down. So if you have a prop selected, while Edit > Duplicate (blah) won't include its children, this array tool will.

Figures basically copy everything beneath them _and_ conformed to them automatically. The problem is that while Poser's developers thought about adding to a figure by conforming, they obviously assumed that if you wanted to combine a hierarchy, you'd use the rigging tools to create one big, combined figure, not parent one figure to another. Everything is designed such that figures are supposed to have the UNIVERSE as their parent.

Which would sort of make sense if in fact the only reason to rig something was to make some sort of discreet being _and_ people were always working with their chosen figures that they made themselves, with content they make themselves. So sure, if you're Rooster Teeth, and you make a new version of your figure, it's not a big deal to update your hair to work with your new figure or even incorporate the hair in the new figure. If you're an average Poser user, you might want to use the hair figure as a child rather than a conformer so that it works on any figure the way props do but still has moving parts. Even a content creator might want to make wall with a working door and window to be a child of a floor with a working trapdoor, because they expect others to use it, and while they might personally find it easy to delete pieces of a combined figure to get just the wall, it's better allow users to choose whether they want one of the pieces on its own or together.

So instead of everything working in a nice consistent way, figures are a special sort of hierarchy that break rules in a particular way, depending on what developers considered. Child props copy with the main figure, child figures copy with the main figure, conformers copy with the main figure, and prop children of conformers copy with the main figure, but child figures of conformers don't copy with the main figure.

To overcome this without making extra copies, after copying a figure, I'd have to go to the original, look at its conformers, look in each conformer's hierarchy for a child figure, copy it, then go back to the copied main item, find the new copy of the correct conformer, find the actor in that conformer that had the child figure, then change the new child figure's parent to the actor of the new copy of the conformer. Oh, and mind, testing figure children of figures revealed an interesting glitch. Copying pretty much anything else automatically makes the CurrentActor() the new copy of the selected item. Copying a figure with multiple child figures will make the most recently added child figure the new CurrentActor(). That's temporally, not hierarchically. It doesn't matter where it is in the hierarchy (child of a child of a child vs. direct descendant), the last item given a parent in that hierarchy is what's selected. So finding the new copy of the conformer, and then the right actor on the new conformer, that would probably be involved.

It's totally possible, but I still have lots of testing and interface building to do, and maybe even some functionality to add (like adding randomness or changing spacing on existing arrays). That seems like a lot of work for a very uncommon use case. Or at least I'm guessing it's uncommon. I'm open to being told otherwise.

Just to say, by far most of my time to this point has been spent figuring out and accounting for Poser's idiosyncrasies. For instance, what deletes with a figure (yes to magnets, no to conformers, yes to child props, no to child figures, etc.) Just accounting for lights has meant adding code I'm not entirely happy with because it's so specific to current light type numbering, and needs to be in more than one place. I've put off dealing with deformers (magnets and waves) because they're so particular. They copy and delete with other child items, but they're not valid as primary/selected actors in this first version.

 

[StudioMartillo]

StudioMartillo- I'm not sure what you're trying to show us?

Now what was it? Hmmmm
Oh yeah, now I remember;
You don't need to pre-heat the microwave.

This reminds me of a scenario from my engineering days.
We were at a design review and one of the engineers 'Bob'
was proposing a change to the design
which he was illustrating at the whiteboard.
Most of us could see, intuitively, that it wouldn't work.
Another engineer 'Mike', to put it kindly said;
"Bob, your math is wrong."
So Bob began to fill the whiteboard with high school Algebra proofs.
Because he was wasting our time I interrupted and said;
"Excuse me Bob, but Mike didn't say 'Math is wrong',
he said 'Your math is wrong'"
Bob looked at me puzzled for a moment and then began to explain
Algebra theorems.
Bob was absolutely sure he couldn't be wrong.

 

[kobaltkween]

You're saying I must be doing this wrong because....? Your

Now what was it? Hmmmm
Oh yeah, now I remember;
You don't need to pre-heat the microwave.

This reminds me of a scenario from my engineering days.
We were at a design review and one of the engineers 'Bob'
was proposing a change to the design
which he was illustrating at the whiteboard.
Most of us could see, intuitively, that it wouldn't work.
Another engineer 'Mike', to put it kindly said;
"Bob, your math is wrong."
So Bob began to fill the whiteboard with high school Algebra proofs.
Because he was wasting our time I interrupted and said;
"Excuse me Bob, but Mike didn't say 'Math is wrong',
he said 'Your math is wrong'"
Bob looked at me puzzled for a moment and then began to explain
Algebra theorems.
Bob was absolutely sure he couldn't be wrong.

I feel very much the same way about you. You keep coming up with use cases that have nothing to do with what I'm doing, and at least seeming to make points grounded in a misunderstanding of what Poser instances include (like embedded and linked externalized morphs, as one can see clearly in Poser scene and library files). In Poser, morphs are instance specific, and always have been. Hence the need for MorphManager. But that's just guessing at your reason for demonstrating instances with different morphs and poses, something that's completely irrelevant to this tool. I mean, sure, I could imagine making a tool that made rows upon rows of soldiers have realistic variations. But that's way outside my intended core use case. The tool is for making and managing arrays. You can do what you want with individual instances afterward. This script facilitates building and managing the instances as a group, not prevents or controls customization of individual instances afterward. Including posing, morphing, adding children, changing parentage, or deleting altogether.

To be clear:

• This script is doing exactly what I want it to so far. The bugs I'm squashing have to do with me a) overlooking situations and b) Poser behaving erratically and idiosyncratically when it comes to figures, mainly as children of other actors. Other than that, it's performing pretty awesome. I'm not happy with the problems I'm encountering (none of which have the slightest to do with anything you've demonstrated or talked about), but what's worked in unit and integration testing has been exactly what I want.
• It is doing this with Poser instances, which render in about the same time as single instances. This is not true of arrayed meshes that are exported as one big mesh. Those can crash Poser, as I've observed several times. So I have quantitative, objective proof not only of instancing, but of its efficacy and even necessity in building large, complex scenes with repeating elements. But even if I didn't have any proof at all, all those highly accomplished vendors like Jack Tomalin, Stonemason, Faveral, Danie & Maforno, and others who have been using instancing in their products for years are highly unlikely to be wrong or even frivolous for doing so.
• Whether or not anyone else would want this script is somewhat moot. I'd love it if this were useful in general, and I'll definitely promote it and submit it here if they'll take it. I really do hope that it's useful to others. But _I_ need this script to build the architectural scenes I want. I'm in the middle of a project where I'll probably have more than 100 instances to manage _in Poser_, and my goal is to make a pair of tools to facilitate that. If I try, as you once suggested, to manage even one set of those instances in Blender alone, then export them as one big mesh into Poser, well, Blender can't handle that mesh and it's more powerful than Poser.
• I am not the first person to make this kind of tool for Poser. From what I've seen, the specific features will be unique, but the core principle is the same as at least two popular products, one of which is gone because the creator, Semidieu, left the community. I think that demonstrates at least something of a demand. I know it demonstrates that my goal is possible. Also, as I've noted, top architecture and scenery creators often use arrays (as in regularly spaced or placed items) of instances in their work. I'd really love to make it easier for them to do that in Poser, because lots of people are complaining that they aren't seeing any new scenery for Poser.

If you have something to add that takes the above facts into account, then please, by all means say it clearly. Otherwise, well, your points will have nothing at all to do with my work. No matter how sure you are that you couldn't be wrong, just like Bob.

 

[phdubrov]

About render-time materialization in SuperFly:
Disclaimer: I know nothing about internal Poser memory management or Firefly memory management.

Experiment 1:
I made 10x10 array of columns from the Indigites product from Daz via SendInTheClones Pro. The column has external geometry.
Scene size is about 700000 polys.
Exported it as one obj.
Rendered both versions.
Result:
Array - rendering memory 313Mb, time 28.34s
Object - rendering memory 304Mb, time 28.46s

Experiment 2:
Ciasson tree from Nothern Soul, ~120k polys, all mats are set to diffuse white, no maps.
Duplicated via Duplicate comand, distributed by hands.
10 trees - 368Mb, 45s
20 trees - 724Mb, 155s
30 trees - 1080Mb, 185s

Obj export of 30 trees - file ~ 960 Mb, Poser hangs on import.

Conclusion: while Poser probably uses instances internally, SuperFly uses full materialization of the instances, not the proxies (=instances in Iray).

 

[StudioMartillo]

An experiment to determine Poser's memory use can also be conducted, as described below.
The prop (Spruce Tree 12) by Designfera uses external geometry.
All of the resources required by the prop are totalled, then the memory in use by the app is recorded,
first with one Spruce12, then with two, and then with 3.

Designfera Spruce Tree 12 Prop assest data sizes
Prop 57.30 KB
Obj 15,286 KB
dfBark 725 KB
dfBarkbump 620 KB
dfLeaf01 421 KB
dfLeaf01-alpha 499 KB
dfLeaf01b 421 KB
dfLeaf01b-alpha 290 KB
Total 18,319.3 KB
in MB 18.32 MB

Poser App Memory usage
1 Spruce12 in scene 285.90 MB
2 Spruce12 in scene 363.20 MB
3 Spruce12 in scene 432.90 MB

Difference of 1 to 2 77.30 MB
Difference of 2 to 3 69.70 MB

As you can see, for each 18.32 MB prop duplicated in the scene, the memory use increases by an average of 73.5 MB,
with a difference of 7.6 MB between the first duplicate and the second duplicate.
And the memory use per prop is 4 times the data size of the prop.

 

[StudioMartillo]

The same experiment can be conducted to determine Lightwave Layout Memory usage for Instancing.
Same Prop;
Designfera Spruce 12 with the same display type;
Texture shading of main prop and all instances.
All instances are displayed.

One Spruce12 in scene: 285.4 MB
with one Instance added: 287.5 MB (now two trees are displayed)
with two Instances added: 287.5 MB (now three trees are displayed)
with twenty Instances added: 287.5 MB (etc.)
with two hundred Instances added: 287.5 MB

As you can see, the memory cost of instancing, with the same prop is 2.1 MB no matter how many instances are generated.
This is only about 10% of the total of the asset's data sizes.

 

[StudioMartillo]

You're saying I must be doing this wrong because....?

No, that is not what I'm saying.
You have stated:
"To be explicit and clear for anyone who comes across this conversation, Poser supports instancing,
just like any instancing tool in any 3D app creates and controls. Cloning generates mesh. Instancing
does not. No matter how many instances of a prop or figure you put in a Poser scene, they all just
point to one mesh."

There is an easy way to test this using the Scene.NumGeometries() method.
As an experiment I placed a simple prop, SWAM's Charmed for Mavka Crystal_Ball in a scene.
This prop has external geometry.
Started the Python Shell and entered:
scn = poser.Scene()
nmGeoms=scn.NumGeometries()
nmGeoms~
2

Then duplicate the Crystal_Ball.
In the Python Shell entered:
nmGeoms2=scn.NumGeometries()
nmGeoms2~
3

It is very clear that duplicating the Crystal_Ball has created another geometry.

Repeat the duplication and the result is:
nmGeoms3=scn.NumGeometries()
nmGeoms3~
4

You can iterate through one of the geometries and reassign vertices to other groups,
without affecting any of the others.
Another very clear indication that each of the actors has a whole and separate geometry.

The Deltas in a morph reference the vertices in each actor's geometry by indexing.
The renders that I posted are showing that each of the duplicate actors can be independently morphed,
which wouldn't be possible if they all 'pointed to' the same geometry.

 

[phdubrov]

But all other reasons still stay:
Poser definitely has much easier time with many smaller objects than with one big.
It just not saves memory.

 

[StudioMartillo]

Here are some screen shots that show how Instancing works.

From Monitor One​

From Monitor Two

 

[StudioMartillo]

But all other reasons still stay:
Poser definitely has much easier time with many smaller objects than with one big.
It just not saves memory.

Very true. There also seems to be a problem with very large scene files,
where everything seems to be OK as you build the scene.
But when the scene is saved, and reloaded, Poser will hang and your work is lost.
Know your limits! It's still a really fun program.