Python Question: Object dimensions

[kobaltkween]

Now that you describe an example, I remember why sometimes I use multi-prop assemblies.
That is so all the parts don't have to be in the scene. Like the door could be there or not, just an opening in the wall.
What I do is lock the origin and maybe certain translations so that when it gets parented to the frame it's right where it should be.

That's great for generic geometry made to work with or without a door, but I think most architecture and vehicle work is more specific, which is why it's mostly figures.

In Lightwave, instancing doesn't add any geometry. You could make a thousand instances of a piece of geometry and only the single piece is using memory in the scene. Lightwave layout just renders it repeatedly wherever it's supposed to appear. 'Course that uses memory anyway, but the instances are all the same, you know, materials and all. I think maybe that's what Ultra-Scatter does but haven't looked at it.

I'm sorry I wasn't clear. Yes, the first is true of Poser. That's why Aslan Court is many pieces and not one. But it's not as if the instances are linked in any way. Transform one, change its materials (not material zones), and it's the only one you've changed. Blender has a concept like this (linked duplicates), but I don't know anything else well enough to make an analogy.

What I am doing is creating a tool to make managing multiple instances of one or more props, figures, and lights easier. First in creating multiples, second in managing materials among multiples, and third in deleting multiples (and children). After that I'd like to get it to edit the multiples. Of course, this whole thing rests on selecting a "base" prop or figure. For instance, in your example of a door parented to a wall, I'm assuming you'll select the wall if you want to work with multiple walls with doors, not the door. I did start off having an automatic figuring out of the "base" object in a hierarchy tree (the one where the parent was the Universe), but I want to be able to make things with parents repeat (say things on a wall or a floor) without repeating the parent.

Do you think that's an OK limitation? Or do you think people would find needing to select the main/base parent item difficult? Mind, it doesn't matter what part of a figure you select. Just that the selected figure is the one you want to work with, not its parent.

I also don't have a solution for arrays of arrays. I _think_ I should be able to figure it out once I get through all this, but I'll have to see.

I don't recall that Python has a Geometry library. Maybe I just never found it but I write my own for things like finding the distance between two points in 3d space given two tuples(x,y,z) and returning a float. That's pretty basic, but you might want to find the volume of a given 'poser geom' and then you would use iteration and integration after aligning the prop to it's exact centers and working with quadrants.
I take the approach of starting by making the lowest level functions, like math stuff, and the building up to higher level functions that call the low level ones, so as I develop stuff a great deal of it is re-usable for other projects. Saves time and work in the future and makes the higher level functions easier to understand.

So... I'm very sure that Python has a 3D Geometry library, because that's just one of those things that programmers do and Python is really popular. That said, it's pretty likely to allow for building 3D apps, not Poser addons. Working with tuples like you're describing is trivial math, so no one would make a library for something as specific and easy as subtracting one tuple from another.

So on the one hand, yes, I've built a method in my class to go through vertices and find a bounding box. That math is _way_ easy. And maybe I'll end up putting that method in some sort of generic class at some point. On the other, I don't know if some other usage would need exactly the same methods. Right now, for instance, I'm mainly concerned with issues specific to this particular use, such as a) needing to loop through each child figure or prop, b) ignoring irrelevant actors like the CenterOfMass and lights, and c) converting all of this to the units relevant to the user. Which is my present concern.

As of my most recent testing, setting values has automatically been in PNU. But I have more than once set values and had them be in the units I was using (meters). I've ascertained that the units for the Poser Geometry and Vertex methods is in PNU. I need to be sure that transformations set by script are always in PNU, and not a generic setting that changes when you change units. That is to say, I need to know that actor.Parameter("xTran").SetValue(0.1) is always 0.1 PNU, and never 0.1 meters, feet, or inches.

Can anyone confirm that? Also, does anyone have a definitive conversion number for PNU to meters by internal Poser standards? I have a number that basically works to about the 5th or so decimal place, but if someone has something more precise, I'd love to use that instead.

 

[StudioMartillo]

I think we have a bit of a semantics problem in this conversation.
The term 'instance' as it's used in Lightwave means other appearances of the very same thing.
So when you change that one thing, all 'instances' are changed also, because it really is that one thing.
Kind of like seeing something in a hall of mirrors. An instance is not a clone.
Other apps that do 'instancing' are just like Lightwave Layout in that multiples only really happen at render time. Be it preview or final.
Ok, hope that's cleared up.
The thing about math is just as you say. Very simple funcs that would probably not be in a library.
I try to think how any piece of what I make has some general use. I explained previously why.
I've been doing modeling since AutoCAD 3. About 1986-87, so in those 30 years I've developed some concepts of how to save effort by making things re-useable, or modular in construction. That includes code. To have your own library of useful things that occur in your work is a good way to enhance productivity.
The distance between two points in 3D space by the way, is found from the square root of the sums of the squares of the absolute deltas of each coordinate, x, y and z. Only one line of code but still a bit more than subtraction.

As for units and dimensions, oh here we go again....
Poser geometry is obj geometry. Without exception. According to the specifications of obj, the values are 1 based and are 'dimensionless'. One based relates pretty well to metric, which is a real world dimension.
Units mean nothing. This is a hard concept for most people to grasp, so in the Poser environment it's possible to set 'display units' to help out people who can't let go of 'real world'.
But it's not is it? It all virtual.
Probably 99% of what you will work with is just those obj numbers. Like when you get the geom for an actor that has one,
and iterate through it to find the vertices for each poly. Just avoid anything that returns 'display units' and you're good.
In another post you mentioned enhancing the array capabilities in Blender. (?)
Creating arrays in the modeling tool would most likely be making clones. In Lightwave Modeler that's what happens,
and each of the clones will have all the properties of the original including it's UV mapping.
In either a radial or matrix array offsets can be included so it's possible to get a lot of effects, like spirals and such.
Don't know if that's just what you mean though.

 

[kobaltkween]

I think we have a bit of a semantics problem in this conversation.
The term 'instance' as it's used in Lightwave means other appearances of the very same thing.
So when you change that one thing, all 'instances' are changed also, because it really is that one thing.
Kind of like seeing something in a hall of mirrors. An instance is not a clone.
Other apps that do 'instancing' are just like Lightwave Layout in that multiples only really happen at render time. Be it preview or final.
Ok, hope that's cleared up.

I guess you could think of it that way. But multiple instances only "happen" at render time the way one instance appearing happens at render time. You have object information, and you have information about that instance (position, scale, rotation, etc.). Making an instance by hand or with, say, a particle system that doesn't show all of its instances in preview, doesn't change the information, or make one type happen at render time and the other at another time. The information the software has about the scene is still object and all of its instance information.

I think you might be making assumptions about the data an "appearance" includes. While you obviously assume that an "appearance" it includes position, and maybe scale and rotation, you also seem to assume that material information must be mesh specific. But that's unnecessarily limiting the instance properties.

So yes, if you change the mesh of one instance, they all change. And they all have the same material zones, same vertex colors, same UVs, etc.. But the shaders or materials applied to those zones, they can be "appearance" specific. Or they might not be. It depends on your system, and what kind of "appearance" specific data it includes. In Blender, materials are the same throughout the entire world, totally independent of objects and meshes at all. In Poser, each instance has its own material settings, just like it has its own position, rotation, and scale settings. And in both Poser and Blender, each instance can have its own subdivision level. Blender can't manage that with automatically created instances, but if you create instances by hand, each one can have its own modifiers. But regardless of whether you're using particles, other shortcuts, or duplicating by hand to make instances, they're still all instances of a single mesh.

Control among instances is independent of whether the software supports instances or not. While Poser very explicitly uses instances through use of externalized geometry files (I'm not sure it can instance items without it), it does not have any built-in instance management tools. But lots of people have built on Poser's instancing to control groups of instances. For example, Semidieu's Eco for TerraDome2 or Poseworks' Particles 3. I'm hoping to make my tool manage instances much the same way Blender's array modifier does, but with scaling and rotating as options.

The thing about math is just as you say. Very simple funcs that would probably not be in a library.
I try to think how any piece of what I make has some general use. I explained previously why.
I've been doing modeling since AutoCAD 3. About 1986-87, so in those 30 years I've developed some concepts of how to save effort by making things re-useable, or modular in construction. That includes code. To have your own library of useful things that occur in your work is a good way to enhance productivity.
The distance between two points in 3D space by the way, is found from the square root of the sums of the squares of the absolute deltas of each coordinate, x, y and z. Only one line of code but still a bit more than subtraction.

Yes, the distance would work that way if you were dealing with distance as a single vector rather than in its components. But so far I'm not seeing a reason to do that. I won't be surprised if I need that in the future, but right now, what I want is separate x, y, and z calculations.

It's really too bad that Poser doesn't have a concept of local x, y, and z the way Blender does.

Yeah, I can definitely understand how useful you've found making your own custom libraries if you've been consistently doing the same thing. Most unfortunately, I've done the complete opposite. I've got tons of different kinds of libraries (Python, PHP, JS, HTML/CSS, 3D objects, presets, etc.) that I don't use and never have. At the time they I thought would be useful. I found them fun and educational to make. Most I used a tiny bit. But I never continued on the path I thought I would, so they've mostly gone unused. I'm finally learning from my mistakes and see where things take me first.

My most useful library has been my materials, and I developed those after beginning to make clothes. Before making clothes, I wouldn't have considered a Velvet/Satin and Velvet/Satin/Lace shader absolutely essential as a basic tool. As it is, that's probably the most common shaders I've used in my products.

As for units and dimensions, oh here we go again....
Poser geometry is obj geometry. Without exception. According to the specifications of obj, the values are 1 based and are 'dimensionless'. One based relates pretty well to metric, which is a real world dimension.
Units mean nothing. This is a hard concept for most people to grasp, so in the Poser environment it's possible to set 'display units' to help out people who can't let go of 'real world'.
But it's not is it? It all virtual.
Probably 99% of what you will work with is just those obj numbers. Like when you get the geom for an actor that has one,
and iterate through it to find the vertices for each poly. Just avoid anything that returns 'display units' and you're good.

I get the "unitless" nature of single meshes. It's not at all hard to understand.

But I'm manipulating multiple items in a larger scene. If I want knife blades and handles with the right length compared to chair depths, shoe heel heights, pen sizes, and necklace link sizes, I need all of those to work off of one single scale. Given multiple items, ratios count. More to the point, those ratios often have real world values. If you make jewelry, there are specific measurement standards. If you make stairs, they have specific measurement standards. Same goes for floor heights, knife measurements, chair and table dimensions, etc. And the best and easiest way to make sure your props have realistic proportions is to use real world units.

There's a reason Bagginsbill's signature says what units he works in, and it's not PNU. If you, for instance, use displacement and set the value to 0.01, it's a huge difference whether that 0.01 is in meters, centimeters, feet, or inches. More to the point, if you want it to be realistic, you should have some real world equivalency for it. A cracked and damaged plaster wall that varies by about 1 cm is realistic. Maybe even up to 2.5cm works. But it varying by 10 to 20 cm isn't realistic. Even 5 cm would be pushing it. If you can't figure out the difference between 1cm and 5cm in a sort of unitless scaling system, then your material isn't going to work properly. And if you want to leave room for that displacement and not have poke-through or overlap, it's necessary to know how much room to give it.

I finally found a place in the documentation where they say the relationship between PNU and real world units. It's in the Poser Python documentation, in the section on materials, as an explanation about units and displacement and bump. For some totally unapparent reason, 1PNU = 8.6 feet or 2.62128 meters.

So yes, I do need to give people the ability to set spacing/offset in real world units. Since I don't seem to have a way to get what units they're using without trying to read Poser's preferences file (which is protected by Windows), I'll probably use meters by default and eventually allow switching. I've found metric much easier to build in (despite being an American), and I'd have to choose between feet and inches if using Imperial units.

In another post you mentioned enhancing the array capabilities in Blender. (?)
Creating arrays in the modeling tool would most likely be making clones. In Lightwave Modeler that's what happens,
and each of the clones will have all the properties of the original including it's UV mapping.
In either a radial or matrix array offsets can be included so it's possible to get a lot of effects, like spirals and such.
Don't know if that's just what you mean though.

OK. So in Blender, there's modifiers, which act on the mesh, and scripts, which do pretty much whatever the hell you want them to because the Blender API is very thorough. The array modifier does "clone" the mesh, but modifiers are apparently one of the few things you _can't_ change with addons, so the issue of clones vs. instances is somewhat moot. Either I edit and compile my own version of Blender with a new array modifier (pretty involved) or I just make an addon that creates and controls instances. I'm pretty sure the latter is _much_ simpler. But getting to the "clones" vs. "instances" issue, because modifiers generate mesh while instances just add new instance data, generating instances is _much_ more efficient.

I've made a piece of architecture with significant detail and therefore tens of thousands of poly per piece. It needs 16 multiples to make a circular wall, then has 3 stories. Building the angular array is mildly annoying, IMHO, but not a big deal. The big deal is that my interface slows to a crawl with 48 subdivided multiples using the array modifier. As instances (using dupliverts, for example), they work great together. Using two array modifiers slows my plain solid shaded preview to a crawl.

Since I've searched and haven't found a Blender tool to create or manage instance arrays, nor any array tool to that has scale and rotation controls, I think my best bet is to make my own tool.

What I'm finding most complex and annoying is the fact that Poser has lots of ways of making a group of items and no coherent notion of how those items behave with one another. For example:

• Conformed figures: They copy with their targets, but don't delete with them. I've accounted for a selected figure having conformers with their own conformers, but not a child having conformers. If, say, you've got something conformed to the DragonBraid, which is then conformed to Dawn, you can delete the whole shebang. But if you've got the braid parented to Dawn's head and the braid has conformers, or if you've parented Dawn to a prop and want to work with the prop, well, I'm just not accounting for that now. Let me know if you want me to take the trouble.
• Cameras: I'm ignoring them altogether due to their specialized behavior. Most of the parented cameras seem to appear once in the scene, but get parented and positioned to whatever figure is selected. Also, I can't think of a use for an array of cameras. If someone thinks of one, please let me know.
• Magnets: they also copy with their targets, but don't delete with props. They do delete with figures. They also have a strange hierarchy ( Actor > Base > Deformer, Actor > Zone). I'm recording bases for deleting, while ignoring zones and deformers since they delete with the base, and deleting will throw errors if they no longer exist.
• Lights: These need special care because they don't delete with figures. Also, I'm defining light "instances" as lights that have the same name and type. Please let me know if you can think of why this might be a problem, or if you have a better idea for how a group of lights might be defined.
• Right now, my intention is to only allow props, figures, and lights to be the basis of an array "item" (includes all the children and conformers of the base actor or figure). As usual, deformers and cameras will copy with their parents, but if your selection is a camera or part of a deformer, you'll be asked to select something else. I can imagine a use for arrays of deformers, but since pretty much no one seems to use them and magnets have a weird structure (two siblings and one child), I don't think they're worth the trouble. But I'm definitely open to being convinced that they are.

In addition to having the tree building and conformer methods written and tested, I've written duplication, renaming, translation and scaling methods. So for the logic/backend, now I just have to write out a rotation method that will work whether or not someone sets the center of rotation. I'm pausing to consider how best to allow that to be changed. After that, I need to write methods that allow to either automatically build an arc or a line. Which shouldn't be a problem since it's basically automatically generating values that should already be working (rotation, rotation center, translation, etc.). I've had and used the rotation/arc equations for a while, and the line should be even easier. So hopefully I'll be working on the interface soon.

 

[StudioMartillo]

Well, while you'd like to think that I'm 'assuming' this and that so 'obviously', it seems more like you're obviously assuming that I'm assuming.
Only you've got stuck somewhere.
What I try to point out is the nature of working in Lightwave.
Clones, and arrays are distinctly different from instancing.
But this apparently isn't going to sink in.
I was just using the analogy of 'appearances' to try to clear it up.
Oh, well.

As for material properties, Lightwave's Node editor has this real cool node called 'Instance Info' that tells the renderer which of the instances it is rendering, so any combination of nodes can be applied through the 'Gradient' node, to the instances. So long as you put enough keys in the gradient node. Very cool because each of the instances can look different.

It's too bad that the poser scene object doesn't have a method to return the display units it's set for.
Because if you want to support this, and the user is thinking in inches, and you just choose meters by default then all those huge differences that are lurking in the shadows are going to jump right out and bite you.
You should present a widget to ask the user for display units at the start.

At least you found where Poser's declaration of unit relations is.
But as I've said, almost all of the methods are working on the geometry numbers, and what a user sees is just calculated for the interace widgets.

So you can test this. Set the display units for PNU.
Use some simple geometry, like a primitive, or whatever, and move it one unit using the text input next to the parameter dial.
Then change the units to whatever, test them all.
Deselect and then reselect the actor, and the display will change to show you the value for that unit.

Ok, then with the units set to meters, then feet, etc use the simple python window to get the actor from the scene, and then set it's xTran, yTran and so on, and then look at what that does to the position in the scene. One display unit at a time.
Then save your scene, and open the scene file in a general code editor and find the actor by name.
Find the parameters section for each of the translations and go to the line that begins with
k 0 , and the next value is the internal value of the translation.
Doing this you can convince yourself that display units has no effect on the methods unless the method specifically states it takes or returns some other unit.
Display units are only for display. Just a comfort for people who can't think in OBJ.
But if you can get a handle on it you are way ahead, without the confusion of real world relations. You clearly have not been able to free your mind from this.

Poser is not going to be used to manufacture any actual physical thing for real world use.
It is a fantasy world that has it's own fantasy scale and a lot of what is found for sale as Poser props and figures varies radically.

Take a look at how Ken does his birds. Very smart.
He has a generalized scale and then provides presets for the many species which make them a size that is compatable with other popular figures.
Not many things you get make any sense at all.

Overall, what you are doing is pretty much modeling functions.
If you do ALL of the things you listed then it could be useful.
Only I wouldn't look to Poser for those functions, and other people who would think of doing those kinds of things might look instead to Blender.

 

[kobaltkween]

Well, while you'd like to think that I'm 'assuming' this and that so 'obviously', it seems more like you're obviously assuming that I'm assuming.
Only you've got stuck somewhere.
What I try to point out is the nature of working in Lightwave.
Clones, and arrays are distinctly different from instancing.
But this apparently isn't going to sink in.
I was just using the analogy of 'appearances' to try to clear it up.
Oh, well.

As for material properties, Lightwave's Node editor has this real cool node called 'Instance Info' that tells the renderer which of the instances it is rendering, so any combination of nodes can be applied through the 'Gradient' node, to the instances. So long as you put enough keys in the gradient node. Very cool because each of the instances can look different.

It's too bad that the poser scene object doesn't have a method to return the display units it's set for.
Because if you want to support this, and the user is thinking in inches, and you just choose meters by default then all those huge differences that are lurking in the shadows are going to jump right out and bite you.
You should present a widget to ask the user for display units at the start.

At least you found where Poser's declaration of unit relations is.
But as I've said, almost all of the methods are working on the geometry numbers, and what a user sees is just calculated for the interace widgets.

So you can test this. Set the display units for PNU.
Use some simple geometry, like a primitive, or whatever, and move it one unit using the text input next to the parameter dial.
Then change the units to whatever, test them all.
Deselect and then reselect the actor, and the display will change to show you the value for that unit.

Ok, then with the units set to meters, then feet, etc use the simple python window to get the actor from the scene, and then set it's xTran, yTran and so on, and then look at what that does to the position in the scene. One display unit at a time.
Then save your scene, and open the scene file in a general code editor and find the actor by name.
Find the parameters section for each of the translations and go to the line that begins with
k 0 , and the next value is the internal value of the translation.
Doing this you can convince yourself that display units has no effect on the methods unless the method specifically states it takes or returns some other unit.
Display units are only for display. Just a comfort for people who can't think in OBJ.
But if you can get a handle on it you are way ahead, without the confusion of real world relations. You clearly have not been able to free your mind from this.

Poser is not going to be used to manufacture any actual physical thing for real world use.
It is a fantasy world that has it's own fantasy scale and a lot of what is found for sale as Poser props and figures varies radically.

Take a look at how Ken does his birds. Very smart.
He has a generalized scale and then provides presets for the many species which make them a size that is compatable with other popular figures.
Not many things you get make any sense at all.

Overall, what you are doing is pretty much modeling functions.
If you do ALL of the things you listed then it could be useful.
Only I wouldn't look to Poser for those functions, and other people who would think of doing those kinds of things might look instead to Blender.

Well, it's clear we're both frustrated. But I do appreciate you sharing your experience. Just so you know, I understood the difference between clones and instances perfectly from the start.

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 (in almost all cases). If you look in the scene file, you can see for yourself that there is only information about how to display the instance, not mesh data. The only time you'll see mesh data in a Poser file or preset is if it uses embedded geometry, which is discouraged precisely because it means that mesh data will be recreated with each duplicate and weigh down the scene.

It's also why you'd want to take the time to externalize your geometry if you're working with your own models.

Yeah, changing materials using instance information is cool. If you notice, I already described how to do that in Blender. Unfortunately, it's a poor substitute for having instance specific materials for human(oid) figures, and those are Poser's primary purpose. So I can't really fault its programmers for designing materials to work the way they do. While it's inconvenient to have to manage scenery materials across instances, it would have been hell trying to make different characters out of multiple Posette instances that all shared the same materials per material zone.

Differences in units would bite me regardless of what unit I chose if I didn't label it. If someone like Bagginsbill is working in inches (as he explicitly does), and I give him an unlabeled interface, he's going to assume it's in inches like everything else. He'll tear into me just as hard whether I choose PNU or meters for my interface without labeling them.

Just to be clear, I don't care about units in my logic. That's all variables, no numbers. I just wanted to make sure Poser Python wasn't operating based on user choice, and was instead acting consistently. I actually had the Poser Python methods _twice_ operate in the units I had selected (as in multiple times during two separate sessions of Poser, using the Python shell to give a single command). No clue why that happened, but it did. I haven't seen that happen again, so I'm counting on Poser Python methods to consistently work in PNU, not variable user selected units. But because I saw it and double, triple, and quadruple checked it each time it happened, I wanted to make sure that I wasn't being lazy and ignoring a complication.

Since no one has mentioned a problem, all my model logic depends on Poser Python consistently operating in degrees and PNU. Everything you've said so far supports my perception that I must have seen some sort of weird fluke of a bug or something.

Just to be clear (again, pardon), I'm aware of how the interface works in terms of converting units for display. I've mucked in Poser files for much more than a decade now (that's why I'm _very_ familiar with Poser instances and their associated data), so I know how Poser presets store information. My goal is to make my interface consistent with the rest of Poser's UI. Array offset values should be the same units as your displacement and positions, or it's going to be a PITA. I really did expect there to be a method and some codes I could use to check for chosen units.

As it is, I've built a way to pull units from the preferences (yay!), but I don't trust it as much as I would specific API methods. The conversion factor is one line in the preferences file, and the unit labels are another. If I want to double check that the labels correctly match the factors, I'd have to do a whole bunch of testing that right now seems unwieldy. And would leave the script vulnerable to a future change in official PNU to real world ratios (they haven't changed it since P6 came out more than a decade ago, but still, you never know). But now it's vulnerable to the labeling system changing. It's something I'd only have to worry about between versions, but still. I wish I could just use something like poser.GetUnitPrefs() or some such, and not have to hard code so much. I know it makes my code a bit brittle, but it's the best solution I can find so far.

If you're more comfortable and satisfied eyeballing and scaling props and figures to fit what you think looks right depending on what figure you're using, that's truly great. More power to you, and to each their own . But I already found modeling with that method problematic due to its imprecision, not because I was unclear on the arbitrary nature of choosing a native scale in a 3D app. I started modeling using PNU in Poser and ignoring real world conversion, and progressed to a more consistent standard a while ago. Going back would be a regression for me.

Setting my own scale wouldn't matter if I just worked on single scene projects with no outside content. But because I use content across projects and other people's content, I find consistent and specific scales and units key to realism and quality.

I don't need to "free my mind," though I understand if that's how you think of scaling standards. For me, it's about making models with consistent real world proportions and measurements. If someone wants to scale them after the fact, that works fine.

This is scene management, not modeling, though the two do overlap. While instances are the norm in Poser, it doesn't have any built in instance generation or management tools. Or any other scene management tools, for that matter. It doesn't even have multiple item selection. This tool will (hopefully) generate and manage instances of whole hierarchies of props and figures. Which you can only do in Blender (or Lightwave, or whatever) if you stay in that app (and, as I mentioned, there's not actually a tool to do this in Blender). You can't generate Poser instances from Blender, and Poser instances are not only hugely useful, a lot of very popular products depend on them.

I just used my tool to duplicate (40+) columns in a row in less than a minute. It took longer when I had subdiv on the preview, but turning it off for previewing cut duplication time in half, while of course not affecting the render subdiv. It would be nice to control that actor property via Python, but I'm not currently finding a way. They rendered just as fast as one column, though it did take a bit longer on the Superfly scene prep stage. That would not have been the case if those columns were a single mesh imported from Blender. That probably would have taken _ages_ to render.

Do you have Aslan Court? If so, load up the full scene. You'll see 16 instances of about 5 different figures. If Tomalin made that in Poser (which he probably didn't, he probably made it in DS, which has instance management tools _and_ multiple item selection), he would have had to convert those 5 items into Poser figures from his modeler of choice (Max), then for each one, duplicate it, then position it. That means he would have had to do that 75 times. If he found his materials had a problem during testing, he would have had to make the change to his materials, save a preset for the new material, then apply that new material collection 15 times, or maybe even apply a single material 75 times. If he found that he wanted to change the model a little, and therefore needed to change each instance's position a little, he would have had to go to each one and change its position by hand.

If I, as someone who owns Aslan Court, want to use it, I have to perform similar tasks. If I want to make all the lights into emitters to light my scene, I have to change each and every light material by hand. If I want to get rid of parts of the scene, again, I have to do that deleting by hand.

My goal for this tool is to make all of those tasks a menu choice and a few clicks. Want to build a 100 ft long wall out of a piece of wall you modeled yourself? Want to change that wall's material from concrete to marble? Want to put some stone lanterns from your runtime in a row on that wall? Want to light those lanterns? Want to put a row of baskets full of arrows along its base, with each arrow as a separate prop? I'm trying to make that whole process a matter of a couple of minutes of unique actions, rather than an hour or so of repetitive actions.

Ideally, I'll be able to sell this plugin when it's done, tested, and approved. But I personally need it so I can convert the scene I'm working on from Blender to Poser without having to copy and position 100+ instances by hand (one piece is 48 instances, a railing piece that's 50+, then there's at least 4 that are 16 instances each, etc.). I personally need it so I can have 4 props parented to each other and manage them as one item. I personally want it so I can get use out of a whole bunch of scenery I own that I avoid because it's such a PITA to do anything with all those instances of walls and windows and columns. And I personally want it so I can make scenes out of simple props I own or ones I make.

I'll also want a version in Blender just so I can make and manage orderly instances, especially radially. As I've said, Blender's array tool operates on the mesh, not generates instances. I could use particles, dupliverts, or duplifaces, but that's kind of using a hammer on screws. I know how to to make those tools give me the results I want, but it forces me to do stuff that's inconvenient, like make additional meshes and match their faces to exactly where I want things placed. I've had a couple of people in the Blender community tell me that it would be a useful plugin, but really, I just feel stupid making a bunch of duplicates and rotating them by hand when I know how to program in Python, Blender's API language.

So maybe you're completely right, and no one else who uses Poser minds building multi-instance scenes like Tomalin's Paltea by making and positioning 50 or more instances. And no one else who owns things like P.I.C.K., or any of the many sci fi or fantasy scene building kits, finds it tedious to try to work with them in a tool that supports instances but not instance management. I saw them stay at the top of store lists for ages, yet rarely see them used in galleries, but there could be tons of reasons for that. I'm _very_ sure that most people are just more patient and quicker than I am when it comes to building a scene in Poser. I follow many artists I'm in absolute awe of when it comes to building large and/or busy scenes with multiple instances of several items, while visually complex scenes have always been my kryptonite. And maybe no one else wants a simple material manager to copy a material to other zones on the same object and to copy material collections to other instances. There's certainly a few heavy duty material managing apps for Poser out there, and just because I mostly find they crash too often (I blame Poser, not the plugins) and are more complex than my basic material needs (which is mostly copying and pasting materials as one task rather than several) doesn't mean anyone else is looking for that kind of simple control. It is perfectly possible that no one else will be interested in this plugin at all.

But this tool will be well worth my time if I don't ever have to duplicate and position by hand the 100 or so instances I'll need to bring my current scene into Poser. And that's before I add furnishings, plants, and other items I have planned for the future. If it lets me build and test my materials on all my 48 wall/window pieces at once, I'll be a happy camper. And if at some point I get _really_ good and manage to figure out how to put instances on a surface, I'll be absolutely _ecstatic_ to have something that lets me manage all the grass instances in the courtyard I'm working on as if they were 1 piece. That alone would let me make lots of props I own _much_ more realistic. And make it easier for me to build natural scenes in Poser.

But first I have to wrestle this relative translation equation into submission. I've got the whole geometric progression from i = 1 to n scale issue down, I just have to a get the center point position worked in. I have an equation that _should_ be correct, that seems to give me the correct simplified equation when the center point is at 0 and 1, but it's not working. I've got an error somewhere, but I don't see it yet.

Once I get relative translation working with scaling, I'll have the fun of testing rotation, which includes rotation about a random point. Then I'll start making the builder interface (I have it designed). And I'll probably add a remove array from the delete interface before that. Right now it's just doing generic children and sibling deletes, and it would be much more convenient if it would "undo" an array when a main array actor or figure is selected. I might want to set some custom data for that just to make things easier.

Lots to do!

 

[kobaltkween]

Yay! It wasn't the equation. I just got used to my handwritten notes, and forgot parentheses on some division for the center point. Scaling works perfectly now. Yay!

 

[phdubrov]

Glad to hear it.

A bit of comment and thoughts.
Main:
I'm still not convicted that Poser uses real instances/proxies, i.e. that objects share geometry not only on a disk but in the memory too. Especially in a render memory, especially in SF memory. Will try some experimentation. And if it's a real instances without pre-render materialization how it's not selling point???

A bit on Poser scene management and management tools (just to have it formalized somewhere):
What is/were available (not a full list I suppose, only what I know):

Semidieu (Shaderworks) scripts (NAN): context-sensitive, made for Terradome2 and Modular Living lines. Latter has universal snap and align tools.

Netherworks:
Scene Toy allows multiple selections and probably should allow material management on this selections with right plugin. But no open API to write such plugin.
MATWriter allows kind of multi-actors material management (Transfer Material plugin) but only one matzone at once.

DraagonStorm SendClonesPro: not very usable interface (I hate sliders! when it's the only options to input numbers), allows not-editable scattering/distribution, treats all object with the same geometry as instances. This bug/feature allow to use it in the cases such as Aslan Court - clone null and you have the option to apply materials (mc6 or pz3) to any actor in the scene. Same geometry objects will be treated as instances, no matter how they were added to the scene.

And EzMat (not for Poser11) allows partial multi-actor material management for its own materials.

 

[StudioMartillo]

I use Python scripting in Poser to duplicate materials by adding a 'data prop' to the scene.
The data prop is pre-made and resides in a working directory within the runtime.
It's a tool.
You can put 'custom data' in a prop and so this data prop will only have that in it.
So what I do in the script is make dictionary data structures for the material nodes and then 'climb'
the tree (I hope you see what I mean, don't want to describe it in detail) collecting the input values
from the nodes of the source item. Figure or prop.
With me so far?
Then I write lines of custom data from the dictionary entries in the very same format they have in the dictionary.
Python is very good about this. It does NOT need to be 'printed'. It will treat the custom data literally so to speak.
Then to put it in the other 'copy' items I just read it back from the custom data in the 'data prop' into fresh dictionaries
climbing the trees of each and writing the input data.
It might seem unnecessary, but it's more robust because I destroy the dictionaries as I go so Poser doesn't have to manage
memory for them.
As many know, that is a weak point for Poser, and why it's so often flakey.
But it has no problem keeping the prop stored however complex it gets.
So it get through all this without crashing.
And lastly delete the custom data prop.
Also, for the same reason I do not create classes.
I just don't trust Poser to manage the memory for them and then I don't have to remember to destroy the instances when
I'm done with them.
It gets to be as tedious as duplicating props in a scene.
'Course you only have to do it once and it's re-usable.
But really, in the context of poser is a scripting environment,
and the script really is not a 'plug-in' and not amenable to app style programming.

Now here is a sample array problem for you:
I have made a hexagonal tile. Oriented with two of the parallel side in the x axis.
I want to make a mosaic of these tiles that is 8 tiles in y and 6 tiles in x.
There can be no open space between them, and it should be possible to distribute texture across them so they can work
as mosaics do to complete a graphic design.

 

[phdubrov]

Err... any reasons to avoid temp file with the material?

 

[StudioMartillo]

Avoid? That's just what it is.

 

[phdubrov]

Why do not save temp material file with Poser API and load it to all other objects?

 

[StudioMartillo]

Well if there has been a folder made for temp materials that the script has the path to OK.
Only if not do you make a new folder? And then where? Make the whole path like;
runtime:materials:dubrov:tempstuff ?
Do I want to make changes to users Runtime? No not really.
If I make the python script an asset and have a directory path all set to include that in my runtimeython or however it is,
like it's packaged and ready for distribution, then I can put my little data prop tool in with it and the script already knows
where it is so there's no need for widgets to find places in the runtime or choose a directory or even create a directory.
Elegance - form fits function - simplicity make a most robust utility.

A data prop can be used to hold any kind of Python data structures - as is.
So it can have helper parts for special constructions, or whatever you come up with.
I use them for lots of things.

 

[StudioMartillo]

For a utility that can work on many different objects you don't really know what mats and all it will find so you best keep it lean 'cause some of these crazy artists build up nodes like maniacs.

 

[phdubrov]

Well if there has been a folder made for temp materials that the script has the path to OK.

poser.TempLocation()

 

[StudioMartillo]

Defined as what?

 

[phdubrov]

TempLocation
Explanation
Get the Poser temporary files directory.
Arguments
None
Syntax
<String> TempLocation()
Always writable from Poser. Default to subfolder in system temp.

 

[StudioMartillo]

Oh, good. So you get that path, and concatenate it with a filename for the set and use it with Actor.SaveMaterialSet()
It must be OK to give that method a full path or you probably wouldn't be saying this.
Or does the SaveMaterialSet default to the temp location with a filename only?
In which case you don't need to call the .TempLocation method anyway.
Well, that's good for bulk transfer of whole sets or selected Materials. Very easy and simple.
Only if you make a copy of an Actor you copy everything no?
Now why do we want these Material sets anyway?
I do the data prop thing when I want to manipulate the nodes.
'Cause there are mat sets that have been created by some crazy tool that puts in everything in the warehouse,
compatible or not. You've probably seen some. So I rip them down to basics for a redo.
Or just use certain parts of the nodes I want in common with a set of actors. In parts of the mats.
I did some things where I just passed around the filled dictionaries but they had a tendency to crash.
So when I used the data prop, they quit crashing.

 

[phdubrov]

Now why do we want these Material sets anyway?

In the context of the topic - apply to the array of the instances. In the most straightforward way.

Node manipulation is a different kettle of fish.

By the way, the array in question probably would need a data prop - as an array info keeper and group parent.

 

[kobaltkween]

Glad to hear it.

A bit of comment and thoughts.
Main:
I'm still not convicted that Poser uses real instances/proxies, i.e. that objects share geometry not only on a disk but in the memory too. Especially in a render memory, especially in SF memory. Will try some experimentation. And if it's a real instances without pre-render materialization how it's not selling point???

I'm not exactly sure what you mean by "pre-render materialization," but I can tell you, yes, it's definitely one geometry in memory. Maybe you're not as mean to your hardware and sofware as I am, and haven't tried pushing a bunch of instances from a modeler into Poser, but I have. I've crashed Poser with all the polys in an object, only to have to use Poser instances and lots more scene building work to get things to work.

That it saves resources is the whole reason that brokerages required external geometry when they started. Because it saved memory and could render easier. And it's not a selling point because it's a feature that's now 20 years old or so. It's how Poser has worked since having a Geometries folder. Which is at least P4 (that's where I started), and I'm guessing goes back to the beginning and the very first figures. The geometry references are right there in the library presets. My guess is that if they didn't make a fuss about it back then, it was because it seemed dead obvious what with the folder of externalized geometry.

A bit on Poser scene management and management tools (just to have it formalized somewhere):
What is/were available (not a full list I suppose, only what I know):

Semidieu (Shaderworks) scripts (NAN): context-sensitive, made for Terradome2 and Modular Living lines. Latter has universal snap and align tools.

Netherworks:
Scene Toy allows multiple selections and probably should allow material management on this selections with right plugin. But no open API to write such plugin.
MATWriter allows kind of multi-actors material management (Transfer Material plugin) but only one matzone at once.

DraagonStorm SendClonesPro: not very usable interface (I hate sliders! when it's the only options to input numbers), allows not-editable scattering/distribution, treats all object with the same geometry as instances. This bug/feature allow to use it in the cases such as Aslan Court - clone null and you have the option to apply materials (mc6 or pz3) to any actor in the scene. Same geometry objects will be treated as instances, no matter how they were added to the scene.

And EzMat (not for Poser11) allows partial multi-actor material management for its own materials.

Ooo, awesome list! Yeah, there's a whole lot of great 3rd party scene management tools out there.

Unfortunately, from what I hear, Semidieu left the community when RDNA closed. I probably would have bought Eco for Terradome2 by now if it were available. That said, I'm focused on content agnostic tools, so I'm hoping that makes a difference. I do have the older version of his Advanced Material Manager, which is really powerful and brilliant but it crashes a lot because it recreates the whole Material Room. All I _really_ need it to do is copy materials. I like the additional stuff it does, but I could get by on just copying to zones and objects.

To be honest, Netherworks has so many plugins that I haven't been able to keep track of them. He's a wiz. I'll take a look at MATWriter's features. That said, I'll definitely be adding material features to the Array Manager, regardless.

You know, EZMat seemed really powerful, but it was complicated enough I never took the time to really figure it out. Snarlygribbly is awesome, though. I spent some time looking the EZSkin3 code (he open sourced it). Very cool.

All objects with the same geometry are technically instances, but I assume by instances you mean part of the distribution? Interesting, I hadn't really thought of that aspect. So this is what I've built so far: arrays that have their own particular parents (a grouping object or the item's parent, the choice being up to you), naming system, and custom data. A delete interface that lets you delete an item and its children, just its children, all instances and their children, and undo an array. That last option deletes only the elements of the array (children of the array "base"), leaves the original item, gets rid of the array naming, and if necessary deletes the grouping base. I haven't thought much about array editing yet, and to be honest, if it gives me many problems, I won't do it. After all, it would essentially have to perform an array undo, then perform the new array build to allow for changes in count. And array build will have a manual and an automatic, with the latter letting you build arcs or lines of content by setting degree or length, spacing, and axis.

It doesn't scatter items or automatically make matrices like Send In the Clones. I could add a an "add randomization" tool to work on either a built array, siblings, or all instances if you think it would be helpful. I don't want to add randomizing elements to the array building screens because I really want to keep this simple. I don't want any one screen to overwhelm people.

If you want arrays of arrays, it should be possible by selecting the array parent and running the array builder again. I haven't tested that yet, though. I think the big thing to consider would be how it handles naming right now. Oh, and child conformers. Right now I'm grabbing conformers of main items, and children of those conformers, but not of conformers of children. So if you have, say, Dawn in an outfit with a hair figure parented (not conformed) to her, and that hair has a conformer, the conformer will copy, but it won't get deleted with everything. Which reminds me. I need to come up with a way to create feedback if there are failures. And maybe catch exceptions. I know better, but I haven't written out formal testing scenarios yet. I've been testing a lot of different things, mostly to figure out how Poser works. It's so random. For instance, magnets copy with props, but don't delete with them. Why? Lights will copy with figures, but not delete with them like everything else does. Because figures are so specific, they will copy with what they're conformed or parented to, but they won't delete with them the way just about any other children will. If you delete a part of a deformer, all the pieces will go away, even though they aren't one piece and aren't even all in one hierarchy.

OK, that should be the next move. I'll write out some test scenarios, then create the manual building interface.

 

[kobaltkween]

I use Python scripting in Poser to duplicate materials by adding a 'data prop' to the scene.
The data prop is pre-made and resides in a working directory within the runtime.
It's a tool.
You can put 'custom data' in a prop and so this data prop will only have that in it.
So what I do in the script is make dictionary data structures for the material nodes and then 'climb'
the tree (I hope you see what I mean, don't want to describe it in detail) collecting the input values
from the nodes of the source item. Figure or prop.
With me so far?
Then I write lines of custom data from the dictionary entries in the very same format they have in the dictionary.
Python is very good about this. It does NOT need to be 'printed'. It will treat the custom data literally so to speak.
Then to put it in the other 'copy' items I just read it back from the custom data in the 'data prop' into fresh dictionaries
climbing the trees of each and writing the input data.
It might seem unnecessary, but it's more robust because I destroy the dictionaries as I go so Poser doesn't have to manage
memory for them.
As many know, that is a weak point for Poser, and why it's so often flakey.
But it has no problem keeping the prop stored however complex it gets.
So it get through all this without crashing.
And lastly delete the custom data prop.
Also, for the same reason I do not create classes.
I just don't trust Poser to manage the memory for them and then I don't have to remember to destroy the instances when
I'm done with them.
It gets to be as tedious as duplicating props in a scene.
'Course you only have to do it once and it's re-usable.
But really, in the context of poser is a scripting environment,
and the script really is not a 'plug-in' and not amenable to app style programming.

Now here is a sample array problem for you:
I have made a hexagonal tile. Oriented with two of the parallel side in the x axis.
I want to make a mosaic of these tiles that is 8 tiles in y and 6 tiles in x.
There can be no open space between them, and it should be possible to distribute texture across them so they can work
as mosaics do to complete a graphic design.

Wow. I've been hard on Poser, and it seems brittle in terms of Python (I can get Poser to crash pretty easy just by asking it to pull up the shell or do something simple when my tasks have gotten messy), but I've never had memory issues with Python data handling. I mean, I'd expect to have an issue if I were messing around with or generating a huge mesh (which is why I was hoping to avoid going through the geometry to get bounding boxes, but the methods don't work like the documentation says it should), or messing with tons of morph data (my loaded V4 was 220 MB) but not with any of the material work I've done. I've certainly never come close to taxing my machine with my scripts. Not using Matmatic, or doing node manipulation on the fly.

The Python crashes I've had have really obviously been some sort of uncaught failure or exception, and mostly when my machine wasn't being taxed at all.

That said, I'm guessing that it must be a joke, but you know there's a memory leak method?
LeakMemory
Explanation
Leak n bytes of memory
Arguments
None
Syntax
LeakMemory({<IntType> memory_size})
I can't imagine the scenario where you'd want to deliberately leak memory? I mean, maybe testing, but really? Seems weird to me.

Yeah, you can write to pretty much anywhere you want, if you want. And it would be pretty easy to serialize your dictionaries as JSON and read it back into a dictionary when you wanted to. But it sounds like you've got some pretty particular and userful stuff going on with your prop and everything.

In terms of hexagons as a mosaic that takes projected textures... again this is just for scene building, not modeling. So it definitely doesn't support UV mapping. If you have something as simple as hexagons, you can probably work with lots of instances in your modeler, export it to Poser, and not have Poser choke. That said, if you're talking about a set of hexagons that have already been mapped the way you want and need to tile a group of them (or for some reason you have some really high polygon hexagons), well, this is why it can be useful to work to exact and consistent scales. You can figure out object relative or real world tiling settings in your modeling app and put them in. Blender lets you see edge measurements as an option, so I'm assuming other apps have a similar feature. Of course, honeycomb patterns have particular math that could be handled with a script rather than by hand (Blender has a honeycomb primitive, in fact), but that's outside the uses of this tool.

So I guess the short answer is that you can use this tool build arrays with any spacing you like, but you'll have to do your own calculations for fitted edges that aren't simple bounding box issues.