Python Question: Object dimensions

[kobaltkween]

Hey all! Does anyone know how to find out the height, width, etc. of an actor? I'd be fine with the answer having to go through geometry or the mesh somehow. I just want to be able to get dimensions as well as position.

 

[phdubrov]

To get the real dimensions the only way is to iterate through all points of the geometry AFAIK to know min and max for every axis.
You need code or algorithm?
With or without children?

 

[kobaltkween]

Ugh, ugh, ugh! Sorry, thank you. I do deeply appreciate the reply. I was just _really_ hoping to avoid that answer.

I'm making an array manager (for sale, but I'm going to need it to put together the model I'm working on). I figured that it would be good to automate either fitting an arc in degrees around an axis or length along one axis. So you're very generous, but I can't ask you to freely give code to a commercial venture.

That said, should I even pursue it? Don't get me wrong, I think it would be good practice to write that kind of algorithm, and try to make it work as fast as possible. I never really thought of it before, but geometry is just data, and if I want to practice messing with lots of data points, that's not a bad idea. But it seems really cumbersome for a feature I'm not sure makes a lot of sense usability-wise. What do you think?

 

[phdubrov]

If you are talking about some sort of scattering tool - it will be good option for, say, garden generation. Real sizes will be needed both to avoid intersections (or have only measured intersections, can be useful too for nature scatter) and to plant objects on the plane/mesh/ground. There is no cheap algorithm for this - there are cheap algorithms for sorting, but in this case you can't escape iteration over every point — so algorithm price will be N reads + 3N comparsions + about 1.5N temporal assignments.

And Poser needs good scatter tool. "Send in the clones" is quite limited in comparsion to the UltraScatter for example.

 

[English Bob]

Poser knows a bounding box for each actor in the scene: that's what you see when you set 'box tracking' mode. Unfortunately I can only find SceneBBox() in the Python methods which returns the bounding box of the whole scene, in inches. However you can also toggle individual actors to appear in the scene bounding box or not, using SetIncludeInBoundingBox(). I suppose you could iterate through the scene and toggle off everything except what you wanted to include... It hardly sounds easier than brute-forcing all geometry points, to be honest, but might turn out to be quicker for a high-poly mesh.

 

[kobaltkween]

Poser knows a bounding box for each actor in the scene: that's what you see when you set 'box tracking' mode. Unfortunately I can only find SceneBBox() in the Python methods which returns the bounding box of the whole scene, in inches. However you can also toggle individual actors to appear in the scene bounding box or not, using SetIncludeInBoundingBox(). I suppose you could iterate through the scene and toggle off everything except what you wanted to include... It hardly sounds easier than brute-forcing all geometry points, to be honest, but might turn out to be quicker for a high-poly mesh.

Thanks so very much for the information! I was thinking of box tracking, but I couldn't find any methods to get that information. Apparently I was foolishly looking in Actor, Figure, and Geometry when I should have been looking in the scene. Yes, the list of actors in the scene is probably going to be under 10,000, while vertices in a mesh have a good chance of being over that. Filtering by hierarchy and by type (don't want to include deformers, for instance) makes the script a bit more involved than just going through vertices, but computer has to do less work, which was my concern.

 

[kobaltkween]

If you are talking about some sort of scattering tool - it will be good option for, say, garden generation. Real sizes will be needed both to avoid intersections (or have only measured intersections, can be useful too for nature scatter) and to plant objects on the plane/mesh/ground. There is no cheap algorithm for this - there are cheap algorithms for sorting, but in this case you can't escape iteration over every point — so algorithm price will be N reads + 3N comparsions + about 1.5N temporal assignments.

And Poser needs good scatter tool. "Send in the clones" is quite limited in comparsion to the UltraScatter for example.

So, no, I wasn't thinking about scattering. I was deliberately avoiding it, in fact. To give background, I'm really thinking about trying to essentially do what the Blender array modifier does, but with more radial options, and instancing at a different level. Mimicking particles is a whole other kettle of fish I was deliberately not doing.

In terms of my basic use case, think Aslan Court, not grassy field. I want to make it easy (or at least easier) to assemble and edit something like Aslan Court I. Assembling is useful to me as I start making architecture, but as a user I avoid using sets like that because they're so hard to manage and always need their materials changed, things moved around, stuff made invisible and visible, things deleted, etc.

For this first stage I just want it to

• Make sequential arrangements of props or figures and their children. Manual (specifying count, rotation and rotation center, translation, and scale) is my top priority here. I really want to be able to say, for instance, "Make a full 360 circle of the selected column given 2 m of spacing on either side," or "Make this piece into a 100m wall," but I'm fine with someone managing that by hand if I can't make that work. Mostly because I'm thinking it's most likely to be used by someone who made the original piece would do, so they'd have some notion of its dimensions. Two major assumptions, I know, so let me know if you think they're misguided.
• Keep those multiples parented to either the original or some other chosen parent so they can be moved and managed easily as a set.
• Delete multiple instances of a selected prop or figure (including its children)
• Apply one objects materials (and/or properties) to all the other instances. For instance, if I set up one instance of Aslan Court's columns, I want to easily apply the new materials (and settings) to all other instances without having to make a library item, select each one, and apply the setting, and change the settings.
• Apply one object's selected material to all other instances, or to all items in the scene with the same material name. So, say the the material "Gold" or "Stone" or "concrete" appears throughout a scene, you just have to edit it in one spot.
• Hopefully allow editing of a created array. Assuming I a) know hierarchy or naming, b) know my transformations are constant, editing count and transformation values should be possible.

Based on what's annoyed me about trying to use Aslan Court, I also have some vague ideas about lights, but no coherent notion of workflow. I mean, in Superfly/Cycles, the materials are enough, and you can technically use Ambient_Color and Value in Firefly. And I don't think my code precludes working with lights rather than props or figures, so I'm pretty sure it would be possible to, say, stick a light somewhere, select it, and then say to make x number of radial duplicates around (0, 0, 0). But I'm not sure if I could, for instance, come up with a simple way to create and manage point lights near specific material zones.

And it would be nice to be able to make arrays of arrays (that would make facades a lot easier), but I'm honestly less sure how to do that in a way that's really obvious and easy interface-wise. I don't mind doing heavy coding, but I want the experience to of using it to be really light-weight. Right now I'm thinking of a Scripts menu folder with 4 or 5 options (Auto Create, Manual Create, Edit Array, Manage Materials, Delete), with each having a pretty simple interface.

If I were going to make a scattering tool (and boy have I had need for that before- I'd love a full grassy field that didn't kill Poser with high poly meshes), I'd have to make it separate because of that last bit. Frankly, I'd avoided it because of my experience with using Particles 3 by Poseworks, which I found so complicated and involved that I felt like it wasn't worth using. But it was made to duplicate particles as special effects, not as things scattered on a surface or in the air. If my main target use case is plants on a ground and leaves in the air, it's more complicated than my ordered arrays but possibly still manageable as its own thing. Looking at UltraScatter's listed features, most seem doable, I think. I mean, yeah, projection mapping isn't something I'm going to try to make happen in Poser, and I wouldn't start at map driven controls. But the basic notion of randomized transformations given a max and min seems pretty doable.

That said, in terms of overlap... It's not been my experience that most particle systems handle that. In fact, what I've seen of tutorials on building natural scenes, people don't worry about it at all. Otherwise there would be huge gaps between objects. And I don't see a way to randomly interlock organic shapes like bunches a of grasses and or sprays of flowers. Spacing seems like a good option for, say, bushes or plants in a garden, but even a forest has trees with overlapping branches.

 

[phdubrov]

Err... scattering is not always driven by particles engines... CarbonScatter for example.
Anyway, a bit of 2¢'s :

• you probably would need exact centers, not only objects sizes, so -> bruteforce. But it can be done only once per object and saved inside the object to reuse in the instances
• same goes for the instances - you can mark its as such, also you can mark material groups - mark all the column as marble if you want, when it was divided by the geometry parts
  
• align, distribute, snap, group and parent selected. with and without children! Errr.... how we don't have it already? Or we somehow have it? (I have AMLC, but it's somehow don't work for me.)

 

[kobaltkween]

AFAIK, particle systems are defined as scattering systems for 2 to n objects, where n can be in the millions. So, yes, CarbonScatter is a particle system. In fact, as far as I can tell, it's a standard (but robust) particle system engine with really heavy duty editing and property controls on the instances.

I'm not sure what you mean by exact centers? I'm definitely sure I don't know what AMLC stands for.

The more I think about it, the more I realize I'd have to learn the math behind scattering. Hmmmmm. Oh, I see. If you don't worry about dimension, it's really simple- give a random value within a range. But if you want need d sized holes in that range, each placement gains significant complexity. I guess I'd have to assume my center point was actually my center point, but that's not really a problem. I can move my base item origin to geometric center of the group to begin with (is that what you meant about exact centers?). The real issue is efficiently finding d sized holes. It's sort of like saving a bunch of stuff to a hard drive if you wanted to do it really inefficiently and not as compactly as possible.

Which, incidentally, limits your count. So I can see why systems like this usually don't address intersection. You don't know how many you can fit until you build the scatter, since the number is always going to change based on your randomized spacing. So you can't even tell the user a solid maximum count for an area. And it gets even more complex when you're talking about scattering across a surface, where the available range is more complicated than just ranges along axes. It's just worlds simpler to let the user chose a random count that basically works in terms of intersection and spacing, and just try different random seeds if there's visible intersection.

I think the problem of scatters with dimension is interesting and something that would definitely help me learn more about time complexity and efficiency in programming. With a system for that in place, I can see how to adjust spacing so that it can be positive or negative, absolute or relative. I think I'd _really_ have to learn some particular skills to place things on surfaces. I find the notion terribly daunting, but I know people have done it so I think I might be able to find out how.

What I don't see a path to addressing are the count and branch problems. I don't see how to handle the interface such that it's OK if the person says put 100 objects on a surface that can only take 5. Do I ignore spacing then? Or do I put as many as can fit and leave it at that? How do I communicate either choice to the user in a way that's both clear and empowering rather than limiting? And all of this assumes that it's basically OK to treat the object like a solid. If I'm, say, making a forest, the trees should branches should overlap each other. If I'm placing flowers in a field, I probably want things a lot closer than bounding box distance.

Still, I like the idea of messing with it.

That said, I still have to get through making an array tool.

By its nature, the array should be aligned and distributed. I'm not sure how snapping would work. I notice that some of ockham's scripts have real-time interaction, but I have no clue how he manages that.

That said, I'm realizing the core thing I need to get straight first is just hierarchy and selection. Setting up the original item's parenting (if any), that's in Poser. But I'll have to come up with a way to travel down to the base of a hierarchy and to keep list of all the items in their hierarchy. And since figures are at once like a bunch of props in a hierarchy and their own thing, I have to figure out how to work with a hierarchy that includes figures and props together. Props copy on their own and keep their place in the hierarchy. Figures copy everything in their tree, but automatically go up to UNIVERSE parentage.

Let's say someone made a group of a floor, a wall with a door, and a ceiling. The wall is with the door is a figure (so the door can work). It's parented to the floor (a prop), and the ceiling (another prop) is parented to its ceiling. Everything I do should affect the whole group.

 

[ockham]

Here's a VERY OLD set of scripts that include at least one use of the bounding box technique. The ZIP includes a bunch of stuff, most of which is probably irrelevant.

LoaderLocate.py is the script that places things sort of randomly around the scene, without intersecting. I haven't used it in more recent Poser versions, but it should work. If it doesn't, let me know. If you want to talk more about it, let me know!

I'm no longer writing python stuff for release, so I have no problem at all with permissions or licensing. Just ask.

http://ockhamsbungalow.com/PPP/Loader.zip

 

[StudioMartillo]

This idea makes me think of instancing. Poser probably doesn't support that AFAIK. Would be nice though. I have lots of fun working with Python in Poser. It's so easy. Sounds like it would be a good thing for you to build up a library of math functions, especially geometric ones. Then you could use them to support a lot of other features.
It isn't really necessary to rig a group of props to make it possible to animate parts, like a door. Just put the origin of the door in line with where you want it to hinge, limit the rotations and translations and parent the door to the door frame. Maybe add a master parameter to the parent. I do that sometimes, then sometimes I rig it. Don't even know why. Just whatever I feel like doing at the time.
My thought on this array business is that it's best to design the parts for the purpose. So it all looks just right when made into a composite whatever. Otherwise it's really hard to get the whole to look good. I've messed around with that sort of thing a lot. There's a prop set called 'Mod_Pods' on my website that does things kind of like you describe, which was designed for the purpose.
Actually, come to think of it, with all these hurricanes, the parts were originally designed as hurricane proof housing. Maybe I should add a history of that to my website.
My stuff is all free so you could download it and play with it just to see another idea of array architecture.

 

[English Bob]

Here's a VERY OLD set of scripts...

Thanks! I'll have a play with those in Poser 11 and let you know how it goes. Just from a quick skim through the documentation, I'm interested to see the morph loader which can apply several morph targets all at once. I could use that, and frequently; and I've seen forum posts from others asking for that facility, too.

I use a very simple loader script that I wrote myself to load library items from anywhere that a file selector can reach, and this suite adds some useful features. If I can't make it work as-is I can steal *cough* be inspired by your code.

 

[ockham]

If you want to modernize and release the morph loader, have at it!

 

[kobaltkween]

Here's a VERY OLD set of scripts that include at least one use of the bounding box technique. The ZIP includes a bunch of stuff, most of which is probably irrelevant.

LoaderLocate.py is the script that places things sort of randomly around the scene, without intersecting. I haven't used it in more recent Poser versions, but it should work. If it doesn't, let me know. If you want to talk more about it, let me know!

I'm no longer writing python stuff for release, so I have no problem at all with permissions or licensing. Just ask.

http://ockhamsbungalow.com/PPP/Loader.zip

Wow! Thanks so much! I'm so glad to see you haven't left the Poser community. I've tried some stuff with the bounding box techniques, and it hasn't worked so far (the Scene results are the same no matter what I do to the individual actors), but maybe I missed something. If not... well, again, it's definitely a good practice for me to get to mess with big data.

This idea makes me think of instancing. Poser probably doesn't support that AFAIK. Would be nice though. I have lots of fun working with Python in Poser. It's so easy. Sounds like it would be a good thing for you to build up a library of math functions, especially geometric ones. Then you could use them to support a lot of other features.
It isn't really necessary to rig a group of props to make it possible to animate parts, like a door. Just put the origin of the door in line with where you want it to hinge, limit the rotations and translations and parent the door to the door frame. Maybe add a master parameter to the parent. I do that sometimes, then sometimes I rig it. Don't even know why. Just whatever I feel like doing at the time.
My thought on this array business is that it's best to design the parts for the purpose. So it all looks just right when made into a composite whatever. Otherwise it's really hard to get the whole to look good. I've messed around with that sort of thing a lot. There's a prop set called 'Mod_Pods' on my website that does things kind of like you describe, which was designed for the purpose.
Actually, come to think of it, with all these hurricanes, the parts were originally designed as hurricane proof housing. Maybe I should add a history of that to my website.
My stuff is all free so you could download it and play with it just to see another idea of array architecture.

On instancing: Poser does and doesn't support it. On the one hand, multiple instances loaded by hand or preset are handled efficiently. So if you, say, build a colosseum, it will be much more efficient as a series of repeating parts than as one whole mesh. Hence, for instance, the multiple parts of Aslan Court. That said, Poser doesn't allow multiple selection and has absolutely no tools for handling instances as a group. Even more importantly, as I'm struggling with now, it has no good way of handling hierarchies unless they're under one base figure. If you have a hierarchy of props _or_ have a hierarchy that includes more than one figure (a figure that's a descendant of another figure), then Poser treats each item like it's its own thing, regardless of its parentage. So additional tools are needed to allow you to change multiple instances at once.

On math functions: Maybe I'm missing something, but math functions don't seem difficult or general enough to need a library beyond what already exists for Python. To build features what you need most are ways to select and get information about items. You don't need heavy duty math for that. I did a lot of playing around with shader math using Matmatic, but pretty much no one else does and everyone's happy with their work. I did build a sort of library of equations for shading, but I don't really use it anymore. Superfly/Cycles makes it largely unnecessary. Though I may transfer my Beer's law node group from Blender to Poser so I can do some nice volumetric shading.

On rigging: It depends on how you do it. So if that door is another prop, no you don't have to rig it. But that's a kind of weird way to handle it, and not what most do. Most make the door a part of the wall, and move the center of that part. Which has the same function, but makes the wall (or car, or spaceship, or what have you) a figure. Frankly, most people seem to make their large static props figures, anyway. Almost all of Tomalin's items that I own are figures.

On array items: Oh, definitely! I'm definitely making this as something to be used on items designed for "tiling," so to speak. To give a clear use case, I'm hoping to make it easy to build and edit something like Tomalin's Aslan Court 1, which is made up of dozens of instances of a few items. Or to possibly make it easier to use something like P.I.C.K. I don't want to have to duplicate items by hand to make a whole set. I don't want to have to copy materials by hand to 20 different instances to change the materials. I want to be able to have a door figure, a ceiling prop, a lighting prop, a floor prop and possibly some sort of light (a point light, an area light, etc.) in a hierarchy, and then to be able to manage that hierarchy and its instances as much like a single item as possible. I'm betting there's other people who feel the same way. I figure if I can get it to work for me, there will be others out there who want a copy.

Thanks so much for the offer! I'll definitely take a look at it. I've been looking at videos of Semidieu's Eco for TerraDome2, and I've definitely got some ideas about how to handle scattering. To be honest, the big thing I'm struggling with right now is (annoyingly) selection, so to speak. Basically, the people who designed Poser did so with very limited thinking. First of all, they decided that hierarchies of props were _totally_ different than figures. For what I can see as no apparent reason. Then they decided that people would never have a reason to parent a figure to another figure. Well, that's the best way to handle hair designed to fit any figure.

Well, and I've also been held up by our dog's health. She was having seizure problems most of last week. We'd been able to get her out of bad spots like that before, but by Saturday morning it had gotten so bad that she was having a seizure every few minutes, so frequently she couldn't walk. My husband had to carry her into the vet to put her to sleep. We tried everything we could, and she fought hard her whole life, but it was just too much. We miss her terribly. I haven't been able to get much of anything done since, but I'm trying to get back into coding now.

 

[Miss B]

Well, and I've also been held up by our dog's health. She was having seizure problems most of last week. We'd been able to get her out of bad spots like that before, but by Saturday morning it had gotten so bad that she was having a seizure every few minutes, so frequently she couldn't walk. My husband had to carry her into the vet to put her to sleep. We tried everything we could, and she fought hard her whole life, but it was just too much. We miss her terribly. I haven't been able to get much of anything done since, but I'm trying to get back into coding now.

Ohhhh, sorry to hear about your loss.

 

[kobaltkween]

Thanks! I'll have a play with those in Poser 11 and let you know how it goes. Just from a quick skim through the documentation, I'm interested to see the morph loader which can apply several morph targets all at once. I could use that, and frequently; and I've seen forum posts from others asking for that facility, too.

Oh, and yes, yes, and yes! A morph loader to load a bunch of morphs is one of the things I've been wanting for ages. Then if I can make or find a way to mass export shape keys from Blender, making morph sets will be a _breeze_.

Ohhhh, sorry to hear about your loss.

Thanks so much for your kind words. Even though she lived so much longer than we expected (we always said we'd be lucky if she made it to 5 with her epilepsy problem), it still feels sudden. We'd been through times like that before with her, and she'd always managed to pull back from the brink. She was the most loving dog I ever had. When she wasn't having problems, she was joyous and full of life. It's so hard to deal with the quiet in the house now.

 

[StudioMartillo]

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.

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 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.

 

[phdubrov]

I don't recall that Python has a Geometry library.

geometry-relates stuff like matrixes and vectors are in numpy.linalg and scipy.spatial, scipy.linalg. Numpy included with Poser.

 

[StudioMartillo]

I've looked at that numpy library in the poser directory but it seems easier to me to write my own funcs, like the one stated above.
The docs are obtuse.
scipy? don't know where it is. Not in site packages on my system.
I use PYTHON from the Python27 install that I have and not from Poser because the IDLE out of Python27 works far better than the Poser one. In the Poser idle, anytime it looses focus it's hard to get back.
So this scipy lib is where? In the Poser library? In Python27? Maybe it's better than numpy if I have it. Sounds like Sci-Fi, is it fiction?

 

[phdubrov]

Numpy is a part of a scipy.
SciPy.org — SciPy.org